最近研究了一下關于文件下載的相關內容，覺得還是寫些東西記下來比較好。起初只是想研究研究，但后來發現寫個可重用性比較高的模塊還是很有必要的，我想這也是大多數開發人員的習慣吧。
對于HTTP協議，向服務器請求某個文件時，只要發送類似如下的請求即可：
GET /Path/FileName HTTP/1.0
Host: www.server.com:80
Accept: */*
User-Agent: GeneralDownloadApplication
Connection: close
每行用一個“回車換行”分隔，末尾再追加一個“回車換行”作為整個請求的結束。
第一行中的GET是HTTP協議支持的方法之一，方法名是大小寫敏感的，HTTP協議還支持OPTIONS、HAED、POST、PUT、DELETE、TRACE、CONNECT等方法，而GET和HEAD這兩個方法通常被認為是“安全的”，也就是說任何實現了HTTP協議的服務器程序都會實現這兩個方法。對于文件下載功能，GET足矣。GET后面是一個空格，其后緊跟的是要下載的文件從WEB服務器根開始的絕對路徑。該路徑后又有一個空格，然后是協議名稱及協議版本。
除第一行以外，其余行都是HTTP頭的字段部分。Host字段表示主機名和端口號，如果端口號是默認的80則可以不寫。Accept字段中的*/*表示接收任何類型的數據。User-Agent表示用戶代理，這個字段可有可無，但強烈建議加上，因為它是服務器統計、追蹤以及識別客戶端的依據。Connection字段中的close表示使用非持久連接。
關于HTTP協議更多的細節可以參考RFC2616（HTTP 1.1）。因為我只是想通過HTTP協議實現文件下載，所以也只看了一部分，并沒有看全。
如果服務器成功收到該請求，并且沒有出現任何錯誤，則會返回類似下面的數據：
HTTP/1.0 200 OK
Content-Length: 13057672
Content-Type: application/octet-stream
Last-Modified: Wed, 10 Oct 2005 00:56:34 GMT
Accept-Ranges: bytes
ETag: "2f38a6cac7cec51:160c"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 16 Nov 2005 01:57:54 GMT
Connection: close
不用逐一解釋，很多東西一看幾乎就明白了，只說我們大家都關心內容吧。
第一行是協議名稱及版本號，空格后面會有一個三位數的數字，是HTTP協議的響應狀態碼，200表示成功，OK是對狀態碼的簡短文字描述。狀態碼共有5類：
1xx屬于通知類；
2xx屬于成功類；
3xx屬于重定向類；
4xx屬于客戶端錯誤類；
5xx屬于服務端錯誤類。
對于狀態碼，相信大家對404應該很熟悉，如果向一個服務器請求一個不存在的文件，就會得到該錯誤，通常瀏覽器也會顯示類似“HTTP 404 - 未找到文件”這樣的錯誤。Content-Length字段是一個比較重要的字段，它標明了服務器返回數據的長度，這個長度是不包含HTTP頭長度的。換句話說，我們的請求中并沒有Range字段（后面會說到），表示我們請求的是整個文件，所以Content-Length就是整個文件的大小。其余各字段是一些關于文件和服務器的屬性信息。
這段返回數據同樣是以最后一行的結束標志（回車換行）和一個額外的回車換行作為結束，即“\r\n\r\n”。而“\r\n\r\n”后面緊接的就是文件的內容了，這樣我們就可以找到“\r\n\r\n”，并從它后面的第一個字節開始，源源不斷的讀取，再寫到文件中了。
以上就是通過HTTP協議實現文件下載的全過程。但還不能實現斷點續傳，而實際上斷點續傳的實現非常簡單，只要在請求中加一個Range字段就可以了。
假如一個文件有1000個字節，那么其范圍就是0-999，則：
Range: bytes=500-????? 表示讀取該文件的500-999字節，共500字節。
Range: bytes=500-599?? 表示讀取該文件的500-599字節，共100字節。
Range還有其它幾種寫法，但上面這兩種是最常用的，對于斷點續傳也足矣了。如果HTTP請求中包含Range字段，那么服務器會返回206（Partial Content），同時HTTP頭中也會有一個相應的Content-Range字段，類似下面的格式：
Content-Range: bytes 500-999/1000
Content-Range字段說明服務器返回了文件的某個范圍及文件的總長度。這時Content-Length字段就不是整個文件的大小了，而是對應文件這個范圍的字節數，這一點一定要注意。
一切好像基本上沒有什么問題了，本來我也是這么認為的，但事實并非如此。如果我們請求的文件的URL是類似http://www.server.com/filename.exe這樣的文件，則不會有問題。但是很多軟件下載網站的文件下載鏈接都是通過程序重定向的，比如pchome的ACDSee的HTTP下載地址是：
http://download.pchome.net/php/tdownload2.php?sid=5547&url=/multimedia/viewer/acdc31sr1b051007.exe&svr=1&typ=0
這種地址并沒有直接標識文件的位置，而是通過程序進行了重定向。如果向服務器請求這樣的URL，服務器就會返回302（Moved Temporarily），意思就是需要重定向，同時在HTTP頭中會包含一個Location字段，Location字段的值就是重定向后的目的URL。這時就需要斷開當前的連接，而向這個重定向后的服務器發請求。
???? 好了，原理基本上就是這些了。其實裝個Sniffer好好分析一下，很容易就可以分析出來的。不過NetAnts也幫了我一些忙，它的文件下載日志對開發人員還是很有幫助的。
本文引自：http://hi.baidu.com/chinessnetstone/blog/item/603d20094009468ad0581b23.html