本文是對這幾天學習Http協議的基礎知識的小結。內容包括了Http協議的原理，Http請求信息和Http響應信息以及Http協議狀態碼等內容。
1、Http協議的基本原理：有客戶端向服務器發送請求，服務端對請求處理，對客戶端進行相應。如下圖所示。
圖1 Http協議原理圖
下面給出一個簡單的請求和響應的示例代碼：
客戶端請求：
GET / HTTP/1.1 Host: localhostAccept: text/htmlAccept-Language: en-usAccept-Encoding: gzip,deflateConnection: keep-alive空行(CR+LF)
服務端響應：
HTTP/1.1 200 OK Date: Fri, 13 Jul 2012 02:45:30 GMTServer: ApacheLast-Modified: Fri ,31 Agu 2007 02:02:20 GMTETag: "45bae1-16a-46d776ac"Connection: closeContent-Type: text/htmlContent-Length:362空行(CR+LF)<html> <head></head><body>.... --Content 362Bytes.... </body></html>
2、Http請求
a.請求報文格式：
----------------------------------------------------------
請求行 ↔ GET / HTTP/1.1
請求頭信息 ↔ Host: localhost
...
...
...
空行（CR+LF）
[請求主體信息]（可以沒有）
-----------------------------------------------------------
b.說明：
→請求行：請求方法+請求路徑+Http協議版本
請求方法：GET,POST,HEAD,OPTION,DELETE,PUT等
請求路徑： /
Http協議版本：HTTP/0.9 HTTP/1.0 HTTP/1.1
→請求頭信息
Host： 請求的主機名稱 （localhost）
注意：Host字段信息必須被包含在請求頭信息中，因為同一個IP地址下可能會有多個虛擬主機，
需要Host來指定請求的是該IP下的哪一個主機。
Accept: 客戶端可以處理的文件類型。 (text/html,text/plain,image/jpeg)
Accept-Encoding: 用戶代理支持的內容編碼及優先級順序 （gzip,deflate,comPRess）
Accept-Charset: 用戶代理支持的字符集及優先級順序 （iso-8859-5）
Referer: 告知服務器請求的原始資源的URI （用此字段可以進行反防盜鏈）
例如：Referer:http://www.baidu.com
User-Agent: 傳達創建請求的瀏覽器和用戶代理名稱等信息
3、Http響應
a.響應報文格式
-------------------------------------------------
響應行 ↔ HTTP/1.1 200 OK
響應頭信息 ↔ Server：Apache
...
...
...
空行（CR+LF）
[響應主體信息]（可以沒有）
--------------------------------------------------
b.說明：
→響應行：Http協議版本+狀態碼+狀態字
Http協議：HTTP/0.9,HTTP/1.0,HTTP/1.1
狀態碼：
狀態碼 說明
1XX 信息性狀態碼。接收的請求正在處理
2XX 成功狀態碼。請求正常處理完畢
3XX 重定向狀態碼。需要進行附加操作以完成請求
4XX 客戶端錯誤狀態碼。服務器無法處理請求
5XX 服務器錯誤狀態碼。服務器處理請求出錯
一些重要的狀態碼：
2XX：200 204 206
200(OK) → 客戶端的請求在服務端被正常處理
204(No Content) → 服務器接收請求成功處理，但在返回響應報文中不含實體的主體部分
206(Partial Content) → 客戶端執行了范圍請求，而服務器成功執行了這部分的GET請求
3XX：301 302 303 304 307
301(Moved Permanently) → 永久重定向。表示請求的資源已被分配了新的URI，以后應使用資源現在所指的URI
302( Found) → 臨時重定向。表示請求的資源已被分配了新的URI，希望用戶（本次）能使用新的 URI訪問
303(See Other) → 表示由于請求對應的資源存在著另一個URI，應使用 GET方法定向獲取請求的資源
304(Not Modified) → 表示客戶端發送附帶條件的請求時，服務器端允許請求訪問資源，但未滿足條件的情況。
304狀態碼返回時，不包含任何響應的主體部分
307(Temporary Redirect) → 臨時重定向。與302有著相同的含義，但是302會將POST變換成GET，而307不會將POST變換成GET
4XX：400 401 403 404
400(Bad Request) → 表示請求的報文中存在語法錯誤
401(Unauthorized) → 表示發送的請求需要通HTTP認證的認證信息，若之前已經進行過一次請求，這表示用戶認證失敗
403(Forbidden) → 表明對請求資源的訪問被服務器拒絕
404(Not Found) → 表名在服務器上無法找到請求的資源
5XX：500 503
500(Internal Server Error) → 表明服務器端執行請求時發生了錯誤。也有可能是Web應用存在bug或某些臨時的故障
503(Service Unavailable) → 表明服務器暫時處于超負載或正在進行停機維護，現在無法執行請求
→響應頭信息
Age： 告知客戶端源服務端在多久前創建了響應（字段單位為：秒）
若創建該響應的服務器是緩存服務器，Age值是指緩存后的響應再次發起認證到認證完成的時間值。
代理創建響應時必須加上首部字段Age
ETag: 告知客戶端響應實體信息的標記，將資源唯一標識，
ETag由服務器分配，沒有統一的算法規則
Location：將接收方引導至另一個資源所在處
Server： 告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，
還有可能包括版本號和安裝時啟用的可選項
4、實體首部字段（請求頭信息或者響應頭信息的字段）
Content-Encoding: 對實體的主體部分選用的內容編碼方式
Content-Language：告知客戶端主體信息使用的語言
Content-Length： 說明主體信息的大小（字節）
Content-Type: 說明主體信息的文件（媒體）類型
Set-Cookie: 服務端向客戶端寫Cookie內容信息
Cookie: 客戶端向服務器發送Cookie內容信息
另：更加深入的了解cookie與session等有關內容的講解請參考：
http://blog.csdn.net/cendy_69576750/article/details/8000091
附：以上內容參考自《圖解HTTP》一書。
新聞熱點
疑難解答
