Web通訊協議，你還須要知道： SPDY 和 QUIC

上一篇文章 前端階段性總結（一）： HTTP 協議，從1.0到2.0梳理了一下HTTP協議。本文將重點介紹，在前端通訊協議中HTTP2的前身，具備開拓性意義的SPDY，以及具備顛覆性的QUIC協議。

1、開拓者：SPDY

1. 簡介：

spdy 是由google推行的，改進版本的HTTP1.1 （那時候尚未HTTP2）。它基於TCP協議，在HTTP的基礎上，結合HTTP1.X的多個痛點進行改進和升級的產物。它的出現使web的加載速度有極大的提升。HTTP2也借鑑了不少spdy的特性。

2. 特性：

上一篇文章中有介紹，基本和HTTP2差很少，這裏就不贅述了：

• 多路複用
• 頭部壓縮
• 服務器推送
• 請求優先級

spdy的架構圖：

3. 現狀：

在HTTP2未推出以前，spdy在業界內已經有必定的市場佔用量，而且它的成績也是不容忽視的，所以在很長一段時間，市場上可能會見到spdy和h2同時使用的場景。

2、顛覆者：QUIC

1. 前置知識：

TCP 與 UDP

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。

1)提供IP環境下的數據可靠傳輸(一臺計算機發出的字節流會無差錯的發往網絡上的其餘計算機，並且計算機A接收數據包的時候，也會向計算機B回發數據包，這也會產生部分通訊量)，有效流控，全雙工操做(數據在兩個方向上能同時傳遞)，多路複用服務，是面向鏈接，端到端的傳輸;

2)面向鏈接：正式通訊前必需要與對方創建鏈接。事先爲所發送的數據開闢出鏈接好的通道，而後再進行數據發送，像打電話。

3)TCP支持的應用協議：Telnet(遠程登陸)、FTP(文件傳輸協議)、SMTP(簡單郵件傳輸協議)。TCP用於傳輸數據量大，可靠性要求高的應用。

UDP(User Datagram Protocol用戶數據報協議）是OSI（Open System Interconnection，開放式系統互聯） 參考模型中一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務。

1) 面向非鏈接的(正式通訊前沒必要與對方創建鏈接，無論對方狀態就直接發送，像短信，QQ)，不能提供可靠性、流控、差錯恢復功能。UDP用於一次只傳送少許數據，可靠性要求低、傳輸經濟等應用。
2) UDP支持的應用協議：NFS(網絡文件系統)、SNMP(簡單網絡管理系統)、DNS(主域名稱系統)、TFTP(通用文件傳輸協議)等。

總的來講：
TCP：面向鏈接、傳輸可靠(保證數據正確性,保證數據順序)、用於傳輸大量數據(流模式)、速度慢，創建鏈接須要開銷較多(時間，系統資源)。
UDP：面向非鏈接、傳輸不可靠、用於傳輸少許數據(數據包模式)、速度快。

Diffie-Hellman 算法

D-H算法的數學基礎是離散對數的數學難題，其加密過程以下：

• （1）客戶端與服務端肯定兩個大素數 n和 g，這兩個數不用保密
• （2）客戶端選擇另外一個大隨機數x，並計算A以下：A = g^x mod n
• （3）客戶端將 A 發給服務端
• （4）服務端選擇另外一個大隨機數y，並計算B以下：B = g^y mod n
• （5）服務端將B發給客戶端
• （7）計算祕密密鑰K1以下：K1=B^2 mod n ， 計算祕密密鑰K2以下：K2=A^y mod n , K1=K2，所以服務端和客戶端能夠用其進行加解密

攻擊者知道n和g，而且截獲了A和B，可是當它們都是很是大的數的時候，依靠這四個數來計算k1和k2很是困難，這就是離散對數數學難題。

2. 什麼是QUIC？

quic 是google推出的，基於UDP的高效可靠協議。quic在UDP的基礎上實現了TCP的一些特性，而因爲底層使用的是UDP，因此傳輸效率比TCP高效。

3. 特性

a. 基於UDP創建的鏈接：

咱們知道，基於TCP的協議，如http2，在首次創建鏈接的時候須要進行三次握手，即至少須要3個ntt，而考慮安全HTTPS的
TLS層，又須要至少次的通訊才能協商出密鑰。這在短鏈接的場景中極大的增長了網絡延遲，而這種延遲是沒法避免的。
而基於UDP的quic協議，則不須要3次握手的過程，甚至在安全協商階段只須要進行1~2次的協商通訊，便可創建安全穩定的鏈接，極大的減小了網絡延遲。

