http(HTTP超文本傳輸協定)

http

HTTP超文本傳輸協定一般指本詞條

HTTP是一個簡單的請求-回響協定,它通常運行在TCP之上。它指定了客戶端可能傳送給伺服器什麼樣的訊息以及得到什麼樣的回響。請求和回響訊息的頭以ASCII碼形式給出;而訊息內容則具有一個類似MIME的格式。這個簡單模型是早期Web成功的有功之臣,因為它使得開發和部署是那么的直截了當。

基本介紹

  • 中文名:超文本傳輸協定
  • 外文名:HTTP
  • 工作層:套用層
  • 基礎:架構在TCP協定上
  • 適用瀏覽器:Firefox、Google chrome等
  • 作用:規定WWW伺服器與瀏覽器之間信息傳遞規範
簡介,發展階段,0.9,1.0,1.1,2.0,套用場景,工作原理,運作方式,報文格式,狀態訊息,版本號,

簡介

全球資訊網WWW(world wide web)發源於歐洲日內瓦量子物理實驗室CERN,正是WWW技術的出現使得網際網路得以超乎想像的速度迅猛發展。這項基於TCP/IP的技術在短短的十年時間內迅速成為已經發展了幾十年的Internet上的規模最大的信息系統,它的成功歸結於它的簡單、實用。在WWW的背後有一系列的協定和標準支持它完成如此宏大的工作,這就是Web協定族,其中就包括HTTP超文本傳輸協定。
圖1 HTTP圖1 HTTP
在1990年,HTTP就成為WWW的支撐協定。當時由其創始人WWW之父蒂姆·貝納斯·李(TimBemers—Lee)提出,隨後WWW聯盟(WWW Consortium)成立,組織了IETF(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協定是適用於各種數據信息的簡潔快速協定,但是遠不能滿足日益發展的各種套用的需要。0.9協定就是一個交換信息的無序協定,僅僅限於文字。由於無法進行內容的協商,在雙發的握手和協定中,並有規定雙發的內容是什麼,也就是圖片是無法顯示和處理的。

1.0

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

1.1

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

2.0

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請求可能僅限於語音和圖片檔案的下載,請求出現的頻率並不算高。
圖2HTTP協定的網頁圖2HTTP協定的網頁

工作原理

HTTP是基於客戶/伺服器模式,且面向連線的。典型的HTTP事務處理有如下的過程:
(1)客戶與伺服器建立連線;
(2)客戶向伺服器提出請求;
(3)伺服器接受請求,並根據請求返回相應的檔案作為應答;
(4)客戶與伺服器關閉連線。
客戶與伺服器之間的HTTP連線是一種一次性連線,它限制每次連線只處理一個請求,當伺服器返回本次請求的應答後便立即關閉連線,下次請求再重新建立連線。這種一次性連線主要考慮到WWW伺服器面向的是Internet中成幹上萬個用戶,且只能提供有限個連線,故伺服器不會讓一個連線處於等待狀態,及時地釋放連線可以大大提高伺服器的執行效率。
HTTP是一種無狀態協定,即伺服器不保留與客戶交易時的任何狀態。這就大大減輕了伺服器記憶負擔,從而保持較快的回響速度。HTTP是一種面向對象的協定。允許傳送任意類型的數據對象。它通過數據類型和長度來標識所傳送的數據內容和大小,並允許對數據進行壓縮傳送。當用戶在一個HTML文檔中定義了一個超文本鏈後,瀏覽器將通過TCP/IP協定與指定的伺服器建立連線。
從技術上講是客戶在一個特定的TCP連線埠(連線埠號一般為80)上打開一個套接字。如果伺服器一直在這個周知的連線埠上傾聽連線,則該連線便會建立起來。然後客戶通過該連線傳送一個包含請求方法的請求塊。
HTTP規範定義了7種請求方法,每種請求方法規定了客戶和伺服器之間不同的信息交換方式,常用的請求方法是GET和POST。伺服器將根據客戶請求完成相應操作,並以應答塊形式返回給客戶,最後關閉連線。

運作方式

在WWW中,“客戶”與“伺服器”是一個相對的概念,只存在於一個特定的連線期間,即在某個連線中的客戶在另一個連線中可能作為伺服器。基於HTTP協定的客戶/伺服器模式的信息交換過程,它分四個過程:建立連線、傳送請求信息、傳送回響信息、關閉連線。
HTTP協定是基於請求/回響範式的。一個客戶機與伺服器建立連線後,傳送一個請求給伺服器,請求方式的格式為,統一資源標識符、協定版本號,後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。伺服器接到請求後,給予相應的回響信息,其格式為一個狀態行包括信息的協定版本號、一個成功或錯誤的代碼,後邊是MIME信息包括伺服器信息、實體信息和可能的內容。其實簡單說就是任何伺服器除了包括HTML檔案以外,還有一個HTTP駐留程式,用於回響用戶請求。你的瀏覽器是HTTP客戶,向伺服器傳送請求,當瀏覽器中輸入了一個開始檔案或點擊了一個超級連結時,瀏覽器就向伺服器傳送了HTTP請求,此請求被送往由IP位址指定的URL。駐留程式接收到請求,在進行必要的操作後回送所要求的檔案。在這一過程中,在網路上傳送和接收的數據已經被分成一個或多個數據包(packet),每個數據包包括:要傳送的數據;控制信息,即告訴網路怎樣處理數據包。TCP/IP決定了每個數據包的格式。如果事先不告訴你,你可能不會知道信息被分成用於傳輸和再重新組合起來的許多小塊。
圖3 http運作方式的一種圖3 http運作方式的一種
許多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。

相關詞條

熱門詞條

聯絡我們