HTTP協議詳細介紹

當你在瀏覽器地址欄敲入「http://www.cnblogs.com/」，而後猛按回車，呈如今你面前的，將是博客園的首頁了（這真是廢話，你會認爲這是理所固然的）。做爲一個開發者，尤爲是web開發人員，我想你有必要去了解這一系列的處理流程，在這期間，瀏覽器和服務器究竟是如何打交道的？服務器又是如何處理的？瀏覽器又是如何將網頁顯示給用戶的呢？......

疑惑和細節真是太多了。坦白講，要想不折不扣的弄清楚以上每一個疑惑和處理細節，至少須要十本書的厚度，所謂「底層無極限」嘛，並且不一樣的web服務 器和服務器端編程語言的實現和處理流程不盡相同（但本質都是相通的）。本文中，我將根據http協議的有關知識，跟你們講解一些web開發的本質。無論你 是從事.NET，仍是J2EE或者php開發等等，都離不開這些本質。但願你讀完本文，能有新的收穫和看法。因爲本人水平和經驗有限，不免有誤，望讀者見 諒。

 

何爲http協議（Hypertext Transfer Protocol，超文本傳輸協議）？

所謂協議，就是指雙方遵循的規範。http協議，就是瀏覽器和服務器之間進行「溝通」的一種規範。咱們在看空間，刷微博...都是在使用http協議，固然，遠遠不止這些應用。

筆者一直據說http是屬於「應用層的協議」，並且是基於TCP/IP協議的。這個不難理解，若是你上大學時候學過「計算機網絡」的課程，就必定知 道OSI七層參考協議（我當時是死記硬背的）。若是你接觸過socket網絡編程，就應該明白TCP和UDP這兩種使用普遍的通訊協議（創建鏈接、三次握 手等等，固然，這不是本文討論的重點）。如圖：

既然TCP/UDP是普遍使用的網絡通訊協議，那爲啥有多出個http協議來呢？

筆者曾本身動手寫過一個簡單的web服務器處理軟件，根據個人推斷（不必定準確）。UDP協議具備不可靠性和不安全性，顯然這很難知足web應用的須要。

而TCP協議是基於鏈接和三次握手的，雖然具備可靠性，但人具備必定的缺陷。但試想一下，普通的C/S架構軟件，頂多上千個Client同時鏈接，而B/S架構的網站，十萬人同時在線也是很日常的事兒。若是十萬個客戶端和服務器一直保持鏈接狀態，那服務器如何知足承載呢？

這就衍生出了http協議。基於TCP的可靠性鏈接。通俗點說，就是在請求以後，服務器端當即關閉鏈接、釋放資源。這樣既保證了資源可用，也吸收了TCP的可靠性的優勢。

正由於這點，因此你們一般說http協議是「無狀態」的，也就是「服務器不知道你客戶端幹了啥」，其實很大程度上是基於性能考慮的。以致於後來有了session之類的玩意。

 

既然TCP/UDP是普遍使用的網絡通訊協議，那爲啥有多出個http協議來呢？

筆者曾本身動手寫過一個簡單的web服務器處理軟件，根據個人推斷（不必定準確）。UDP協議具備不可靠性和不安全性，顯然這很難知足web應用的須要。

而TCP協議是基於鏈接和三次握手的，雖然具備可靠性，但人具備必定的缺陷。但試想一下，普通的C/S架構軟件，頂多上千個Client同時鏈接，而B/S架構的網站，十萬人同時在線也是很日常的事兒。若是十萬個客戶端和服務器一直保持鏈接狀態，那服務器如何知足承載呢？

這就衍生出了http協議。基於TCP的可靠性鏈接。通俗點說，就是在請求以後，服務器端當即關閉鏈接、釋放資源。這樣既保證了資源可用，也吸收了TCP的可靠性的優勢。

正由於這點，因此你們一般說http協議是「無狀態」的，也就是「服務器不知道你客戶端幹了啥」，其實很大程度上是基於性能考慮的。以致於後來有了session之類的玩意。

點擊Record，就能夠開始監視並記錄http消息了。stop、Clear等等按鈕的功能，這裏就不一一介紹了。拿實例來講話，下面就是我記錄訪問main.aspx頁面的時候記錄的，可以清晰的看到http報文消息的詳細信息，如圖：

學習http協議，主要須要瞭解http的請求和響應（固然，還有get、post等請求方式，狀態碼、URI、MIME等）

 

