HTTP 協議簡介

HTTP 協議簡介

超文本傳輸協議（Hypertext Transfer Protocol，簡稱HTTP）是應用層協議，自 1990 年起，HTTP 就已經被應用於 WWW 全球信息服務系統。

HTTP 是一種請求/響應式的協議。一個客戶機與服務器創建鏈接後，發送一個請求給服務器；服務器接到請求後，給予相應的響應信息。

HTTP 的初版本 HTTP/0.9是一種簡單的用於網絡間原始數據傳輸的協議；

HTTP/1.0由 RFC 1945 定義 ，在原 HTTP/0.9 的基礎上，有了進一步的改進，容許消息以類 MIME 信息格式存　在，包括請求/響應範式中的已傳輸數據和修飾符等方面的信息；

HTTP/1.1(RFC2616) 的要求更加嚴格以確保服務的可靠性，加強了在HTTP/1.0 沒有充分考慮到分層代理服務器、高速緩衝存儲器、持久鏈接需求或虛擬主機等方面的效能；

安全加強版的 HTTP （即S-HTTP或HTTPS），則是HTTP協議與安全套接口層(SSL)的結合，使HTTP的協議數據在傳輸過程當中更加安全。

協議結構

請求頭格式

a) 通用頭(general-header)：

Cache-Control：客戶端但願服務端如何緩存本身的請求數據，如」Cache-Control: no-cache」，」Cache-Control: max-age=0″；

Connection：客戶端是否但願與服務端之間保持長鏈接，如」Connection: close」, 「Connection: keep-alive」；

Date：只有當請求方法爲POST或PUT方法時客戶端纔可能會有些字段；

Pragma：包含了客戶端一些特殊請求信息，如 「Pragma: no-cache」 客戶端但願代理或應用服務器不該緩存與該請求相關的結果數據；

Via：通常用在代理網關嚮應用服務器發送的請求頭中，代表該來自客戶端的請求通過了網關代理，

格式爲：」Via: 請求協議版本  網關標識   [其它信息] 「，

如 ：」 Via: 1.1  webcache_250_199.hexun.com:80 (squid)」

b) 請求頭(request-header)：

Accept： 代表客戶同端可接受的請求迴應的媒體類型範圍列表。星號「*」用於按範圍將類型分組，用「*/*」指示可接受所有類型

用「type/*」指示可接受 type類型的全部子類型，如「 Accept: p_w_picpath/gif, p_w_picpath/jpeg, */*」；

Accept-Charset：客戶端所能識別的字符集編碼格式，格式：「Accept-Charset: 字符集1[:權重]，字符集2[:權重]」，如：「 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8」；

Accept-Language：客戶端所能識別的語言，格式：「Accept-Language: 語言1[:權重]，語言2[:權重]」，如：」 Accept-Language: zh, en;q=0.7」；

Host：客戶請求的主機域名或主機IP，格式：「Host: 域名或IP[:端口號]」，如：「Host: www.hexun.com:80「，請求行中如有HTTP/1.1則必須有該請求頭；

User-Agent：代表用戶所使用的瀏覽器標識，主要用於統計的目的；

Referer：指明該請求是從哪一個關聯鏈接而來；

Accept-Encoding：客戶端所能識別的編碼壓縮格式，如：「Accept-Encoding: gzip, deflate」；

If- Modified-Since：該字段與客戶端緩存相關，客戶端所訪問的URL自該指定日期以來在服務端是否被修改過，若是修改過則服務端返回新的修改後 的信息，若是未修改過則服務器返回304代表此請求所指URL不曾修改過，如：「If-Modified-Since: Fri, 2 Sep 2006 19:37:36 GMT」；

If-None-Match：該字段與客戶端緩存相關，客戶端發送URL請求的同時發送該字段及標識，如 果服務端的標識與客戶端的標識一致，則返回304代表此URL未修改過，若是不一致則服務端返回完整的數據信息，如：「If-None-Match: 0f0a893aad8c61:253, 0f0a893aad8c61:252, 0f0a893aad8c61:251」；

Cookie：爲擴展字段，存儲於客戶端，向同一域名的服務端發送屬於該域的cookie，如：「Cookie: MailUserName=whouse」；

c) 實體頭(entity-header): (此類頭存在時要求有數據體)

Content-Encoding：客戶端所能識別的編碼壓縮格式，如：「Content-Encoding: gzip, deflate」；

Content-Length：客戶端以POST方法上傳數據時數據體部分的內容長度，如：「 Content-Length: 24」；

