本文來(lái)自作者 宋璐 在 GitChat 上分享「如何快速入門(mén)網(wǎng)絡(luò)基礎(chǔ)知識(shí)（TCP/IP 和 HTTP）」，「閱讀原文」查看交流實(shí)錄
「文末高能」
編輯 | 洛肯
在寫(xiě)之前，先給這篇文章做一個(gè)明確定位，讀完這篇文章后，希望你能夠：
對(duì)于計(jì)算機(jī)網(wǎng)絡(luò)有初步的認(rèn)識(shí)和了解，了解一些經(jīng)典專業(yè)術(shù)語(yǔ)，如三次握手、四次揮手、DNS解析的含義。
了解一些應(yīng)用層協(xié)議，如傳統(tǒng)的HTTP、HTTPS協(xié)議，以及業(yè)界近幾年開(kāi)始逐步普及的HTTP2、QUIC協(xié)議。
通過(guò)實(shí)際生產(chǎn)環(huán)境下的例子，了解網(wǎng)絡(luò)優(yōu)化在項(xiàng)目中的實(shí)際意義以及帶來(lái)的效果。
為了能夠更好地理解這篇文章的內(nèi)容，建議閱讀之前做以下幾個(gè)準(zhǔn)備：
了解TCP/IP的基本概念，推薦去閱讀《TCP/IP協(xié)議詳解》中的第3章和第17章，這里給大家一個(gè)鏈接，可以免費(fèi)下載，傳送門(mén)(http://download.csdn.net/download/u012155923/10046395)。
其次希望在學(xué)習(xí)的過(guò)程中，為了能夠更好地看到效果，請(qǐng)下載抓包工具，這里推薦的是Wireshark(https://www.wireshark.org/download.html)和Charles(https://www.charlesproxy.com/download/)，大家可以下載后，結(jié)合文章內(nèi)容并嘗試抓包，更容易理解整個(gè)網(wǎng)絡(luò)轉(zhuǎn)發(fā)過(guò)程。
在學(xué)習(xí)具體知識(shí)前，搞清楚它所在的知識(shí)體系和模型是非常重要的，對(duì)于網(wǎng)絡(luò)知識(shí)亦是如此，目前公認(rèn)的網(wǎng)絡(luò)模型有兩種，一種是OSI七層模型，另一種則是TCP/IP五層模型，請(qǐng)看下圖：
可以看到，OSI七層模型和TCP/IP五層模型存在一個(gè)對(duì)應(yīng)關(guān)系，并且傳輸層以下的完全一致(TCP模型中的網(wǎng)絡(luò)接口層就是數(shù)據(jù)鏈路層和物理層的集合)，因此可以說(shuō)將OSI模型中的會(huì)話層、表示層與應(yīng)用層合并為T(mén)CP/IP模型中的應(yīng)用層后，二者基本一致。
上述兩個(gè)網(wǎng)絡(luò)模型都屬于通用網(wǎng)絡(luò)模型，相對(duì)來(lái)說(shuō)，TCP/IP模型更為普遍一些，所以我們也主要以TCP/IP模型為網(wǎng)絡(luò)模型開(kāi)展論述，這也是為什么這節(jié)課的名字TCP/IP的由來(lái)。
那么每一層都對(duì)應(yīng)哪些協(xié)議呢？請(qǐng)看下圖：
可以看到，我們熟知的一些協(xié)議，IP協(xié)議位于網(wǎng)絡(luò)層，TCP協(xié)議位于傳輸層，而HTTP協(xié)議則位于應(yīng)用層，其余還有比較熟悉的DNS協(xié)議，F(xiàn)TP協(xié)議等等，都有其所屬的層級(jí)。
我們可以通過(guò)Wireshark抓包驗(yàn)證這一點(diǎn)，隨便抓取一個(gè)HTTP報(bào)文：
從上往下依次是Frame幀頭、以太幀頭、IP協(xié)議頭、TCP協(xié)議頭和HTTP協(xié)議頭，最后的一行則是本次請(qǐng)求的數(shù)據(jù)，其格式為JSON
所謂三握四揮是指三次握手和四次揮手，也就是TCP協(xié)議建立連接和斷開(kāi)連接的過(guò)程，之所以叫做三次握手，是因?yàn)榻⑦B接的雙方需要經(jīng)過(guò)三次數(shù)據(jù)交互以后才能完成連接的建立，同樣的，四次揮手是指在斷開(kāi)連接時(shí)需要四次數(shù)據(jù)交互，其交互過(guò)程圖如下：
舉個(gè)簡(jiǎn)單的例子，兩個(gè)人小S和小C打電話，他們的三次握手建立連接過(guò)程就是：
小S：喂，是小C么？
小C：嗯嗯是的，你是小S么？
小S：是的是的，咱們開(kāi)始愉快的聊天吧！
而四次揮手的過(guò)程則是：
小S：喂，小C，我有點(diǎn)累啦，今天要不就這樣吧
小C：好呀，你休息下，我再說(shuō)兩句
小C：哎呀，我也好累呀，今天就到這里吧
小S：好，那就到這吧，886
然后小S和小C就掛了電話，我們注意到，在四次揮手的過(guò)程中，小S先提出了斷開(kāi)連接，但實(shí)際上他們的對(duì)話并沒(méi)有結(jié)束，后面小C確認(rèn)這個(gè)消息后，并沒(méi)有立馬斷開(kāi)連接，而是繼續(xù)對(duì)話，這是因?yàn)門(mén)CP協(xié)議具備全雙工特性，簡(jiǎn)單點(diǎn)說(shuō)就是一個(gè)連接，存在小C——小S和小S到小C兩條線路，而小S提出并由小C確認(rèn)關(guān)閉的只是小S——小C這條線路，因此小C還可以繼續(xù)向小S發(fā)消息，直到小C也覺(jué)得要關(guān)閉連接并由小S確認(rèn)后，兩人的所有連接才徹底關(guān)閉。
那么你肯定會(huì)問(wèn)啦，為什么TCP要這么設(shè)計(jì)呢，這是因?yàn)門(mén)CP是一個(gè)全雙工的協(xié)議，全雙工(Full Duplex)是通訊傳輸?shù)囊粋€(gè)術(shù)語(yǔ)。通信允許數(shù)據(jù)在兩個(gè)方向上同時(shí)傳輸，我們?cè)谏厦娴睦右蔡岬搅嗽谝淮蜹CP交互中，需要維持兩條線路，因此無(wú)論是在建立和斷開(kāi)的時(shí)候，都要確保兩條線路的狀態(tài)正確。
上面的闡述還是建立在理論階段，為了能更好地鞏固知識(shí)，我們利用Wireshark在實(shí)際生產(chǎn)環(huán)境下抓包看下:
客戶端IP為：10.2.203.93
服務(wù)端IP為：10.108.21.2
客戶端和服務(wù)端建立連接時(shí)的抓包情況：
可以看到由客戶端首先發(fā)SYN報(bào)文，服務(wù)端收到并回應(yīng)SYN ACK報(bào)文，客戶端最后再回一個(gè)ACK報(bào)文，連接就算建立完畢了。
再來(lái)看看斷開(kāi)連接時(shí)的情況：
和建立連接時(shí)不同，斷開(kāi)連接的發(fā)起者是服務(wù)端，可以看到服務(wù)端發(fā)送FIN報(bào)文，然后客戶端再發(fā)ACK報(bào)文，此時(shí)服務(wù)端便不再向客戶端傳輸數(shù)據(jù)，而客戶端在完成數(shù)據(jù)傳輸后，也發(fā)送FIN報(bào)文到服務(wù)端，在收到服務(wù)端的Last ACK報(bào)文后正式斷開(kāi)連接。
關(guān)于TCP連接建立和斷開(kāi)時(shí)的三握四揮就先講到這里，再附上一張TCP的狀態(tài)遷移圖，對(duì)了解整個(gè)TCP協(xié)議有很大的幫助：
DNS（Domain Name System，域名系統(tǒng)），因特網(wǎng)上作為域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，能夠使用戶更方便的訪問(wèn)互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的IP數(shù)串。通過(guò)主機(jī)名，最終得到該主機(jī)名對(duì)應(yīng)的IP地址的過(guò)程叫做域名解析（或主機(jī)名解析）。
這是來(lái)源于百度百科的一段描述，簡(jiǎn)單點(diǎn)說(shuō)DNS解析做的工作就是，讓我們把能記住的，比較好記的域名轉(zhuǎn)換為IP地址的一個(gè)系統(tǒng)，下面我們就借助Wireshark來(lái)看看它到底是怎么工作的。
我們?cè)跒g覽器中輸入www.baidu.com時(shí)，會(huì)向服務(wù)器發(fā)送DNS請(qǐng)求報(bào)文，當(dāng)服務(wù)器端處理完這個(gè)請(qǐng)求以后，就會(huì)發(fā)送DNS響應(yīng)報(bào)文，其中就包含我們關(guān)心的IP地址，可以看到我們抓到兩個(gè)報(bào)文，前者我們稱之為DNS請(qǐng)求報(bào)文，后者稱之為DNS響應(yīng)報(bào)文，注意我們的篩選條件，通過(guò)UDP端口來(lái)過(guò)濾更加方便：
先來(lái)看DNS請(qǐng)求報(bào)文：
可以看到DNS的傳輸層協(xié)議是UDP，而不是TCP，并且其端口號(hào)為53。緊接著的是Transaction ID(2字節(jié))，這個(gè)ID可以作為DNS請(qǐng)求的一個(gè)唯一ID來(lái)使用，也就是說(shuō)對(duì)于一個(gè)請(qǐng)求和應(yīng)答報(bào)文，這個(gè)ID是相同的，因此也可以借助這個(gè)ID來(lái)查找請(qǐng)求報(bào)文相對(duì)應(yīng)的應(yīng)答報(bào)文。
Flags字段長(zhǎng)度也是2字節(jié)，可以看到，16bit被分成了以下幾部分，依次為：
Response(1比特)，該值為0則說(shuō)明是一個(gè)DNS請(qǐng)求報(bào)文，為1則說(shuō)明是DNS響應(yīng)報(bào)文
opcode（4比特）：定義查詢或響應(yīng)的類型（若為0則表示是標(biāo)準(zhǔn)的，若為1則是反向的，若為2則是服務(wù)器狀態(tài)請(qǐng)求）。
AA（1比特）：授權(quán)回答的標(biāo)志位。該位在響應(yīng)報(bào)文中有效，1表示名字服務(wù)器是權(quán)限服務(wù)器
TC（1比特）：截?cái)鄻?biāo)志位。1表示響應(yīng)已超過(guò)512字節(jié)并已被截?cái)?/span>
RD（1比特）：該位為1表示客戶端希望得到遞歸回答
RA（1比特）：只能在響應(yīng)報(bào)文中置為1，表示可以得到遞歸響應(yīng)。
zero（3比特）：不說(shuō)也知道都是0了，保留字段。
rcode（4比特）：返回碼，表示響應(yīng)的差錯(cuò)狀態(tài)，通常為0和3，各取值含義如下：
0 無(wú)差錯(cuò)
1 格式差錯(cuò)
2 問(wèn)題在域名服務(wù)器上
3 域參照問(wèn)題
4 查詢類型不支持
5 在管理上被禁止
6 — 15 保留
緊接著Flags下面的幾個(gè)字段分別是：queries、answers、auth_r、add_rr，其相應(yīng)的中文含義為問(wèn)題數(shù)、資源記錄數(shù)、授權(quán)資源記錄數(shù)和額外資源記錄數(shù)，它們的長(zhǎng)度都是2字節(jié)，一般來(lái)說(shuō)queries為1，其余的字段值為0。
接下來(lái)就是報(bào)文的正文部分，這里包括要查詢的域名，查詢類型和相應(yīng)的查詢類，這里的域名的格式比較特別，在這里的域名是www.baidu.com，而標(biāo)記為藍(lán)色的部分則是報(bào)文中的表示，可以看到，03是代表3個(gè)字節(jié)，而緊跟著3個(gè)77，如果轉(zhuǎn)換為ASIC碼的話，就是0x77，因此對(duì)于www.baidu.com，首先是以“.”為分隔符，分成3個(gè)部分后，用相應(yīng)的段長(zhǎng)度再加上域名段的ASIC組成一個(gè)段，這樣就構(gòu)成了一個(gè)完整的域名。
后續(xù)的兩個(gè)字段分別是Type和Class，在這里兩個(gè)字段都為1，其中Type為A則代表此次請(qǐng)求類型是通過(guò)域名獲取IP地址，也是最為常見(jiàn)的一種DNS請(qǐng)求形式。而Class字段為1，則代表這里查詢的數(shù)據(jù)是internet數(shù)據(jù)，也是最為常見(jiàn)的一種形式。
介紹完了請(qǐng)求報(bào)文，接下來(lái)再看一下響應(yīng)報(bào)文：
響應(yīng)報(bào)文和應(yīng)答報(bào)文相同的部分就不再贅述了，可以看到Flags中的Response值為1，就說(shuō)明這是一個(gè)響應(yīng)報(bào)文，同時(shí)Transaction ID也和請(qǐng)求報(bào)文中的ID一致，說(shuō)明這就是上面那個(gè)請(qǐng)求報(bào)文所對(duì)應(yīng)的響應(yīng)報(bào)文。
請(qǐng)求報(bào)文正文中最主要的部分就是Answers字段，這里面包括了我們想要的IP地址，但是我們也注意到，對(duì)于www.baidu.com這一個(gè)域名，響應(yīng)字段居然有3條，那么究竟以哪一條為準(zhǔn)呢？我們一條條來(lái)看。
首先是第1條Answer，這里的Type類型為CNAME，這里的CNAME表示這個(gè)回應(yīng)是請(qǐng)求報(bào)文中查詢的域名的一個(gè)別名，也就是此處返回的將是www.baidu.com的一個(gè)別名，也就是www.a.shifen.com，緊接著后面兩個(gè)Answer，Type類型為A，代表返回值將是一個(gè)IPV4地址，其他的比較常見(jiàn)的Type類型還有AAAA——IPV6地址，PTR——IP地址轉(zhuǎn)換為域名，NS——名字服務(wù)器。
可以看到，對(duì)于同一個(gè)域名，可以返回多個(gè)IP地址，在上面的響應(yīng)報(bào)文中，返回了2個(gè)IP地址，分別是61.135.169.125和61.135.169.121，這就是我們最終想要的結(jié)果，為了防止其中某個(gè)IP地址出現(xiàn)異常，因此通常對(duì)于一個(gè)域名，都會(huì)有兩個(gè)甚至以上的IP地址與其對(duì)應(yīng)，這樣便可以起到一個(gè)主備容災(zāi)效果，當(dāng)其中一個(gè)IP地址無(wú)法連接時(shí)，還可以切換到另一個(gè)IP進(jìn)行訪問(wèn)。在瀏覽器中輸入 或61.135.169.121，也可以正常訪問(wèn)頁(yè)面：
對(duì)于使用chrome瀏覽器的同學(xué)，可以輸入chrome://net-internals/#dns 來(lái)查看瀏覽器DNS解析列表：
在這里可以看到你訪問(wèn)過(guò)的網(wǎng)站，以及相應(yīng)的解析記錄，這里還有一欄TTL，代表域名解析結(jié)果的生存時(shí)間，簡(jiǎn)單點(diǎn)說(shuō)就是當(dāng)我們解析完畢一個(gè)域名以后，會(huì)將其記錄緩存起來(lái)，在TTL時(shí)間之內(nèi)的訪問(wèn)，我們都直接從緩存中獲取，而不再去進(jìn)行DNS解析，這樣帶來(lái)的好處就是減少DNS解析時(shí)間，加快網(wǎng)頁(yè)訪問(wèn)速度，但同時(shí)帶來(lái)的影響就是如果TTL值過(guò)大，那么如果服務(wù)器的域名解析發(fā)生變化，也需要很長(zhǎng)時(shí)間才能在客戶端生效，所以TTL要根據(jù)實(shí)際生產(chǎn)環(huán)境需求來(lái)調(diào)整
關(guān)于DNS的解析暫時(shí)將到這里，建議大家參照上面的抓包過(guò)程去實(shí)踐一把，相信可以對(duì)整個(gè)過(guò)程有更深入的理解！
介紹完TCP協(xié)議和DNS協(xié)議之后，我們就要開(kāi)始介紹處于TCP/IP模型中最上層的應(yīng)用層協(xié)議了。應(yīng)用層協(xié)議也是和用戶交互最密切的，因此對(duì)用戶感知影響也是最直接的，下面就以此介紹幾種比較常見(jiàn)的應(yīng)用層協(xié)議。
HTTP
HTTP（HyperText Transport Protocol）是超文本傳輸協(xié)議的縮寫(xiě)，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細(xì)內(nèi)容請(qǐng)參考RFC2616。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求，請(qǐng)求頭包含請(qǐng)求的方法、URL、協(xié)議版本、以及包含請(qǐng)求修飾符、客戶信息和內(nèi)容的類似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯(cuò)誤編碼加上包含服務(wù)器信息、實(shí)體元信息以及可能的實(shí)體內(nèi)容。
上面是關(guān)于HTTP的權(quán)威描述，HTTP可以說(shuō)是整個(gè)互聯(lián)網(wǎng)當(dāng)中最普遍也是最重要的一個(gè)協(xié)議了，包括你現(xiàn)在能看到我寫(xiě)的這篇文章，也是利用HTTP進(jìn)行數(shù)據(jù)傳輸?shù)模敲醇m結(jié)是如何進(jìn)行工作的呢？這次我們借助另外一款抓包神器——Charles來(lái)進(jìn)行抓包分析。
當(dāng)我們利用瀏覽器訪問(wèn)http://www.csdn.net/時(shí)，瀏覽器會(huì)在我們輸入地址并敲下回車后在頁(yè)面顯示：
這是一個(gè)在平常不過(guò)的操作了，此時(shí)我們用Charles進(jìn)行抓包，得到下面的結(jié)果：
上面是整個(gè)完整的交互，實(shí)際上包含了兩部分，首先是HTTP request請(qǐng)求，也就是上面中上半部分，可以看到，在request請(qǐng)求中幾個(gè)關(guān)鍵點(diǎn)是GET、HTTP/1.1、Host、User-Agent、Accept以及Cookie，這些關(guān)鍵字構(gòu)成了一個(gè)request請(qǐng)求的報(bào)文頭，代表客戶端想通過(guò)本次請(qǐng)求得到服務(wù)端的哪些數(shù)據(jù)，服務(wù)端在收到request后，作出的回應(yīng)便是HTTP response報(bào)文，也就是上圖中下半部分，因?yàn)槲覀冊(cè)L問(wèn)的是csdn的主頁(yè)，并且在Accept里也指定了html是一種請(qǐng)求數(shù)據(jù)，所以response報(bào)文返回的數(shù)據(jù)里便包含了HTML數(shù)據(jù)，當(dāng)然，response報(bào)文也有其它組成部分，如下圖所示：
這里面就包括了服務(wù)端對(duì)于本次請(qǐng)求的回應(yīng)數(shù)據(jù)，其中最關(guān)鍵的便是200 OK這個(gè)字段，這是響應(yīng)狀態(tài)碼，最常見(jiàn)的就是200，也就是表明請(qǐng)求OK，還有比較常見(jiàn)的就是404和502，前者代表客戶端非法請(qǐng)求，后者代表服務(wù)端響應(yīng)失敗，比如說(shuō)我們輸入http://www.csdn.net/test123時(shí)，頁(yè)面就會(huì)提示：
HTTPS
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在HTTP與TCP之間）
從上面的闡述中我們可以得到HTTPS = HTTP + TLS這樣一個(gè)簡(jiǎn)單的結(jié)論，也就試試哦HTTPS是比HTTP更加安全的協(xié)議，并且目前已經(jīng)有不少網(wǎng)站開(kāi)始支持HTTPS了。比如說(shuō)百度：
可以看到，使用的是HTTPS協(xié)議，同時(shí)瀏覽器會(huì)提示安全，我們?cè)倏戳硗鈳讉€(gè)例子：
上圖是工行的登陸界面，可以看到也使用了HTTPS協(xié)議，如果使用的仍然是HTTP協(xié)議，瀏覽器便不會(huì)有安全字樣的提示：
哈，建行主頁(yè)竟然還沒(méi)有使用HTTPS協(xié)議，那是不是就說(shuō)明建行不安全了呢？
其實(shí)不然，我們點(diǎn)擊登陸按鈕：
可以看到使用的協(xié)議還是HTTPS協(xié)議，這說(shuō)明我們的登陸操作依然是有安全保障的，大大降低了賬號(hào)信息被盜用的可能
HTTP2
HTTP/2（超文本傳輸協(xié)議第2版，最初命名為HTTP 2.0），簡(jiǎn)稱為h2（基于TLS/1.2或以上版本的加密連接）或h2c（非加密連接）[1]，是HTTP協(xié)議的的第二個(gè)主要版本，使用于萬(wàn)維網(wǎng)。
HTTP/2是HTTP協(xié)議自1999年HTTP 1.1發(fā)布后的首個(gè)更新，主要基于SPDY協(xié)議。它由互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進(jìn)行開(kāi)發(fā)。[2]該組織于2014年12月將HTTP/2標(biāo)準(zhǔn)提議遞交至IESG進(jìn)行討論[3]，于2015年2月17日被批準(zhǔn)。[4]
HTTP/2標(biāo)準(zhǔn)于2015年5月以RFC 7540正式發(fā)表。[5]HTTP/2的標(biāo)準(zhǔn)化工作由Chrome、Opera、Firefox[6]、Internet Explorer 11、Safari、Amazon Silk及Edge等瀏覽器提供支持。[7]
多數(shù)主流瀏覽器已經(jīng)在2015年底支持了該協(xié)議。[8]此外，根據(jù)W3Techs的數(shù)據(jù)，在2017年5月，在排名前一千萬(wàn)的網(wǎng)站中，有13.7%支持了HTTP/2。
可以看到HTTP2協(xié)議已經(jīng)在互聯(lián)網(wǎng)占有一席之地，那么它究竟比HTTP強(qiáng)在哪里呢？總結(jié)了一下，大致有以下幾點(diǎn)。相比 HTTP/1.x，HTTP/2 在底層傳輸做了很大的改動(dòng)和優(yōu)化：
二進(jìn)制傳輸：HTTP2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 的文本格式。二進(jìn)制格式在協(xié)議的解析和優(yōu)化擴(kuò)展上帶來(lái)更多的優(yōu)勢(shì)和可能
多路復(fù)用：HTTP2 做到了并發(fā)請(qǐng)求。同時(shí)，流還支持優(yōu)先級(jí)和流量控制。
服務(wù)端push：服務(wù)端能夠更快的把資源推送給客戶端
首部壓縮：首部壓縮使得整個(gè)HTTP2數(shù)據(jù)包小了很多，傳輸也就會(huì)更快
QUIC
QUIC是一種新的傳輸 方式，與TCP相比可以減少延遲。 表面上，QUIC與在UDP上實(shí)現(xiàn)的TCP + TLS + HTTP / 2非常相似。由于TCP是在操作系統(tǒng)內(nèi)核和中間件固件中實(shí)現(xiàn)的，所以對(duì)TCP進(jìn)行重大改變幾乎是不可能的。但是，由于QUIC是建立在UDP之上的，所以沒(méi)有這樣的限制。
QUIC相比于上述介紹的HTTP、HTTPS和HTTP2協(xié)議最大的不同就在于，其傳輸層采用的是UDP協(xié)議而不是TCP協(xié)議，因此其具備的特性有以下幾點(diǎn)：
0-RTT 建聯(lián)(首次建聯(lián)除外)
類似TCP的可靠傳輸
類似TLS的加密傳輸，支持完美前向安全
用戶空間的擁塞控制，最新的BBR算法
支持h2的基于流的多路復(fù)用， 但沒(méi)有TCP的HOL問(wèn)題
前向糾錯(cuò)FEC
類似MPTCP的Connection migration
那在實(shí)際環(huán)境中，如何知道哪些訪問(wèn)使用了HTTP2、哪些訪問(wèn)使用了QUIC協(xié)議呢？
這里就要提到chrome的一個(gè)插件——HTTP/2 and SPDY indicator，當(dāng)下載該插件并成功訪問(wèn)后，我們就可以看到瀏覽器地址欄右側(cè)會(huì)多一個(gè)??標(biāo)志：
訪問(wèn)百度時(shí)，這個(gè)??標(biāo)志是白色的，當(dāng)我們?cè)L問(wèn)YouTube時(shí)：
會(huì)發(fā)現(xiàn)標(biāo)志變?yōu)樗{(lán)色，鼠標(biāo)移到該標(biāo)志時(shí)，提示HTTP2已經(jīng)使能，這說(shuō)明在YouTube上面已經(jīng)開(kāi)始使用HTTP2協(xié)議了，在chrome瀏覽器中輸入chrome://net-internals/#http2就可以看到具體哪些網(wǎng)站使用了HTTP2和QUIC：
本期的內(nèi)容到這里也就告一段落了，希望讀完本篇文章后，可以讓你對(duì)網(wǎng)絡(luò)有更深入的了解，并且能夠在實(shí)際生活中，去留意這些知識(shí)，尤其是抓包分析網(wǎng)絡(luò)問(wèn)題，可以說(shuō)是學(xué)習(xí)網(wǎng)絡(luò)知識(shí)和分析網(wǎng)絡(luò)問(wèn)題的最大利器。
后續(xù)我會(huì)在這一期的基礎(chǔ)上，再推出一期網(wǎng)絡(luò)知識(shí)進(jìn)階篇，敬請(qǐng)期待！
近期熱文
《Python 的 C 擴(kuò)展開(kāi)發(fā)慣例》
《輕松入門(mén) | 用 WordPress 和主題模板做網(wǎng)站》
福利
聯(lián)系客服
