Http簡史

常莽

超文本傳輸協(xié)議（Http）是分布式協(xié)作超媒體信息系統(tǒng)的應(yīng)用協(xié)議，超文本傳輸協(xié)議是萬維網(wǎng)數(shù)據(jù)通信的基礎(chǔ)，在萬維網(wǎng)中超文本文檔包括用戶可以訪問其他資源的超鏈接。Http超文本傳輸協(xié)議在網(wǎng)絡(luò)中如同空氣一般，感觸不到它的存在但又是無處不在。

萬維網(wǎng)之父蒂姆·伯納斯·李是英國工程師和計算機科學家，是最著名的萬維網(wǎng)的發(fā)明者，他是牛津大學計算機科學教授和麻省理工學院教授。他于1989年3月12日提出了一種信息管理系統(tǒng)，然后在同年11月中旬通過Internet實現(xiàn)了超文本傳輸協(xié)議Http客戶端和服務(wù)器之間的首次成功通信。他是萬維網(wǎng)聯(lián)盟W3C的負責人，該聯(lián)盟負責監(jiān)督Web的持續(xù)發(fā)展。他還是萬維網(wǎng)基金會的創(chuàng)始人，還是麻省理工學院計算機科學和人工智能實驗室CSAIL的3Com創(chuàng)始人主席和高級研究員，他也是網(wǎng)絡(luò)科學研究計劃WSRI的主任和MIT集體智慧中心的顧問委員會成員，他也是開放數(shù)據(jù)研究所的創(chuàng)始人兼總裁，目前是社交網(wǎng)絡(luò)MeWe的顧問。

2004年，伯納斯·李因其開創(chuàng)性工作而被女王伊麗莎白二世封為爵士。在2009年4月，他當選為美國國家科學院外籍研究員，位列《時代》雜志的20世紀100位最重要人物名單被譽為“萬維網(wǎng)發(fā)明者”獲得了2016年圖靈獎。

Http各個版本的基本情況

Http協(xié)議經(jīng)過20多年的演進出現(xiàn)過0.9，1.0，1.1，2.0，3.0，5個主要版本。

1. A.Http0.9版本

0.9是鼻祖版本，它的主要特點包括：

請求方法支持有限

只支持GET請求方式，不支持其他請求方式因此客戶端向服務(wù)端傳輸信息的量非常有限，現(xiàn)在常用的POST請求無法使用。

不支持請求頭header

不能在請求中指定版本號，服務(wù)端只具有返回HTML字符串的能力。

響應(yīng)即關(guān)閉

服務(wù)端相響應(yīng)之后，立即關(guān)閉TCP連接。

2. B.Http1.0版本

1.0版本主要是對0.9版本的強化，效果也比較明顯，主要特性和缺點包括：

新增了請求方法

請求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客戶端向服務(wù)端發(fā)送信息的量級。

增加請求頭和響應(yīng)頭

增添了請求頭和響應(yīng)頭的概念，可以在通信中指定了Http協(xié)議版本號，以及其他HEADER信息，使得C/S交互更加靈活方便。

豐富數(shù)據(jù)傳輸內(nèi)容

擴充了傳輸內(nèi)容格式包括：圖片、音視頻資源和二進制等都可以進行傳輸，相比0.9版本的只能傳輸HTML內(nèi)容讓Http的應(yīng)用場景更多。

鏈接復用性差

1.0版本中每個TCP連接只能發(fā)送一個請求，數(shù)據(jù)發(fā)送完畢連接就關(guān)閉，如果還要請求其他資源，就必須重新建立連接。TCP為了保證正確性和可靠性需要客戶端和服務(wù)器3次握手和4次揮手，因此建立連接成本很高，基于擁塞控制開始時發(fā)送速率較慢，所以1.0版本的性能并不理想。

無狀態(tài)無連接的弊端

1.0版本是無狀態(tài)且無連接的，換句話說就是服務(wù)器不跟蹤不記錄請求過的狀態(tài)，客戶端每次請求都需要建立TCP連接不能復用，并且1.0規(guī)定在前一個請求響應(yīng)到達之后下一個請求才能發(fā)送，如果前一個阻塞后面的請求就會被阻塞。丟包、亂序以及高成本的鏈接過程，讓復用和隊頭阻塞產(chǎn)生很多問題，所以無連接無狀態(tài)是1.0版本的一個弱肋。

