HTTP

萬維網WWW（World Wide Web）發源於歐洲日內瓦量子物理實驗室CERN，正是WWW技術的出現使得因特網得以超乎想象的速度迅猛發展。這項基於TCP/IP的技術在短短的十年時間內迅速成為已經發展了幾十年的Internet上的規模最大的信息系統，它的成功歸結於它的簡單、實用。在WWW的背後有一系列的協議和標準支持它完成如此宏大的工作，這就是Web協議族，其中就包括HTTP超文本傳輸協議。

在1990年，HTTP就成為WWW的支撐協議。當時由其創始人WWW之父蒂姆·伯納斯·李（Tim Berners-Lee）提出，隨後WWW聯盟（WWW Consortium）成立，組織了IETF（Internet Engineering Task Force）小組進一步完善和發佈HTTP。 ^[1] 

HTTP是應用層協議，同其他應用層協議一樣，是為了實現某一類具體應用的協議，並由某一運行在用户空間的應用程序來實現其功能。HTTP是一種協議規範，這種規範記錄在文檔上，為真正通過HTTP進行通信的HTTP的實現程序。

HTTP是基於B/S架構進行通信的，而HTTP的服務器端實現程序有httpd、nginx等，其客户端的實現程序主要是Web瀏覽器，例如Firefox、Internet Explorer、Google Chrome、Safari、Opera等，此外，客户端的命令行工具還有elink、curl等。Web服務是基於TCP的，因此為了能夠隨時響應客户端的請求，Web服務器需要監聽在80/TCP端口。這樣客户端瀏覽器和Web服務器之間就可以通過HTTP進行通信了。 ^[2] 

0.9協議是適用於各種數據信息的簡潔快速協議，但是遠不能滿足日益發展的各種應用的需要。0.9協議就是一個交換信息的無序協議，僅僅限於文字。由於無法進行內容的協商，在雙發的握手和協議中，並沒有規定雙發的內容是什麼，也就是圖片是無法顯示和處理的。 ^[3] 

到了1.0協議階段，也就是在1982年，Tim Berners-Lee提出了HTTP/1.0。在此後的不斷豐富和發展中，HTTP/1.0成為最重要的面向事務的應用層協議。該協議對每一次請求/響應建立並拆除一次連接。其特點是簡單、易於管理，所以它符合了大家的需要，得到了廣泛的應用。

在1.0協議中，雙方規定了連接方式和連接類型，這已經極大擴展了HTTP的領域，但對於互聯網最重要的速度和效率，並沒有太多的考慮。畢竟，作為協議的制定者，當時也沒有想到HTTP會有那麼快的普及速度。 ^[3] 

關於HTTP1.1協議的具體內容可以參考RFC 2616。 ^[4] 

HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個版本，但這兩個版本所包含的協議規範之龐大，足以讓任何一個有經驗的工程師為之頭疼。網絡協議新版本並不會馬上取代舊版本。實際上，1.0和1.1在之後很長的一段時間內一直並存，這是由於網絡基礎設施更新緩慢所決定的。 ^[5] 

關於HTTP2.0協議的具體內容可以參考RFC 7540。 ^[6] 

HTTP誕生之初主要是應用於WEB端內容獲取，那時候內容還不像現在這樣豐富，排版也沒那麼精美，用户交互的場景幾乎沒有。對於這種簡單的獲取網頁內容的場景，HTTP表現得還算不錯。但隨着互聯網的發展和WEB2.0的誕生，更多的內容開始被展示（更多的圖片文件），排版變得更精美（更多的CSS），更復雜的交互也被引入（更多的JS）。用户打開一個網站首頁所加載的數據總量和請求的個數也在不斷增加。

今天絕大部分的門户網站首頁大小都會超過2M，請求數量可以多達100個。另一個廣泛的應用是在移動互聯網的客户端app，不同性質的app對HTTP的使用差異很大。對於電商類app，加載首頁的請求也可能多達10多個。對於微信這類IM，HTTP請求可能僅限於語音和圖片文件的下載，請求出現的頻率並不算高。

HTTP是基於客户/服務器模式，且面向連接的。典型的HTTP事務處理有如下的過程： ^[7] 

（1）客户與服務器建立連接；

（2）客户向服務器提出請求；

（3）服務器接受請求，並根據請求返回相應的文件作為應答；

（4）客户與服務器關閉連接。

