HTTP知識整理

HTTP協議 HTTP協議的主要特點可概括如下：
1.支援客戶/伺服器模式。
2.簡單快速：客戶向伺服器請求服務時，只需傳送要求方法和路徑。要求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的類型不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
3.靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以標記。
4.無串連：不需連線的含義是限制每次串連只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即中斷連線。採用這種方式可以節省傳輸時間。

5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於交易處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次串連傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

HTTP請求

http請求由三部分組成，分別是：請求行、訊息前序、請求本文。
請求行格式：Method Request-URI HTTP-Version CRLF
其中， Method表示要求方法；Request-URI是一個統一資源識別項；HTTP-Version表示請求的HTTP協議版本；CRLF表示斷行符號和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。
要求方法（所有方法全為大寫）有多種，各個方法的解釋如下： GET 請求擷取Request-URI所標識的資源 POST 在Request-URI所標識的資源後附加新的資料 HEAD 請求擷取由Request-URI所標識的資源的響應訊息前序 PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識 DELETE 請求伺服器刪除Request-URI所標識的資源 TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷 CONNECT 保留將來使用 OPTIONS 請求查詢服務器的效能，或者查詢與資源相關的選項和需求 HTTP響應

在接收和解釋請求訊息後，伺服器返回一個HTTP響應訊息。
HTTP響應也是由三個部分組成，分別是：狀態行、訊息前序、響應本文。
狀態行格式：HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態碼；Reason-Phrase表示狀態碼的文本描述。
狀態碼有三位元字組成，第一個數字定義了響應的類別，且有五種可能取值： 1xx：指示資訊--表示請求已接收，繼續處理 2xx：成功--表示請求已被成功接收、理解、接受 3xx：重新導向--要完成請求必須進行更進一步的操作 4xx：用戶端錯誤--請求有語法錯誤或請求無法實現 5xx：伺服器端錯誤--伺服器未能實現合法的請求 HTTP訊息

HTTP訊息由用戶端到伺服器的請求和伺服器到用戶端的回應群組成。請求訊息和響應訊息都是由開始行（對於請求訊息，開始行就是請求行，對於響應訊息，開始行就是狀態行），訊息前序（可選），空行（只有CRLF的行），訊息本文（可選）組成。
HTTP訊息前序包括普通前序、請求前序、響應前序、實體前序。每一個前序域都是由名字+“：”+空格+值 組成，訊息前序域的名字是大小寫無關的。
1、普通前序

在普通前序中，有少數前序域用於所有的請求和響應訊息，但並不用於被傳輸的實體，只用於傳輸的訊息。
Cache-Control 用於指定緩衝指令，緩衝指令是單向的（響應中出現的緩衝指令在請求中未必會出現），且是獨立的（一個訊息的緩衝指令不會影響另一個訊息處理的緩衝機制），HTTP1.0使用的類似的前序域為Pragma。
請求時的緩衝指令包括：no-cache（用於指示請求或響應訊息不能緩衝）、no-store、max-age、max-stale、min-fresh、only-if-cached;
響應時的緩衝指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
2、請求前序

請求前序允許用戶端向伺服器端傳遞請求的附加資訊以及用戶端自身的資訊。
常用的請求前序
1）Accept
Accept請求前序域用於指定用戶端接受哪些類型的資訊。eg：Accept：image/gif，表明用戶端希望接受GIF圖象格式的資源；Accept：text/html，表明用戶端希望接受html文本。
2）Accept-Charset
Accept-Charset請求前序域用於指定用戶端接受的字元集。eg：Accept-Charset:iso-8859-1,gb2312.如果在請求訊息中沒有設定這個域，預設是任何字元集都可以接受。
3）Accept-Encoding
Accept-Encoding請求前序域類似於Accept，但是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.如果請求訊息中沒有設定這個網域服務器假定用戶端對各種內容編碼都可以接受。
4）Accept-Language
Accept-Language請求前序域類似於Accept，但是它是用於指定一種自然語言。eg：Accept-Language:zh-cn.如果請求訊息中沒有設定這個前序域，伺服器假定用戶端對各種語言都可以接受。
5）Authorization
Authorization請求前序域主要用於證明用戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到伺服器的響應代碼為401（未授權），可以發送一個包含Authorization請求前序域的請求，要求伺服器對其進行驗證。
6）Host
發送請求時，該前序域是必需的。Host請求前序域主要用於指定被請求資源的Internet主機和連接埠號碼，它通常從HTTP URL中提取出來的。
7）User-Agent
User-Agent請求前序域允許用戶端將它的作業系統、瀏覽器和其它屬性告訴伺服器。這個前序域不是必須的。
請求前序舉例：