3. C.Http 1.1版本

1.1版本在1.0版本發(fā)布后大約1年就推出了，是對1.0版本的優(yōu)化和完善，1.1版本的主要特點包括：

增加長連接

新增Connection字段，可以設(shè)置keep-alive值保持連接不斷開，即TCP連接默認不關(guān)閉，可以被多個請求復用，這也是1.1版本很重要的優(yōu)化，但是在S端服務(wù)器只有處理完一個回應(yīng)，才會進行下一個回應(yīng)。要是前面的回應(yīng)特別慢，后面就會有許多請求排隊等著，仍然存在隊頭阻塞問題。

管道化

在長連接的基礎(chǔ)上，管道化可以不等第一個請求響應(yīng)繼續(xù)發(fā)送后面的請求，但響應(yīng)的順序還是按照請求的順序返回，即在同一個TCP連接中，客戶端可以同時發(fā)送多個請求，進一步改進了Http協(xié)議的傳輸效率。

更多的請求方法

增加了PUT，PATCH，OPTIONS，DELETE等請求方式。

Host字段

Host字段用來指定服務(wù)器的域名，這樣就可以將多種請求發(fā)往同一臺服務(wù)器上的不同網(wǎng)站，提高了機器的復用，這個也是重要的優(yōu)化

4. D.Http 2.0版本

2.0版本是個里程碑式的版本，相比1.x版本有了非常多的優(yōu)化去適應(yīng)當前的網(wǎng)絡(luò)場景，其中幾個重要功能點包括：

二進制格式

1.x是文本協(xié)議，然而2.0是以二進制幀為基本單位，可以說是一個二進制協(xié)議，將所有傳輸?shù)男畔⒎指顬橄⒑蛶⒉捎枚M制格式的編碼，一幀中包含數(shù)據(jù)和標識符，使網(wǎng)絡(luò)傳輸變得高效而靈活。

多路復用

這是一個非常重要的改進，1.x中建立多個連接的消耗以及效率都存在問題，2.0版本的多路復用多個請求共用一個連接，多個請求可以同時在一個TCP連接上并發(fā)，主要借助于二進制幀中的標識進行區(qū)分實現(xiàn)鏈路的復用。

頭部壓縮

2.0版本使用HPACK算法對頭部HEADER數(shù)據(jù)進行壓縮，從而減少請求的大小提高效率，這個非常好理解，之前每次發(fā)送都要帶相同的HEADER，顯得很冗余，2.0版本對頭部信息進行增量更新有效地減少了頭部數(shù)據(jù)的傳輸。

服務(wù)端推送

之前1.x版本服務(wù)端都是收到請求后被動執(zhí)行，在2.0版本允許服務(wù)器主動向客戶端發(fā)送資源，這樣在客戶端可以起到加速的作用。

Http2.0詳解

前面對比了幾個版本的演進和優(yōu)化過程，接下來深入研究下2.0版本的一些特性及其基本實現(xiàn)原理。

從對比來看2.0版本并不是在1.1版本上的一些優(yōu)化而是革新，因為2.0背負了更多的性能目標任務(wù)，1.1雖然增加了長連接和管道化，但是從根本上并沒有實現(xiàn)真正的高性能。2.0的設(shè)計目標是在兼容1.x語義和操作的基礎(chǔ)上，給用戶帶來更快捷、簡單和安全的體驗，以及高效地利用當前網(wǎng)絡(luò)帶寬，為此2.0做了很多調(diào)整主要包括：二進制化分幀、多路復用和頭部壓縮等。

1. SPDY協(xié)議

