HTTP

超文本傳輸協定（Hypertext Transfer Protocol，HTTP）是一個簡單的請求-回響協定，它通常運行在TCP之上。它指定了客戶端可能傳送給伺服器什麼樣的訊息以及得到什麼樣的回響。請求和回響訊息的頭以ASCII形式給出；而訊息內容則具有一個類似MIME的格式。超文本傳輸協定是一種用於分散式、協作式和超媒體信息系統的套用層協定，是全球資訊網WWW（World Wide Web）的數據通信的基礎。

基本介紹

• 中文名：超文本傳輸協定
• 外文名：HTTP
• 工作層：套用層
• 基礎：架構在TCP上
• 適用瀏覽器：Firefox、Google Chrome等
• 作用：規定WWW伺服器與瀏覽器之間信息傳遞規範，是二者共同遵守的協定

簡介

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

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

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進行通信了。

發展階段

0.9

1991年，第一個有文檔記載的HTTP正式版本被寫成了一個普通文檔，長度不到700字，這個版本被命名為HTTP/0.9。0.9協定是適用於各種數據信息的簡潔快速協定，但是遠不能滿足日益發展的各種套用的需要。0.9協定就是一個交換信息的無序協定，僅僅限於文字。由於無法進行內容的協商，在雙發的握手和協定中，並沒有規定雙發的內容是什麼，也就是圖片是無法顯示和處理的。

1.0

到了1.0協定階段，也就是在1992年，Tim Berners-Lee編寫了一份新的檔案，以具體說明基本議定書向下一個完整版本的演變。它支持0.9版本的簡單請求方法和包含客戶端HTTP版本的完整GET請求。1996年5月，RFC 1945作為HTTP/1.0的最終修訂版發布，該修訂版在過去4年中一直作為標準HTTP/1.0草案使用，已經被許多Web瀏覽器和Web伺服器使用。在此後的不斷豐富和發展中，HTTP/1.0成為最重要的面向事務的套用層協定。該協定對每一次請求/回響建立並拆除一次連線。其特點是簡單、易於管理，所以它符合了大家的需要，得到了廣泛的套用。

關於HTTP1.0協定的具體內容可以參考RFC 1945。

1.1

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

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

2.0

HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個版本，但這兩個版本所包含的協定規範十分龐大。網路協定新版本並不會馬上取代舊版本。實際上，HTTP 1.0和HTTP1.1在之後很長的一段時間內一直並存，這是由於網路基礎設施更新緩慢所決定的。

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

3.0

HTTP3.0是超文本傳輸協定的第三個主要版本，用於在全球資訊網上交換信息，補充了廣泛部署的HTTP1.1和HTTP2.0。與之前依賴於成熟的TCP的版本不同，HTTP3.0使用QUIC，一種基於UDP的多路傳輸協定。HTTP3.0具有更低的延遲和更快的載入速度。

關於HTTP3.0協定的具體內容可以參考RF 9114。

套用場景

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文檔中定義了一個超文本鏈後，瀏覽器將通過TCP/IP協定與指定的伺服器建立連線。

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。伺服器將根據客戶請求完成相應操作，並以應答塊形式返回給客戶，最後關閉連線。

運作方式

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

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

狀態訊息

1xx:信息

訊息	描述
100 Continue	伺服器僅接收到部分請求，但是一旦伺服器並沒有拒絕該請求，客戶端應該繼續傳送其餘的請求。
101 Switching Protocols	伺服器轉換協定：伺服器將遵從客戶的請求轉換到另外一種協定。

2xx:成功

訊息	描述
200 OK	請求成功（其後是對GET和POST請求的應答文檔。）
201 Created	請求被創建完成，同時新的資源被創建。
202 Accepted	供處理的請求已被接受，但是處理未完成。
203 Non-authoritative Information	文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。
204 No Content	沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205 Reset Content	沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content	客戶傳送了一個帶有Range頭的GET請求，伺服器完成了它。

3xx:重定向

