HTTP協議原理及請求、響應報文格式
阿新 • • 發佈:2018-12-30
前言
HTTP是一個屬於應用層的面向物件的協議,由於其簡捷、快速的方式,適用於分散式超媒體資訊系統。它於1990年提出,經過幾年的使用與發展,得到不斷地完善和擴充套件。
HTTP協議的主要特點
- 支援C/S(客戶/伺服器)模式。
- 簡單快速:客戶向伺服器請求服務時,只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST,每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單,使得HTTP伺服器的程式規模小,因而通訊速度很快。
- 靈活:HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
- 無連線:無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求,並收到客戶的應答後,即斷開連線。採用這種方式可以節省傳輸時間。
- 無狀態:HTTP協議是無狀態協議,無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊,則它必須重傳,這樣可能導致每次連線傳送的資料量增大。另一方面,在伺服器不需要先前資訊時它的應答就較快。
HTTP URL 的格式: http://host[:port][abs_path]
URL | http://host[:port][abs_path] |
http | 表示要通過HTTP協議來定位網路資源 |
host | 表示合法的Internet主機域名或IP地址 |
port | 用於指定一個埠號,擁有被請求資源的伺服器主機監聽該埠的TCP連線(如果port是空,則使用預設的埠80。當伺服器的埠不是80的時候,需要顯式指定埠號 |
abs_path | 指定請求資源的URI(Uniform Resource Identifier,統一資源定位符),如果URL中沒有給出abs_path,那麼當它作為請求URI時,必須以“/”的形式給出。通常這個工作瀏覽器就幫我們完成了 |
HTTP請求、響應報文格式:
(1).HTTP請求報文格式:
HTTP請求報文主要由請求行、請求頭部、請求資料3部分組成1,請求行
由3部分組成,分別為:請求方法、URL、以及協議版本,之間由空格分隔,格式如下:
Method Request-URL HTTP-Version CRLF 1.其中 Method表示請求方法;Request-URI是一個統一資源識別符號;HTTP-Version表示請求的HTTP協議版本;CRLF表示回車和換行 為結尾的CRLF外,不允許出現單獨的CR或LF字元)。 2.協議版本的格式為:HTTP/主版本號.次版本號,常用的有HTTP/1.0和HTTP/1.1 |
請求方法包括GET、POST、DELETE、PUT、HEAD、TRACE、CONNECT 、OPTIONS。其中PUT、DELETE、POST、GET分別對應著增刪改查,對於移動開發最常用的就是POST和GET了。
GET | 請求獲取Request-URI所標識的資源 |
POST | 在Request-URI所標識的資源後附加新的資料 |
HEAD | 請求獲取由Request-URI所標識的資源的響應訊息報頭 |
PUT | 請求伺服器儲存一個資源,並用Request-URI作為其標識 |
DELETE | 請求伺服器刪除Request-URI所標識的資源 |
TRACE | 請求伺服器回送收到的請求資訊,主要用於測試或診斷 |
CONNECT | HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器 |
OPTIONS | 請求查詢伺服器的效能,或者查詢與資源相關的選項和需求 |
2,請求頭部
請求頭部為請求報文添加了一些附加資訊,由“名/值”對組成,每行一對,名和值之間使用冒號分隔
請求頭 | 解釋 |
Host | 接受請求的服務地址,可以是IP:埠號,也可以是域名 |
Connection | 指定與連線的相關屬性:Keep-Alive |
Accept-Encoding | 通知服務端可以傳送的資料壓縮格式 |
User-Agent | 傳送請求的應用程式名 |
Accept-Language | 通知服務端可以傳送的語言 |
Accept-Charset | 通知服務端可以傳送的編碼格式 |
例圖:
3,請求資料
HTTP響應報文格式:
HTTP響應報文主要由狀態行、響應頭部、響應正文3部分組成。狀態行格式如下:
HTTP-Version Status-Code Reason-Phrase CRLF 其中,HTTP-Version表示伺服器HTTP協議的版本;Status-Code表示伺服器發回的響應狀態程式碼;Reason-Phrase表示狀態程式碼的文字描述。 狀態程式碼有三位數字組成, 100~199:指示資訊,表示請求已接收,繼續處理 200-299的狀態碼錶示成功 300-399的狀態碼指資源重定向 400-499的狀態碼指客戶端請求出錯 500-599的狀態碼指服務端出錯(HTTP/1.1向協議中引入了資訊性狀態碼,範圍為100~199)
2,響應頭部 |
響應頭 | 解釋 |
Server | 伺服器應用程式軟體的名稱和版本 |
Content-Type | 傳送給接收者的實體正文的媒體型別 |
Accept-Language | 描述資源所用的自然語言,沒有設定則該選項則認為實體內容將提供給所有的語言閱讀 |
Content-Lenght | 實體正文的長度 |
如上,在解析請求的時候,可能遇見的Transfer-Encoding響應頭,而沒有Content-Length。
compress | 採用 Lempel-Ziv-Welch (LZW) 壓縮演算法 |
deflate | 採用 zlib 結構 (在 RFC 1950 中規定),和 deflate 壓縮演算法(在 RFC 1951 中規定) |
gzip | 表示採用 Lempel-Ziv coding (LZ77) 壓縮演算法,以及32位CRC校驗的編碼方式 |
identity | 用於指代自身(例如:未經過壓縮和修改)。除非特別指明,這個標記始終可以被接受 |
chunked | 資料以一系列分塊的形式進行傳送。 Content-Length 首部在這種情況下不被髮送 |