1 概述
1.1 定義
HTTP協議是HyperText Transfer Protocol（超文本傳輸協議）的縮寫，是一個應用層協議，由請求和回應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議，用于分發、協作超文本資訊系統。
1.2 版本
目前主要有Http1.0、Http1.1、Http2.0版本，Http3.0版本處于草稿狀態。
1.3 標準性
由World Wide Web Consortium (W3C)和 Internet Engineering Task Force （IETF）聯合發布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。
1.4 其它
2 協議規范
2.1 協議內容
2.1.1 HTTP 版本（HTTP Version）
HTTP 采用主從（<major>.<minor>）數字形式來表示版本。例如 1.0,1.1,20。
2.1.2 統一資源標識
2.1.3 Connection
一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程式之間。
在http1.1，request和reponse頭中都有可能出現一個connection的頭，此header的含義是當client和server通信時對于長鏈接如何進行處理。
在http1.1中，client和server都是默認對方支持長鏈接的， 如果client使用http1.1協議，但又不希望使用長鏈接，則需要在header中指明connection的值為close；如果server方也不想支持長鏈接，則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明當前正在使用的tcp鏈接在當天請求處理完畢后會被斷掉。以后client再進行新的請求時就必須創建新的tcp鏈接了。
2.1.4 訊息：Message
HTTP通訊的基本單位，包括一個結構化的八元組序列并通過連接傳輸。
2.1.5 請求：Request
一個從客戶端到服務器的請求資訊包括應用于資源的方法、資源的識別符號和協議的版本號。
2.1.6 回應：Response
一個從服務器回傳的資訊包括HTTP協議的版本號、請求的狀態(例如“成功”或“沒找到”)和檔案的MIME型別。
2.1.7 資源：Resource
由URI標識的網路資料物件或服務。
2.1.8 物體：Entity
資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或回應資訊中。一個物體包括物體頭資訊和物體的本身內容。
2.1.9 客戶機：Client
一個為發送請求目的而建立連接的應用程式。
2.1.10 用戶代理：UserAgent
初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。
2.1.11 服務器：Server
一個接受連接并對請求回傳資訊的應用程式。
2.1.12 源服務器：Originserver
是一個給定資源可以在其上駐留或被創建的服務器。
2.1.13 代理：Proxy
一個中間程式，它可以充當一個服務器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的服務器中。一個代理在發送請求資訊之前，必須解釋并且如果可能重寫它。
代理經常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。
2.1.14 網關：Gateway
一個作為其它服務器中間媒介的服務器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源服務器；發出請求的客戶機并沒有意識到它在同網關打交道。
網關經常作為通過防火墻的服務器端的門戶，網關還可以作為一個協議翻譯器以便存取那些存盤在非HTTP系統中的資源。
2.1.15 通道：Tunnel
是作為兩個連接中繼的中介程式。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
2.1.16 快取：Cache
反應資訊的局域存盤。
2.2 HTTP狀態碼
回傳結果的狀態碼
1XX 表示服務器已經接收了客戶端請求，客戶端可繼續發送請求
2XX 請求正常處理完畢
3XX 需要進行附加操作以完成請求
4XX 表示客戶端的請求有非法內容
5XX 服務器處理請求出錯
2.3 HTTP請求方法
方法 說明 支持版本
GET 獲取資源 1.0、1.1、2.0、3.0
POST 傳輸物體主體 1.0、1.1、2.0、3.0
PUT 傳輸檔案 1.0、1.1、2.0、3.0
HEAD 獲得報文首部 1.0、1.1、2.0、3.0
DELETE 洗掉檔案 1.0、1.1、2.0、3.0
OPTIONS 詢問支持的方法 1.0、1.1、2.0、3.0
TRACE 追蹤路徑 1.1、2.0、3.0
CONNECT 要求用隧道協議連接代理 1.1、2.0、3.0
LINK 建立與資源之間的聯系 1.0
UNLINK 斷開連接關系 1.0
3 協議實作
3.1 版本選擇
3.2 實作機理
3.2.1 請求回應模型
HTTP協議是客戶端發起請求，服務器回送回應。見下圖：
這樣就限制了使用HTTP協議，無法實作在客戶端沒有發起請求的時候，服務器將訊息推送給客戶端。
HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關系。
3.2.2 作業流程
一次HTTP操作稱為一個事務，其作業程序可分為四步：
1）首先客戶機與服務器需要建立連接。
2）建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源識別符號（URL）、協議版本號，后邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。
3）服務器接到請求后，給予相應的回應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的代碼，后邊是MIME資訊包括服務器資訊、物體資訊和可能的內容。
4）客戶端接收服務器所回傳的資訊通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務器斷開連接。
如果在以上程序中的某一步出現錯誤，那么產生錯誤的資訊將回傳到客戶端。
3.3 HTTP/2.0改進
?多路復用
HTTP/2.0 使用多路復用技術，同一個 TCP 連接可以處理多個請求。
?首部壓縮
HTTP/1.1 的首部帶有大量資訊，而且每次都要重復發送。HTTP/2.0 要求通訊雙方各自快取一份首部欄位表，從而避免了重復傳輸。
?服務端推送
HTTP/2.0 在客戶端請求一個資源時，會把相關的資源一起發送給客戶端，客戶端就不需要再次發起請求了。例如客戶端請求 index.html 頁面，服務端就把 index.js 一起發給客戶端。
?二進制格式
HTTP/1.1 的決議是基于文本的，而 HTTP/2.0 采用二進制格式。
3.4 HTTP/3.0版本的改進
?減少 TCP 三次握手及 TLS 握手時間
?改進的擁塞控制
?避免隊頭阻塞的多路復用
?連接遷移
?前向糾錯
3.5 Apache Http Client 和 Apache Http Core 版本5
Apache Http Client版本5將支持 http2.0協議
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/39343.html