「開位」你所應該知道的HTTP——基礎篇

前言

本人學習HTTP相關知識的總結，力求以最簡單和高效的語言說明問題，讓你們快速掌握知識點。
本章家主要介紹HTTP協議的基礎，重點放在對cookie的講解。
本人能力有限，若有不正確之處請批評指正。

概述

HTTP全稱Hypertext Transfer Protocol，即超文本傳輸協議。
它是一種屬於應用層的通訊協議，容許將超文本標記語言（HTML）文檔從Web服務器傳送到客戶端的瀏覽器。
HTTP字面意義上就是爲了HTML的傳輸而發明的網絡協議，但進過不斷的完善、改進和發展後，它已經再也不侷限於此，好比如今css、js、圖片也是經過這個協議傳輸的。所以HTTP已經成爲了Web領域一種通用的傳輸協議。

發展簡史

• 1990年10月
  萬維網之父Tim Berners-Lee最先提出了HTTP協議
• 1991年
  HTTP/0.9誕生（Tim的文章）
• 1994年
  成立W3C組織
• 1996年5月
  HTTP/1.0發佈（RFC1945）
• 1997年1月
  HTTP/1.1發佈（初版RFC2068，第二版RFC2616）
• 2000年5月
  HTTPS發佈（RFC2818）
• 2015年5月
  HTTP/2.0（取代SPDY協議）發佈（RFC7540）
• 將來
  QUIC協議，或HTTP/3.0

特色

1. 支持客戶/服務器模式
   由客戶端向服務器發出請求，服務器端響應請求，並進行相應服務。
2. 簡單快速
   客戶向服務器請求服務時，只需傳送請求方法和路徑。因爲HTTP協議簡單、使得HTTP服務器的程序規模小，於是通訊速度很快。
3. 靈活
   HTTP容許傳輸任意類型的數據類型。傳輸的類型由Content-Type頭部標識加以標記。
4. 無鏈接（限HTTP/1.1以前）
   限制每次TCP鏈接只處理一個請求。服務器處理完客戶的請求，並應答後，即斷開鏈接。採用這種方式能夠節省服務器資源。HTTP/1.1以後加入的keep-alive機制必定程度上打破了這一限制。
5. 無狀態
   協議對於事務處理沒有記憶能力。這樣的設計讓服務器能夠省略不少上下文的維護工做，也有利於不穩定的網絡環境。但缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

報文結構

請求部分

1. 請求行（Request line）
   位與第一行；分爲Method（請求方法）、Path-to-resource（請求URI）、Http/Version-number（HTTP協議及版本）三部分。
2. 請求報文頭（Request headers）
   從第二行開始至第一個空行結束；向服務器傳遞附加信息，形式是<key>:<value>。
3. 請求報文體（Request body）
   從第一個空行以後的都是正文；可選；能夠自定義格式的文本，好比json格式、表單格式、二進制數據。

響應部份

1. 響應行（Response line）
   位與第一行；分爲Http/Version-number（HTTP協議及版本）、Statuscode（狀態碼）、message（狀態描述）三部分；
2. 響應報文頭（Response headers）
   從第二行開始至第一個空行結束；向客戶端傳遞附加信息，形式是<key>:<value>。
3. 響應報文體（Response body）
   從第一個空行以後的都是正文；可選；能夠自定義格式的文本，好比json格式、表單格式、二進制數據。

報文頭

HTTP協議的報文頭大致能夠分爲四類：通用報文頭、請求報文頭、響應報文頭和實體報文頭（描述報文體）。
在HTTP/1.1裏一共規範了47種報文頭字段。
各類報文定義參見：報文列表

請求方法

請求方法使用在請求行中，是客戶端告訴服務器該執行什麼樣的數據操做的標記，但也僅僅只是標記做用，並無嚴格意義上限制服務器的行爲。
可以嚴格遵循這套標準的服務，好比RESTful架構，有利於語義化並提供客戶端必定的自主性，但在非標準實現的服務器上，你甚至能夠用一個POST方法涵蓋GET、POST、PUT、DELETE操做。

