http協議和web本質

當你在瀏覽器地址欄敲入“http://www.cnblogs.com/”，然後猛按斷行符號，呈現在你面前的，將是部落格園的首頁了（這真是廢話，你會認為這是理所當然的）。作為一個開發人員，尤其是web開發人員，我想你有必要去瞭解這一系列的處理流程，在這期間，瀏覽器和伺服器到底是如何打交道的？伺服器又是如何處理的？瀏覽器又是如何將網頁顯示給使用者的呢？......

疑惑和細節真是太多了。坦白講，要想徹徹底底的弄清楚以上每個疑惑和處理細節，至少需要十本書的厚度，所謂“底層無極限”嘛，而且不同的web服務 器和伺服器端程式設計語言的實現和處理流程不盡相同（但本質都是相通的）。本文中，我將根據http協議的有關知識，跟大家講解一些web開發的本質。不管你 是從事.NET，還是J2EE或者php開發等等，都離不開這些本質。希望你讀完本文，能有新的收穫和見解。由於本人水平和經驗有限，難免有誤，望讀者見 諒。

 

何為http協議（Hypertext Transfer Protocol，超文字傳輸通訊協定 (HTTP)）？

所謂協議，就是指雙方遵循的規範。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之類的玩意。

 

實戰準備工作：

在監視網路方面，windows平台上有一款叫做Sniffer的優秀軟體，這也是很多“駭客”經常使用的嗅探工具。 在研究http協議時，推薦大家使用一款

叫作httpwatch的工具。（遺憾的是，該工具是收費的。該咋辦就咋辦，你懂的）。安裝完成後，可以在IE瀏覽器的tools中直接開啟（目前也支援firefox）。：

 

 

 

 

 

 

 

點擊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請求訊息和響應訊息，相信你對於http協議已經理解得足夠深刻了。關於http協議的更多具體細節，可以參照http RFC文檔。

大致步驟就是：瀏覽器先向伺服器發送請求，伺服器接收到請求後，做相應的處理，然後封裝好響應報文，再回送給瀏覽器。瀏覽器拿到響應報文後，再通過 瀏覽器引擎去渲染網頁，解析DOM樹，javascript引擎解析並執行指令碼操作，外掛程式去幹外掛程式該乾的事兒...關於瀏覽器渲染、解析的原理，可以參考http://kb.cnblogs.com/page/129756/

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

筆者淺淺的認為，其實瀏覽器就是一種特殊的Client，而B/S架構也是一種特殊的C/S架構。這裡值得一提的是，不同的web伺服器和編程語 言，又是如何接收使用者http請求。如何處理，如何響應的呢？筆者拿熟悉的ASP.NET為例，通過反編譯工具查看原始碼（微軟這傢伙實在封裝的太好了） 從底層進行了剖析，

由於篇幅有限，無法再繼續將asp.net、iis web伺服器的細節及底層實現再做進一步地進行剖析了。因為微軟的asp.net技術體系實在龐大，而且很複雜。有時間筆者會繼續更新系列文章，歡迎讀者繼續關注。

 

 

本文出自http://blog.csdn.net/dinglang_2009，轉載請註明出處。

當你在瀏覽器地址欄敲入“http://www.cnblogs.com/”，然後猛按斷行符號，呈現在你面前的，將是部落格園的首頁了（這真是廢話，你會認為這是理所當然的）。作為一個開發人員，尤其是web開發人員，我想你有必要去瞭解這一系列的處理流程，在這期間，瀏覽器和伺服器到底是如何打交道的？伺服器又是如何處理的？瀏覽器又是如何將網頁顯示給使用者的呢？......

疑惑和細節真是太多了。坦白講，要想徹徹底底的弄清楚以上每個疑惑和處理細節，至少需要十本書的厚度，所謂“底層無極限”嘛，而且不同的web服務 器和伺服器端程式設計語言的實現和處理流程不盡相同（但本質都是相通的）。本文中，我將根據http協議的有關知識，跟大家講解一些web開發的本質。不管你 是從事.NET，還是J2EE或者php開發等等，都離不開這些本質。希望你讀完本文，能有新的收穫和見解。由於本人水平和經驗有限，難免有誤，望讀者見 諒。

 

何為http協議（Hypertext Transfer Protocol，超文字傳輸通訊協定 (HTTP)）？

所謂協議，就是指雙方遵循的規範。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之類的玩意。

 

實戰準備工作：

在監視網路方面，windows平台上有一款叫做Sniffer的優秀軟體，這也是很多“駭客”經常使用的嗅探工具。 在研究http協議時，推薦大家使用一款

叫作httpwatch的工具。（遺憾的是，該工具是收費的。該咋辦就咋辦，你懂的）。安裝完成後，可以在IE瀏覽器的tools中直接開啟（目前也支援firefox）。：

 

 

 

 

 

 

 

點擊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請求訊息和響應訊息，相信你對於http協議已經理解得足夠深刻了。關於http協議的更多具體細節，可以參照http RFC文檔。

大致步驟就是：瀏覽器先向伺服器發送請求，伺服器接收到請求後，做相應的處理，然後封裝好響應報文，再回送給瀏覽器。瀏覽器拿到響應報文後，再通過 瀏覽器引擎去渲染網頁，解析DOM樹，javascript引擎解析並執行指令碼操作，外掛程式去幹外掛程式該乾的事兒...關於瀏覽器渲染、解析的原理，可以參考http://kb.cnblogs.com/page/129756/

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

筆者淺淺的認為，其實瀏覽器就是一種特殊的Client，而B/S架構也是一種特殊的C/S架構。這裡值得一提的是，不同的web伺服器和編程語 言，又是如何接收使用者http請求。如何處理，如何響應的呢？筆者拿熟悉的ASP.NET為例，通過反編譯工具查看原始碼（微軟這傢伙實在封裝的太好了） 從底層進行了剖析，

由於篇幅有限，無法再繼續將asp.net、iis web伺服器的細節及底層實現再做進一步地進行剖析了。因為微軟的asp.net技術體系實在龐大，而且很複雜。有時間筆者會繼續更新系列文章，歡迎讀者繼續關注。

 

 

本文出自http://blog.csdn.net/dinglang_2009，轉載請註明出處。