【文章內(nèi)容簡介】 器下載原理圖 Fig 21 Server Download principle 第二類 ： P2P(Peer To Peer)下載 ； BT、 EMULE、 VAGAA 都屬于此類 ， 雖然協(xié)議不一樣 ， 但是下載方式都是根據(jù)文件信息 ， 從互聯(lián)網(wǎng)中尋找正在下載該文件的用戶 ， 并從他們那里下載 。 當(dāng)然軟件會尋找用戶 ， 并從多個用戶下載自己沒有的部分 ， 而將自己已下載的而別人沒有的上傳給別人 ， 相對與別 8 人來說 ， 你的上傳就是他的下載了 。 此類軟件就是在浩瀚的互聯(lián)網(wǎng)中尋找已經(jīng)下載或者正在下載的那些文件 ， 所有的下載用戶形成一個連鎖網(wǎng)絡(luò) ， 每個人都從其他人那里獲得 ，同時也給別人上傳 ， 體現(xiàn)了人人平等的關(guān)系 。 由于沒有固定的服務(wù)器 ， 每個人即充當(dāng)客戶端也充當(dāng) 服務(wù)器 ， 人越多下載 速度 越快是這類下載的優(yōu)點 。 圖 22 P2P下載基本原理圖 Fig 22 P2P principle HTTP 協(xié)議簡介 在 TCP/IP 體系結(jié)構(gòu)中 ， HTTP 屬于應(yīng)用層協(xié)議 ， 位于 TCP/IP 協(xié)議的頂層 。 瀏覽 Web時 ， 瀏覽器通過 HTTP 協(xié)議與 Web 服務(wù)器交換信息 。 這些信息（文檔）類型的格式由 MIME定義 。 HTTP 協(xié)議具有以下的特點 ： 1. HTTP 按客戶 /服務(wù)器模式工作 HTTP 支持客戶（一般情況是瀏覽器）與服務(wù)器的通訊 ， 相互傳輸數(shù)據(jù) 。 HTTP 定義的事務(wù)處理由以下四步組成 ： o 客戶與服務(wù)器建立連接 ； o 客戶向服務(wù)器提出請求 ； 9 o 如果請求被接受 ， 則服務(wù)器送回響應(yīng) ， 在響應(yīng)中包括狀態(tài)碼和所需的文件 ； o 客戶與服務(wù)器斷開連接 ； o 一次 HTTP 操作稱為一次事務(wù)（ transaction） 。 2. HTTP 是無狀態(tài)的 也就是說 ， 瀏覽器和服務(wù)器每進行一次 HTTP 操作 ， 就建立一次連接 ， 但任務(wù)結(jié)束就中斷連接 。 3. HTTP 使用元信息作為頭標(biāo) HTTP 對所有事務(wù)都加了 頭標(biāo)（ header） 。 也就是說 ， 在主要數(shù)據(jù)前加上一塊信息 ，稱為 元信息（ metainformation） 。 它使服務(wù)器能夠提供正在傳送數(shù)據(jù)的有關(guān)信息 。例如 ， 傳送對象是哪種類型 ， 是用哪種語言書寫的等 。 從功能上講 ， HTTP 支持四類元信息 ： 一般信息頭標(biāo)、請求頭標(biāo)、響應(yīng)頭標(biāo)和實體頭標(biāo) 。 4. HTTP 支持兩種請求和響應(yīng)格式 HTTP 由不同的兩部分組成 ， 一是從瀏覽器發(fā)往服務(wù)器的請求 ， 二是服務(wù)器對客戶的響應(yīng) 。 HTTP 支持兩種請求和響應(yīng) ， 即簡單請求與完全請求和簡單響應(yīng)與完全響應(yīng) 。 5. HTTP 是基于文本的簡單協(xié)議 。 HTTP的請求 [13] HTTP 的常用請求方法 ： 表 21 HTTP的常用請求方法 Table 21 HTTP request method 方 法 說 明 GET 請求讀取一個 Web頁面 HEAD 請求讀取一個 Web頁面的頭標(biāo) PUT 請求存儲一個 Web頁面 POST 附加到命名資源中 DELETE 刪除 Web頁面 10 LINK 連接兩個已有資源 UNLINK 取消兩個資源之間的已有連接 HTTP 請求的格式如下所示 ： ＜ requestline＞ ＜ headers＞ ＜ blank line＞ [＜ requestbody＞ ] 在 HTTP 請求中 ， 第一行必須是一個請求行（ request line） ， 用來說明請求類型、要訪問的資源以及使用的 HTTP 版本 。 緊接著是一個首部（ header）小節(jié) ， 用來說明服務(wù)器要使用的附加信息 。 在首部之后是一個空行 ， 再此之后可以添加任意的其他數(shù)據(jù) [稱之為主體（ body） ]。 在 HTTP 中 ， 定義了大量的請求類型 ， 不過開 發(fā)人員關(guān)心的只有 GET 請求和 POST 請求 。只要在 Web瀏覽器上輸入一個 URL， 瀏覽器就將基于該 URL向服務(wù)器發(fā)送一個 GET請求 ，以告訴服務(wù)器獲取并返回什么資源 。 對于 的 GET 請求如下所示 ： GET / HTTP/ Host: UserAgent: Mozilla/ (Windows。 U。 Windows NT 。 enUS。 rv:.6) Gecko/20200225 Firefox/ Connection: KeepAlive 請求行的第一部分說明了該請求是 GET 請求 。 該行的第二部分是一個斜杠（ /） ， 用來說明請求的是該域名的根目錄 。 該行的最后一部分說明使用的是 HTTP 版本（另一個可選項是 ） 。 那么請求發(fā)到哪里去呢？這就是第二行的內(nèi)容 。 第 2行是請求的第一個首部 ， HOST。 首部 HOST 將指出請求的目的地 。 結(jié)合 HOST 和上一行中的斜杠（ /） ， 可以通知服務(wù)器請求的是 （ HTTP 才需要使用首部 HOST， 而原來的 版本則不需要使用） 。 第三行中包含的是首部 UserAgent， 服務(wù)器端和客戶 端腳本都能夠訪問它 ， 它是瀏覽器類型檢測邏輯的重要基礎(chǔ) 。 該信息由你使用的瀏覽器來定義（在本例中是 Firefox ） ， 并且在每個請求中將自動發(fā)送 。 最后 11 一行是首部 Connection， 通常將瀏覽器操作設(shè)置為 KeepAlive（當(dāng)然也可以設(shè)置為其他值 ， 但這已經(jīng)超出了本 文 討論的范圍） 。 注意 ， 在最后一個首部之后有一個空行 。 即使不存在請求主體 ， 這個空行也是必需的 。 如果要獲取一個諸如 的 域內(nèi)的頁面 ，那么該請求可能類似于 ： GET /books/ HTTP/ Host: UserAgent: Mozilla/ (Windows。 U。 Windows NT 。 enUS。 rv:.6) Gecko/20200225 Firefox/ Connection: KeepAlive 注意只有第一行的內(nèi)容發(fā)生了變化 ， 它只包含 URL 中 后面的部分 。 要發(fā)送 GET請求的參數(shù) ， 則必須將這些額外的信息附在 URL 本身的后面 。 其格式類似于 ： URL ? name1=value1amp。name2=value2amp。...amp。nameN=valueN 該信息稱之為查詢字符串（ query string） ， 它將會復(fù)制在 HTTP 請求的請求行中 ， 如下所示 ： GET /books/? name1=value1amp。name2=value2amp。...amp。nameN=valueN HTTP/ Host: UserAgent: Mozilla/ (Windows。 U。 Windows NT 。 enUS。 rv:.6) Gecko/20200225 Firefox/ Connection: KeepAlive 另一方面 ， POST 請求在請求主體中為服務(wù)器提供了一些附加的信息 。 通常 ， 當(dāng)填寫一個在線表單并提交它時 ， 這些填入的數(shù)據(jù)將以 POST 請求的方式發(fā)送給服務(wù)器 。 以下就是一個典型的 POST 請求 ： POST / HTTP/ Host: 12 UserAgent: Mozilla/ (Windows。 U。 Windows NT 。 enUS。 rv:.6) Gecko/20200225 Firefox/ ContentType: application/xformurlencoded ContentLength: 40 Connection: KeepAlive name=Professional%20Ajaxamp。publisher=Wiley 從上面可以發(fā)現(xiàn) ， POST 請求和 GET 請求之間有一些區(qū)別 。 首先 ， 請求行開始處的 GET改為了 POST， 以表示不同的請求類型 。 你會發(fā)現(xiàn)首部 Host 和 UserAgent 仍然存在 ， 在后面有兩個新行 。 其中首部 ContentType 說明了請求主體的內(nèi)容是如何編碼的 。 瀏覽器始終以 application/ xform urlencoded 的格式編碼來傳送數(shù)據(jù) ， 這是針對簡單 URL 編碼的 MIME 類型 。 首部 ContentLength 說明了請求主體的字節(jié)數(shù) 。 在首部Connection 后是一個空行 ， 再后面就是請求主 體 。 與大多數(shù)瀏覽器的 POST 請求一樣 ，這是以簡單的 “ 名稱 — 值 ” 對的形式給出的 ， 其中 name 是 Professional Ajax，publisher 是 Wiley。 你可以以同樣的格式來組織 URL 的查詢字符串參數(shù) 。 正如前面所提到的 ， 還有其他的 HTTP 請求類型 ， 它們遵從的基本格式與 GET 請求和 POST請求相同 。 下一步我們來看看服務(wù)器將對 HTTP 請求發(fā)送什么響應(yīng) 。 HTTP的 響應(yīng) 如下所示 ， HTTP 響應(yīng)的格式與請求的格式十分類似 ： ＜ statusline＞ ＜ headers＞ ＜ blank line＞ [＜ responsebody＞ ] 正如你所見 ， 在響應(yīng)中唯一真正的區(qū)別在于第一行中用狀態(tài)信息代替了請求信息 。 狀態(tài)行（ status line）通過提供一個狀態(tài)碼來說明所請求的資源情況 。 以下就是一個 HTTP響應(yīng)的例子 ： HTTP/ 200 OK Date: Sat, 31 Dec 2020 23:59:59 GMT ContentType: text/html； charset=ISO88591 ContentLength: 122 13 ＜ html＞ ＜ head＞ ＜ title＞ Homepage＜ /title＞ ＜ /head＞ ＜ body＞ ＜ ! body goes here ＞ ＜ /body＞ ＜ /html＞ 在本例中 ， 狀態(tài)行給出的 HTTP 狀態(tài)代碼是 200， 以及消息 OK。 狀態(tài)行始終包含的是狀態(tài)碼和相應(yīng)的簡短消息 ， 以避免混亂 。 最常用的狀態(tài)碼有 ： ? 200 (OK): 找到了該資源 ， 并且一切正常 。 ? 304 (NOT MODIFIED): 該資源在上次請求之后沒有任何修改 。 這通常用于瀏覽器的緩存機制 。 ? 401 (UNAUTHORIZED):客戶端無權(quán)訪問該資源 。 這通常會使得瀏覽器要求用戶輸入用戶名和密碼 ， 以登錄到服務(wù)器 。 ? 403 (FORBIDDEN):客戶端未 能獲得授權(quán) 。 這通常是在 401 之后輸入了不正確的用戶名或密碼 。 ? 404 (NOT FOUND):在指定的位置不存在所申請的資源 。 在狀態(tài)行之后是一些首部 。 通常 ， 服務(wù)器會返回一個名為 Date 的首部 ， 用來說明響應(yīng)生成的日期和時間（服務(wù)器通常還會返回一些關(guān)于其自身的信息 ， 盡管并非是必需的） 。接下來的兩個首部大家應(yīng)該熟悉 ， 就是與 POST 請求中一樣的 ContentType 和ContentLength。 在本例中 ， 首部 ContentType 指定了 MIME 類型 HTML（ text/html） ，其編碼類型是 ISO88591（這是針對美國英語資源的編碼標(biāo)準(zhǔn)） 。 響應(yīng)主體所包含的就是所請求資源的 HTML 源文件（盡管還可能包含純文本或其他資源類型的二進制數(shù)據(jù)） 。瀏覽器將把這些數(shù)據(jù)顯示給用戶 。 注意 ， 這里并沒有指明針對該響應(yīng)的請求類型 ， 不過這對于服務(wù)器并不重要 。 客戶端知道每種類型的請求將返回什么類型的數(shù)據(jù) ， 并決定如何使用這些數(shù)據(jù) 。 Java 中的多線程 現(xiàn)在將多線程下載同一個文件的原理講述一下 [3]： 14 首先得到要下載的文件的長度 ， 這是通過 HTTP 的 HEAD 命令得到其長度 。 根據(jù)長度和線程數(shù) ， 確定各線程所下載 的數(shù)據(jù)范圍 。 通過 HTTP 的 Get 命令 ， 這里需要指定 From 和 To. 創(chuàng)建一個文件 ， 這個文件是一個空文件 ， 不需要事先生成與下載文件同樣大小的空文件 。 給每個線程只需要傳遞其打開的文件句柄即可 。 創(chuàng)建各個下載線程 ， 每個線程接受到數(shù)據(jù)后就保存到相應(yīng)的位置上去 。 這里不需要對文件加鎖 ， 因為操作系統(tǒng)一級本身對文件的 I/O 有鎖的 ， 我們的應(yīng)用不用管 ， 而且各個線程所寫的文件位置是不一樣的 ， 每一線程負責(zé)下載和寫一段數(shù)據(jù) 。 每個線程都記錄下來了當(dāng)前已經(jīng)下載到的位置 ， 這樣若有線程出錯了 ， 可以從斷點處繼續(xù)下載 。 等各線程都下 載完各自的數(shù)據(jù)塊后 ， 最后中關(guān)閉這個文件 。 注意 ： 這里的文件打開時一定要以二制打開 ， 否則在調(diào)用 fseek 時將導(dǎo)致位置定位不正確 。 斷點續(xù)傳原理 其實斷點續(xù)傳的原理很簡單 ， 就是在 HTTP 的請求上和一般的下載有所不同而已 。打個比方 ， 瀏覽器請求服務(wù)器上的一個文時 ， 所發(fā)出的請求如下 ： 假設(shè)服務(wù)器域名為 ， 文件名為 。 GET