說到2.0版本標準和新特性就必須提谷歌的SPDY協(xié)議，SPDY是Google開發(fā)的基于TCP的會話層協(xié)議，可以最小化網(wǎng)絡(luò)延遲提升網(wǎng)絡(luò)速度、優(yōu)化用戶的網(wǎng)絡(luò)使用體驗。SPDY并不是一種用于替代Http的協(xié)議，而是對Http協(xié)議的增強。新協(xié)議的功能包括數(shù)據(jù)流的多路復用、請求優(yōu)先級以及Http報頭壓縮，谷歌表示引入SPDY協(xié)議后，在實驗室測試中頁面加載速度比原先快64 %。

隨后SPDY協(xié)議得到Chrome，F(xiàn)irefox等大型瀏覽器的支持，這個高效的協(xié)議引起了Http工作組的注意，在此基礎(chǔ)上制定了官方Http 2.0標準。之后幾年SPDY和Http 2.0繼續(xù)演進相互促進，Http 2.0讓服務(wù)器、瀏覽器和網(wǎng)站開發(fā)者在新協(xié)議中獲得更好的體驗，很快被大眾所認可。

2.二進制分幀層

二進制分幀層在不修改請求方法和語義的基礎(chǔ)上，重新設(shè)計了編碼機制。

二進制編碼機制使得通信可以在單個TCP連接上進行，該連接在整個對話期間一直處于活躍狀態(tài)。

二進制協(xié)議將通信數(shù)據(jù)分解為更小的幀，數(shù)據(jù)幀充斥在C/S之間的雙向數(shù)據(jù)流中，就像雙向多車道的高速路，來往如織川流不息。

要理解二進制分幀層需要知道4個概念：

鏈接Link：就是指一條C/S之間的TCP鏈接，這是個基礎(chǔ)的鏈路數(shù)據(jù)的高速公路。

數(shù)據(jù)流Stream：已建立的TCP連接內(nèi)的雙向字節(jié)流，TCP鏈接中可以承載一條或多條消息。

消息Message：消息屬于一個數(shù)據(jù)流，消息就是邏輯請求或響應(yīng)消息對應(yīng)的完整的一系列幀，也就是幀組成了消息。

幀F(xiàn)rame：幀是通信的最小單位，每個幀都包含幀頭和消息體，標識出當前幀所屬的數(shù)據(jù)流。

四者是一對多的包含關(guān)系。

再來看一下Headers Frame頭部幀的結(jié)構(gòu)：從各個域可以看到長度、類型、標志位、流標識符和數(shù)據(jù)凈荷等，感興趣可以閱讀一下相關(guān)文檔。

總之2.0版本將通信數(shù)據(jù)分解為二進制編碼幀進行交換，每個幀對應(yīng)著特定數(shù)據(jù)流中的特定消息，所有幀和流都在一個TCP連接內(nèi)復用，二進制分幀協(xié)議是2.0其他功能和性能優(yōu)化的重要基礎(chǔ)。

3.多路復用

1.1版本中存在隊首阻塞問題，因此如果客戶端要發(fā)起多個并行請求來提升性能，必須使用多個TCP連接，這樣就要承受更大延時和建鏈拆鏈成本，不能有效利用TCP鏈接。

2.0版本中使用新的二進制分幀協(xié)議突破了1.0的諸多限制，從根本上實現(xiàn)了真正的請求和響應(yīng)多路復用?？蛻舳撕头?wù)器將交互數(shù)據(jù)分解為相互獨立的幀，互不影響地交錯傳輸，最后再在對端根據(jù)幀頭中的流標識符把它們重新組裝起來，從而實現(xiàn)了TCP鏈接的多路復用。

4.首部壓縮

A.HEADER冗余傳輸

Http請求都有HEADER部分，并且相對于一條鏈接而言大部分包的header部分都是相同的，這樣的話每次傳輸相同的部分確實非常浪費。

現(xiàn)代網(wǎng)絡(luò)中每個網(wǎng)頁平均包含100多個Http請求，每個請求頭平均有300～500 Byte，總數(shù)據(jù)量達到幾十KB以上，這樣可能造成數(shù)據(jù)延時，尤其復雜的WiFi環(huán)境或者蜂窩網(wǎng)絡(luò)。但是這些請求頭之間通常幾乎沒有變化，在本已經(jīng)擁擠的鏈路中多次傳輸相同的數(shù)據(jù)部分確實不是高效做法。

