Http協議構成

什麼是協議

詞條解釋：通過談判、協商而制定的共同認可、共同遵照的規定與條款。
標準協議：買票上車，司機與乘客都認同協議，只要乘客買了票，司機必須讓乘客上車。
流氓協議：生米煮成熟飯。

什麼是Http協議

Http協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW）服務器傳輸超文本到本地瀏覽器的傳送協議。
客戶端與服務端都是認同的，簡單一點理解就是客戶端找服務端要東西，也就是請求，服務端必須給客戶端東西，也就是響應。

在瀏覽器端輸入域名，會發生什麼

發生了什麼：

搜索本地Dns > 本地host > 向寬帶運營商服務器發起Dns解析請求 > 創建TCP鏈接(三次握手) > 數據傳輸 > TCP鏈接斷開（也就是揮手）

什麼是Dns

Dns是domain name service的縮寫，它的做用是將域名翻譯成ip地址。服務器或者應用，對於域名是無感知的，它們只會IP地址查找網絡節點，Dns其實就是一個翻譯，將服務器看不懂的域名地址翻譯成Ip地址，這樣用戶在瀏覽器中輸入域名，服務器就能夠經過dns知道用戶請求的是哪一個網站，而後纔將對應的網站內容返回給用戶。
Dns找不到的狀況下會從本地host中查找；
chrome查看本地Dns緩存 chrome://net-internals/#dns

Http協議分爲三部分，Http狀態行、Http請求頭，Http響應

Http狀態行

必應的：

百度的：

上面的圖片是firefox的，chrome的長這樣

狀態行由包含了請求方式，請求路徑，協議版本等數據構成
常見屬性：

Request URL：請求Url
Request Method: 請求方式，除了經常使用的GET、POST外還有PUT與DELETE
Status Code: 經常使用的狀態碼有以下幾種

1xx 信息處理狀態碼

表示數據正在處理中

2xx 成功狀態碼

* 200：數據被正常處理
* 204： 服務器接受數據並請求成功處理，但沒有資源可返回

3xx 重定向狀態碼

* 302：臨時性重定向
* 301：永久重定向，與302的區別是對於SEO更加友好，搜索引擎到頁面後爬蟲會記錄重定向的地址
* 304：重定向到本地緩存，瀏覽器中存在訪問頁面時會用到

4xx 客戶端錯誤

* 400：錯誤的請求，好比本地開發nginx配置錯誤後，訪問某個本地站點返回400
* 403：服務端收到了請求，但拒絕訪問，好比普通員工請求管理員數據提示403
* 404：找不到該路徑對應的資源

5xx 服務端錯誤

* 500：服務器端執行請求時發生錯誤
* 503：服務器處於超負載或者正在停機維護，如今沒法處理請求　　

固然Http狀態碼包含六七十種，具體能夠看W3C關於狀態碼的規範)

Remote Address: 請求遠程Ip地址
Referrer Policy: Referrer策略，當咱們在頁面中請求圖片、Js、接口的時候瀏覽器通常會加上表示來源的Reffer數據，該數據有5個值。

* no-referrer: 全部狀況下都不發送referrer
* no-referrer-when-downgrade: 協議降級時不發送 Referrer 信息，好比Https頁面中請求http資源，大部分瀏覽器默認所採用的
* Origin Only: 發送只包含host部分的Reffer信息，好比「101.101.0.3/main的referrer」值就是「101.101.0.3」
* origin-when-crossorigin: 只有跨域是才發送只包含host部分的reffer值，（域名，協議，端口其中任何一個值不一致則被認爲是跨域）
* unsafe-url: 不管任何狀況下都發送reffer信息，不多使用

Http請求頭

包含3部分，請求行、請求首部、請求體。

請求行

相似於上圖的一串數據，默認爲空

請求首部

請求首部就是客戶端向服務器提供的額外信息，好比User-Agent代表客戶端身份，代表客戶端的身份，常見的請求首部以下：

