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

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.0之前）
   限制每次TCP連接只處理一個請求。服務器處理完客戶的請求，並應答後，即斷開連接。採用這種方式可以節省服務器資源。但隨着網頁的複雜度增大，這一限制反而降低了性能，HTTP/1.0之後加入的keep-alive機制一定程度上打破了這一限制。
5. 無狀態
   協議對於事務處理沒有記憶能力。這樣的設計讓服務器可以省略很多上下文的維護工作，也有利於不穩定的網絡環境。但缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。

報文結構

請求部分

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

響應部份

1. 響應行（Response line）
   位與第一行；分爲Http/Version-number（HTTP協議及版本）、Statuscode（狀態碼）、message（狀態描述）三部分；
2. 響應報文頭（Response headers）
   從第二行開始至第一個空行結束；向客戶端傳遞附加信息，形式是:。
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爲可選值。所有可選屬性如下：

請求報文頭

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，進而獲得用戶狀態。

示意圖：

URI、URL與URN

URI（Uniform Resource Identifier）
統一資源標誌符，一個緊湊的字符串用來標示抽象或物理資源。
URL（Uniform Resource Locator）
統一資源定位符，URI的子集，除了確定一個資源，還提供一種定位該資源的主要訪問機制。
URN（Uniform Resource Name）
統一資源名稱，URI的子集，定義某事物的身份，不關心其訪問方式與位置。
示意圖：（來自維基百科）

例子：辨析https://segmentfault.com/a/1190000022295229.html#intro

https是訪問方式；segmentfault.com/a/1190000022295229.html是存放位置；#intro是資源
URL即https://segmentfault.com/a/1190000022295229.html
URN即segmentfault.com/a/1190000022295229.html#intro
兩者都是URI

後記

想要了解更多，敬請關注哦
記得留下你的贊哦