SPDY和QUIC的特性及定義

一、開拓者：SPDY

1. 簡介：

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

2. 特性：

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

• 多路復(fù)用
• 頭部壓縮
• 服務(wù)器推送
• 請求優(yōu)先級
• spdy的架構(gòu)圖：

3. 現(xiàn)狀：

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

二、顛覆者：QUIC

1. 前置知識：

TCP 與 UDP

TCP（Transmission Control Protocol 傳輸控制協(xié)議） 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

1)提供IP環(huán)境下的數(shù)據(jù)可靠傳輸(一臺計算機(jī)發(fā)出的字節(jié)流會無差錯的發(fā)往網(wǎng)絡(luò)上的其他計算機(jī)，而且計算機(jī)A接收數(shù)據(jù)包的時候，也會向計算機(jī)B回發(fā)數(shù)據(jù)包，這也會產(chǎn)生部分通信量)，有效流控，全雙工操作(數(shù)據(jù)在兩個方向上能同時傳遞)，多路復(fù)用服務(wù)，是面向連接，端到端的傳輸;

2)面向連接：正式通信前必須要與對方建立連接。事先為所發(fā)送的數(shù)據(jù)開辟出連接好的通道，然后再進(jìn)行數(shù)據(jù)發(fā)送，像打電話。

3)TCP支持的應(yīng)用協(xié)議：Telnet(遠(yuǎn)程登錄)、FTP(文件傳輸協(xié)議)、SMTP(簡單郵件傳輸協(xié)議)。TCP用于傳輸數(shù)據(jù)量大，可靠性要求高的應(yīng)用。

UDP(User Datagram Protocol用戶數(shù)據(jù)報協(xié)議） 是OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)） 參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡單不可靠信息傳送服務(wù)。

1. 面向非連接的(正式通信前不必與對方建立連接，不管對方狀態(tài)就直接發(fā)送，像短信，QQ)，不能提供可靠性、流控、差錯恢復(fù)功能。UDP用于一次只傳送少量數(shù)據(jù)，可靠性要求低、傳輸經(jīng)濟(jì)等應(yīng)用。
2. UDP支持的應(yīng)用協(xié)議：NFS(網(wǎng)絡(luò)文件系統(tǒng))、SNMP(簡單網(wǎng)絡(luò)管理系統(tǒng))、DNS(主域名稱系統(tǒng))、TFTP(通用文件傳輸協(xié)議)等。

總的來說：

TCP：面向連接、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)、用于傳輸大量數(shù)據(jù)(流模式)、速度慢，建立連接需要開銷較多(時間，系統(tǒng)資源)。

UDP：面向非連接、傳輸不可靠、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快。

Diffie-Hellman 算法

D-H算法的數(shù)學(xué)基礎(chǔ)是離散對數(shù)的數(shù)學(xué)難題，其加密過程如下：

（1）客戶端與服務(wù)端確定兩個大素數(shù) n和 g，這兩個數(shù)不用保密

（2）客戶端選擇另一個大隨機(jī)數(shù)x，并計算A如下：A = g^x mod n

（3）客戶端將 A 發(fā)給服務(wù)端

（4）服務(wù)端選擇另一個大隨機(jī)數(shù)y，并計算B如下：B = g^y mod n

（5）服務(wù)端將B發(fā)給客戶端

（7）計算秘密密鑰K1如下：K1=B^2 mod n ， 計算秘密密鑰K2如下：K2=A^y mod n , K1=K2，因此服務(wù)端和客戶端可以用其進(jìn)行加解密

攻擊者知道n和g，并且截獲了A和B，但是當(dāng)它們都是非常大的數(shù)的時候，依靠這四個數(shù)來計算k1和k2非常困難，這就是離散對數(shù)數(shù)學(xué)難題。

2. 什么是QUIC？

quic 是google推出的，基于UDP的高效可靠協(xié)議。quic在UDP的基礎(chǔ)上實現(xiàn)了TCP的一些特性，而由于底層使用的是UDP，所以傳輸效率比TCP高效。

3. 特性

a. 基于UDP建立的連接：

我們知道，基于TCP的協(xié)議，如http2，在首次建立連接的時候需要進(jìn)行三次握手，即至少需要3個ntt，而考慮安全HTTPS的TLS層，又需要至少次的通信才能協(xié)商出密鑰。這在短連接的場景中極大的增加了網(wǎng)絡(luò)延遲，而這種延遲是無法避免的。

而基于UDP的quic協(xié)議，則不需要3次握手的過程，甚至在安全協(xié)商階段只需要進(jìn)行1~2次的協(xié)商通信，即可建立安全穩(wěn)定的連接，極大的減少了網(wǎng)絡(luò)延遲。

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

HTTPS 使用的是 TLS + SSL 的加密手段，在交換證書、協(xié)商密鑰的過程中，至少需要2次ntt進(jìn)行協(xié)商通信。而quic使用了Diffie-Hellman算法,算法的原理使得客戶端和瀏覽器之間只需要1次的協(xié)商就能獲得通信密鑰，quic建立安全鏈接的詳細(xì)過程:

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

c. 改進(jìn)的多路復(fù)用

我們知道，無論是HTTP2還是SPDY,基于TCP的協(xié)議盡管實現(xiàn)了多路復(fù)用，但仍然沒有避免隊頭阻塞的問題，這個問題是由于TCP底層的實現(xiàn)造成的，即TCP的包有嚴(yán)格的順序控制，前序包如果丟失，則后續(xù)包即使返回了也不會通知到應(yīng)用層協(xié)議，從而導(dǎo)致了前序包阻塞。而quic基于UDP則天然的避免了這個問題，由于UDP沒有嚴(yán)格的包順序，一個包的阻塞只會影響它自身，并不會影響到其他資源，且quic也實現(xiàn)了類似HTTP2的多路復(fù)用，這種沒有隊頭阻塞的多路復(fù)用對延遲的降低是顯而易見的。

d. 連接的遷移

在以往的基于TCP的協(xié)議中，往往使用四元組（源IP，源端口，目的IP，目的端口）來標(biāo)識一條連接，當(dāng)四元組中的IP或端口任一個發(fā)生變化了連接就需要重新建立，從而不具備連接遷移的能力。

而QUIC使用了connection id對連接進(jìn)行唯一標(biāo)識。即使網(wǎng)絡(luò)從4G變成了wifi，只要兩次連接中的connection id不變，并且客戶端或者服務(wù)器能通過校驗，就不需要重新建立連接，連接遷移就能成功。

這在移動端場景的優(yōu)勢極為明顯，因為手機(jī)經(jīng)常會在wifi和4g中切換，使用quic協(xié)議降低了重建連接的成本。

e. 協(xié)商的升級

在chorme瀏覽器中，發(fā)起一個TCP請求，這個請求會同時與服務(wù)器開始建立tcp 和 quic 的連接（前提是服務(wù)器支持），如果quic連接先建立成功，則使用quic建立的連接通信，反之，則使用tcp建立的連接進(jìn)行通信。具體步驟如下：

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

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

d. 其他特性：

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

三、總結(jié)與思考

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