基于TCP設(shè)計的擁塞控制具有線增積減AIMD特性，如果發(fā)生丟包傳輸速率將大幅度下降，這樣在擁擠的網(wǎng)絡(luò)環(huán)境中大的包頭意味著只能加劇擁塞，造成低速率傳輸。

B.Http壓縮和犯罪攻擊

在2.0版本的HPACK算法之前，Http壓縮使用gzip去壓縮，后來提出的SPDY算法對Headers進行特殊設(shè)計，但是它依舊使用的是DEFLATE算法。

在后來的一些實際應(yīng)用中發(fā)現(xiàn)DEFLATE和SPDY都有被攻擊的危險，因為DEFLATE算法使用后向字符串匹配和動態(tài)Huffman編碼，攻擊者可以控制部分請求頭部，通過修改請求部分然后看壓縮之后大小改變多少，如果變小了攻擊者就知道注入的文本和請求中的某些內(nèi)容有重復。這個過程有點像俄羅斯方塊的消除過程，這樣經(jīng)過一段時間的嘗試數(shù)據(jù)內(nèi)容就可能被全部搞清楚，由于這種風險的存在才研發(fā)出更安全的壓縮算法。

C.HPACK算法

2.0版本中HPACK算法在C/S中使用首部表來存儲之前發(fā)送的鍵值對，對于相同數(shù)據(jù)通信期間幾乎不會改變的通用鍵值對只發(fā)送一次即可。

極端情況如果請求頭每次沒有變化，那么傳輸中則不包含首部，也就是首部就是零字節(jié)。如果首部鍵值對發(fā)生變化了，也只需要發(fā)送變化的數(shù)據(jù)，并且新增或修改的首部幀會被追加到首部表，首部表在鏈接存活期始終存在，并且由客戶端和服務(wù)器共同更新和維護。

簡單說就是客戶端和服務(wù)端共同維護了一個key-value的結(jié)構(gòu)，發(fā)生變化時則更新傳輸，否則就不傳輸，這樣相當于在首次全量傳輸之后增量更新傳輸即可，這個思想在日常開發(fā)中也非常普遍，不用太復雜。

5.服務(wù)端推送

服務(wù)端推送是2.0版本新增的一個強大功能，和一問一答式的C/S交互不同，推送式交互中服務(wù)器可以對客戶端的一個請求發(fā)送多個響應(yīng)，除了對最初請求的響應(yīng)外還向客戶端推送額外資源，無需客戶端明確地請求也可以推送。

舉個例子：想象一下你去餐廳吃飯，服務(wù)好的快餐廳在你點好一份牛肉面之后，還會給你送上餐巾紙、筷子、勺子甚至調(diào)料等，這樣主動式的服務(wù)，節(jié)約了客人的時間并且提高了用餐體驗。

在實際的C/S交互中這種主動推送額外資源的方法很有效，因為幾乎每個網(wǎng)絡(luò)應(yīng)用都會包含多種資源，客戶端需要全部逐個獲取他們，此時如果讓服務(wù)器提前推送這些資源，可以有效地減少額外的延遲時間，因為服務(wù)器可以知道客戶端下一步要請求什么資源。

Http 2.0和Http 3.0

科技永不止步，互聯(lián)網(wǎng)中業(yè)務(wù)是不斷迭代前進的，像Http這種重要的網(wǎng)絡(luò)協(xié)議也是如此，新版本是對舊版本的揚棄。

1. Http 2.0和TCP

Http2.0是2015年推出的，還是比較年輕的，其重要的二進制分幀協(xié)議、多路復用、頭部壓縮和服務(wù)端推送等重要優(yōu)化使Http協(xié)議真正上了一個新臺階。

像谷歌這種重要的公司并沒有滿足于此，而且想繼續(xù)提升Http的性能，花最少的時間和資源獲取極致體驗。那么肯定要問Http2.0雖然性能已經(jīng)不錯了，還有什么不足嗎？

建立連接時間長（本質(zhì)上是TCP的問題）；

隊頭阻塞問題；

移動互聯(lián)網(wǎng)領(lǐng)域表現(xiàn)不佳（弱網(wǎng)環(huán)境）。