• Accept: 告知服務端客戶端接受的MIME類型數據，好比「text/html,image/jpeg」表示接受「html」文本與「jpeg」格式圖片文件
• Accept-Charset: 瀏覽器接受字符集類型，默認「utf-8」，不少中文網頁中是「gb2312」
• Accept-Encoding: 瀏覽器能解壓數據的解碼方式，常見的有「gzip、deflate、 br」,存在多個的狀況下使用逗號隔開，在瀏覽器支持的狀況下優先使用後置解壓方式，如「gzip,deflate,br」三個中優先使用br解碼
• Connection: 鏈接方式，默認「Keep-Alive」，表示須要持續鏈接，但此處的持續鏈接指的並非永久鏈接，而是指在必定時間內若是存在數據請求則會複用通一個Tcp容器傳輸數據，不然斷開
• Content-Length: 設置請求正文長度，對於Post請求無效
• Scheme: 使用協議，默認Http/Https，默認Http
• Host：瀏覽器請求的主機與端口，與Scheme配合能夠在服務端進行第三方接口轉發代理
• User-Agent：瀏覽器信息，能夠用來進行獲取訪問瀏覽器類型佔比分析。「GOOGLEBOT-IMAGE」是google的圖片爬蟲User-Agent信息，能夠用來分析網頁圖片被爬蟲抓取次數。
• Content-Type: 內容格式，好比「text/html」表示html文本，「Application/json」表示傳輸json數據。
• Cache-control: 緩存控制，這裏不作細講，詳細原理能夠看這篇博文

請求體

Get類型的請求請求內容是有長度限制的，好比IE中限制是2KB，Post中無限制。

Http響應

HTTP響應是服務器在接收客戶端發送請求後通過一些處理而作出的響應，Http響應與Http請求相似，也由三個部分組成，分別是：狀態行，響應頭，響應正文

狀態行

與Http請求狀態行一致，不深究

響應頭

響應頭就是服務端想客戶端提供的額外信息，常見的響應頭以下：

• Connection: 鏈接方式，默認「Keep-Alive」，若是服務端不支持長鏈接方式則會返回close
• Content-Type: 內容格式，好比「text/html」表示html文本，「Application/json」表示傳輸json數據。
• Set-Cookie: 設置cookie數據，包含cookie主體內容，過時時間，做用域等信息
• ...不少數據與Http請求頭一致，數據在來回傳遞

響應正文

與Http請求正文一致，區別是數據由服務度發送給客戶端

會話跟蹤

因爲Http協議是一個無狀態協議，該協議不能保存客戶信息，一旦數據傳輸完畢，下次數據請求須要從新鏈接，因此須要會話跟蹤

Cookie

簡單一點理解就是Cookie是服務端頒發給客戶端的一個通行證，用來確認客戶信息，瀏覽器獲得這個通行證後，會在本地保存起來，當瀏覽器再次請求該網站是，瀏覽器將這個通行證一併提交給服務器，服務器檢查該通行證，一次來確認用戶信息。
Cookie在請求頭和響應頭之間來回傳遞，因此客戶端與服務端都能獲取到Cookie數據。

Session

在不理解Http協議是一個無狀態協議的狀況下，初學者每每會有一個誤區，認爲Session是保存在服務端的，當服務端與客戶端鏈接關閉的時候Session會被清空。
正確的理解應該是Session實際上是一個特殊的Cookie。

• 當服務端須要未客戶客戶端的請求建立一個Session的時候，首先會檢查客戶端是否存在sessionId標識，存在SessionId的狀況下，則說明之前已經爲此客戶端建立過Session，服務器就按照SessionId把這個Session檢索出來使用。
• 客戶端不存在SessionId的狀況下，服務端會新建一個Session，而且生成一個與該Session相關聯的SessionId，SessionId通常都是通過加密計算，很難找到規律的字符串，
• 這個session id將被在本次響應中返回給客戶端保存。
• 客戶端保持SessionId的方式仍然是採用Cookie進行保存，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。
• 般這個cookie的名字都是相似於「SEEESIONID」，而。例如：xxxSESSIONID=KI98uvjFDJu671F7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWKjHb!-135785664。
• 當服務端在設置的時間段內沒有與客戶端進行Session數據的傳輸狀況下，會自動清除服務端Session對象。

