http

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

在1990年，HTTP就成為WWW的支撐協議。當時由其創始人WWW之父蒂姆·貝納斯·李（TimBemers—Lee）提出，隨後WWW聯盟（WWW Consortium）成立，組織了IETE（Internet Engineering Task Force）小組進一步完善和發布HTTP協議。

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

HTTP協議是基於C/S架構進行通信的，而HTTP協議的伺服器端實現程序有httpd、nginx等，其客戶端的實現程序主要是Web瀏覽器，例如Firefox、InternetExplorer、Google chrome、Safari、Opera等，此外，客戶端的命令行工具還有elink、crul等。Web服務是基於TCP的，因此為了能夠隨時響應客戶端的請求，Web伺服器需要監聽在80/TCP埠。這客戶端瀏覽器和Web伺服器之間就可以通過HTTP協議進行通信了。

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

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

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

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

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

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

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

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

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

（1）客戶與伺服器建立連接；

（2）客戶向伺服器提出請求；

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

（4）客戶與伺服器關閉連接。

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

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

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

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

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

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

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

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

HTTP報文由從客戶機到伺服器的請求和從伺服器到客戶機的響應構成。請求報文格式如下：

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

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

應答報文格式如下：

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

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

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