熟悉Http2.0協(xié)議的同學應(yīng)該知道，這些缺點基本都是由于TCP協(xié)議引起的，水能載舟亦能覆舟，其實TCP也很無辜。在我們眼里，TCP是面向連接、可靠的傳輸層協(xié)議，當前幾乎所有重要的協(xié)議和應(yīng)用都是基于TCP來實現(xiàn)的。網(wǎng)絡(luò)環(huán)境的改變速度很快，但是TCP協(xié)議相對緩慢，正是這種矛盾促使谷歌做出了一個看似出乎意料的決定———基于UDP來開發(fā)新一代Http協(xié)議。

2.谷歌為什么選擇UDP

谷歌選擇UDP是看似出乎意料的，仔細想一想其實很有道理，我們來看看TCP協(xié)議的不足和UDP的一些優(yōu)點：

基于TCP開發(fā)的設(shè)備和協(xié)議非常多，兼容困難；

TCP協(xié)議棧是Linux內(nèi)部的重要部分，它的修改和升級成本很大；

UDP本身是無連接的、沒有建鏈和拆鏈成本；

UDP的數(shù)據(jù)包無隊頭阻塞問題；

UDP改造成本小。

從上面的對比可以知道，谷歌要想從TCP上進行改造升級絕非易事，但是UDP雖然沒有TCP為了保證可靠連接而引發(fā)的問題，但是UDP本身不可靠，又不能直接用。綜合而知，谷歌決定在UDP基礎(chǔ)上改造一個具備TCP協(xié)議優(yōu)點的新協(xié)議也就順理成章了，這個新協(xié)議就是QUIC協(xié)議。

3. QUIC協(xié)議和Http 3.0

維基百科對于QUIC協(xié)議的一些介紹：QUIC協(xié)議最初由Google的Jim Roskind設(shè)計，實施并于2012年部署，在2013年隨著實驗的擴大而公開宣布，并向IETF進行了描述。

QUIC提高了當前正在使用TCP的面向連接的Web應(yīng)用程序的性能。它在2個端點之間使用用戶數(shù)據(jù)報協(xié)議（UDP）建立多個復用連接來實現(xiàn)此目的。

QUIC的次要目標包括減少連接和傳輸延遲，在每個方向進行帶寬估計以避免擁塞。它還將擁塞控制算法移動到用戶空間，而不是內(nèi)核空間，此外使用前向糾錯（FEC）進行擴展，以在出現(xiàn)錯誤時進一步提高性能。

Http 3.0又稱為Http Over QUIC，其棄用TCP協(xié)議，改為使用基于UDP協(xié)議的QUIC協(xié)議來實現(xiàn)。

QUIC協(xié)議

擇其善者而從之，其不善者而改之。Http3.0既然選擇了QUIC協(xié)議，也就意味著Http 3.0基本繼承了Http 2.0的強大功能，并且進一步解決了Http 2.0存在的一些問題，同時也必然引入了新的問題。

QUIC協(xié)議必須要實現(xiàn)Http2.0在TCP協(xié)議上的重要功能，同時解決遺留問題，我們來看看QUIC是如何實現(xiàn)的。

1.隊頭阻塞問題

隊頭阻塞是計算機網(wǎng)絡(luò)中是一種性能受限的現(xiàn)象，通俗來說就是：一個數(shù)據(jù)包影響了一堆數(shù)據(jù)包，它過不來大家都走不了。

隊頭阻塞問題可能存在于Http層和TCP層，在Http1.x時2個層次都存在該問題。

Http2.0協(xié)議的多路復用機制解決了Http層的隊頭阻塞問題，但是在TCP層仍然存在隊頭阻塞問題。

TCP協(xié)議在收到數(shù)據(jù)包之后，這部分數(shù)據(jù)可能是亂序到達的，但是TCP必須將所有數(shù)據(jù)收集排序整合后給上層使用，如果其中某個包丟失了，就必須等待重傳，從而出現(xiàn)某個丟包數(shù)據(jù)阻塞整個連接的數(shù)據(jù)使用。

