摘要：當你在瀏覽器地址欄敲入“https://www.yzmcms.com/”，然后猛按回車，呈現在你面前的，將是YzmCMS官方首頁了（這真是廢話...

當你在瀏覽器地址欄敲入“https://www.yzmcms.com/”，然后猛按回車，呈現在你面前的，將是YzmCMS官方首頁了（這真是廢話，你會認為這是理所當然的）。作為一個開發者，尤其是web開發人員，我想你有必要去了解這一系列的處理流程，在這期間，瀏覽器和服務器到底是如何打交道的？服務器又是如何處理的？瀏覽器又是如何將網頁顯示給用戶的呢？......

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

何為http協議（Hypertext Transfer Protocol，超文本傳輸協議）？所謂協議，就是指雙方遵循的規范。http協議，就是瀏覽器和服務器之間進行“溝通”的一種規范。我們在看空間，刷微博...都是在使用http協議，當然，遠遠不止這些應用。

筆者一直聽說http是屬于“應用層的協議”，而且是基于TCP/IP協議的。這個不難理解，如果你上大學時候學過“計算機網絡”的課程，就一定知道OSI七層參考協議（我當時是死記硬背的）。如果你接觸過socket網絡編程，就應該明白TCP和UDP這兩種使用廣泛的通信協議（建立連接、三次握手等等，當然，這不是本文討論的重點）。如圖：

既然TCP/UDP是廣泛使用的網絡通信協議，那為啥有多出個http協議來呢？UDP協議具有不可靠性和不安全性，顯然這很難滿足web應用的需要。

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

這就衍生出了http協議。基于TCP的可靠性連接。通俗點說，就是在請求之后，服務器端立即關閉連接、釋放資源。這樣既保證了資源可用，也吸取了TCP的可靠性的優點。

正因為這點，所以大家通常說http協議是“無狀態”的，也就是“服務器不知道你客戶端干了啥”，其實很大程度上是基于性能考慮的。以至于后來有了session之類的玩意。

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

叫作httpwatch的工具。（遺憾的是，該工具是收費的。該咋辦就咋辦，你懂的）。

其實火狐的firebug也支持簡單的查看服務器的響應信息

學習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響應代表服務器端向客戶端回送的數據，它包括：

一個狀態行，若干個消息頭，以及實體內容

響應頭(消息頭)狀態碼被分為五大類： 

100-199 用于指定客戶端應相應的某些動作。 

200-299 用于表示請求成功。 

300-399 用于已經移動的文件并且常被包含在定位頭信息中指定新的地址信息。 

400-499 用于指出客戶端的錯誤。 

500-599 用于支持服務器錯誤。 

響應頭(消息頭)包含:

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