一、開拓者：SPDY

1. 簡介：

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

2. 特性：

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

• 多路復用
• 頭部壓縮
• 服務器推送
• 請求優先級
• spdy的架構圖：

3. 現狀：

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

二、顛覆者：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，包括客戶端公鑰信息

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建立的連接進行通信。具體步驟如下：

• 1、客戶端發出tcp請求
• 2、服務端如果支持quic可以通過響應頭alt-svc告知客戶端
• 3、客戶端同時發起tcp連接和quic連接競賽
• 4、一旦quic建立連接獲勝則采用quic協議發送請求
• 5、如遇網絡或服務器不支持quic/udp，客戶端標記quic為broken
• 6、傳輸中的請求通過tcp重發
• 7、5min后嘗試重試quic，下一次嘗試增大到10min
• 8、一旦再次成功采用quic并把broken標記取消

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

d. 其他特性：

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

三、總結與思考

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