GET /form.html HTTP/1.1 (CRLF)Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)Accept-Language:zh-cn (CRLF)Accept-Encoding:gzip,deflate (CRLF)If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)Host:www.guet.edu.cn (CRLF)Connection:Keep-Alive (CRLF)(CRLF)

3、響應前序

響應前序允許伺服器傳遞不能放在狀態行中的附加響應資訊，以及關於伺服器的資訊和對Request-URI所標識的資源進行下一步訪問的資訊。
常用的響應前序
1）Location
Location響應前序域用於重新導向接受者到一個新的位置。Location響應前序域常用在更換網域名稱的時候。
2）Server
Server響應前序域包含了伺服器用來處理請求的軟體資訊。與User-Agent請求前序域是相對應的。
4、實體前序

請求和響應訊息都可以傳送一個實體。一個實體由實體前序域和實體本文組成，但並不是說實體前序域和實體本文要在一起發送，可以只發送實體前序域。實體前序定義了關於實體本文和請求所標識的資源的元資訊。
常用的實體前序：
1）Content-Encoding
Content-Encoding實體前序域被用作媒體類型的修飾符，它的值指示了已經被應用到實體本文的附加內容的編碼，因而要獲得Content-Type前序域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content-Encoding：gzip
2）Content-Language
Content-Language實體前序域描述了資源所用的自然語言。沒有設定該域則認為實體內容將提供給所有的語言閱讀者。
3）Content-Length
Content-Length實體前序域用於指明實體本文的長度，以位元組方式儲存的十進位數字來表示。
4）Content-Type
Content-Type實體前序域用於指明發送給接收者的實體本文的媒體類型。eg：
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
5）Last-Modified
Last-Modified實體前序域用於指示資源的最後修改日期和時間。
6）Expires
Expires實體前序域給出響應到期的日期和時間。 HTTP1.0和HTTP1.1區別 1、長串連

在1.0的版本中,如果用戶端要求標頭沒有設定Connection: Keep-Alive的話,那麼每次請求完成都會立即中斷連線,然後用戶端又要重建立立一個HTTP串連.假設一個網頁包含了10個圖片,那麼為了請求圖片,用戶端必須要發送10次請求,無疑這對頻寬和資源是極大的浪費,TCP的優勢就沒有體現出來.在HTTP1.1中,keep-Alive已經被棄用(但是大多數伺服器和瀏覽器都還保留這個選項).在1.1的版本中,持久串連預設就是啟用的,除非你顯式在回應標頭部包含Connection: close,用戶端收到響應後才會關閉串連.
2 、host頭域

在HTTP1.0中認為每台伺服器都綁定一個唯一的IP地址,因此,請求訊息中的URL並沒有傳遞主機名稱(hostname).但隨著虛擬機器主機技術的發展,在一台物理伺服器上可以存在多個虛擬機器主機(Multi-homed Web Servers),並且它們共用一個IP地址.HTTP1.1的請求訊息和響應訊息都應支援Host頭域,且請求訊息中如果沒有Host頭域會報告一個錯誤(400 Bad Request).此外,伺服器應該接受以絕對路徑標記的資源請求.
3 、要求方法

HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法.
HTTP1.1 增加的新的status code：
用戶端事先發送一個只帶頭域的請求，如果伺服器因為許可權拒絕了請求，就回送響應碼401（Unauthorized）；如果伺服器接收此請求就回送響應碼100，用戶端就可以繼續發送帶實體的完整請求了。100 (Continue) 狀態碼的使用，允許用戶端在發request訊息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發request body。

HTTP1.0沒有定義任何具體的1xx status code, HTTP1.1有2個100 Continue101 Switching Protocols203 Non-Authoritative Information205 Reset Content206 Partial Content302 Found (在HTTP1.0中有個 302 Moved Temporarily)303 See Other305 Use Proxy307 Temporary Redirect405 Method Not Allowed406 Not Acceptable407 Proxy Authentication Required408 Request Timeout409 Conflict410 Gone411 Length Required412 Precondition Failed413 Request Entity Too Large414 Request-URI Too Long415 Unsupported Media Type416 Requested Range Not Satisfiable417 Expectation Failed504 Gateway Timeout505 HTTP Version Not Supported

4、內容長度

       HTTP應答訊息中發送的資料是整個發送的,Content-Length訊息頭欄位表示資料的長度.資料的長度很重要,因為用戶端需要知道哪裡是應答訊息的結束,以及後續應答訊息的開始.但是在一些動態網頁中,由於網頁是動態產生的,所以沒法計算出準確的Content-Length,這樣導致的後果是:如果 Content-Length 比實際長度短,會造成內容被截斷;如果比實體內容長,會造成 pending,瀏覽器一直轉圈.
      所以在HTTP1.1中引入了Transfer-Encoding,如果一個HTTP訊息(請求訊息或應答訊息)的Transfer-Encoding訊息頭的值為chunked,那麼,訊息體由數量未定的塊組成,並以最後一個大小為0的塊為結束.如果同時設定了Content-Length 和Transfer-Encoding,那麼Transfer-Encoding的優先順序更高,Content-Length會被忽略.
5、緩衝

      在HTTP/1.0中,使用Expire頭域來判斷資源的fresh或stale,並使用條件請求(conditional request)來判斷資源是否仍有效.例如,cache伺服器通過If-Modified-Since頭域向伺服器驗證資源的Last-Modefied頭域是否有更新,原始伺服器可能返回304(Not Modified),則表明該對象仍有效;也可能返回200(OK)替換請求的Cache對象.
      此外,HTTP/1.0中還定義了Pragma:no-cache頭域,用戶端使用該頭域說明請求資源不能從cache中擷取,而必須回源擷取.HTTP/1.1在1.0的基礎上加入了一些cache的新特性,當緩衝對象的Age超過Expire時變為stale對象,cache不需要直接拋棄stale對象,而是與原始伺服器進行重新啟用(revalidation).
      HTTP/1.0中,If-Modified-Since頭域使用的是絕對時間戳記,精確到秒,但使用絕對時間會帶來不同機器上的時鐘同步問題.而HTTP/1.1中引入了一個ETag頭域用於重啟用機制,它的值entity tag可以用來唯一的描述一個資源.請求訊息中可以使用If-None-Match頭域來匹配資源的entitytag是否有變化.
      為了使caching機制更加靈活,HTTP/1.1增加了Cache-Control頭域(請求訊息和響應訊息都可使用),它支援一個可擴充的指令子集：例如max-age指令支援相對時間戳記;private和no-store指令禁止對象被緩衝;no-transform阻止Proxy進行任何改變響應的行為.
      Cache使用關鍵字索引在磁碟中緩衝的對象,在HTTP/1.0中使用資源的URL作為關鍵字.但可能存在不同的資源基於同一個URL的情況,要區別它們還需要用戶端提供更多的資訊,如Accept-Language和Accept-Charset頭域.為了支援這種內容協商機制(content negotiation mechanism),HTTP/1.1在響應訊息中引入了Vary頭域,該頭域列出了請求訊息中需要包含哪些頭域用於內容協商. HTTP1.1和HTTP2.0區別