前言
一切還要從那個經(jīng)典問題出發(fā)：
當你在瀏覽器中輸入 https://www.google.com/ 并且按下回車之后發(fā)生了什么？
Whaaat!!! 都 9012 年了你還在問這個問題到逊！
解析 URL薯定，DNS 查詢恨诱，獲得服務器 IP 地址晕窑，向目標地址發(fā)送 HTTP 請求，服務器收到睹栖，響應硫惕，返回頁面，瀏覽器接收野来，渲染恼除，bingo！
你露出滿意笑容，又是一個滿分回答豁辉。
停令野！還沒完呢。請問這位同學徽级，你發(fā)送的請求是怎么到達目標服務器的气破，服務器的響應又是如何回來的？
你陷入沉默餐抢，說了一些 TCP 協(xié)議现使、OSI 模型、路由器之類的詞旷痕。
此時問題又來了：瀏覽器又是如何將請求發(fā)送出去的碳锈？
空氣中的沉默加深了幾分，仿佛要滴出水來······
這篇文章欺抗，我將以網(wǎng)絡通信常用的 TCP/IP 模型為主售碳，解釋網(wǎng)絡通信涉及的各個階段，不管是常規(guī)的頁面訪問佩迟，還是我們業(yè)務中常見的 HTTP 請求团滥，都包含在這樣的過程中，了解整體對前端開發(fā)者們很有益處报强。開始吧灸姊！
目錄
- TCP/IP 參考模型是什么
- 一次完整的網(wǎng)絡通信過程
- 各個階段的深入理解
一、TCP/IP參考模型是什么
在進入具體的解釋之前秉溉，我們對 TCP/IP 協(xié)議的前世今身做一個簡單回顧力惯。
所謂無規(guī)矩不成方圓，網(wǎng)絡誕生之初召嘶，為了保證網(wǎng)絡通信的有序進行父晶，相關組織開始著手制定各種通信協(xié)議，例如最早的網(wǎng)絡控制協(xié)議（NCP）弄跌，到后來耳熟能詳?shù)?OSI 七層協(xié)議等甲喝，整個因特網(wǎng)在這些協(xié)議的制約下迅速發(fā)展。事物總是發(fā)展變化的铛只，技術自然更新?lián)Q代埠胖。到上一世紀 80 年代，美國國防部的 ARPA 網(wǎng)（也就是阿帕網(wǎng)淳玩，互聯(lián)網(wǎng)的鼻祖）項目中直撤，TCP、IP 協(xié)議最早被提出來得到應用蜕着，并且由于其優(yōu)異性迅速成為互聯(lián)網(wǎng)通信的主流通用協(xié)議谋竖。
這一協(xié)議最早得名是因為兩個最重要最先被提出的協(xié)議 TCP 和 IP，后來，互聯(lián)網(wǎng)通信的各類協(xié)議（HTTP蓖乘、IP锤悄、DNS、TCP驱敲、ARP）整體都被納入這一協(xié)議體系中铁蹈，被統(tǒng)稱為“TCP/IP 協(xié)議族”。
也就是說众眨，TCP/IP 協(xié)議族最早的確只有 TCP 和 IP 兩個協(xié)議握牧，現(xiàn)在則是一系列與網(wǎng)絡通信有關的各類協(xié)議的集合。對應這一協(xié)議族娩梨，同時發(fā)展出了TCP/IP 參考模型沿腰，這一模型是一個抽象出來的分層模型，TCP/IP 協(xié)議族中的所有協(xié)議被歸類到這一模型的 4 個層次中狈定，每一層相互獨立颂龙，下一層為上一層提供服務，各個層次間互相協(xié)作纽什，完成了互聯(lián)網(wǎng)通信的主要工作措嵌。
這四個層分別是：網(wǎng)絡訪問層（又叫數(shù)據(jù)鏈路層或者網(wǎng)絡接口層），網(wǎng)絡層芦缰，傳輸層企巢，應用層，大家通常將這四個層次與更為詳細的OSI七層模型映射：
在 TCP/IP 參考模型中让蕾，各項通信協(xié)議各有歸屬浪规，例如我們在瀏覽器中常用的：HTTP（超文本傳輸協(xié)議）、DNS（域名系統(tǒng)）探孝、FTP（文件傳輸協(xié)議）笋婿、SMTP（簡單郵件傳輸協(xié)議等）都是屬于應用層協(xié)議，而 TCP顿颅、UDP 則屬于傳輸層協(xié)議缸濒，IP 則屬于網(wǎng)絡層協(xié)議。更多的通信協(xié)議粱腻，大家可以搜索了解绍填。我們這篇文章主要分析以 HTTP 為主的通信過程。
（常見協(xié)議）
二栖疑、一次完整的網(wǎng)絡通信過程
為了對 HTTP 請求的通信過程有一個更好的理解，我將從 TCP/IP 四個層次出發(fā)滔驶，對應各個層次的通信實體遇革，或者媒介（例如瀏覽器，路由器以及網(wǎng)線等），看各個協(xié)議是如何在這些通信實體中發(fā)生作用萝快，將一個請求發(fā)送到服務器锻霎，服務器的響應又是如何趕回來的。
整體來講揪漩，一次完整的通信旋恼，很像快遞郵遞包裹，物品被加上包裝奄容，寫上地址信息和聯(lián)系方式冰更，經(jīng)過一個又一個的快遞中轉(zhuǎn)站，到達收貨人的位置昂勒，在網(wǎng)絡請求中蜀细，請求的數(shù)據(jù)就是需要快遞的物品，IP 地址和 MAC 地址就是通信的地址戈盈，網(wǎng)線和路由器奠衔、交換機和集線器等就是運輸?shù)缆泛涂爝f中轉(zhuǎn)站，網(wǎng)絡協(xié)議則可以看做快遞員和快遞政策塘娶，而和快遞類似的是归斤，網(wǎng)絡通信也會出現(xiàn)丟包（包裹損壞）等情況。所以說刁岸，一個簡單的 HTTP 請求脏里，要完整地拿到請求信息，中間有若干操作系統(tǒng)組件难捌、通信協(xié)議膝宁、通信實體參與，才能保證通信的順利進行根吁。
那么员淫，這個快遞過程，具體是怎么進行的呢击敌？
其基本原則是介返，通過分層的順序，發(fā)送端由上往下發(fā)送沃斤，接收端則由下向上接收圣蝎。為了保證數(shù)據(jù)順利發(fā)送到下一個層次，會在發(fā)送在其頭部加上一些必要的信息衡瓶，這些信息是為了保證數(shù)據(jù)的完整和符合需求的約束信息徘公。發(fā)送 HTTP 請求時，經(jīng)常會設置 Request Header哮针，例如 Content-Type：text/html 是向服務器說明关面，我需要的是 HTML 頁面坦袍，你返回其他東西是不行滴。
這些頭部信息還可能包含協(xié)議信息等太，請求路徑捂齐、請求方法等，但這僅僅是發(fā)生在應用層缩抡，整個通信過程奠宜，經(jīng)過四個層次，會被依次加上 HTTP 請求頭瞻想，TCP 頭部压真、IP 頭部以及以太網(wǎng)頭部。數(shù)據(jù)加上這些頭部信息之后内边，才會被發(fā)往下一層榴都，數(shù)據(jù)經(jīng)過重重包裝，從你的網(wǎng)卡出發(fā)漠其，穿過若干路由器嘴高，網(wǎng)線，交換機和屎，到達目標服務器所在的子網(wǎng)拴驮，服務器要做的則是相反的過程，它會根據(jù)前面加上的頭部信息柴信，層層解析套啤，最后到達服務器被處理（處理就是服務端程序代碼的責任），之后再將響應數(shù)據(jù)返回随常。整體過程如下圖：
（圖片來自謝希仁版《計算機網(wǎng)絡》）
數(shù)據(jù)在各個層次間依次傳遞潜沦，其傳遞的數(shù)據(jù)單位我們可以統(tǒng)一理解為數(shù)據(jù)包，數(shù)據(jù)包在不同的層次有不同的稱呼绪氛，我們熟悉的是唆鸡，其從應用層出發(fā)時，將之稱為 HTTP 請求消息（message）或者報文枣察，為其加上消息頭之后争占，發(fā)送至傳輸層，加上 TCP 頭部序目，叫它報文段（segment）臂痕，到網(wǎng)絡層，加上 IP 頭部猿涨，成為 IP 數(shù)據(jù)包握童，到了最后的網(wǎng)絡訪問層，其已經(jīng)套上層層包裝叛赚，在這里在為其加上以太網(wǎng)首部的同時澡绩，還會加上一些尾部信息片效，搖身變?yōu)?strong>幀（framing），這個過程叫做封裝過程英古。不管怎么叫，數(shù)據(jù)在各個層次間昙读，是以數(shù)據(jù)包的形式傳遞召调，當數(shù)據(jù)量大時，還會出現(xiàn)分包傳遞的情況蛮浑。
接下來我將這個過程進行擴展唠叛，看看在輸入 https://www.google.com/ 之后，TCP/IP 的各個層次間沮稚，前面提到的通信協(xié)議是如何參與其中的：
三艺沼、各階段發(fā)生了什么
1. DNS 查詢
URL 只是為了人類更友好識別網(wǎng)絡程序而設置的互聯(lián)網(wǎng)資源的定位標識，瀏覽器首先會對 URL 進行解析蕴掏，獲取到請求的協(xié)議（https）障般，域名（google.com），路徑（/）盛杰，由于沒有其他子域名挽荡，也就是查詢 google 的默認主頁。解析完畢后即供，DNS 出場定拟。
DNS，也就是域名查詢系統(tǒng)逗嫡，負責 URL 對應的 IP 地址的查詢青自，每個操作系統(tǒng)會內(nèi)置 Socket 協(xié)議庫，協(xié)議庫中有解析器（resolver）專門負責這個過程驱证，又是一個漫長的過程（當然我們等的時間不會很長）延窜，這里不再具體展開，感興趣的同學可以看看我在文尾列出的參考資源 How DNS works雷滚，其用生動有趣的動畫形式展示了這一過程需曾，十分有趣。
經(jīng)過 DNS 查詢祈远，瀏覽器拿到了請求資源的 IP 地址呆万。IP 地址，又叫網(wǎng)際協(xié)議地址车份，是分配給網(wǎng)絡上設備的數(shù)字標識谋减，也就是說，只要聯(lián)網(wǎng)的設備扫沼，例如我們的電腦手機以及路由器等都是有 IP 地址的出爹。其是我們的請求數(shù)據(jù)識別服務器在網(wǎng)絡中的位置的必須標識庄吼。
2. Mac 地址查詢
IP 地址在網(wǎng)絡層使用，但在實際的數(shù)據(jù)鏈路上傳遞數(shù)據(jù)時严就，在同一個鏈路中不同的計算機总寻，其必須要使用另一個地址來識別—— Mac 地址，又叫做物理地址梢为。
說到這里渐行，岔開一句，在網(wǎng)絡通信中铸董，我們通常提到三個地址：IP 地址祟印、Mac 地址以及端口號，三者分別代表的是：
IP地址：網(wǎng)絡中互聯(lián)的主機和路由器的標識粟害。
Mac 地址：每個網(wǎng)卡硬件的物理地址蕴忆。
端口號：識別同一個主機上不同的應用程序，也可以理解為程序地址悲幅。
所以套鹅，在一個網(wǎng)絡通信中，我們需要用到五大識別符：源IP地址夺艰、目標IP地址芋哭、協(xié)議、源端口號和目標端口號郁副。
言歸正傳减牺，Mac 地址是每一個網(wǎng)卡被生產(chǎn)的時候就寫死在其中的，所以其是不變且唯一的存谎，那么如何得到服務器的 Mac 地址呢拔疚，又一個協(xié)議閃亮登場——ARP。
ARP既荚，英文全稱叫做 Address Resolution Protocol稚失，也就是地址解析協(xié)議，其作用是恰聘，根據(jù)IP地址獲取通信設備的物理地址句各，其工作原理類似于以前我們常見的廣播，它會將包發(fā)送給同一以太網(wǎng)的所有主機晴叨，若目標主機的 Mac 地址與對應的 IP 地址命中凿宾，則找到了目標，但是兼蕊，若每次查詢都要給所有的主機發(fā)送 ARP 請求初厚，網(wǎng)絡中則會出現(xiàn)很多 ARP 包，因此孙技，每個主機都會有一個 ARP 緩存产禾，里面存放著常用的 MAC 地址排作，主機會優(yōu)先從緩存中查詢是否有需要的信息，如果有亚情，就不再發(fā)送廣播妄痪。Mac 地址會在網(wǎng)絡層加入 IP 頭部發(fā)往網(wǎng)絡訪問層，其實你會發(fā)現(xiàn)楞件，為了提高效率和性能拌夏，網(wǎng)絡通信中隨處可見緩存，HTTP 緩存履因、DNS 緩存以及 ARP 緩存等。值得了解的是盹愚，在IPv6中栅迄，有一個 NDP（鄰居發(fā)現(xiàn)協(xié)議）替代 ARP 來完成這個工作。
3. 數(shù)據(jù)傳輸——套接字來幫忙
我們前面提到操作系統(tǒng)中有一個協(xié)議庫皆怕，負責本機中網(wǎng)絡通信的很多功能毅舆，在 DNS 查詢的時候，協(xié)議棧中的解析器就參與其中愈腾，當應用層獲取到服務器的 IP 地址和 Mac 地址憋活，已經(jīng)擁有了數(shù)據(jù)傳遞的必要條件，接下來虱黄，瀏覽器會向操作系統(tǒng)的協(xié)議庫發(fā)出委托指令悦即，調(diào)用其中 Socket 庫中的程序組件，建立套接字（socket）橱乱，套接字的本質(zhì)可以理解為一個數(shù)據(jù)通道的出入口辜梳，其執(zhí)行的是一個“打開，讀/寫泳叠，關閉”的流程作瞄。
在進行數(shù)據(jù)傳輸時，客戶端和服務器都會創(chuàng)建一個套接字危纫，之后調(diào)用 socket 庫中的 connect 組件宗挥，該組件會依據(jù)描述符（套接字的匹配令符，與服務端的套接字的接頭暗號）种蝶，服務器的 IP 地址和端口號契耿，在瀏覽器和目標服務器之間建立一個傳輸通道（實際上并沒有真實的通道，中間隔著N多網(wǎng)關蛤吓、路由器和防火墻宵喂，這樣說更好理解），而大名鼎鼎的 TCP 三次握手實際就是發(fā)生在這個階段会傲，我們會在后面具體介紹 TCP 到底做了什么锅棕。
通道建立之后拙泽，接下來就是數(shù)據(jù)的讀寫操作，我們的程序代碼無法直接控制套接字裸燎，它依然會委托 Socket 庫中的組件來完成數(shù)據(jù)的讀寫（write 和 read）顾瞻，數(shù)據(jù)傳輸完成后，服務器會主動執(zhí)行斷開操作德绿，調(diào)用 Socket 庫中的 close 組件斷開連接荷荤，瀏覽器發(fā)現(xiàn)之后，也會執(zhí)行斷開操作移稳，數(shù)據(jù)傳輸完成蕴纳。
可以看到，在應用程序代碼的背后个粱，操作系統(tǒng)中內(nèi)置的組件庫和互聯(lián)網(wǎng)協(xié)議互為網(wǎng)絡通信的左膀右臂古毛，共同負責整個通信過程，缺一不可都许。
4. 三次握手與四次揮手
TCP 和 UDP 是傳輸層中的兩個主要協(xié)議稻薇，兩者的區(qū)別是：前者是面向連接的（實際就是套接字管道）纫版、可靠的流協(xié)議晓殊，后者則并不可靠，它采取一種“盡最大努力”的傳輸策略羡忘，大家可以記住睛低，瀏覽器案狠、郵件等應用程序一般使用 TCP 傳遞數(shù)據(jù)，而像 DNS 查詢等較短的收發(fā)則使用 UDP钱雷。我們主要介紹 TCP莺戒。
整體來講，之所以要在發(fā)送數(shù)據(jù)之前建立套接字急波，正是因為 TCP 是面向連接的傳輸協(xié)議从铲，在傳輸協(xié)議面前，你發(fā)送的內(nèi)容無關緊要澄暮，它們會將之看為一串具有一定長度的數(shù)據(jù)名段。
為了保證數(shù)據(jù)傳輸?shù)目煽浚琓CP 在套接字建立連接時泣懊，采用“三次握手”策略傳輸數(shù)據(jù)伸辟。
下面是一張三次握手流程圖：
圖中的 syn 是 Synchronize Sequence Numbers 的簡寫，也就是同步序列編號馍刮，擁有數(shù)據(jù)傳輸序列的標識信夫。
ack 指的是acknowledgement，表示確認。
通俗來講静稻，是這樣一個過程：
第一次握手：客戶端嘗試連接服務器警没，向服務器發(fā)送syn包（同步序列編號），syn=j振湾，其進入SYN_SEND 狀態(tài)等待服務器確認：我已準備好杀迹，隨時出發(fā)！
第二次握手：服務器接收客戶端 syn 包并確認（ack=j+1）押搪，同時向客戶端發(fā)送一個 syn 包（syn=k）树酪，也即 syn + ack 包，此時服務器進入SYN_RECV 狀態(tài)：收到請求大州，隨時接收续语。
第三次握手：客戶端收到服務器的 syn + ack 包，向服務器發(fā)送確認包 ack(ack=k+1）厦画，此包發(fā)送完畢绵载，客戶端和服務器進入ESTABLISHED 狀態(tài)，完成三次握手：OK苛白，我知道了，那我們開始發(fā)送數(shù)據(jù)焚虱。
你可能會覺得相當麻煩购裙，確認一次就可以了嘛，收到了嗎鹃栽？收到躏率，傳輸，為什么需要三次握手呢民鼓？
其實薇芝，為了保證數(shù)據(jù)傳輸?shù)慕^對可靠，三次確認是最少的次數(shù)丰嘉，試想這樣一種情況：在第一次得到確認后夯到，客戶端發(fā)送數(shù)據(jù)出去，但是這個數(shù)據(jù)由于中途網(wǎng)絡等問題饮亏，遲遲到不了服務端耍贾，服務端選擇關掉通道，但通道關閉后路幸，剛剛的數(shù)據(jù)又跑過來了荐开，這時候，服務端會將這個數(shù)據(jù)視為來自客戶端的新的傳輸請求简肴，同意建立連接晃听，而建立一個新的連接，但是，客戶端并沒有發(fā)送數(shù)據(jù)能扒，所以佣渴，它會忽視服務端的確認，也不會回應給服務端赫粥，服務端就在傻傻滴等待观话，但這種等待是沒有結(jié)果的，這就造成了服務端資源的浪費越平。
我在知乎上看到另外一種理解：之所以需要三次握手频蛔，本質(zhì)的原因是，傳輸信道是不可靠的秦叛，你不知道網(wǎng)絡會在什么時候出什么樣的問題晦溪，所以，為了保證傳輸?shù)拇_可靠挣跋，三次握手是理論上的最小值三圆。
TCP 傳輸數(shù)據(jù)時，并不是將所有數(shù)據(jù)一股腦全丟出去避咆，而是會將數(shù)據(jù)存放在一個的發(fā)送緩沖區(qū)舟肉，并且會等待應用程序的下一段程序到達，之所以這樣干查库，是因為一收到數(shù)據(jù)立馬發(fā)送路媚，很可能會造成信道的浪費與閑置，導致網(wǎng)絡效率太低樊销，就像明明很寬的馬路整慎，非要像過獨木橋一樣通過。
而 TCP 如何決定數(shù)據(jù)什么時候會發(fā)送围苫，其擁有一套計算機制裤园，整體來說，是按網(wǎng)絡包的長度以及應用程序送包過來的時間剂府，雖然你的數(shù)據(jù)很小拧揽，但你半天不發(fā)送，我也不會一直傻等著腺占。
還有一種情況是强法，當發(fā)送過來的數(shù)據(jù)包很大時，會在緩沖區(qū)對包進行拆分發(fā)送湾笛，拆分的時候饮怯，TCP 模塊會計算好每一塊數(shù)據(jù)的開頭和結(jié)尾的字節(jié)數(shù)，并將之寫在 TCP 頭部信息中嚎研，以待對方確認蓖墅，根據(jù)這些起始序號库倘，接收方可以判斷是否有數(shù)據(jù)遺漏的情況。
每發(fā)送一個包论矾，就需要等待 ack 包的確認教翩，這也是一種資源浪費，所以為了利用等待 ack 的空閑時間贪壳，數(shù)據(jù)可以不用等待 ack 直接發(fā)送饱亿，但是，這會出現(xiàn)一種情況闰靴，一邊一味地發(fā)送彪笼，但超過了接收方的處理能力，就會出現(xiàn)網(wǎng)絡擁堵蚂且，得不償失配猫。為了解決這個問題，TCP 采取了一種滑動窗口的發(fā)送策略杏死，它的原理是這樣的：
滑動窗口實際上是數(shù)據(jù)流量控制策略泵肄，我們可以將所有的數(shù)據(jù)想象為一個序列，而窗口則是數(shù)據(jù)可處理的數(shù)據(jù)大小淑翼，接收方會將窗口的大小寫入 ack 包的頭部信息中腐巢，告知發(fā)送方，發(fā)送方會據(jù)此動態(tài)調(diào)整發(fā)送的速率玄括，由于傳輸?shù)某掷m(xù)進行冯丙，這個窗口大小會動態(tài)變化，因此達到了流量的控制惠豺，其本質(zhì)的目的是，不要發(fā)的太快风宁，讓接收方處理不過來洁墙。
（滑動窗口示意圖）
接下來的路
上面我們只提到發(fā)送和接收，但是在瀏覽器和服務器之間戒财，可能隔著極多的網(wǎng)關热监、路由器、交換機等饮寞，數(shù)據(jù)是如何在龐大無比的因特網(wǎng)上找到服務器的呢孝扛？
這就是網(wǎng)絡層協(xié)議的用武之地了。
實際上幽崩，這一切在請求發(fā)送之前已經(jīng)準備好了苦始，我們使用 DNS 和 ARP 等方式，獲取到了目標服務器的 IP 地址和 Mac 地址慌申，這兩個地址引導發(fā)送的數(shù)據(jù)包到達服務器陌选，IP 地址用于在網(wǎng)絡中的所有主機中匹配通信的目標主機，IP 地址包含網(wǎng)絡標識和主機標識，前者用于區(qū)別不同的網(wǎng)段咨油，后者找到同一網(wǎng)段的不同主機您炉，數(shù)據(jù)到達路由器時，路由器會根據(jù)網(wǎng)絡標識將數(shù)據(jù)轉(zhuǎn)發(fā)到相應的網(wǎng)段役电，到達相應的網(wǎng)段之后赚爵，又會根據(jù)主機號，到達真正的主機法瑟。
說到這里冀膝，大家可能會有一個疑惑，既然 IP 地址都能找到目標服務器瓢谢，為什么還需要 Mac 地址畸写？
請容我解釋：
在同一個網(wǎng)段內(nèi)通信時，只用知道 Mac 地址氓扛，就可以精準找到目標枯芬，但是，互聯(lián)網(wǎng)上的網(wǎng)絡數(shù)量無比龐大采郎，網(wǎng)絡被各大運營商分割為多個網(wǎng)段千所，每個網(wǎng)段又有多個子網(wǎng)，如果僅僅知道一個 Mac 地址蒜埋，要在所有的網(wǎng)絡設備進行匹配淫痰，就是相當大的工程了，這時候整份，IP 地址的妙用體現(xiàn)出來了：它可以用來找路待错，這就類似于快遞中的省市地區(qū)等，而 Mac 地址可能是唯一的名字烈评，你在全中國找一個小強的人那就太多了火俄，但是你要具體到某一個村或小區(qū)，就很簡單了讲冠。
另外一個原因是瓜客，交換機這個東西，只認 Mac 地址竿开，就如同路由器根據(jù) IP 地址決定網(wǎng)絡請求的轉(zhuǎn)發(fā)路線谱仪，交換機通過 Mac 地址來確定具體的網(wǎng)卡位置。
路由器否彩、交換機疯攒、網(wǎng)線、光纖等正是 TCP/IP 四層協(xié)議的最底層列荔，網(wǎng)絡訪問層卸例，也就是 OSI 模型中的數(shù)據(jù)鏈路層和物理層称杨，在這一層，數(shù)據(jù)被加上以太網(wǎng)首部筷转，封裝成幀姑原，在各個路由器之間轉(zhuǎn)發(fā)傳送，經(jīng)常來說呜舒，路由器之間的傳送又有常用的點對點協(xié)議锭汛，也就是PPP（Point-To-Point Protocol），這是一個網(wǎng)絡訪問層協(xié)議袭蝗，PPP會在幀的前后加上幀界定符進行發(fā)送唤殴。最后，到達服務器所在子網(wǎng)到腥，會將消息轉(zhuǎn)交網(wǎng)絡層向上傳遞朵逝。
向上傳遞的過程如前所述，乃是解析頭部信息乡范，最終到達服務器的相反過程配名，不再細述。
這個過程我們可以在前面的整體過程圖清晰看到晋辆，請求數(shù)據(jù)到達服務器所在子網(wǎng)的路由器之后渠脉，又是一個由下而上的過程，這與客戶端發(fā)送數(shù)據(jù)基本相反瓶佳，每經(jīng)過一個層次芋膘，都會解析前面添加到請求數(shù)據(jù)上的多層頭部信息，交由上一層處理霸饲，在整個 TCP/IP 協(xié)議棧的幫助下为朋，我們的請求數(shù)據(jù)終于到達了目標服務器，穿過服務器的網(wǎng)卡厚脉，服務器操作系統(tǒng)同樣有協(xié)議棧來負責找到服務端程序?qū)亩丝谙按纾瑢?shù)據(jù)交由服務端應用程序處理。
服務器會根據(jù)我們的請求頭信息器仗，處理返回結(jié)果融涣，之后童番，請求響應信息重新出發(fā)精钮，再次回到瀏覽器。
瀏覽器收到請求后剃斧，經(jīng)過解析轨香、渲染過程，頁面呈現(xiàn)在我們面前幼东。
參考鏈接
- How DNS works
- 謝希仁《計算機網(wǎng)絡》
- 戶根勤《網(wǎng)絡是怎樣連接的》
- what-happens-when...
- 通俗大白話來理解TCP協(xié)議的三次握手和四次分手