• GET
  用來請求訪問已被URI標識的資源，會把請求的數據掛在URL中；對用戶隱私不友好；請求的字符長度有限制（IE最短，只支持2083）。
• POST
  通常用來傳輸實體的主體，目的不是獲取響應主體內容；把數據放在報文體裏傳送。
• PUT
  和POST同樣，用來提交數據，不一樣的是，PUT是冪等的，POST不是冪等的。
• HEAD
  和GET差很少，只不過是用於獲取報頭的，能夠用來驗證超連接的有效性。
• DELETE
  請求服務器刪除指定資源，和PUT同樣沒有驗證機制，存在安全隱患。
• TRACE
  回顯服務器收到請求，用於測試或診斷。
• CONNECT
  開啓一個C端和所請求資源之間的雙向溝通的通道，好比代理服務器proxy來訪問網站。
• OPTION
  用來查詢針對請求URI指定的資源支持的方法。

等冪性：若是一個方法或功能執行一次或者屢次，結果是同樣的，那麼就說這個方法或功能是等冪的。
例如，設置某個用戶的性別爲男性，這個方法不管執行一次仍是屢次，它的結果都是相同的。因此，該方法具備冪等性。
例如，某個帳戶充值100元，這個方法執行一次和執行屢次的結果是不相同的。因此，該方法不具備冪等性。

響應狀態碼

用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼。按首字母可分爲如下五大類：

• 1xx：表示消息。表明請求已被接受，須要繼續處理；只包含狀態行，幾乎不用。
• 2xx：表示成功。表明請求已被服務器接收、理解、接受。
• 3xx：重定向。表明須要客戶端採起進一步操做才能完成請求，後續的請求地址在本次的響應location域中指明。
• 4xx：請求錯誤。表明客戶端看起來可能發生了錯誤。
• 5xx：表示服務器錯誤。

完整列表請參考：狀態碼列表

cookie

概述

前面講到HTTP協議的特色時，提到其「無狀態」的特性，但實際使用中須要登陸狀態的場景是十分廣泛的，爲了解決這個問題就有了cookie機制。
cookie其實是服務器保存在客戶端上的一小段的文本信息。以鍵值對的形式保存，並由客戶端維護其有效期。服務器經過響應報文頭set-cookie進行設置。當客戶端再次請求該源時，會在請求報文頭裏將有效的cookie提交給服務器。
cookie遵循同源策略。cookie這種保存並自動回傳必定數據的特性，使基於無狀態的HTTP協議記錄穩定的狀態信息成爲了可能。

不知道同源策略是啥能夠看個人另外一篇文章的第一部分：傳送門。

格式

響應報文頭

set-cookie是響應報文頭，形如：

set-cookie: <key>=<value>; Expires=<date>; Secure; HttpOnly

key爲屬性名，value爲值，一個set-cookie設置一個key，如需設置多個key，只須要同時返回多個set-cookie，例子中Expires、Secure、HttpOnly爲可選值。全部可選屬性以下：

屬性名	說明文字
Expires	超時時間點，默認是session，即關閉瀏覽器失效。
Max-Age	失效前的秒數。優先級高於expires。
Domain	可使用這個cookie的域，二級域名可指定爲一級，一級只能指定爲一級。
Path	可使用這個cookie的路徑。
Secure	限制該cookie只經過https傳遞。
HttpOnly	限制該cookie只由服務器讀寫，不能被js獲取到。

請求報文頭

cookie是請求報文頭，形如：

cookie: <key>=<value>; <key>=<value>...

key爲屬性名，value爲值，會一次返回該源下的全部有效key，以分號爲分割。這個結果與在瀏覽器執行document.cookie獲取到的值相同。

cookie與session

session是服務器記錄客戶狀態的機制。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。客戶端再次訪問時只須要從該session中查找該用戶的狀態。
通常session與cookie配合使用，構成會話跟蹤技術，即session-cookie機制。

session-cookie機制過程以下：
服務器生成session的id（即sessionid）後，就將它經過set-cookie傳遞到客戶端，客戶端保存這個sessionid，下次請求經過cookie回傳到服務器，服務器便可經過sessionid查詢到用戶的session，進而得到用戶狀態。

示意圖：