-
HTTP
鎖定
超文本傳輸協議(Hypertext Transfer Protocol,HTTP)是一個簡單的請求-響應協議,它通常運行在TCP之上。它指定了客户端可能發送給服務器什麼樣的消息以及得到什麼樣的響應。請求和響應消息的頭以ASCII形式給出;而消息內容則具有一個類似MIME的格式。超文本傳輸協議是一種用於分佈式、協作式和超媒體信息系統的應用層協議,是萬維網WWW(World Wide Web)的數據通信的基礎。
[1]
- 中文名
- 超文本傳輸協議
- 外文名
- HTTP
- 工作層
- 應用層
HTTP簡介
萬維網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。
[2]
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]
HTTP發展階段
HTTP0.9
1991年,第一個有文檔記載的HTTP正式版本被寫成了一個普通文檔,長度不到700字,這個版本被命名為HTTP/0.9。0.9協議是適用於各種數據信息的簡潔快速協議,但是遠不能滿足日益發展的各種應用的需要。0.9協議就是一個交換信息的無序協議,僅僅限於文字。由於無法進行內容的協商,在雙發的握手和協議中,並沒有規定雙發的內容是什麼,也就是圖片是無法顯示和處理的。
[3]
HTTP1.0
到了1.0協議階段,也就是在1992年,Tim Berners-Lee編寫了一份新的文件,以具體説明基本議定書向下一個完整版本的演變。它支持0.9版本的簡單請求方法和包含客户端HTTP版本的完整GET請求。
[4]
1996年5月,RFC 1945作為HTTP/1.0的最終修訂版發佈,該修訂版在過去4年中一直作為標準HTTP/1.0草案使用,已經被許多Web瀏覽器和Web服務器使用。在此後的不斷豐富和發展中,HTTP/1.0成為最重要的面向事務的應用層協議。該協議對每一次請求/響應建立並拆除一次連接。其特點是簡單、易於管理,所以它符合了大家的需要,得到了廣泛的應用。
HTTP1.1
在1.0協議中,雙方規定了連接方式和連接類型,這已經極大擴展了HTTP的領域,但對於互聯網最重要的速度和效率,並沒有太多的考慮。
[3]
畢竟,作為協議的制定者,當時也沒有想到HTTP會有那麼快的普及速度。
HTTP2.0
HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個版本,但這兩個版本所包含的協議規範十分龐大。網絡協議新版本並不會馬上取代舊版本。實際上,HTTP 1.0和HTTP1.1在之後很長的一段時間內一直並存,這是由於網絡基礎設施更新緩慢所決定的。
[7]
HTTP3.0
HTTP3.0是超文本傳輸協議的第三個主要版本,用於在萬維網上交換信息,補充了廣泛部署的HTTP1.1和HTTP2.0。與之前依賴於成熟的TCP的版本不同,HTTP3.0使用QUIC,一種基於UDP的多路傳輸協議。HTTP3.0具有更低的延遲和更快的加載速度。
HTTP應用場景
HTTP誕生之初主要是應用於WEB端內容獲取,那時候內容還不像現在這樣豐富,排版也沒那麼精美,用户交互的場景幾乎沒有。對於這種簡單的獲取網頁內容的場景,HTTP表現得還算不錯。但隨着互聯網的發展和WEB2.0的誕生,更多的內容開始被展示(更多的圖片文件),排版變得更精美(更多的CSS),更復雜的交互也被引入(更多的JS)。用户打開一個網站首頁所加載的數據總量和請求的個數也在不斷增加。
今天絕大部分的門户網站首頁大小都會超過2M,請求數量可以多達100個。另一個廣泛的應用是在移動互聯網的客户端app,不同性質的app對HTTP的使用差異很大。對於電商類app,加載首頁的請求也可能多達10多個。對於微信這類IM,HTTP請求可能僅限於語音和圖片文件的下載,請求出現的頻率並不算高。
HTTP工作原理
(1)客户與服務器建立連接;
(2)客户向服務器提出請求;
(3)服務器接受請求,並根據請求返回相應的文件作為應答;
(4)客户與服務器關閉連接。
客户與服務器之間的HTTP連接是一種一次性連接,它限制每次連接只處理一個請求,當服務器返回本次請求的應答後便立即關閉連接,下次請求再重新建立連接。這種一次性連接主要考慮到WWW服務器面向的是Internet中成千上萬個用户,且只能提供有限個連接,故服務器不會讓一個連接處於等待狀態,及時地釋放連接可以大大提高服務器的執行效率。
[10]
HTTP是一種無狀態協議,即服務器不保留與客户交易時的任何狀態。這就大大減輕了服務器記憶負擔,從而保持較快的響應速度。HTTP是一種面向對象的協議。允許傳送任意類型的數據對象。它通過數據類型和長度來標識所傳送的數據內容和大小,並允許對數據進行壓縮傳送。當用户在一個HTML文檔中定義了一個超文本鏈後,瀏覽器將通過TCP/IP協議與指定的服務器建立連接。
[10]
HTTP支持持久連接,在HTTP / 0.9和1.0中,連接在單個請求/響應對之後關閉。在HTTP / 1.1中,引入了保持活動機制,其中連接可以重用於多個請求。這樣的持久性連接可以明顯減少請求延遲,因為在發送第一個請求之後,客户端不需要重新協商TCP 3-Way-Handshake連接。另一個積極的副作用是,通常,由於TCP的緩慢啓動機制,連接隨着時間的推移而變得更快。
該協議的1.1版還對HTTP / 1.0進行了帶寬優化改進。例如,HTTP / 1.1引入了分塊傳輸編碼,以允許流傳輸而不是緩衝持久連接上的內容。HTTP流水線進一步減少了延遲時間,允許客户端在等待每個響應之前發送多個請求。協議的另一項附加功能是字節服務,即服務器僅傳輸客户端明確請求的資源部分。
HTTP規範定義了9種請求方法,每種請求方法規定了客户和服務器之間不同的信息交換方式,常用的請求方法是GET和POST。服務器將根據客户請求完成相應操作,並以應答塊形式返回給客户,最後關閉連接。
[10]
HTTP運作方式
在WWW中,“客户”與“服務器”是一個相對的概念,只存在於一個特定的連接期間,即在某個連接中的客户在另一個連接中可能作為服務器。基於HTTP的客户/服務器模式的信息交換過程,它分四個過程:建立連接、發送請求信息、發送響應信息、關閉連接。
[6]
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狀態消息
消息 | 描述 |
---|---|
100 Continue | 服務器僅接收到部分請求,但是一旦服務器並沒有拒絕該請求,客户端應該繼續發送其餘的請求。 |
101 Switching Protocols | 服務器轉換協議:服務器將遵從客户的請求轉換到另外一種協議。 |
消息 | 描述 |
---|---|
200 OK | 請求成功(其後是對GET和POST請求的應答文檔。) |
201 Created | 請求被創建完成,同時新的資源被創建。 |
202 Accepted | 供處理的請求已被接受,但是處理未完成。 |
203 Non-authoritative Information | 文檔已經正常地返回,但一些應答頭可能不正確,因為使用的是文檔的拷貝。 |
204 No Content | 沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用户定期地刷新頁面,而Servlet可以確定用户文檔足夠新,這個狀態代碼是很有用的。 |
205 Reset Content | 沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。 |
206 Partial Content | 客户發送了一個帶有Range頭的GET請求,服務器完成了它。 |
消息 | 描述 |
---|---|
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。 |
消息 | 描述 |
---|---|
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 | 鎖定的錯誤。 |
消息 | 描述 |
---|---|
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版本號
- 參考資料
-
- 1. Joe Touch, John Heidemann, Katia Obraczka.Analysis of HTTP Performance[J].USC/ISI Research Report,Aug. 16, 1996, 98(463)
- 2. Jeffrey C. Mogul.The Case for Persistent-Connection HTT[J].SIGCOMM,1995,195(0008)
- 3. HTTP協議之前世今生——兼談網絡應用結構設計 .《程序員》2008年05期[引用日期2024-04-17]
- 4. T. Berners-Lee.Basic HTTP as defined in 1992 [J].Internet Engineering Task Force (IETF),1992,(misc)
- 5. T. Berners-Lee,R. Fielding,H. Frystyk.Hypertext Transfer Protocol -- HTTP/1.0[J].RFC,1945,10(17487)
- 6. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,T. Berners-Lee..RFC2616: Hypertext Transfer Protocol -- HTTP/1.1[J].RFC,1999,10(17487)
- 7. 曉涵.HTTP協議揭秘[J].計算機與網絡,2017,43(2)
- 8. Daniel Stenberg .HTTP2 Explained[J].ACM SIGCOMM Computer Communication Review,2014,44(3)
- 9. M. Trevisan, D. Giordano, I. Drago and A. S. Khatouni.Measuring HTTP/3: Adoption and Performance[J].2021 19th Mediterranean Communication and Computer Networking Conference (MedComNet),2021,10(1109):1-8
- 10. 皖東.HTTP協議的傳輸機制與超文本鏈的研究[J].微電子學與計算機,1997,14(4)
- 11. J. Mogul, R. Fielding, J. Gettys, H. Nielsen.Use and Interpretation of HTTP Version Numbers[J].RFC,1997,2145(1-7)
- 收起
- 詞條統計
-
- 瀏覽次數:次
- 編輯次數:98次歷史版本
- 最近更新: Shirleysheep11