b. 基於Diffie-Hellman的加密算法：

HTTPS 使用的是 TLS + SSL 的加密手段，在交換證書、協商密鑰的過程當中，至少須要2次ntt進行協商通訊。而quic使用了Diffie-Hellman算法,算法的原理使得客戶端和瀏覽器之間只須要1次的協商就能得到通訊密鑰，quic創建安全連接的詳細過程:

• 客戶端發起Inchoate client hello
• 服務器返回Rejection，包括密鑰交換算法的公鑰信息，算法信息，證書信息等被放到server config中傳給客戶端
• 客戶端發起client hello，包括客戶端公鑰信息

後續發起鏈接的過程當中，一旦客戶端緩存或持久化了server config，就能夠複用並結合本地生成的私鑰進行加密數據傳輸了，不須要再次握手，從而實現0RTT創建鏈接。

c. 改進的多路複用

咱們知道，不管是HTTP2仍是SPDY,基於TCP的協議儘管實現了多路複用，但仍然沒有避免隊頭阻塞的問題，這個問題是因爲TCP底層的實現形成的，即TCP的包有嚴格的順序控制，前序包若是丟失，則後續包即便返回了也不會通知到應用層協議，從而致使了前序包阻塞。而quic基於UDP則自然的避免了這個問題，因爲UDP沒有嚴格的包順序，一個包的阻塞只會影響它自身，並不會影響到其餘資源，且quic也實現了相似HTTP2的多路複用，這種沒有隊頭阻塞的多路複用對延遲的下降是顯而易見的。

d. 鏈接的遷移

在以往的基於TCP的協議中，每每使用四元組（源IP，源端口，目的IP，目的端口）來標識一條鏈接，當四元組中的IP或端口任一個發生變化了鏈接就須要從新創建，從而不具有鏈接遷移的能力。
而QUIC使用了connection id對鏈接進行惟一標識。即便網絡從4G變成了wifi，只要兩次鏈接中的connection id不變，而且客戶端或者服務器能經過校驗，就不須要從新創建鏈接，鏈接遷移就能成功。
這在移動端場景的優點極爲明顯，由於手機常常會在wifi和4g中切換，使用quic協議下降了重建鏈接的成本。

e. 協商的升級

在chorme瀏覽器中，發起一個TCP請求，這個請求會同時與服務器開始創建tcp 和 quic 的鏈接（前提是服務器支持），若是quic鏈接先創建成功，則使用quic創建的鏈接通訊，反之，則使用tcp創建的鏈接進行通訊。具體步驟以下：

• 一、客戶端發出tcp請求
• 二、服務端若是支持quic能夠經過響應頭alt-svc告知客戶端
• 三、客戶端同時發起tcp鏈接和quic鏈接競賽
• 四、一旦quic創建鏈接獲勝則採用quic協議發送請求
• 五、如遇網絡或服務器不支持quic/udp，客戶端標記quic爲broken
• 六、傳輸中的請求經過tcp重發
• 七、5min後嘗試重試quic，下一次嘗試增大到10min
• 八、一旦再次成功採用quic並把broken標記取消

其中，支持quic的alt-svc頭部信息以下圖示：

d. 其餘特性：

• 改進的擁塞控制
• 丟包恢復
• 底層的鏈接持久化
• head stream 保證包順序
• 雙級別流量控制

3、總結與思考

在web通訊協議的演進中，SPDY是不可或缺的角色，在沒有HTTP2的時代，它的出現極大的提高了網頁加載速度，甚至HTTP2也是吸收了它不少的特性而制定的，是當之無愧的開拓者。而在有HTTP2的今天，quic協議的出現無異於對TCP的顛覆，它在底層拋棄了傳統的TCP，而使用高效的UDP，並實現了TCP的特性，而且沒有修改到應用層協議，咱們能夠無縫的基於原有的規範去開發。最後，這兩東西竟然都是google提出並推行的。只能說google真的牛叉~

參考文章
https://www.jianshu.com/p/2d8...
https://wetest.qq.com/lab/vie...
https://cloud.tencent.com/dev...
https://www.zhihu.com/questio...