【深入HTTP協議】
HTTP是（Hyper Text Transfer Protocol）超文字傳輸協議的縮寫.
HTTP的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終釋出了一系列的RFC.
RFC 1945定義了HTTP/1.0版本，其中最著名的就是RFC 2616，RFC 2616定義了今天普遍使用一個版本——HTTP 1.1
------->
HTTP協議（Hyper Text Transfer Protocol）超文字傳輸協議是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議.
它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示（如文字先於圖形）等.
文章目錄
HTTP響應模型
·
HTTP協議永遠都是客戶端發起請求，伺服器回送響應，如下圖：
這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，伺服器將訊息推送給客戶端.
HTTP工作流程
·
一次HTTP操作稱為一個事務，其工作過程可分為四步：
- 首先客戶機與伺服器需要建立連線。只要單擊某個超級連結，HTTP的工作開始.
- 建立連線後，客戶機發送一個請求給伺服器，請求方式的格式為：統一資源識別符號（URL）、協議版本號.
後邊是MIME(宣告文字資訊)資訊包括請求修飾符、客戶機資訊和可能的內容.- 伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的程式碼.
後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容.- 客戶端接收伺服器所返回的資訊並通過瀏覽器顯示在使用者的顯示屏上，然後客戶機與伺服器斷開連線.
·
如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到客戶端，由顯示屏輸出.
對於使用者來說，這些過程是由HTTP自己完成的，使用者只要用滑鼠點選，等待資訊顯示就可以了.
HTTP 請求
HTTP請求包括的內容
·
客戶端連上伺服器後，向伺服器請求某個Web資源，稱之為客戶端向伺服器傳送了一個HTTP請求.
·
一個完整的HTTP請求包括的內容：一個請求行、若干訊息頭、實體內容.
·
如下圖：
HTTP請求細節——請求頭
·
請求行中的GET稱之為請求方式，請求方式有：POST、GET、HEAD、OPTIONS、DELETE、TRACE、PUT，常用的有： GET、 POST
·
使用者如果沒有設定，預設情況下瀏覽器向伺服器傳送的都是GET請求，例如在瀏覽器直接輸地址訪問，點超連結訪問等都是GET，使用者如想把請求方式改為POST，可通過更改表單的提交方式實現.
·
不管POST或GET，都用於向伺服器請求某個WEB資源，這兩種方式的區別主要表現在資料傳遞上：如果請求方式為GET方式，則可以在請求的URL地址後以?的形式帶上交給伺服器的資料，多個數據之間以&進行分隔，例如：GET /mail/1.html?name=abc&password=xyz HTTP/1.1
·
GET請求的特點：在URL地址後附帶的引數是有限制的，其資料容量通常不能超過1K.
·
如果請求方式為POST方式，則可以在請求的實體內容中向伺服器傳送資料，Post方式的特點：傳送的資料量無限制.
HTTP請求細節——訊息頭
·
Accept
宣告瀏覽器支援的資料型別
·
Accept-Charset
宣告瀏覽器支援的字符集
·
Accept-Encoding
宣告瀏覽器支援的壓縮格式
·
Accept-Language
宣告瀏覽器的語言環境
·
Host
宣告瀏覽器要訪問那臺主機
·
If-Modified-since
宣告瀏覽器快取資料的時間
·
Referer
宣告客戶機是哪個頁面來的，用於防盜鏈
·
Connection
瀏覽器通過這個頭告訴伺服器，請求完後是斷開連結還是何持連結
·
X-Requested-with: XMLHttpRequest
代表通過ajax方式進行訪問
·
以上為HTTP請求中的常用訊息頭，如下圖：
HTTP 響應
HTTP響應包括的內容
·
HTTP響應代表伺服器向客戶端回送的資料.
它包括：一個狀態行、若干訊息頭、以及實體內容.
HTTP響應細節——狀態行
·
狀態行格式：
HTTP/1.1 200 OKHTTP版本號 狀態碼 原因敘述<CRLF>
·
狀態碼用於表示伺服器對請求的處理結果.
狀態碼是一個三位的十進位制數，響應狀態碼分為5類.
·
常見的HTTP狀態碼
·
100 客戶端應繼續傳送請求
客戶端應當繼續傳送請求，客戶端應當繼續傳送請求的剩餘部分.
或如果請求已經完成，忽略這個響應.
·
101 轉換協議
在傳送完這個響應的最後空行後，伺服器將會切換到在Upgrade訊息頭中定義的那些協議.
只有在切換到新的協議更有好處的時候才應該採取類似的措施.
·
102 繼續處理
由WebDAV（RFC 2518）擴充套件的狀態碼，代表請求將被繼續執行.
·
200 請求成功
表示這條請求執行成功了.
處理方式：獲得響應的內容，進行處理.
·
201 請求完成
表示這條請求執行完成了
結果是建立了新資源，新建立的資源的URL可在響應的實體中得到.
處理方式在爬蟲中不會遇到.
·
202 請求被接受
請求被接受了，但處理尚未完成.
處理方式：阻塞等待.
·
204 伺服器以實現請求
伺服器已經實現了請求，但未返回新的資訊.
如果客戶端是使用者代理，則無需為此更新自身的文件檢視.
處理方式：丟棄.
·
300
該狀態碼不被HTTP/1.0的應用程式直接使用，只是作為3XX型別迴應的預設解釋，存在多個可用的被請求資源.
處理方式：若程式中能夠處理，則進一步處理；若程式中不能夠處理，則丟棄.
·
301 永久重定向
請求到的資源都會分配一個永久的URL，這樣就可以在將來通過該URL來訪問此資源.
處理方式：重定向到分配的URL，永久重定向.
·
302 臨時重定向
請求到資源在一個不同的URL處臨時儲存.
處理方式：重定向到臨時的URL，臨時重定向.
·
304 請求的資源未更新
請求的資源未更新.
使用的是本地快取檔案（不會發送請求）.
處理方式：丟棄.
·
400 非法請求
處理方式：丟棄.
·
401 未授權
處理方式：丟棄.
·
403 禁止
處理方式：丟棄.
·
404 沒有找到
處理方式：丟棄.
·
500 伺服器內部錯誤
伺服器遇到了一個未曾預料的狀況，導致它無法完成對請求的處理.
一般這個問題會在伺服器端的原始碼出現錯誤時出現.
即伺服器問題，程式碼邏輯有問題.
·
501 伺服器無法識別
伺服器不支援當前請求需要的某個功能.
當伺服器無法識別請求的方法時，將無法支援其對任何資源的請求.
·
502 錯誤閘道器
作為閘道器或代理工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的響應.
HTTP響應細節——常用響應頭
·
Location
伺服器通過這個頭，來告訴瀏覽器跳到哪裡
·
Server
宣告伺服器的型號
·
Content-Encoding
伺服器通過這個頭，告訴瀏覽器，資料的壓縮格式
·
Content-Length
宣告伺服器回送的資料的長度
·
Content-Language
伺服器通過這個頭，告訴瀏覽器語言環境
·
Content-Type
宣告伺服器回送的資料的型別
·
Refresh
伺服器通過這個頭，告訴瀏覽器定時重新整理
·
Content-Disposition
伺服器通過這個頭，告訴瀏覽器以下載方式開啟資料
·
Transfer-Encoding
伺服器通過這個頭，告訴瀏覽器資料是以分塊方式回送的
·
Expires: -1
控制瀏覽器不要快取
·
Cache-Control: no-cache
·
Pragma: no-cache