QUIC協(xié)議是基于UDP協(xié)議實現(xiàn)的，在一條鏈接上可以有多個流，流與流之間是互不影響的，當一個流出現(xiàn)丟包影響范圍非常小，從而解決隊頭阻塞問題。

2. 0RTT建鏈

衡量網(wǎng)絡(luò)建鏈的常用指標是RTT，也就是數(shù)據(jù)包一來一回的時間消耗。

RTT包括3部分：往返傳播時延、網(wǎng)絡(luò)設(shè)備內(nèi)排隊時延和應(yīng)用程序數(shù)據(jù)處理時延。

HttpS協(xié)議要建立完整鏈接包括：TCP握手和TLS握手，總計需要至少2～3個RTT，普通的Http協(xié)議也需要至少1個RTT才可以完成握手。然而，QUIC協(xié)議可以在第一個包就包含有效的應(yīng)用數(shù)據(jù)，從而實現(xiàn)0RTT，但這也是有條件的。

簡單來說，基于TCP協(xié)議和TLS協(xié)議的Http 2.0在真正發(fā)送數(shù)據(jù)包之前需要花費一些時間來完成握手和加密協(xié)商，完成之后才可以真正傳輸業(yè)務(wù)數(shù)據(jù)。但是QUIC則第一個數(shù)據(jù)包就可以發(fā)業(yè)務(wù)數(shù)據(jù)，從而在連接延時方面有很大優(yōu)勢，可以節(jié)約數(shù)百毫秒的時間。

QUIC的0RTT也是需要條件的，對于第一次交互的客戶端和服務(wù)端0RTT也是做不到的，畢竟雙方完全陌生，因此，QUIC協(xié)議分為首次連接和非首次連接2種情況。

3.首次連接和非首次連接

使用QUIC協(xié)議的客戶端和服務(wù)端要使用1RTT進行密鑰交換，使用的交換算法是迪菲·赫爾曼（Diffie-Hellman，DH）算法。DH算法開辟了密鑰交換的新思路，RSA算法也是基于這種思想實現(xiàn)的，但是DH算法和RSA的密鑰交換不完全一樣，感興趣的讀者可以看看DH算法的數(shù)學原理。

首次連接

簡單來說，首次連接時客戶端和服務(wù)端的密鑰協(xié)商和數(shù)據(jù)傳輸過程，其中涉及了DH算法的基本過程。

非首次連接

客戶端和服務(wù)端首次連接時服務(wù)端傳遞了config包，里面包含了服務(wù)端公鑰和2個隨機數(shù)，客戶端會將config存儲下來，后續(xù)再連接時可以直接使用，從而跳過這個1RTT，實現(xiàn)0RTT的業(yè)務(wù)數(shù)據(jù)交互。

客戶端保存config是有時間期限的，在config失效之后仍然需要進行首次連接時的密鑰交換。

4.前向安全問題

前向安全是密碼學領(lǐng)域的專業(yè)術(shù)語，百度上的解釋是：前向安全或前向保密Forward Secrecy是密碼學中通信協(xié)議的安全屬性，是指長期使用的主密鑰泄漏不會導致過去的會話密鑰泄漏。

前向安全能夠保護過去進行的通信不受密碼或密鑰在未來暴露的威脅，如果系統(tǒng)具有前向安全性，就可以保證在主密鑰泄露時歷史通信的安全，即使系統(tǒng)遭到主動攻擊也是如此。通俗來說，前向安全指的是密鑰泄漏也不會讓之前加密的數(shù)據(jù)被泄漏，影響的只有當前，對之前的數(shù)據(jù)無影響。

前面提到QUIC協(xié)議首次連接時先后生成了2個加密密鑰，由于config被客戶端存儲了，如果期間服務(wù)端私鑰泄漏，那么可以根據(jù)K = mod p，計算出密鑰K。

如果一直使用這個密鑰進行加解密，那么就可以用K解密所有歷史消息，因此后續(xù)又生成了新密鑰，使用其進行加解密，當時完成交互時則銷毀，從而實現(xiàn)了前向安全。

5.前向糾錯

