網(wǎng)絡(luò)的導(dǎo)航勾哩，是從輸入 url 到最終獲取到文件的過(guò)程抗蠢。其中牽扯到瀏覽器架構(gòu)、操作系統(tǒng)思劳、網(wǎng)絡(luò)等一系列知識(shí)迅矛。本文將從各個(gè)角度詳細(xì)論述這一過(guò)程，涉及廣度與深度潜叛。如果您是已經(jīng)有一定基礎(chǔ)的同學(xué)秽褒，那么本文可以快速帶你系統(tǒng)化整理碎片化知識(shí)。
導(dǎo)航篇
本小節(jié)威兜，我們將以普通請(qǐng)求作為抓手销斟，跟隨請(qǐng)求數(shù)據(jù)包漫游整個(gè) OSI 模型，本節(jié)目錄：
解析 URI
當(dāng)我們?cè)诘刂窓谳斎胄枰?qǐng)求的網(wǎng)站地址椒舵，如：晨風(fēng) 并按下回車蚂踊，
Chrome 首先會(huì)解析內(nèi)容，判斷這是 URL 還是搜索內(nèi)容笔宿，若是搜索內(nèi)容則自動(dòng) URL 編碼并拼接為默認(rèn)搜索引擎的 params 犁钟。
如果是 URI ，如:test.com泼橘，則處理 URI涝动，添加 http 并默認(rèn)訪問(wèn) 80 端口號(hào)。
在 Chrome 層面炬灭，如果你的地址欄原本就有展示頁(yè)面醋粟，那么進(jìn)行上述操作后，會(huì)觸發(fā)當(dāng)前頁(yè)面的 beforeunload 與 unload 事件。同時(shí)瀏覽器標(biāo)簽進(jìn)入 loading 圖標(biāo)狀態(tài)昔穴，新頁(yè)面有兩個(gè)重要的時(shí)間節(jié)點(diǎn)镰官，在渲染篇會(huì)詳細(xì)介紹:
-
interactive：它表示瀏覽器已經(jīng)完成了HTML parser、Recalculate Style吗货、Layout Tree泳唠、Render Tree、draw list等工作宙搬。 -
complete: 它表示瀏覽器已經(jīng)完成頁(yè)面渲染笨腥，這會(huì)替換掉本窗口原本的位圖，顯示最新的界面勇垛。在interactive與complete之間脖母，就是渲染進(jìn)程中的合成線程的工作位置，Chrome渲染進(jìn)程基于 skia 進(jìn)行2D界面元素的繪制闲孤。
早些時(shí)候一些網(wǎng)站會(huì)在 URI 中直接制定路徑和具體的后綴的文件谆级，如：https://www.test.com/home/index.html。但是這所帶來(lái)的諸如非法訪問(wèn)等安全問(wèn)題與互聯(lián)網(wǎng)業(yè)務(wù)需求的爆發(fā)式增長(zhǎng)讼积，人們對(duì) Web 的安全性與效率有了更高的要求肥照，因此引入代理服務(wù)器滿足 保證安全、負(fù)載均衡勤众、緩存代理 等需求∮咭铮現(xiàn)代 Web 幾乎都采用代理服務(wù)器以隱藏真實(shí)的資源位置。
構(gòu)建請(qǐng)求
通過(guò) URI Check 后们颜，Chrome 需要為它創(chuàng)建 get 請(qǐng)求吕朵，在此之前先介紹一下 Chrome 的架構(gòu)組成。
Chrome 目前采用的是 SOA 架構(gòu)窥突，主要特點(diǎn)是將應(yīng)用程序的不同的 Service 進(jìn)行拆分努溃，并通過(guò)這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來(lái)。常用的進(jìn)程如下：
- 瀏覽器主進(jìn)程：負(fù)責(zé)頁(yè)面展示波岛，用戶交互茅坛，子進(jìn)程管理等功能
- 渲染進(jìn)程：每個(gè)選項(xiàng)卡都有自己的渲染進(jìn)程音半，無(wú)關(guān)乎是否為 same-site 站點(diǎn)则拷，
SandBox運(yùn)行環(huán)境，處理HTML曹鸠、CSS煌茬、JavaScript。同時(shí)V8和Blink也都運(yùn)行在該進(jìn)程中彻桃。 - 插件進(jìn)程：負(fù)責(zé)插件運(yùn)行坛善，根據(jù)插件的功能決定是否運(yùn)行在
Sandbox環(huán)境 - GPU 進(jìn)程：處理一些特殊的 CSS 效果
- NetWork Service：處理網(wǎng)絡(luò)資源加載，請(qǐng)求響應(yīng)，校驗(yàn) CORS眠屎。
- Storage Service：處理對(duì)
localStorage剔交、sessionStorage、cookie改衩、Indexed DB存儲(chǔ)的控制岖常。 - Audio Service：處理音視頻
Buffer的音量播放等操作 - V8 PAC tool：利用 V8 解析 PAC 文件，干一些你懂得的事 ??葫督。
從上文得知 Chrome 主進(jìn)程需要通過(guò) IPC 把構(gòu)建請(qǐng)求的任務(wù)委托給 NetWork Service 負(fù)責(zé)此任務(wù)竭鞍。
NetWork Service 接受任務(wù)后，創(chuàng)建了 get 請(qǐng)求橄镜，其中請(qǐng)求行由 請(qǐng)求方法 + 請(qǐng)求路徑 + HTTP 版本號(hào) 組成偎快；請(qǐng)求頭信息由 Chrome 內(nèi)置提供。
在 HTTP 2.x 標(biāo)準(zhǔn)中引入了
Hpack和Stream洽胶，其中Hpack主要的目的是壓縮請(qǐng)求報(bào)文頭信息以減少每次鏈接發(fā)送的冗余數(shù)據(jù)晒夹。 它會(huì)將報(bào)文頭信息整合成一張Hash Table，并使用Huffman編碼壓縮文本內(nèi)容姊氓。并且請(qǐng)求行也被取消惋戏，其內(nèi)容置入Hash Table首部并以:開(kāi)頭，以此區(qū)分請(qǐng)求行與請(qǐng)求頭信息他膳。Stream的作用我們稍后介紹
查找強(qiáng)緩存
NetWork Service 會(huì)委托 Storage Service 依次在 service work cache响逢、memory cache、disk cache棕孙、push cache（HTTP2 Stream）中尋找對(duì)應(yīng)的 URI 是否有可用的強(qiáng)緩存舔亭，如果存在強(qiáng)緩存，則直接使用緩存進(jìn)入瀏覽器解析環(huán)節(jié)蟀俊，否則進(jìn)入 DNS 解析钦铺。
為了方便同學(xué)們學(xué)習(xí)和驗(yàn)證，我把非 memory cache 的 cache 資源在 MacOS 的位置統(tǒng)計(jì)如下：
- Service Work Cache：
/Users/YOUR_NAME/Library/Application Support/Google/Chrome/Default/Service Worker/[CacheStorage || ScriptCache] - Disk Cache：
/Users/YOUR_NAME/Library/Application Support/Google/Chrome/Default/Application Cache/Cache
由于 Chrome 取消了通過(guò) chrome://cache 進(jìn)行訪問(wèn)肢预，因此查看這類問(wèn)題時(shí)需要自行安裝反編譯工具查看矛洞。
一般情況下大文件會(huì)默認(rèn)存放在
disk cache中，小文件存入memory cache烫映。但當(dāng)內(nèi)存使用率較高時(shí)沼本，需要緩解使用壓力會(huì)優(yōu)先放入disk cache。
HTTP 2 提供了多路復(fù)用锭沟，頭部壓縮抽兆、Service Push。其中 Service Push 是唯一需要手動(dòng)實(shí)現(xiàn)的功能族淮，Service Push 可在某次 Stream 中返回用戶端還沒(méi)主動(dòng)請(qǐng)求辫红，但是相關(guān)的數(shù)據(jù)凭涂，以節(jié)約報(bào)文上不必要的開(kāi)銷。
DNS 解析
若強(qiáng)緩存不存在或過(guò)期時(shí)贴妻，NetWork Service 繼續(xù)將報(bào)文發(fā)送至接收端切油。這需要 OS 的配合，首先需要將報(bào)文委托給 OS 至協(xié)議棧名惩，但 OS 無(wú)法識(shí)別報(bào)文對(duì)應(yīng)的 domain 白翻，因此無(wú)法提供相應(yīng)幫助。我們必須提供 IP 地址绢片。將制定域名轉(zhuǎn)換成 IP 的工作是由 DNS 服務(wù)器提供滤馍。
域名的誕生也是為了符合人們的習(xí)慣性記憶，沒(méi)有人喜歡記憶無(wú)意義的 IP 地址底循。于是便有了 DNS 服務(wù)賦能 IP 對(duì)應(yīng)的 Domain 以方便記憶巢株。
DNS 層級(jí)
由于域名系統(tǒng)是外國(guó)人發(fā)明的，因此 DNS 的層級(jí)劃分是從右往左根據(jù) **.** 進(jìn)行切分熙涤，它就像英文人名一樣阁苞，根域 / 姓氏 取域名最末尾的部分，不符合國(guó)人記憶習(xí)慣祠挫。
根據(jù)層級(jí) DNS 服務(wù)器分為：
- 根域 DNS 服務(wù)器：不保存具體的域名信息那槽，但它是通向所有頂級(jí)域 DNS 服務(wù)器的總?cè)肟?/li>
- 頂級(jí)域 DNS 服務(wù)器：代表不同的域名后綴服務(wù)器，如
cn等舔、com骚灸、tech等。同樣不保存具體的域名信息慌植，是通往對(duì)應(yīng)后綴權(quán)威 DNS 服務(wù)器的總?cè)肟?/li> - 權(quán)威 DNS 服務(wù)器：正如其名甚牲，代表著對(duì)應(yīng) Domain 映射 IP 的權(quán)威。它是存儲(chǔ)映射關(guān)系的真實(shí)服務(wù)器蝶柿。
從上圖可知丈钙，DNS 服務(wù)器之間有著類似 trie 樹(shù)的結(jié)構(gòu)，樹(shù)的每一層的信息都是完整域名的一部分且非葉子節(jié)點(diǎn)的信息均是沒(méi)有幫助的交汤。而葉子節(jié)點(diǎn)被稱為權(quán)威服務(wù)器雏赦，是 IP 與 Domain 映射關(guān)系存儲(chǔ)的實(shí)際位置鳖链。根域 DNS 服務(wù)器的信息保存在互聯(lián)網(wǎng)中所有的 DNS 服務(wù)器中癣丧，正因如此赁濒，客戶端只需要訪問(wèn)到任意 DNS 服務(wù)器就可以順著它找到根域服務(wù)器果录，從而獲取目標(biāo) IP。
Chrome 從 83 版本開(kāi)始正式開(kāi)始了 DOH 即 DNS-over-HTTPS平委，主要目的是防止原本的 DNS 請(qǐng)求因?yàn)槭?HTTP 明文傳輸導(dǎo)致容易被中間人篡改淹朋，因此 DOH 就是批著 TLS 的 DNS 請(qǐng)求。
Hosts
正如 JavaScript 的 Promise 支持 thenable施逾，instanceof 支持 Symbol.hasInstance敷矫，JSON.stringify 支持 toJSON 等等都會(huì)開(kāi)設(shè)一個(gè)定制化行為的入口。
域名解析也存在本地定制化入口 Hosts汉额。它是一個(gè)本地的關(guān)聯(lián) “數(shù)據(jù)庫(kù)”曹仗，將 Domain 與 IP 地址相對(duì)應(yīng)。解析優(yōu)先級(jí)大于 DNS 服務(wù)蠕搜。
DNS 解析流程
筆者以訪問(wèn) http://www.test.com 為例怎茫，DNS 的解析流程如下：
- 查看
hosts是否存儲(chǔ)目標(biāo)domain和IP地址的映射關(guān)系，若找到則直接返回給客戶端妓灌。 - 若
hosts不存在對(duì)應(yīng)domain轨蛤，客戶端建立DNS請(qǐng)求，問(wèn)詢本地DNS服務(wù)器Domain對(duì)應(yīng)的IP地址虫埂。 - 本地
DNS服務(wù)器收到請(qǐng)求后祥山，首先查看DNS緩存能否找到domain對(duì)應(yīng)的IP地址，若找到則直接返回給客戶端掉伏。若DNS緩存中不存在缝呕，則找到自身記錄的根域DNS地址并發(fā)起請(qǐng)求問(wèn)詢根域服務(wù)器Domain對(duì)應(yīng)的IP地址。 - 根域服務(wù)器不保存具體的數(shù)據(jù)斧散，但是指明了我們接下來(lái)詢問(wèn)的目標(biāo)：對(duì)應(yīng)
com的頂級(jí)域名服務(wù)器地址供常。 - 本地
DNS服務(wù)器收到根域的回應(yīng)后，繼續(xù)問(wèn)詢com的頂級(jí)域名服務(wù)鸡捐。 - 頂級(jí)域名服務(wù)器同理會(huì)返回相對(duì)應(yīng)
test.com的權(quán)威服務(wù)器地址栈暇。 - 本地服務(wù)器繼續(xù)問(wèn)詢權(quán)威服務(wù)器，它是域名解析結(jié)果的原出處箍镜，也是最后一次問(wèn)詢瞻鹏。
- 權(quán)威
DNS服務(wù)器返回域名對(duì)應(yīng)的IP地址給客戶端。 - 本地
DNS服務(wù)器緩存結(jié)果鹿寨。將IP發(fā)給OS新博。 -
OS返回IP至Chrome NetWork Service。
這下 NetWork Service 擁有了綠卡脚草，已經(jīng)萬(wàn)事俱備赫悄。終于可通過(guò) socket library 將數(shù)據(jù)委托給 OS 以進(jìn)入?yún)f(xié)議棧啦。同時(shí)也標(biāo)志著即將離開(kāi) OSI 應(yīng)用層馏慨。
協(xié)議棧
請(qǐng)求數(shù)據(jù)包在 OS 的幫助下進(jìn)入?yún)f(xié)議棧埂淮。工作在應(yīng)用層與傳輸層中間的協(xié)議棧會(huì)處理對(duì)應(yīng) H2 的 Hpack 和 Stream，如果 domain 使用了 TLS / SSL 協(xié)議写隶，那么 OS 會(huì)從本地加密套件列表中選取加密套件倔撞，并將信息添加至數(shù)據(jù)包。
傳輸層
至此數(shù)據(jù)包來(lái)到協(xié)議簇上層慕趴，它表示工作在傳輸層和網(wǎng)絡(luò)層相關(guān)的協(xié)議總稱痪蝇。協(xié)議簇分為上下兩個(gè)部分鄙陡，分別承擔(dān)不同的工作且上下層關(guān)系有一定的規(guī)則，上層完成部分工作后會(huì)委托下層繼續(xù)執(zhí)行躏啰。在上層協(xié)議簇中最先映入眼簾的便是負(fù)責(zé)數(shù)據(jù)包收發(fā)的 TCP / UDP
TCP
TCP 是面向一對(duì)一鏈接趁矾，可靠有狀態(tài)且基于字節(jié)流的協(xié)議。在 HTTP 傳輸數(shù)據(jù)之前给僵，首先需要 TCP 建立連接毫捣，TCP 連接的建立，通常稱為三次握手帝际。
在深入介紹 TCP 前蔓同，我們得先了解 MTU，它是一個(gè)網(wǎng)絡(luò)包的最大長(zhǎng)度蹲诀，在以太網(wǎng)中一般為 1500 字節(jié)牌柄。而我們的 HTTP 數(shù)據(jù)表都昌都很有可能會(huì)大于 1500，所以要對(duì)超出的內(nèi)容進(jìn)行切片發(fā)送侧甫，TCP 會(huì)對(duì)報(bào)文進(jìn)行切分并添加一些信息以確保每個(gè)數(shù)據(jù)包能順利到達(dá)接收端珊佣。TCP 數(shù)據(jù)的最大長(zhǎng)度為 MSS，它通過(guò) MTU - TCP head - IP head 計(jì)算而來(lái)披粟。至此我們介紹下 TCP Head 具體添加的信息咒锻。
源端口、目標(biāo)端口
首先是一組端口號(hào)守屉，如果沒(méi)有它們惑艇，數(shù)據(jù)包到端后不知道自己是屬于哪個(gè)端口應(yīng)用的數(shù)據(jù)。
同時(shí)拇泛，我們也通過(guò)源 IP滨巴、源端口、目標(biāo) IP 和目標(biāo)端口組成唯一的標(biāo)識(shí)俺叭。
這時(shí)候可能有同學(xué)提出疑問(wèn)恭取，那么瀏覽器打開(kāi)多個(gè)頁(yè)簽時(shí)，如果訪問(wèn)的域名和端口也一樣熄守，數(shù)據(jù)如何對(duì)應(yīng)正確的標(biāo)簽蜈垮？筆者推斷 Chrome 可能通過(guò) TCP 的 timestamp 或 ISN 進(jìn)行識(shí)別，若有同學(xué)能提供準(zhǔn)確的答案歡迎指出裕照。
Sequence Number
簡(jiǎn)稱 seq攒发，它代表本報(bào)文段第一個(gè)字節(jié)的序列號(hào)，序列號(hào)是一個(gè)長(zhǎng)為 4 個(gè)字節(jié)晋南，也就是能夠表示 32 位的無(wú)符號(hào)整數(shù)惠猿。如果到達(dá)最大值了后就循環(huán)到 0。它主要有以下幾個(gè)作用
- 確保端具有發(fā)送功能的標(biāo)志负间。
- 初次發(fā)送 SYN 報(bào)文時(shí)交換 ISN偶妖。
- 確保被切分的數(shù)據(jù)包以正確的順序組裝姜凄。
ISN 即 Initial Sequence Number，通過(guò)三次握手中的前兩次握手進(jìn)行交換餐屎，其目的是防止不法分子得知 ISN 后偽造 IP 和 Port 通過(guò) TCP 標(biāo)志位對(duì)鏈接進(jìn)行非法攻擊檀葛。由于現(xiàn)在的 ISN 并不是一個(gè)固定的值玩祟，而是每 4 ms 加一腹缩，溢出則回到 0。從而大大提高了攻擊者猜測(cè) ISN 的難度空扎。
Acknowledgment Number
簡(jiǎn)稱 ack藏鹊，和 seq 一樣，占有 4 個(gè)字節(jié)转锈，具體表示小于此字節(jié)的內(nèi)容均已收到盘寡。它主要有以下幾個(gè)作用
- 確保端具有接收能力
- 告知發(fā)送端期望下一次發(fā)送的數(shù)據(jù)起始位置
標(biāo)記位
根據(jù) TCP 報(bào)文處理信息的類別不同，需要給予一定的標(biāo)識(shí)撮慨，這就是標(biāo)記位竿痰。
常見(jiàn)的標(biāo)記位有 SYN，ACK砌溺，FIN影涉，RST，PSH规伐。這方面比較基礎(chǔ)蟹倾，不清楚的同學(xué)可以結(jié)合三次握手去詳細(xì)了解。
窗口大小
它賦能 TCP 做流量控制猖闪，通信雙方各聲明一個(gè)窗口（緩存大邢侍摹），標(biāo)識(shí)自己當(dāng)前能夠的處理能力培慌。這也被稱為初始化窗口豁陆。
除了用滑動(dòng)窗口做流量控制以外，TCP 還會(huì)通過(guò)擁塞窗口做擁塞控制吵护，通過(guò)初始化的擁塞窗口采取慢啟動(dòng)献联、快速重傳和快速恢復(fù)、擁塞避免等能力何址。
校驗(yàn)和
占用兩個(gè)字節(jié)里逆，防止傳輸過(guò)程中數(shù)據(jù)包有損壞，如果遇到校驗(yàn)和有差錯(cuò)的報(bào)文用爪，TCP 則直接丟棄原押，通過(guò)使返回的 ack 值保持不變以提醒發(fā)送端需要重傳。
緊急指針
這是為了應(yīng)對(duì)一些應(yīng)用程序在某些緊急情況下（如在某些連接中進(jìn)行強(qiáng)制中斷）
要求在接收方在沒(méi)有處理完數(shù)據(jù)之前就能夠發(fā)送一些緊急數(shù)據(jù)偎血。
選項(xiàng)
這是 TCP 中的可選項(xiàng)诸衔，其中比較重要的是
- TimeStamp:
TCP時(shí)間戳盯漂，解決RTT錯(cuò)亂與序列號(hào)回繞 - MSS：前文提過(guò)，通過(guò)
MTU-TCP head-IP head計(jì)算而來(lái)笨农。
回到三次握手就缆，所謂的建立連接，只是雙方計(jì)算機(jī)里維護(hù)一個(gè)狀態(tài)機(jī)谒亦，在連接建立的過(guò)程中竭宰，雙方的狀態(tài)從 close → established。通過(guò)三次握手的 SYN份招，ACK 傳遞確保雙方的發(fā)送接收能力切揭。
在 Linux 中我們可以通過(guò) netstat -napt 來(lái)查看 TCP 鏈接狀態(tài)：
tcp 0 0 0.0.0.0:5440 0.0.0.0:* LISTEN 9138/java
tcp 1070 0 199.161.10.251:9020 199.161.10.251:34512 CLOSE_WAIT 4122/java
tcp 1 0 199.161.10.251:60254 199.161.100.195:38399 CLOSE_WAIT 7377/java
tcp 1076 0 199.161.10.251:9020 199.161.10.251:34540 CLOSE_WAIT 4122/java
tcp 416 0 199.161.10.251:9020 199.161.10.251:39166 CLOSE_WAIT 4122/java
tcp 0 0 199.161.10.251:36956 199.161.10.116:22 ESTABLISHED 7377/java
在實(shí)際的網(wǎng)絡(luò)環(huán)境中，此時(shí)數(shù)據(jù)包傳輸被阻塞锁摔，先和對(duì)端完成三次握手廓旬，之后才繼續(xù)發(fā)送數(shù)據(jù)。這也是人們?cè)?HTTP3.0 前谐腰，稱 HTTP 是基于 TCP 的主要原因孕豹，同時(shí)從此處可以看出** TCP 的隊(duì)頭阻塞**是個(gè)不可避免的問(wèn)題。
TCP 還提供了 keep-alive 功能十气，但是非常雞肋励背。
UDP
UCP 是面向無(wú)連接，一對(duì)多發(fā)送且無(wú)狀態(tài)的協(xié)議桦踊。
由于 TCP 的先入為主且其可靠性經(jīng)受住了歷史的考驗(yàn)椅野，讓我們很容易相信它會(huì)一直保持 Web 端傳輸層的主導(dǎo)地位，然而 Google 團(tuán)隊(duì)的開(kāi)創(chuàng)能力籍胯，也再一次讓筆者大開(kāi)眼界竟闪。HTTP 3.0 標(biāo)準(zhǔn)將拋棄 TCP。 UDP 成功獲得主導(dǎo)地位杖狼。
主要的原因想必大家早已略有耳聞炼蛤，TCP 鏈接必須經(jīng)歷三次握手，即便你使用了 TFO (TCP Fast Open) 也一樣蝶涩。如果需要提高數(shù)據(jù)交互的安全性理朋，既增加傳輸層安全協(xié)議（TLS），在確保安全的 Session Ticket 優(yōu)化方案下也需要增加 1 RTT绿聘。我們不考慮 PSK嗽上，因?yàn)樗话踩熄攘？傊?TCP 協(xié)議連接建立的成本相對(duì)較高兽愤，由于 TCP 是在操作系統(tǒng)內(nèi)核和中間件固件（上文所提的協(xié)議棧）中實(shí)現(xiàn)的，因此對(duì) TCP 進(jìn)行重大更改幾乎是不可能的。
而 UDP 協(xié)議是無(wú)連接協(xié)議浅萧≈鹕常客戶端發(fā)出 UDP 數(shù)據(jù)包后，只能“假設(shè)”這個(gè)數(shù)據(jù)包已經(jīng)被服務(wù)端接收洼畅。好處是在傳輸層無(wú)需對(duì)數(shù)據(jù)包進(jìn)行校驗(yàn)吩案，一般用于網(wǎng)絡(luò)游戲、流媒體數(shù)據(jù)的一些傳輸帝簇。與之相對(duì)的徘郭，如果需要確保數(shù)據(jù)傳輸?shù)目煽啃裕瑧?yīng)用層協(xié)議需要自己對(duì)包傳輸情況進(jìn)行確認(rèn)己儒。此協(xié)議就是 QUIC
QUIC 協(xié)議是基于 UDP 的低時(shí)延的互聯(lián)網(wǎng)傳輸層協(xié)議崎岂。 HTTP 2.0 解決了由 HTTP 引起的隊(duì)頭阻塞問(wèn)題捆毫，但更深層次的 TCP 隊(duì)頭阻塞問(wèn)題無(wú)法避免闪湾，QUIC 基于 UDP 協(xié)議，因此徹底解決了所有隊(duì)頭阻塞問(wèn)題绩卤。
QUIC 協(xié)議根據(jù)連接的服務(wù)器是新的還是已知的途样，可在 1-2 個(gè) RTT 內(nèi)完成連接的創(chuàng)建（包括支持 TLS），這具備很高的誘惑力濒憋。
QUIC 雖然有諸多優(yōu)勢(shì)何暇，但目前仍未達(dá)到大量普及的階段，并且目前部分路由會(huì)封殺 QUIC 所在的 443 端口凛驮，UDP 包過(guò)多讓服務(wù)商誤以為是攻擊裆站、防火墻對(duì) QUIC 的支持等均未到位。讓我們一起期待 QUIC 協(xié)議規(guī)范能夠成為終稿并實(shí)現(xiàn)推廣的那天黔夭。
本文主要還是以目前主流的 TCP 為主宏胯，經(jīng)過(guò) TCP 包頭后，當(dāng)前數(shù)據(jù)包如下：
TCP / IP 協(xié)議簇下層
在傳輸層執(zhí)行連接本姥、收發(fā)肩袍、斷開(kāi)等各階段操作都需要委托 IP 協(xié)議將數(shù)據(jù)包封裝成網(wǎng)絡(luò)包發(fā)送給通信對(duì)象。下面我們來(lái)看看 IP 報(bào)文頭部的格式
其中最重要的是源 IP 與目標(biāo) IP婚惫。
- 源 IP 即當(dāng)前客戶端的 IP 地址
- 目標(biāo) IP 為 DNS 域名解析得到的接收端服務(wù)器 IP
其次是 IP Header 中的協(xié)議號(hào)氛赐，表示傳輸層使用的協(xié)議。以十六進(jìn)制表示先舷。例如 06 表示的是 TCP艰管。經(jīng)過(guò) IP Header 包裝后，如下：
路由表
通過(guò) IP Head蒋川，我們知曉了接收數(shù)據(jù)的目標(biāo) IP牲芋，但我們不能確定這個(gè) IP 距離我們地址位置有多遠(yuǎn)，很多時(shí)候或許我們無(wú)法直接發(fā)送到對(duì)端，而是要在網(wǎng)關(guān)中進(jìn)行數(shù)次中轉(zhuǎn)街图，控制此過(guò)程就是根據(jù)路由表的規(guī)則浇衬。
在 Linux 系統(tǒng)可以根據(jù) route -n 查看當(dāng)前系統(tǒng)的路由表。
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 199.161.100.1 0.0.0.0 UG 100 0 0 eth0
199.254.169.254 199.161.100.153 255.255.255.255 UGH 100 0 0 eth0
199.161.100.0 0.0.0.0 255.255.252.0 U 100 0 0 eth0
此步也是網(wǎng)關(guān)是否介入鏈接過(guò)程的關(guān)鍵分歧點(diǎn)餐济。來(lái)看看路由表是如何工作的耘擂。
- 首先根據(jù)路由表 list 依次取出每一條信息
- 根據(jù)每條信息中的子網(wǎng)掩碼（Genmask）與接收方的目標(biāo) IP 進(jìn)行與運(yùn)算，如果結(jié)果和 Destination 匹配絮姆，說(shuō)明與我們通信的對(duì)端處在同一以太網(wǎng)中醉冤，接下去的發(fā)送不需要走網(wǎng)關(guān)。并確定以當(dāng)前的 IP 作為 IP 包頭地址篙悯。
- 若以上匹配都失敗了蚁阳，那么會(huì)匹配到默認(rèn)網(wǎng)關(guān)，一般這就是路由器的 IP鸽照，最后網(wǎng)絡(luò)包會(huì)轉(zhuǎn)發(fā)給路由器螺捐，讓路由器幫忙發(fā)送。
ARP
生成 IP 包頭后矮燎，網(wǎng)絡(luò)包還需要加上 MAC 包頭定血，IP 的誕生是為了更加方便的管理計(jì)算機(jī)在各類以太網(wǎng)中的身份。而連入所有網(wǎng)絡(luò)的每一個(gè)計(jì)算機(jī)都會(huì)有網(wǎng)卡接口诞外，每一個(gè)網(wǎng)卡都會(huì)有一個(gè)唯一的地址澜沟，這個(gè)地址就叫做 MAC 地址。計(jì)算機(jī)之間的數(shù)據(jù)傳送峡谊，就是通過(guò) MAC 地址來(lái)唯一尋找茫虽、傳送的。MAC 包頭的結(jié)構(gòu)如下：
其中發(fā)送方的 MAC 非常容易確認(rèn)既们，因?yàn)?MAC 在網(wǎng)卡生產(chǎn)過(guò)程中已經(jīng)寫入 ROM 中濒析，直接讀取此值寫入 MAC 頭部即可。
接收端的 MAC 地址相對(duì)復(fù)雜一些贤壁，當(dāng)前我們已經(jīng)知曉了接收方的 IP悼枢，通過(guò)子網(wǎng)掩碼，我們能把接收端分為兩類
- 處于同一子網(wǎng)的鄰居
- 處于外部子網(wǎng)的通信對(duì)象脾拆，我們交給居委會(huì)大媽（網(wǎng)關(guān)）去通信
可以看得出來(lái)馒索，不論通訊對(duì)象是否是鄰居，我們首次發(fā)送的對(duì)象都是同一子網(wǎng)的名船，也許是鄰居服務(wù)器也許是網(wǎng)關(guān)绰上。因此我們使用廣播進(jìn)行問(wèn)詢目標(biāo)的 MAC 地址。
廣播
ARP 協(xié)議會(huì)在以太網(wǎng)中以廣播的形式渠驼，對(duì)以太網(wǎng)所有的設(shè)備問(wèn)話路由表匹配的目標(biāo) IP 地址對(duì)應(yīng)的 MAC 地址蜈块。
就像操場(chǎng)的喊話，所有人都可以聽(tīng)見(jiàn)，但如果喊話對(duì)象不是自己百揭，不再回應(yīng)就是爽哎。被喊話的對(duì)象聽(tīng)見(jiàn)后，以 MAC 地址作為回應(yīng)器一。
ARP 緩存
正如大部分服務(wù)一樣课锌，ARP 也有自己的緩存系統(tǒng)，以空間換時(shí)間提高效率祈秕。獲取到 MAC 地址后渺贤，OS 會(huì)把本次查詢結(jié)果放到一塊叫做 ARP 緩存的內(nèi)存空間留著以后用，不過(guò)緩存的時(shí)間就幾分鐘请毛。
也就是說(shuō)志鞍，在構(gòu)建 MAC 包頭時(shí)：
- 先查詢 ARP 緩存，如果其中已經(jīng)保存了對(duì)方的 MAC 地址方仿，就不需要發(fā)送 ARP 廣播查詢固棚，直接使用 ARP 緩存中的地址。
- 而當(dāng) ARP 緩存中不存在對(duì)方 MAC 地址時(shí)兼丰，則發(fā)送 ARP 廣播查詢玻孟。
linux 中可以使用 arp -a 查看 ARP 緩存的內(nèi)容
gateway (199.161.100.1) at 79:2c:29:11:0a:32 [ether] on eth0
? (199.161.100.251) at ff:91:13:17:a0:00 [ether] on eth0
? (199.161.101.189) at ff:63:8a:1f:83:00 [ether] on eth0
? (199.161.100.153) at b3:ab:ef:43:1d:40 [ether] on eth0
得到接收方 MAC 地址后唆缴，讀取自身網(wǎng)卡 ROM 的 MAC 地址鳍征，塞入 MAC 頭，目前的數(shù)據(jù)包呈現(xiàn)為：
ICMP
ICMP 協(xié)議是 IP 的一個(gè)組成部分面徽，必須由每個(gè)IP模塊實(shí)現(xiàn)艳丛。
主要用于在 IP 主機(jī)、路由器之間傳遞控制消息趟紊〉控制消息是指網(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)霎匈、路由是否可用等網(wǎng)絡(luò)本身的消息戴差。
網(wǎng)卡與驅(qū)動(dòng)
通過(guò)協(xié)議棧生成的網(wǎng)絡(luò)包只是內(nèi)存中的一串二進(jìn)制信息，還是無(wú)法直接進(jìn)行發(fā)送铛嘱。需要將數(shù)字信息轉(zhuǎn)換成電信號(hào)暖释，計(jì)算機(jī)底層實(shí)際上也是各種邏輯電路的組合，通過(guò)晶體管等硬件改變高低電壓墨吓。轉(zhuǎn)換成數(shù)字信號(hào)后球匕，就可以在網(wǎng)線上進(jìn)行傳輸。這就是數(shù)據(jù)真正的發(fā)送過(guò)程帖烘。同時(shí)網(wǎng)卡負(fù)責(zé)的部分也被稱為 Ethernet Frame
網(wǎng)卡負(fù)責(zé)執(zhí)行這一操作亮曹，但是要控制網(wǎng)卡，必須依靠網(wǎng)卡驅(qū)動(dòng)程序，它內(nèi)置了網(wǎng)卡行為的一些方法照卦。具體步驟如下：
- 網(wǎng)卡驅(qū)動(dòng)從 IP 模塊獲取到網(wǎng)絡(luò)包后式矫，會(huì)復(fù)制其二進(jìn)制信息至網(wǎng)卡內(nèi)的緩存區(qū)。為了區(qū)分這一段段的數(shù)據(jù)役耕，我們需要一套規(guī)則來(lái)傳輸二進(jìn)制衷佃，比如多少電信號(hào)為一組，如何識(shí)別開(kāi)頭和結(jié)尾等等蹄葱。
- 因此我們?cè)诙M(jìn)制信息的起始位置添加報(bào)頭和二進(jìn)制幀的起始分解符氏义，用來(lái)表示包的起始位置
- 在數(shù)據(jù)包結(jié)尾加上 FCS，也被稱為幀校驗(yàn)序列图云，檢查包在傳輸過(guò)程中是否損壞惯悠。
- 最后網(wǎng)卡將包轉(zhuǎn)換為電信號(hào)，通過(guò)網(wǎng)線和光纖等物理介質(zhì)進(jìn)行傳輸竣况。
最后整個(gè)數(shù)據(jù)幀呈現(xiàn)如下圖：
電信號(hào)護(hù)航者
中繼器
由于電信號(hào)在傳輸過(guò)程中會(huì)不斷衰減克婶，為了不讓信號(hào)衰減對(duì)通信質(zhì)量產(chǎn)生影響，產(chǎn)生了中繼器丹泉。它僅做放大信號(hào)作用情萤，能把信號(hào)傳導(dǎo)偏遠(yuǎn)的地方。
集線器
我們假設(shè)參與網(wǎng)絡(luò)鏈接的雙方都只有一個(gè)網(wǎng)絡(luò)接口摹恨，那么只能夠建立一對(duì)一的通信筋岛，從前文也可以發(fā)現(xiàn)，我們需要有廣播這樣一對(duì)多的場(chǎng)景晒哄，廣播也就是將信號(hào)進(jìn)行復(fù)制睁宰，這就是集線器的作用，并且可以將電信號(hào)整形再放大寝凌。它工作于物理層柒傻。
順便提一下它和交換機(jī)的區(qū)別，它沒(méi)有交換機(jī)的智能記憶和學(xué)習(xí)能力较木，也不具備交換機(jī)所具有的 MAC 地址表红符。它發(fā)送數(shù)據(jù)時(shí)都是沒(méi)有針對(duì)性的，可以說(shuō)它就是廣播發(fā)送的代名詞伐债。
網(wǎng)橋
自從有集線器以來(lái)它解決了一對(duì)多的效率問(wèn)題预侯，同時(shí)也帶來(lái)了問(wèn)題，在真實(shí)的網(wǎng)絡(luò)環(huán)境中泳赋，很有可能有多個(gè)集線器連接在一起雌桑，但由于是用來(lái)做廣播通信，會(huì)互相沖突祖今，因此我們需要能夠有效隔離各個(gè)子網(wǎng)校坑，這就是網(wǎng)橋拣技。名稱也非常形象。它位于數(shù)據(jù)鏈路層耍目，而集線器是在物理層膏斤。因此它可以有效的控制讓廣播通信僅僅在于一個(gè)局部，局部和局部中間用網(wǎng)橋連接邪驮。
網(wǎng)橋原理
現(xiàn)在我們來(lái)介紹下網(wǎng)橋是如何解決廣播沖突的莫辨。網(wǎng)橋只有兩個(gè)端口，連接兩個(gè)端口的網(wǎng)絡(luò)被切分成 A毅访、B 兩個(gè)子網(wǎng)沮榜，網(wǎng)橋內(nèi)部會(huì)為每個(gè)子網(wǎng)維護(hù)一張表，一開(kāi)始表是空的喻粹，網(wǎng)橋會(huì)分別根據(jù) A蟆融、B 子網(wǎng)發(fā)送的數(shù)據(jù)包，并解開(kāi) MAC 頭部獲取源 MAC 地址守呜，并記錄在對(duì)應(yīng)的表中型酥，并轉(zhuǎn)發(fā)給另一子網(wǎng)。工作一段時(shí)候后幾乎可以記錄下 A查乒、B 子網(wǎng)中所有的機(jī)器的 MAC 地址弥喉。此時(shí)假設(shè)網(wǎng)橋接收 A 子網(wǎng)的數(shù)據(jù)包，它還是會(huì)拆解 MAC 頭部查看接收端 MAC 地址玛迄。如果發(fā)現(xiàn) A 表已經(jīng)記錄了此 MAC 地址由境，說(shuō)明這不需要廣播給 B 子網(wǎng)，A 子網(wǎng)內(nèi)就可以解決憔晒，網(wǎng)關(guān)會(huì)丟棄此數(shù)據(jù)包藻肄，如果 A 表不存在接口端 MAC 地址，則轉(zhuǎn)發(fā)給 B 子網(wǎng)拒担，再查看源 MAC 地址，如果不存在則繼續(xù)補(bǔ)充在 A 表上攻询。到此就徹底解決了因集線器整形擴(kuò)大數(shù)據(jù)包后子網(wǎng)間廣播沖突的問(wèn)題从撼。
在實(shí)際環(huán)境中，網(wǎng)橋內(nèi)部不一定有兩個(gè)子表钧栖，也可能是收集在一起的低零，具體要看內(nèi)部實(shí)現(xiàn)決定。
交換機(jī)
網(wǎng)橋是切分一個(gè)局域網(wǎng)一分為二拯杠，也解決了廣播沖突問(wèn)題掏婶，但歷史的車輪總在向前，由于網(wǎng)橋是數(shù)據(jù)鏈路層的廣播通信潭陪，A 和 B 通信的時(shí)候雄妥，C 和 D 就沒(méi)法通信最蕾。就像一座小橋負(fù)載有限，無(wú)法讓多人一起通過(guò)老厌。為了能夠?qū)崿F(xiàn)多對(duì)多的通信瘟则，于是多端口的網(wǎng)橋誕生了，這就是交換機(jī)枝秤。
電信號(hào)與交換機(jī)
我們回到正軌醋拧，網(wǎng)卡根據(jù)以太網(wǎng)協(xié)議給二進(jìn)制數(shù)據(jù)添加起始符和 FCS，并轉(zhuǎn)換為電信號(hào)進(jìn)行發(fā)送淀弹。
之后電信號(hào)通過(guò)網(wǎng)線到達(dá)交換機(jī)網(wǎng)線接口丹壕，交換機(jī)內(nèi)模塊接收后會(huì)將電信號(hào)轉(zhuǎn)換為數(shù)字信號(hào)，數(shù)字信號(hào)表示讓信息參數(shù)在給定范圍內(nèi)表現(xiàn)的更加連續(xù)薇溃，而不是離散雀费。與之相對(duì)的是模擬信號(hào)。
交換機(jī)的一個(gè)重要的作用就是確保數(shù)據(jù)包能夠原樣的轉(zhuǎn)發(fā)到目的地痊焊。他會(huì)拆解以太網(wǎng)頭部獲取 FCS 校驗(yàn)錯(cuò)誤盏袄，如果數(shù)據(jù)沒(méi)問(wèn)題則進(jìn)入交換機(jī)緩沖區(qū)，之后部分基本和之前網(wǎng)卡的概念相同薄啥，但是工作方式和網(wǎng)卡不一樣辕羽，因?yàn)榫W(wǎng)卡的 ROM 中有 MAC 地址，而交換機(jī)沒(méi)有垄惧。取而代之的是交換機(jī)會(huì)維護(hù)一張 MAC 地址表刁愿。地址表主要包含兩個(gè)信息：
- 記錄下接收方 MAC 地址的信息
- 記錄下此接收方的設(shè)備鏈接在交換機(jī)的哪個(gè)端口上。
細(xì)心的同學(xué)應(yīng)該發(fā)現(xiàn)了到逊，這部分和網(wǎng)橋非常相似铣口，只是網(wǎng)橋只有兩個(gè)端口，通過(guò)拆表記錄觉壶，可以不記錄端口位置信息脑题。如果目前的數(shù)據(jù)包和 MAC 表上記錄的 MAC 地址匹配上了，就會(huì)直接轉(zhuǎn)發(fā)到對(duì)應(yīng)的端口铜靶。如果找不到指定的 MAC 地址叔遂，很可能此地址背后的設(shè)備還沒(méi)有和交換機(jī)發(fā)送過(guò)包，或者因?yàn)槌掷m(xù)沒(méi)有工作争剿，導(dǎo)致交換機(jī)把它從地址表中刪除了已艰。此時(shí)只能和廣播一樣，發(fā)送給所有的端口蚕苇，前文也提過(guò)哩掺，在同一以太網(wǎng)中，設(shè)計(jì)之初就是以廣播的形式發(fā)送給整個(gè)網(wǎng)絡(luò)的所有設(shè)備涩笤，只有接收者才會(huì)接收包嚼吞，其他設(shè)備會(huì)忽略盒件。接收方返回響應(yīng)后，交換機(jī)會(huì)對(duì)其 MAC 地址進(jìn)行記錄誊薄。
除了沒(méi)有記錄的 MAC 地址會(huì)轉(zhuǎn)發(fā)到除了源端口外的所有端口外履恩，如果接收地址滿足廣播地址，也會(huì)觸發(fā)同樣的行為呢蔫，常見(jiàn)的廣播地址有：
- MAC 地址的 FF:FF:FF:FF:FF:FF
- IP 地址的 255.255.255.255
網(wǎng)關(guān)
前文講述路由表時(shí)提過(guò)切心，如果沒(méi)有比配到默認(rèn)網(wǎng)關(guān)的情況下，是可能不需要網(wǎng)關(guān)的片吊，因此我們假設(shè)之前的接收方 IP 地址匹配到了默認(rèn)網(wǎng)關(guān)绽昏。
默認(rèn)網(wǎng)關(guān)一般就是路由器的別稱，到達(dá)路由器時(shí)也可以比作高速路的關(guān)卡俏脊，數(shù)據(jù)包準(zhǔn)備離開(kāi)子網(wǎng)了全谤。下文我們以路由器代指網(wǎng)關(guān)。
路由器爷贫，也被稱為三層網(wǎng)絡(luò)設(shè)備认然，路由器每個(gè)端口都有 MAC 地址和 IP 地址。所以它可以作為以太網(wǎng)的發(fā)送和接收端漫萄，從此角度來(lái)看卷员，它和網(wǎng)卡是一樣的。我們來(lái)看看路由器的工作流程：
- 路由器會(huì)拆解以太網(wǎng)首部腾务，驗(yàn)證 FCS 校驗(yàn)毕骡，如果沒(méi)有問(wèn)題進(jìn)入下一步
- 接下來(lái)拆解 MAC 首部，查看接收方的 MAC 地址是否是自己岩瘦，不是自己就丟棄數(shù)據(jù)包
- 如果是發(fā)送給自己的包未巫，此 MAC 首部的任務(wù)徹底完成，便完全刪掉 MAC 頭部启昧。繼續(xù)拆解 IP 首部叙凡，讀取到 IP 地址。
- 接著查詢自身的路由表箫津，這和 IP 層查詢路由表的操作一致狭姨，先驗(yàn)證子網(wǎng)掩碼，再看具體的子網(wǎng) IP
- 如果網(wǎng)關(guān)為空苏遥，則表示對(duì)應(yīng)的 IP 地址就是目標(biāo)地址，已經(jīng)抵達(dá)終點(diǎn)赡模。
- 如果沒(méi)有匹配上路由表的子網(wǎng)田炭，說(shuō)明還未抵達(dá)終點(diǎn)，繼續(xù)把數(shù)據(jù)包轉(zhuǎn)發(fā)給路由器的默認(rèn)網(wǎng)關(guān)
遞歸至對(duì)端
路由器會(huì)根據(jù)查詢到的默認(rèn)網(wǎng)關(guān) IP 漓柑，通過(guò) ARP 獲取 MAC 地址教硫，并且也具有 ARP 緩存叨吮，查詢到 MAC 地址后，給數(shù)據(jù)包新增 MAC 頭瞬矩，之后數(shù)據(jù)包加上以太網(wǎng)首部茶鉴，通過(guò)端口轉(zhuǎn)發(fā)給其他網(wǎng)關(guān)。雖然路由器讀取了 IP 包的目標(biāo) IP景用，但是發(fā)送方和接收方的 IP 地址是永遠(yuǎn)不會(huì)被改變的涵叮。
轉(zhuǎn)發(fā)到其他網(wǎng)關(guān)后還會(huì)遞歸這些步驟，進(jìn)行網(wǎng)關(guān)到網(wǎng)關(guān)的中轉(zhuǎn)伞插，直到抵達(dá)對(duì)端 IP割粮。
到達(dá)接收端后會(huì)依次去除以太網(wǎng)首部、MAC 首部媚污、IP 首部舀瓢、TCP 首部，最后讀取 HTTP 信息耗美。到此 test.com 成功接收到了 get 請(qǐng)求京髓，向我們發(fā)送資源文件。
服務(wù)器的 HTTP 進(jìn)程看到商架，原來(lái)這個(gè)請(qǐng)求是要訪問(wèn)一個(gè)頁(yè)面堰怨，于是就把這個(gè)網(wǎng)頁(yè)文件封裝在 HTTP 響應(yīng)報(bào)文里。
HTTP 響應(yīng)報(bào)文也需要穿上 TCP甸私、IP诚些、MAC 頭部，不過(guò)這次是源地址是服務(wù)器 IP 地址皇型，目的地址是客戶端 IP 地址诬烹。
套上各種首部后，再次從網(wǎng)卡發(fā)送出去弃鸦，只交換機(jī)轉(zhuǎn)發(fā)到網(wǎng)關(guān)路由绞吁，路由器就把響應(yīng)數(shù)據(jù)包發(fā)到了下一個(gè)路由器，接著遞歸過(guò)程唬格，直到跳到了客戶端的路由器家破，路由器扒開(kāi) IP 頭部發(fā)現(xiàn)確實(shí)是給本子網(wǎng)的信息，于是把包發(fā)給了子網(wǎng)交換機(jī)购岗，再由交換機(jī)轉(zhuǎn)發(fā)到我們一開(kāi)始的發(fā)送端汰聋。
發(fā)送端 OS 收到了服務(wù)器的響應(yīng)數(shù)據(jù)包后，去除各種頭部喊积，拿到最后 HTTP 的響應(yīng)報(bào)文烹困，通過(guò) IPC 將包發(fā)給 Network Service。
Network Service 收到報(bào)文后判斷響應(yīng)狀態(tài)碼乾吻，還記得我們一開(kāi)始的訪問(wèn)地址嗎髓梅？ test.com 因此返回了 301 狀態(tài)碼拟蜻，我們可以通過(guò) curl -I test.com 查看：
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0
Date: Tue, 07 Sep 2021 03:21:49 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
X-DIS-Request-ID: 241ea10b621b0644e9844c0f52ef76e1
Location: http://www.test.com/
此時(shí) Network Service 會(huì)自動(dòng)構(gòu)建新的請(qǐng)求，請(qǐng)求的目標(biāo)為響應(yīng)報(bào)文的 location 枯饿，那么回到本文構(gòu)建請(qǐng)求的環(huán)節(jié)酝锅，重新走一遍整個(gè)流程，值得注意的是現(xiàn)代瀏覽器會(huì)默認(rèn)開(kāi)啟 connection: keep-alive 這會(huì)復(fù)用之前建立的 TCP 鏈接奢方，加快請(qǐng)求速度搔扁。直到 Network Service 再次收到響應(yīng)。
本次收到響應(yīng)后袱巨，狀態(tài)碼正常阁谆，接著查看響應(yīng)頭部 content-type。它是 MIME 的子集愉老。若內(nèi)容無(wú)法解析场绿，瀏覽器會(huì)啟動(dòng)自動(dòng)下載，如果為 text/html嫉入，就正式進(jìn)入編譯篇壳猜∮模可以通過(guò) curl -i [https://www.test.com/](https://www.test.com/) 查看：
HTTP/1.1 200
Server: nginx/1.18.0
Date: Tue, 07 Sep 2021 03:39:19 GMT
Content-Type: text/html
Content-Length: 8859
Connection: keep-alive
Keep-Alive: timeout=20
ETag: "5e53086c-229b"
X-DIS-Request-ID: c821b8e4044843e8855e76558a610532
Set-Cookie: dis-request-id=c821b8e4044843e8855e76558a610532; secure
Set-Cookie: dis-timestamp=2021-09-06T20:39:19-07:00; secure
Set-Cookie: dis-remote-addr=61.175.192.50; secure
X-Frame-Options: sameorigin
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
...
最后助赞，如果客戶端要離開(kāi)了语御，向服務(wù)器發(fā)起了 TCP 四次揮手，至此雙方的連接就斷開(kāi)了垫竞。
筆者在到端后省略了 TCP 首次到端后進(jìn)行的二次握手澎粟，QUIC 以及 TLS 的校驗(yàn)等工作。它們?cè)?HTTP 首次響應(yīng)前就被完成欢瞪。
網(wǎng)絡(luò)的導(dǎo)航活烙，是從輸入 url 到最終獲取到文件的過(guò)程。其中牽扯到瀏覽器架構(gòu)遣鼓、操作系統(tǒng)啸盏、網(wǎng)絡(luò)等一系列知識(shí)。本文將從各個(gè)角度詳細(xì)論述這一過(guò)程骑祟，涉及廣度與深度回懦。如果您是已經(jīng)有一定基礎(chǔ)的同學(xué)，那么本文可以快速帶你系統(tǒng)化整理碎片化知識(shí)次企。
