http協議詳解

HTTP協議簡介：

    HTTP協議是一個基於請求與響應模式、無狀態、應用層的協議，常基於TCP的鏈接方式。絕大多數的web項目都是構建在HTTP協議之上的web應用。

HTTP協議的5個主要特色：

1.支持客戶/服務器模式。

2.簡單快速：當客戶向服務器請求服務時，只須要向服務器傳遞請求方法（GET、HEAD、POST…）和路徑便可。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

3.靈活：HTTP協議容許傳輸任意類型的數據對象，由Content-Type指定。

4.無鏈接：指HTTP協議限定每次鏈接只能處理一個請求，服務器處理完請求、並收到客戶端的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。（我也不明白爲何這種無鏈接的傳輸方式能夠節省傳輸時間，求指教。）

（注：新的HTTP/1.1協議採用的是持續性鏈接：它支持一個TCP鏈接上能夠傳送多個請求和響應，並且容許客戶端不須要等待上一次的請求結果就能夠發出下一次請求。但服務器端響應時必須按照接收到的請求的前後順序依次返回響應結果）

5.無狀態：指HTTP協議對於事務的處理沒有記憶能力。若是後面的處理須要前面的信息，那麼必須重傳，這樣會致使數據的傳輸量變大。

HTTP協議的URL(Uniform Resource Locator)

http://host[:port][abs_path]

http:表示要經過HTTP協議來定位網絡資源。

host:表示合法的Internet主機或者IP地址（以點分十進制表示，如：127.0.0.1）

port:用於指定一個端口號，擁有被請求資源的服務器主機監聽該端口的TCP鏈接。缺省是80。

abs_path:指定請求資源的URI，若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以"/"的形式給出，一般這個工做瀏覽器會自動幫咱們完成。

如：輸入www.google.com.hk瀏覽器會自動補充爲：http://www.google.com.hk

HTTP協議的請求：

HTTP請求由三部分組成：請求行，消息報頭，請求正文。

1.請求行格式以下：Method Request-URI HTTP-Version CRLF.(以空格分隔)

Method:指請求的方法。（GET、POST…）

Request-URI:統一資源標識符。也就是URL中的abs_path部分。

HTTP-Version:HTTP協議的版本。（如今通常都爲HTTP/1.1）

CRLF：表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）

例如：請求www.google.com.hk，那麼請求行的內容即爲以下所示：

GET / HTTP/1.1

(「GET」爲請求方法；「/」爲URI，因爲URL中沒有給出abs_path，瀏覽器自動幫助補充"/"；「HTTP/1.1"爲HTTP協議版本)

請求方法（全部方法都爲大寫）有多種：

GET：請求獲取由Request-URI所標識的資源。

POST：在Request-URI所標識的資源後附加新的數據。

HEAD：請求獲取由Request-URI所標識的資源的響應消息報送。

PUT：請求服務器存儲一個資源，用Request-URI做爲其標識。

DELETE：請求服務器刪除Request-URI所標識資源。

TRACE：請求服務器回送收到的請求消息。主要用於測試或者診斷。

CONNECT：保留。

OPTIONS：請求查詢服務器的性能 ，或者查詢與資源相關的選項。

經常使用的有GET和POST兩種方法。

2.消息報頭（後述）

3.請求正文（略）

HTTP協議的響應：

HTTP響應也是由三部分組成：狀態行，消息報頭，響應正文。

1.狀態行格式以下：HTTP-Version Status-Code Reason-Phrase CRLF.(以空格分隔)

HTTP-Version:HTTP協議的版本。（如今通常都爲HTTP/1.1）

Status-Code：指服務器發回的響應狀態代碼。

Reason-Phrase：指狀態代碼的文本描述。

例如：請求www.google.com.hk，那麼狀態行的內容即爲以下所示：

HTTP/1.1 200 OK

"HTTP/1.1"爲HTTP協議版本；「200」爲響應狀態代碼。「OK」爲響應狀態代碼的文本描述。

響應狀態代碼有多種：

1xx：指示信息--表示請已接收，繼續處理。

2xx：成功--表示請求已被成功接收，理解，接受。

3xx：重定向--表示要完成請求必須進行進一步操做。

4xx：客戶端錯誤--表示請求有語法錯誤或者沒法實現。

5xx：服務器端錯誤--服務器未能實現合法的請求。

常見的狀態代碼以下：

200 OK 表示客戶端請求成功

400 Bad Request 表示客戶端語法有語法錯誤，不能被服務器所理解

403 Forbidden 表示服務器拒絕提供服務

404 Not Found 表示所請求的資源不存在

500 Internal Server Error 表示服務器發生了不可預期的錯誤

503 Server Unavailable 表示服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

2.消息報頭（後述）

3.響應正文就是服務器返回的資源的內容

HTTP協議的消息報頭：

HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。

HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。

每個報頭域都是由名字+「：」+空格+值 組成，消息報頭域的名字是大小寫無關的。

1.普通報頭：在普通報頭中，有少數報頭域用於全部的請求和響應消息，但並不用於被傳輸的實體，只用於傳輸的消息。（常普通報送：Cache-Control、Date、Connection）

2.請求報頭：容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。（經常使用請求報頭：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Host、Uer-Agent）

3.響應報頭：容許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。（常見響應報頭：Location、Server）

4.實體報頭：請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。（常見的實體報頭：Content-Encoding、Content-Language、Content-Length、Content-Type、Last-Modified、Expires）

如：訪問www.google.com.hk的請求報頭爲：

Host: www.google.com.hk

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Cookie: PREF=ID=b38fb978efac77fe:U=ea32f8666ff8e2e0:FF=2:LD=zh-CN:NR=10:NW=1:TM=1383534674:LM=1395650039:C2COFF=1:SG=3:S=ejtjpgRPRAM-P-Iw; NID=67=erlEd3m6GKzsbsLBTWUqFdS2mkhrU-z5RaZs45lW7G0LQhwA-KnpxcMtZMY8ptnS85---5goxc7qg74OhuLUNdnElZS4Jcs59wRIYY1yFToVCbUIfYodpPdgZXvl1wXIw_gphoCnQkvUMxy8gg3W9GoUpQvHPACCHmkf4xS_zBRC5wjdtu76ES_POxq0ZdFvGA

Connection: keep-alive

訪問www.google.com.hk的響應報頭爲：

Date: Mon, 24 Mar 2014 08:34:05 GMT

Expires: -1

Cache-Control: private, max-age=0

Content-Type: text/html; charset=UTF-8

Set-Cookie: PREF=ID=b38fb978efac77fe:U=ea32f8666ff8e2e0:FF=2:LD=zh-CN:NR=10:NW=1:TM=1383534674:LM=1395650045:C2COFF=1:SG=3:S=Qcv2BOBez8mHIRaz; expires=Wed, 23-Mar-2016 08:34:05 GMT; path=/; domain=.google.com.hk

Content-Encoding: gzip

Server: gws

X-XSS-Protection: 1; mode=block

X-Frame-Options: SAMEORIGIN

Transfer-Encoding: chunked

Alternate-Protocol: 80:quic