首先看看http請求消息（就是瀏覽器丟給服務器的）：

一個http請求表明客戶端瀏覽器向服務器發送的數據。一個完整的http請求消息，包含一個請求行，若干個消息頭（請求頭），換行，實體內容

請求行：描述客戶端的請求方式、請求資源的名稱、http協議的版本號。 例如： GET/BOOK/JAVA.HTML HTTP/1.1

請求頭（消息頭）包含（客戶機請求的服務器主機名，客戶機的環境信息等）：
Accept：用於告訴服務器，客戶機支持的數據類型  （例如：Accept:text/html,image/*）
Accept-Charset：用於告訴服務器，客戶機採用的編碼格式
Accept-Encoding：用於告訴服務器，客戶機支持的數據壓縮格式
Accept-Language：客戶機語言環境
Host:客戶機經過這個服務器，想訪問的主機名
If-Modified-Since：客戶機經過這個頭告訴服務器，資源的緩存時間
Referer：客戶機經過這個頭告訴服務器，它（客戶端）是從哪一個資源來訪問服務器的（防盜鏈）
User-Agent：客戶機經過這個頭告訴服務器，客戶機的軟件環境（操做系統，瀏覽器版本等）
Cookie：客戶機經過這個頭，將Coockie信息帶給服務器
Connection：告訴服務器，請求完成後，是否保持鏈接
Date：告訴服務器，當前請求的時間

（換行）
實體內容：
就是指瀏覽器端經過http協議發送給服務器的實體數據。例如：name=dylan&id=110
（get請求時，經過url傳給服務器的值。post請求時，經過表單發送給服務器的值）
  
再看看HTTP響應消息（服務器返回給瀏覽器的）：

一個http響應表明服務器端向客戶端回送的數據，它包括：
一個狀態行，若干個消息頭，以及實體內容

響應頭(消息頭)包含:
Location：這個頭配合302狀態嗎，用於告訴客戶端找誰
Server：服務器經過這個頭，告訴瀏覽器服務器的類型
Content-Encoding：告訴瀏覽器，服務器的數據壓縮格式
Content-Length：告訴瀏覽器，回送數據的長度
Content-Type：告訴瀏覽器，回送數據的類型
Last-Modified：告訴瀏覽器當前資源緩存時間
Refresh：告訴瀏覽器，隔多長時間刷新
Content-Disposition：告訴瀏覽器如下載的方式打開數據。例如： context.Response.AddHeader("Content-Disposition","attachment:filename=aa.jpg");                                        context.Response.WriteFile("aa.jpg");
Transfer-Encoding：告訴瀏覽器，傳送數據的編碼格式
ETag：緩存相關的頭（能夠作到實時更新）
Expries：告訴瀏覽器回送的資源緩存多長時間。若是是-1或者0，表示不緩存
Cache-Control：控制瀏覽器不要緩存數據   no-cache
Pragma：控制瀏覽器不要緩存數據          no-cache

Connection：響應完成後，是否斷開鏈接。  close/Keep-Alive
Date：告訴瀏覽器，服務器響應時間

狀態行：  例如：  HTTP/1.1  200 OK   （協議的版本號是1.1  響應狀態碼爲200  響應結果爲 OK）

實體內容（實體頭）：響應包含瀏覽器可以解析的靜態內容，例如：html，純文本，圖片等等信息

理解了以上的http請求消息和響應消息，相信你對於http協議已經理解得足夠深入了。關於http協議的更多具體細節，能夠參照http RFC文檔。

大體步驟就是：瀏覽器先向服務器發送請求，服務器接收到請求後，作相應的處理，而後封裝好響應報文，再回送給瀏覽器。瀏覽器拿到響應報文後，再經過 瀏覽器引擎去渲染網頁，解析DOM樹，javascript引擎解析並執行腳本操做，插件去幹插件該乾的事兒...關於瀏覽器渲染、解析的原理，能夠參考http://kb.cnblogs.com/page/129756/

說白了，所謂web的本質，無非是：請求/處理/響應 ，任何的web服務器，任何的服務端編程語言，都無法脫離這個本質。 而瀏覽器端解析html、圖片等靜態內容，呈現給用戶，腳本引擎執行腳本代碼，完成腳本代碼要作的事兒（例如dom操做，css屬性更改，發送ajax請 求等等）。