1. 程式人生 > >HTTP協議原理及請求、響應報文格式

HTTP協議原理及請求、響應報文格式

前言

HTTP是一個屬於應用層的面向物件的協議,由於其簡捷、快速的方式,適用於分散式超媒體資訊系統。它於1990年提出,經過幾年的使用與發展,得到不斷地完善和擴充套件。

HTTP協議的主要特點

  1. 支援C/S(客戶/伺服器)模式。
  2. 簡單快速:客戶向伺服器請求服務時,只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST,每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單,使得HTTP伺服器的程式規模小,因而通訊速度很快。
  3. 靈活:HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
  4. 無連線:無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求,並收到客戶的應答後,即斷開連線。採用這種方式可以節省傳輸時間。
  5. 無狀態:HTTP協議是無狀態協議,無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊,則它必須重傳,這樣可能導致每次連線傳送的資料量增大。另一方面,在伺服器不需要先前資訊時它的應答就較快。

HTTP URL 的格式: http://host[:port][abs_path]

URLhttp://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請求伺服器回送收到的請求資訊,主要用於測試或診斷
CONNECTHTTP/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
常見的狀態碼
200 OK客戶端請求成功
400 Bad Request客戶端請求有語法錯誤,不能被伺服器所理解
401 Unauthorized請求未經授權,這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden伺服器收到請求,但是拒絕提供服務(認證失敗)
404請求資源不存在
500 Internal Server Error伺服器發生不可預期的錯誤

2,響應頭部


響應頭解釋
Server伺服器應用程式軟體的名稱和版本
Content-Type傳送給接收者的實體正文的媒體型別
Accept-Language描述資源所用的自然語言,沒有設定則該選項則認為實體內容將提供給所有的語言閱讀
Content-Lenght實體正文的長度


如上,在解析請求的時候,可能遇見的Transfer-Encoding響應頭,而沒有Content-Length。
Transfer-Encoding編碼方式
compress採用 Lempel-Ziv-Welch (LZW) 壓縮演算法
deflate採用 zlib 結構 (在 RFC 1950 中規定),和 deflate 壓縮演算法(在 RFC 1951 中規定)
gzip表示採用 Lempel-Ziv coding (LZ77) 壓縮演算法,以及32位CRC校驗的編碼方式
identity用於指代自身(例如:未經過壓縮和修改)。除非特別指明,這個標記始終可以被接受
chunked資料以一系列分塊的形式進行傳送。 Content-Length 首部在這種情況下不被髮送