舉個例子：

上圖在koaJs中添加session

上圖是服務端返回的cookie，這個cookie與通常的cookie的區別是是帶一串session標識加密字符串（koa:sess.sig=Dp_qBm3JsJX1rxvx9kgEQi64TV0）

上圖是客戶端發送的cookie，與通常的cookie的區別也是呆了一串session標識加密字符串

對比cookie：

• 若是瀏覽器禁用了Cookie，Session一樣不可以使用。
• 對比於Cookie，Session對於服務器消耗更大。

Http1.1缺點

目前大部分網站使用的都是Http1.1協議，Http1.1協議存在如下缺點

• Http1.1是文本協議，對與人類來講是很容易理解的，但對於計算力來講及其不友好，轉換效率低
• Tcp啓動與鏈接都很慢，雖然可使用keep-alive複用Tcp連接(這也是爲何網頁中的圖片資源爲何須要使用精靈圖的緣由)。
• 當網頁中資源較多的狀況下，瀏覽器處於資源控制對於單個域名會有最多同時發起6-8個鏈接請求限制
• 統一域名下Http請求頭重複
• 資源加載不能設置優先級

Http2

瞭解Http2一開始可能會有兩個誤區

• 不少教程中都把Https當作Http2來說解，╯□╰，Https是針對網頁數據加密傳輸的一種認證機制。
• Http2協議並非Http2.0協議，後續官方把後面的版本叫作http3.0了，因此2就是2了，22222222~

Http2協議專門針對Http1.1協議缺點作了改進

二進制文本協議

HTTP/2 採用二進制格式傳輸數據，而非HTTP1.1 中的文本格式，對於計算機解析起來會更高效二進制協議解析起來更高效。

單一鏈接

在同一個域名下，Http2只會建立一個Tcp或者Tls鏈接，減小了鏈接數，對於多個資源的頁面Http1.1中會建立6~8個鏈接。
而且因爲Tcp的滑動鏈接(鏈接剛開始數據傳輸很慢，後續會愈來愈快)，Http1.1中多個Tcp鏈接會致使每一個資源的請求都至關慢，Http2中因爲只建立一個鏈接，完美的避免了這種情形。
Http2中的這個鏈接能夠承載任意數量的雙向數據流。每一個數據流都以消息的形式發送，而消息由個幀(HTTP2中數據通訊的最小單位)組成。多個幀之間能夠亂序發送，由於根據幀首部的流標識能夠從新組裝。
關於幀的格式(官方)以下：

+-----------------------------------------------+
|                 Length (24)                   |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31)                      |
+=+=============================================================+
|                   Frame Payload (0...)                      ...
+---------------------------------------------------------------+

多路複用

多路複用是經過在一個流上分配多個HTTP請求響應交換來實現的。流在很大程度上是相互獨立的，所以一個請求上的阻塞或終止並不會影響其餘請求的處理。下圖一目瞭然

請求頭優化

HTT2在客戶端和服務器端使用「請求對照表」來跟蹤和存儲以前發送的請求頭key-value，對於相同的數據，再也不經過每次請求和響應發送；
在必定的時間內，在HTTP/2的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新;
每一個新的首部鍵－值對要麼被追加到當前表的末尾，要麼替換表中以前的值
而且Http2對請求頭進行數據進行「HPACK」數據壓縮，╯□╰說實話我也不知道這個是個什麼鬼~

服務端推送

服務端能夠在發送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。例如服務端能夠主動把 JS 和 CSS 文件推送給客戶端，而不須要客戶端解析 HTML 再發送這些請求。
該如何開啓，如何設置，好像沒有比較好的教程~

資源傳輸優先級

資源傳輸設置優先級，好比優先加載js腳本，讓頁面儘快出現動態效果
還沒研究過怎麼進行設置~

參考資料

http狀態碼：https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
瀏覽器緩存：https://segmentfault.com/a/1190000012233230
Session原理：https://zhuanlan.zhihu.com/p/33925382