「開位」你所應該知道的HTTP——拓展篇

前言

接上篇，本篇主要對HTTP/1.1版本進行瓶頸分析，介紹爲了解決這些問題，所提出的多個擴展協議和加強協議。

《你所應該知道的HTTP》系列的其餘篇章：

• 基礎篇
• 進階篇
• 緩存篇
• HTTPS篇
• 優化篇

HTTP/1.1協議的瓶頸

1. 一條TCP鏈接上只可同時發送一個請求，請求低效。
2. 請求只能從客戶端開始，客戶端不能夠接受除響應之外的指令。
3. 請求/響應頭部不經壓縮就發送。
4. 每次互相發送相同的頭部形成的浪費較多。
5. 非強制性壓縮發送。
6. 非強制性使用安全加密（STL/SSL）。

WebSocket協議

概述

做爲HTTP的補充協議，能夠實現雙工通訊，即一問多答，也能夠服務器主動推送。其實WebSocket只是借用HTTP完成「握手」，本質已經不一樣。
WebSocket協議解決了HTTP/1.1瓶頸中①和②的問題。

WebSocket的「握手」

• 客戶端請求頭部
  請求報文頭裏新增：

Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: <隨機加密串>
  Sec-WebSocket-Protocol: <自定義服務名>
  Sec-WebSocket-Version: <協議版本號>

• 服務器應答
  狀態碼：101 Switching Protocols
  響應報文頭裏新增：

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <加密key>
Sec-WebSocket-Protocol: <自定義服務名>

過程如圖：

特色

• 真正的全雙工方式：突破HTTP一問一答的模式；
• 減小通訊量：複用TCP鏈接，只需一次「握手」。

SPDY

概述

谷歌於2012年提出SPDY，它是的基於TCP協議的會話層協議，屬於加強HTTP協議。SPDY一直處於草案階段，如今已經被HTTP/2.0取代，Chrome 51已經移除對SPDY的支持。
SPDY協議解決了HTTP/1.1瓶頸中①、③、⑤和⑥的問題，部分解決了②。

結構

SPDY定義爲會話層協議（OSI模型），在TCP/IP模型中能夠歸類爲應用層，介於STL/SSL與HTTP之間。
從底網上分別是：
IP=>TCP=>TLS/SSL=>SPDY=>HTTP

結構如圖：（圖片來自網絡）

特色

• 多路複用（多個請求併發在一個TCP鏈接上）；
• 請求優化（優先級排序）；
• 消息—幀機制；
• 支持服務器推送技術；
• 強制性壓縮（包括HTTP頭部）
• 強制使用SSL傳輸協議。

HTTP/2.0

概述

HTTP/2是HTTP協議自1999年HTTP 1.1發佈後的首個更新，主要基於SPDY協議。
HTTP/2.0基本上都能解決上面提到的有關HTTP/1.0遇到的瓶頸。

分層結構

HTTP/2.0在原有的HTTP層前加入了分幀層，相似與SPDY協議的結構，分幀層介於STL/SSL與HTTP之間。

• 分幀層：HTTP/2.0特性的核心部分；
• 數據/HTTP層：其中包含傳統上被認爲是HTTP及其關聯數據的部分。

結構如圖：（圖片來自網絡）

特色：

• 二進制分幀
  HTTP/2.0的分幀層是基於幀的二進制協議，最小消息單位是幀。這方便了機器解析，解析更加高效。每一個數據流都以消息的形式發送，而消息由一個或多個幀組成。多個幀之間能夠亂序發送，根據幀首部的流標識能夠從新組裝。
• 首部壓縮
  H2在客戶端和服務端使用「首部表」來跟蹤和存儲以前發送的頭部鍵值對，每次只須要差量更新，不須要重複交換;
  首部表在H2的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新；
  頭部內容也會被壓縮處理。
• 多路複用
  基於二進制分幀的特性，全部請求經過一個TCP鏈接併發完成，不在依賴多開TCP鏈接去實現並行加載。
• 並行雙向字節流的請求和響應
  基於二進制分幀的特性，同一個TCP鏈接上同時有多個不一樣方向的數據流，所以客戶端能夠一邊亂序發送，一邊接收響應，服務器也如此。
• 加密傳輸
  雖然協議並未嚴格限制，但現代瀏覽器都要求必須使用HTTPS，已成爲了事實上的強制標準。
• 服務器推送
  服務器能夠主動將HTML頁面相關的js和css文件推送給瀏覽器，不須要等待瀏覽器解析HTML後再發起請求獲取。遵循同源策略，瀏覽器可拒絕。
• 請求優先級
  基於二進制分幀的特性，請求能夠帶上32bit的優先級值，0表示最高優先級，數值越大優先級越低，能夠制定策略優化傳輸。

存在的問題

HTTP/2.0雖然已經解決了HTTP/1.0的諸多瓶頸問題，但依然存在問題，這些問題基本都是因爲TCP協議自己的限制致使的。

• 隊頭阻塞：這是TCP協議自己可靠性的重傳機制致使的問題，若是出現丟包，那就會不斷重試。這時候又只有一條TCP鏈接，因此會致使性能還不如HTTP1.1。
• 握手延遲大：TCP協議的三次握手依然沒法避免。

QUIC

概述

QUIC是Quick UDP Internet Connections的縮寫，讀做quick。由Google開發。
能夠認爲QUIC是爲了解決HTTP/2.0在TCP遇到的瓶頸，而在UDP上作探索所設計的方案。（參考上面HTTP2的存在問題）

特性

• 沒有隊頭阻塞的多路複用。
• UDP協議依據id尋找目標設備，在多變的移動網絡有優點。
• 前向糾錯，每一個包還包括其餘包的部分信息，能夠在丟包的狀況下依靠已接受的包的冗餘數據拼湊出丟失的部分，減小重傳。
• 不須要屢次握手，下降延遲。