Content- Type：客戶端發送的數據體的內容類型，如：「Content-Type: application/x-www-form-urlencoded」爲以普通的POST方法發送的數據；「Content-Type: multipart/form-data; boundary=—————————5169208281820」，則代表數據體由多部分組成，分隔符爲 「—————————–5169208281820」；

響應頭格式

a) 通用頭(general-header)：

Cache- Control：服務端要求中間代理及客戶端如何緩存本身響應的數據，如「Cache-Control: no-cache」，如：「Cache-Control: private」 不但願被緩存，「Cache-Control: public」 能夠被緩存；

Connection：服務端是否但願與客戶端之間保持長鏈接，如「Connection: close」, 「Connection: keep-alive」；

Date：只有當請求方法爲POST或PUT方法時客戶端纔可能會有些字段；

Pragma：包含了服務端一些特殊響應信息，如 「Pragma: no-cache」 服務端但願代理或客戶端不該緩存結果數據；

Transfer-Encoding：服務端向客戶端傳輸數據所採用的傳輸模式(僅在HTTP1.1中出現)，如：「Transfer-Encoding: chunked」，注：該字段的優先級要高於「Content-Length」　字段的優先級；

b）響應頭(response-header)：

Accept-Ranges：代表服務端接收的數據單位，如：「Accept-Ranges: bytes」, ；

Location：服務端向客戶端返回此信息以使客戶端進行重定向，如：「Location: http://www.hexun.com」；

Server：服務端返回的用於標識本身的一些信息，如：「 Server: Microsoft-IIS/6.0」；

ETag：服務端返回的響應數據的標識字段，客戶端可根據此字段的值向服務器發送某URL是否更新的信息；

c）實體頭(entity-header): (此類頭存在時要求有數據體)

Content-Encoding：服務端所響應數據的編碼格式，如：「Content-Encoding: gzip」；

Content-Length：服務端所返回數據的數據體部分的內容長度，如：「 Content-Length: 24」；

Content-Type：服務端所返回的數據體的內容類型，如：「Content-Type: text/html; charset=gb2312」 ；

Set-Cookie：服務端返回給客戶端的cookie數據，如：「 Set-Cookie: ASP.NET_SessionId=icnh2ku2dqlmkciyobgvzl55; path=/」

服務器返回狀態碼

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

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

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

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

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

常見狀態代碼、狀態描述的說明以下。

• 200 OK：客戶端請求成功。

• 400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。

• 401 Unauthorized：請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用。

• 403 Forbidden：服務器收到請求，可是拒絕提供服務。

• 404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。

• 500 Internal Server Error：服務器發生不可預期的錯誤。

• 503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。

常見請求方法

GET、POST、HEAD、CONNECT、PUT、DELETE、TRACE、OPTIONS

1).GET

最多見的一種請求方式，當客戶端要從服務器中讀取文檔時，當點擊網頁上的連接或者經過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給客戶端。使用GET方法時，請求參數和對應的值附加在URL後面，利用一個問號（「?」）表明URL的結尾與請求參數的開始，傳遞參數長度受限制。這種方式不適合傳送私密數據。另外，因爲不一樣的瀏覽器對地址的字符限制也有所不一樣，通常最多隻能識別1024個字符，因此若是須要傳送大量數據的時候，也不適合使用GET方式。

例如：

GET http://photo.test.com/inc/global.js HTTP/1.1
Host: photo.test.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,p_w_picpath/png,*/*;q=0.5
Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: ASP.NET_SessionId=ey5drq45lsomio55hoydzc45
Cache-Control: max-age=0

2).POST

對於上面提到的不適合使用GET方式的狀況，能夠考慮使用POST方式，由於使用POST方法能夠容許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，能夠傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，並且也不會顯示在URL中。

POST方式請求行中不包含數據字符串，這些數據保存在」請求內容」部分，各數據之間也是使用」&」符號隔開。POST方式大多用於頁面的表單中。由於POST也能完成GET的功能，所以多數人在設計表單的時候一概都使用POST方式，其實這是一個誤區。GET方式也有本身的特色和優點，咱們應該根據不一樣的狀況來選擇是使用GET仍是使用POST。

例如：

POST / HTTP/1.1
Accept: p_w_picpath/gif, p_w_picpath/x-xbitmap, p_w_picpath/jpeg, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: www.test.com
Content-Length: 24
Connection: Keep-Alive
Cache-Control: no-cache
 
name=value&submit=submit

3).HEAD

HEAD就像GET，只不過服務端接受到HEAD請求後只返回響應頭，而不會發送響應內容。當咱們只須要查看某個頁面的狀態的時候，使用HEAD是很是高效的，由於在傳輸的過程當中省去了頁面內容。