客户與服務器之間的HTTP連接是一種一次性連接，它限制每次連接只處理一個請求，當服務器返回本次請求的應答後便立即關閉連接，下次請求再重新建立連接。這種一次性連接主要考慮到WWW服務器面向的是Internet中成千上萬個用户，且只能提供有限個連接，故服務器不會讓一個連接處於等待狀態，及時地釋放連接可以大大提高服務器的執行效率。 ^[7] 

HTTP是一種無狀態協議，即服務器不保留與客户交易時的任何狀態。這就大大減輕了服務器記憶負擔，從而保持較快的響應速度。HTTP是一種面向對象的協議。允許傳送任意類型的數據對象。它通過數據類型和長度來標識所傳送的數據內容和大小，並允許對數據進行壓縮傳送。當用户在一個HTML文檔中定義了一個超文本鏈後，瀏覽器將通過TCP/IP協議與指定的服務器建立連接。 ^[7] 

HTTP支持持久連接，在HTTP / 0.9和1.0中，連接在單個請求/響應對之後關閉。在HTTP / 1.1中，引入了保持活動機制，其中連接可以重用於多個請求。這樣的持久性連接可以明顯減少請求延遲，因為在發送第一個請求之後，客户端不需要重新協商TCP 3-Way-Handshake連接。另一個積極的副作用是，通常，由於TCP的緩慢啓動機制，連接隨着時間的推移而變得更快。

該協議的1.1版還對HTTP / 1.0進行了帶寬優化改進。例如，HTTP / 1.1引入了分塊傳輸編碼，以允許流傳輸而不是緩衝持久連接上的內容。HTTP流水線進一步減少了延遲時間，允許客户端在等待每個響應之前發送多個請求。協議的另一項附加功能是字節服務，即服務器僅傳輸客户端明確請求的資源部分。

從技術上講是客户在一個特定的TCP端口（端口號一般為80）上打開一個套接字。如果服務器一直在這個周知的端口上傾聽連接，則該連接便會建立起來。然後客户通過該連接發送一個包含請求方法的請求塊。

HTTP規範定義了9種請求方法，每種請求方法規定了客户和服務器之間不同的信息交換方式，常用的請求方法是GET和POST。服務器將根據客户請求完成相應操作，並以應答塊形式返回給客户，最後關閉連接。 ^[7] 

在WWW中，“客户”與“服務器”是一個相對的概念，只存在於一個特定的連接期間，即在某個連接中的客户在另一個連接中可能作為服務器。基於HTTP的客户/服務器模式的信息交換過程，它分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。 ^[6] 

HTTP是基於請求/響應範式的。一個客户機與服務器建立連接後，發送一個請求給服務器，請求方式的格式為，統一資源標識符、協議版本號，後邊是MIME信息包括請求修飾符、客户機信息和可能的內容。服務器接到請求後，給予相應的響應信息，其格式為一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。其實簡單説就是任何服務器除了包括HTML文件以外，還有一個HTTP駐留程序，用於響應用户請求。你的瀏覽器是HTTP客户，向服務器發送請求，當瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程序接收到請求，在進行必要的操作後回送所要求的文件。在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：要傳送的數據；控制信息，即告訴網絡怎樣處理數據包。TCP/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道信息被分成用於傳輸和再重新組合起來的許多小塊。

許多HTTP通訊是由一個用户代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用户代理（UA）和源服務器（O）之間通過一個單獨的連接來完成。

當一個或多箇中介出現在請求/響應鏈中時，情況就變得複雜一些。中介有三種：代理（Proxy）、網關（Gateway）和通道（Tunnel）。一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，並且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一箇中介（例如：防火牆等）或者是中介不能識別消息的內容時，通道經常被使用。

HTTP報文由從客户機到服務器的請求和從服務器到客户機的響應構成。請求報文格式如下： ^[6] 

請求行 － 通用信息頭 － 請求頭 － 實體頭 － 報文主體

請求行以方法字段開始，後面分別是URL字段和HTTP協議版本字段，並以CRLF結尾。SP是分隔符。除了在最後的CRLF序列中CF和LF是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。

應答報文格式如下：

狀態行 － 通用信息頭 － 響應頭 － 實體頭 － 報文主體

狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用户使用。客户機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。

HTTP請求和響應消息包括HTTP版本號，關於HTTP版本號的正確使用和解釋以及關於不同協議轉換的HTTP實現的互操作性存在一些混淆。使用和解釋HTTP版本號可以參考RFC 2145。 ^[8]