前向糾錯是通信領(lǐng)域的術(shù)語，也叫前向糾錯碼（Forward Error Correction，F(xiàn)EC）是增加數(shù)據(jù)通信可信度的方法，在單向通信信道中，一旦錯誤被發(fā)現(xiàn)，其接收器將無權(quán)再請求傳輸。FEC是利用數(shù)據(jù)進行傳輸冗余信息的方法，當傳輸中出現(xiàn)錯誤，將允許接收器再建數(shù)據(jù)。

QUIC每發(fā)送一組數(shù)據(jù)就對這組數(shù)據(jù)進行異或運算，并將結(jié)果作為一個FEC包發(fā)送出去，接收方收到這一組數(shù)據(jù)后根據(jù)數(shù)據(jù)包和FEC包即可進行校驗和糾錯。

6.連接遷移

網(wǎng)絡(luò)切換幾乎無時無刻都在發(fā)生，TCP協(xié)議使用五元組來表示一條唯一的連接，當從4G環(huán)境切換到WiFi環(huán)境時，手機的IP地址就會發(fā)生變化，這時必須創(chuàng)建新的TCP連接才能繼續(xù)傳輸數(shù)據(jù)。

QUIC協(xié)議基于UDP實現(xiàn)摒棄了五元組的概念，使用64位的隨機數(shù)作為連接的ID，并使用該ID表示連接。

基于QUIC協(xié)議之下，在日常WiFi和4G切換時，或者不同基站之間切換都不會重連，從而提高業(yè)務(wù)層的體驗。

QUIC的應(yīng)用和前景

通過前面的一些介紹可以看出QUIC協(xié)議雖然是基于UDP來實現(xiàn)的，但是它將TCP的重要功能都進行了延續(xù)和優(yōu)化，否則使用者是不會買賬的。

QUIC協(xié)議的核心思想是將TCP協(xié)議在內(nèi)核實現(xiàn)的諸如可靠傳輸、流量控制和擁塞控制等功能轉(zhuǎn)移到用戶態(tài)來實現(xiàn)，同時在加密傳輸方向的嘗試也推動了TLS1.3的發(fā)展。但是TCP協(xié)議的勢力過于強大，很多網(wǎng)絡(luò)設(shè)備甚至對于UDP數(shù)據(jù)包做了很多不友好的策略，甚至進行攔截從而導致成功連接率下降。

主導者谷歌在自家產(chǎn)品做了很多嘗試，國內(nèi)騰訊公司也做了很多關(guān)于QUIC協(xié)議的嘗試。其中騰訊云對QUIC協(xié)議表現(xiàn)了很大的興趣，并做了一些優(yōu)化后在一些重點產(chǎn)品中對連接遷移、QUIC成功率和弱網(wǎng)環(huán)境耗時等進行了實驗，給出了來自生產(chǎn)環(huán)境的諸多寶貴數(shù)據(jù)。

任何新生事物的推動都是需要時間的，出現(xiàn)多年的Http 2.0和HttpS協(xié)議的普及度都沒有預想高，IPv6也是如此，不過QUIC已經(jīng)展現(xiàn)出了強大的生命力。

本文通過介紹Http協(xié)議的歷史演進、各個版本的主要特征和優(yōu)缺點、重點介紹了Http 2.0協(xié)議的一些特性，包括：SPDY協(xié)議、二進制分幀協(xié)議、多路復用、首部壓縮和服務(wù)端推送等重要功能。雖然Http2.0版本協(xié)議有很多非常優(yōu)秀的功能并且在2015年正式發(fā)布，現(xiàn)在國內(nèi)外一些大廠基本都有使用Http 2.0承擔部分請求，但是目前仍然未廣泛普及。

其實Http3.0版本在2018年也已經(jīng)推出來了，但是Http 2.0和Http 3.0的推廣和普及還是需要時間的。

不過現(xiàn)在來看QUIC協(xié)議，雖然基于UDP主體將TCP的重要功能轉(zhuǎn)移到用戶空間來實現(xiàn)，從而繞開內(nèi)核實現(xiàn)用戶態(tài)的TCP協(xié)議，但是真正實現(xiàn)起來還是非常復雜的。