訊息	描述
300 Multiple Choices	多重選擇。連結列表。用戶可以選擇某連結到達目的地。最多允許五個地址。
301 Moved Permanently	所請求的頁面已經轉移至新的url。
302 Found	所請求的頁面已經臨時轉移至新的url。
303 See Other	所請求的頁面可在別的url下被找到。
304 Not Modified	未按預期修改文檔。客戶端有緩衝的文檔並發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。伺服器告訴客戶，原來緩衝的文檔還可以繼續使用。
305 Use Proxy	客戶請求的文檔應該通過Location頭所指明的代理伺服器提取。
306 Unused	此代碼被用於前一版本。目前已不再使用，但是代碼依然被保留。
307 Temporary Redirect	被請求的頁面已經臨時移至新的url。

4xx:客戶端錯誤

訊息	描述
400 Bad Request	伺服器未能理解請求。
401 Unauthorized	被請求的頁面需要用戶名和密碼。
401.1	登錄失敗。
401.2	伺服器配置導致登錄失敗。
401.3	由於ACL對資源的限制而未獲得授權。
401.4	篩選器授權失敗。
401.5	ISAPI/CGI應用程式授權失敗。
401.7	訪問被Web伺服器上的URL授權策略拒絕。這個錯誤代碼為IIS 6.0所專用。
402 Payment Required	此代碼尚無法使用。
403 Forbidden	對被請求頁面的訪問被禁止。
403.1	執行訪問被禁止。
403.2	讀訪問被禁止。
403.3	寫訪問被禁止。
403.4	要求SSL。
403.5	要求SSL 128。
403.6	IP位址被拒絕。
403.7	要求客戶端證書。
403.8	站點訪問被拒絕。
403.9	用戶數過多。
403.10	配置無效。
403.11	密碼更改。
403.12	拒絕訪問映射表。
403.13	客戶端證書被吊銷。
403.14	拒絕目錄列表。
403.15	超出客戶端訪問許可。
403.16	客戶端證書不受信任或無效。
403.17	客戶端證書已過期或尚未生效。
403.18	在當前的應用程式池中不能執行所請求的URL。這個錯誤代碼為IIS 6.0所專用。
403.19	不能為這個應用程式池中的客戶端執行CGI。這個錯誤代碼為IIS 6.0所專用。
403.20	Passport登錄失敗。這個錯誤代碼為IIS 6.0所專用。
404 Not Found	伺服器無法找到被請求的頁面。
404.0	（無）–沒有找到檔案或目錄。
404.1	無法在所請求的連線埠上訪問Web站點。
404.2	Web服務擴展鎖定策略阻止本請求。
404.3	MIME映射策略阻止本請求。
405 Method Not Allowed	請求中指定的方法不被允許。
406 Not Acceptable	伺服器生成的回響無法被客戶端所接受。
407 Proxy Authentication Required	用戶必須首先使用代理伺服器進行驗證，這樣請求才會被處理。
408 Request Timeout	請求超出了伺服器的等待時間。
409 Conflict	由於衝突，請求無法被完成。
410 Gone	被請求的頁面不可用。
411 Length Required	"Content-Length"未被定義。如果無此內容，伺服器不會接受請求。
412 Precondition Failed	請求中的前提條件被伺服器評估為失敗。
413 Request Entity Too Large	由於所請求的實體的太大，伺服器不會接受請求。
414 Request-url Too Long	由於url太長，伺服器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發生這種情況。
415 Unsupported Media Type	由於媒介類型不被支持，伺服器不會接受請求。
416 Requested Range Not Satisfiable	伺服器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed	執行失敗。
423	鎖定的錯誤。

5xx:伺服器錯誤

訊息	描述
500 Internal Server Error	請求未完成。伺服器遇到不可預知的情況。
500.12	應用程式正忙於在Web伺服器上重新啟動。
500.13	Web伺服器太忙。
500.15	不允許直接請求Global.asa。
500.16	UNC授權憑據不正確。這個錯誤代碼為IIS 6.0所專用。
500.18	URL授權存儲不能打開。這個錯誤代碼為IIS 6.0所專用。
500.100	內部ASP錯誤。
501 Not Implemented	請求未完成。伺服器不支持所請求的功能。
502 Bad Gateway	請求未完成。伺服器從上游伺服器收到一個無效的回響。
502.1	CGI應用程式逾時。
502.2	CGI應用程式出錯。
503 Service Unavailable	請求未完成。伺服器臨時過載或宕機。
504 Gateway Timeout	網關逾時。
505 HTTP Version Not Supported	伺服器不支持請求中指明的HTTP版本。

版本號

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