瀏覽器輸入「xxxxhub」的背后.....
點擊藍(lán)色“程序員cxuan ”關(guān)注我喲
加個“星標(biāo)”，及時接收最新文章
Hey guys 各位讀者姥爺們大家好，這里是程序員 cxuan 計算機(jī)網(wǎng)絡(luò)連載系列的第 13 篇文章。
到現(xiàn)在為止，我們算是把應(yīng)用層、運輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層都介紹完了，那么現(xiàn)在是時候把這些內(nèi)容都串起來，做一個全面的回顧了。那么我這就以 Web 頁面的請求歷程為例，來和你聊聊計算機(jī)網(wǎng)絡(luò)中這些協(xié)議是怎樣工作的、數(shù)據(jù)包是怎么收發(fā)的，從輸入 URL 、敲擊回車到最終完成頁面呈現(xiàn)在你面前的這個過程。
首先，我打開了 Web Browser ，然后在 Google 瀏覽器 URL 地址欄中輸入了 maps.google.com。
然后 ……
查找 DNS 緩存
瀏覽器在這個階段會檢查四個地方是否存在緩存，第一個地方是瀏覽器緩存，這個緩存就是 DNS 記錄。
瀏覽器會為你訪問過的網(wǎng)站在固定期限內(nèi)維護(hù) DNS 記錄。因此，它是第一個運行 DNS 查詢的地方。瀏覽器首先會檢查這個網(wǎng)址在瀏覽器中是否有一條對應(yīng)的 DNS 記錄，用來找到目標(biāo)網(wǎng)址的 IP 地址。
我是 chrome 瀏覽器，所以在 mac 中，無法使用 chrome://net-internals/#dns 找到對應(yīng)的 IP 地址，在 windows 中是可以找到的。
那么 mac 怎么查詢 DNS 記錄呢？你可以使用
nslookup命令來查找，但這不是我們討論的重點。
DNS(Domain Name System) 是一個分布式的數(shù)據(jù)庫，它用于維護(hù)網(wǎng)址 URL 到其 IP 地址的映射關(guān)系。在互聯(lián)網(wǎng)中，IP 地址是計算機(jī)所能夠理解的一種地址，而 DNS 的這種別名地址是我們?nèi)祟惸軌蚶斫夂陀洃浀牡刂罚珼NS 就負(fù)責(zé)把人類記憶的地址映射成計算機(jī)能夠理解的地址，每個 URL 都有唯一的 IP 地址進(jìn)行對應(yīng)。
舉個例子，google 的官網(wǎng)是 www.google.com ，而 google 的 ip 地址是 216.58.200.228 ，這兩個地址你在 URL 上輸入哪個都能訪問，但是 IP 地址不好記憶，而 google.com 簡單明了。DNS 就相當(dāng)于是我們幾年前使用的家庭電話薄，比如你想給 cxuan 打電話，你有可能記不住 cxuan 的電話號碼，此時你需要查詢電話薄來找到 cxuan 的電話號碼。
瀏覽器第二個需要檢查的地方就是操作系統(tǒng)緩存。如果 DNS 記錄不在瀏覽器緩存中，那么瀏覽器將對操作系統(tǒng)發(fā)起系統(tǒng)調(diào)用，Windows 下就是 getHostName。
在 Linux 和大部分 UNIX 系統(tǒng)上，除非安裝了
nscd，否則操作系統(tǒng)可能沒有 DNS 緩存。nscd 是 Linux 系統(tǒng)上的一種名稱服務(wù)緩存程序。
瀏覽器第三個需要檢查的地方是路由器緩存，如果 DNS 記錄不在自己電腦上的話，瀏覽器就會和與之相連的路由器共同維護(hù) DNS 記錄。
如果與之相連的路由器也沒有 DNS 記錄的話，瀏覽器就會檢查 ISP 中是否有緩存。ISP 緩存就是你本地通信服務(wù)商的緩存，因為 ISP 維護(hù)著自己的 DNS 服務(wù)器，它緩存 DNS 記錄的本質(zhì)也是為了降低請求時間，達(dá)到快速響應(yīng)的效果。一旦你訪問過某些網(wǎng)站，你的 ISP 可能就會緩存這些頁面，以便下次快速訪問。對于經(jīng)常看小電影的你是否感到震驚呢？如果家里還安裝了一個可以聯(lián)網(wǎng)的攝像頭的話，那就有點嗨皮了。
你肯定比較困惑為什么第一步瀏覽器需要檢查這么多緩存，你可能會感到不舒服，因為緩存可能會透露我們的隱私，但是這些緩存在調(diào)節(jié)網(wǎng)絡(luò)流量和縮短數(shù)據(jù)傳輸時間等方面至關(guān)重要。
所以，上面涉及到 DNS 緩存的查詢過程如下。
如果上面四個步驟中都不存在 DNS 記錄，那么就表示不存在 DNS 緩存，這個時候就需要發(fā)起 DNS 查詢，以查找目標(biāo)網(wǎng)址（本示例中是 maps.google.com）的 IP 地址。
發(fā)起 DNS 查詢
如上所述，如果想要使我的計算機(jī)和 maps.google.com 建立連接并進(jìn)行通信的話，我需要知道 maps.google.com 的 IP 地址，由于 DNS 的設(shè)計原因，本地 DNS 可能無法給我提供正確的 IP 地址，那么它就需要在互聯(lián)網(wǎng)上搜索多個 DNS 服務(wù)器，來找到網(wǎng)站的正確 IP 地址。
這里有個疑問，為什么我需要搜索多個 DNS 服務(wù)器的來找到網(wǎng)站的 IP 地址呢？一臺服務(wù)器不行嗎？
因為 DNS 是分布式域名服務(wù)器，每臺服務(wù)器只維護(hù)一部分 IP 地址到網(wǎng)絡(luò)地址的映射，沒有任何一臺服務(wù)器能夠維持全部的映射關(guān)系。
在 DNS 的早期設(shè)計中只有一臺 DNS 服務(wù)器。這臺服務(wù)器會包含所有的 DNS 映射。這是一種集中式的設(shè)計，這種設(shè)計并不適用于當(dāng)今的互聯(lián)網(wǎng)，因為互聯(lián)網(wǎng)有著數(shù)量巨大并且持續(xù)增長的主機(jī)，這種集中式的設(shè)計會存在以下幾個問題
單點故障(a single point of failure)，如果 DNS 服務(wù)器崩潰，那么整個網(wǎng)絡(luò)隨之癱瘓。通信容量(traaffic volume)，單個 DNS 服務(wù)器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級，一臺服務(wù)器很難滿足。遠(yuǎn)距離集中式數(shù)據(jù)庫(distant centralized database)，單個 DNS 服務(wù)器不可能鄰近所有的用戶，假設(shè)在美國的 DNS 服務(wù)器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經(jīng)過低速和擁堵的鏈路，造成嚴(yán)重的時延。維護(hù)(maintenance)，維護(hù)成本巨大，而且還需要頻繁更新。
所以在當(dāng)今網(wǎng)絡(luò)情況下 DNS 不可能集中式設(shè)計，因為它完全沒有可擴(kuò)展能力，所以采用分布式設(shè)計，這種設(shè)計的特點如下
分布式、層次數(shù)據(jù)庫。
首先分布式設(shè)計首先解決的問題就是 DNS 服務(wù)器的擴(kuò)展性問題，因此 DNS 使用了大量的 DNS 服務(wù)器，它們的組織模式一般是層次方式，并且分布在全世界范圍內(nèi)。沒有一臺 DNS 服務(wù)器能夠擁有因特網(wǎng)上所有主機(jī)的映射。相反，這些映射分布在所有的 DNS 服務(wù)器上。
大致來說有三種 DNS 服務(wù)器：根 DNS 服務(wù)器、 頂級域(Top-Level Domain, TLD) DNS 服務(wù)器 和 權(quán)威 DNS 服務(wù)器 。這些服務(wù)器的層次模型如下圖所示
根 DNS 服務(wù)器，有 400 多個根域名服務(wù)器遍及全世界，這些根域名服務(wù)器由 13 個不同的組織管理。根域名服務(wù)器的清單和組織機(jī)構(gòu)可以在 https://root-servers.org/ 中找到，根域名服務(wù)器提供 TLD 服務(wù)器的 IP 地址。頂級域 DNS 服務(wù)器，對于每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務(wù)器或服務(wù)器集群。所有的頂級域列表參見 https://tld-list.com/ 。TDL 服務(wù)器提供了權(quán)威 DNS 服務(wù)器的 IP 地址。權(quán)威 DNS 服務(wù)器，在因特網(wǎng)上具有公共可訪問的主機(jī)，如 Web 服務(wù)器和郵件服務(wù)器，這些主機(jī)的組織機(jī)構(gòu)必須提供可供訪問的 DNS 記錄，這些記錄將這些主機(jī)的名字映射為 IP 地址。一個組織機(jī)構(gòu)的權(quán)威 DNS 服務(wù)器收藏了這些 DNS 記錄。
在了解了 DNS 服務(wù)器的設(shè)計理念之后，我們回到 DNS 查找的步驟上來，DNS 的查詢方式主要分為三種
DNS 查找中會出現(xiàn)三種類型的查詢。通過組合使用這些查詢，優(yōu)化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用緩存的記錄數(shù)據(jù)，從而使 DNS 域名服務(wù)器能夠直接使用非遞歸查詢。
遞歸查詢：在遞歸查詢中，DNS 客戶端要求 DNS 服務(wù)器（一般為 DNS 遞歸解析器）將使用所請求的資源記錄響應(yīng)客戶端，或者如果解析器無法找到該記錄，則返回錯誤消息。
迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務(wù)器與查詢名稱不匹配，則其將返回對較低級別域名空間具有權(quán)威性的 DNS 服務(wù)器的引用。然后，DNS 客戶端將對引用地址進(jìn)行查詢。此過程繼續(xù)使用查詢鏈中的其他 DNS 服務(wù)器，直至發(fā)生錯誤或超時為止。
非遞歸查詢：當(dāng) DNS 解析器客戶端查詢 DNS 服務(wù)器以獲取其有權(quán)訪問的記錄時通常會進(jìn)行此查詢，因為其對該記錄具有權(quán)威性，或者該記錄存在于其緩存內(nèi)。DNS 服務(wù)器通常會緩存 DNS 記錄，查詢到來后能夠直接返回緩存結(jié)果，以防止更多帶寬消耗和上游服務(wù)器上的負(fù)載。
上面負(fù)責(zé)開始 DNS 查找的介質(zhì)就是 DNS 解析器，它一般是 ISP 維護(hù)的 DNS 服務(wù)器，它的主要職責(zé)就是通過向網(wǎng)絡(luò)中其他 DNS 服務(wù)器詢問正確的 IP 地址。
如果想要了解更多關(guān)于 DNS 的消息，請查閱 萬字長文爆肝 DNS 協(xié)議！
所以對于 maps.google.com 這個域名來說，如果 ISP 維護(hù)的服務(wù)器沒有 DNS 緩存記錄，它就會向 DNS 根服務(wù)器地址發(fā)起查詢，根名稱服務(wù)器會將其重定向到 .com 頂級域名服務(wù)器。.com 頂級域名服務(wù)器會將其重定向到google.com 權(quán)威服務(wù)器。google.com 名稱服務(wù)器將在其 DNS 記錄中找到 maps.google.com 匹配的 IP 地址，并將其返回給您的 DNS 解析器，然后將其發(fā)送回你的瀏覽器。
這里值得注意的是，DNS 查詢報文會經(jīng)過許多路由器和設(shè)備才會達(dá)到根域名等服務(wù)器，每經(jīng)過一個設(shè)備或者路由器都會使用路由表 來確定哪種路徑是數(shù)據(jù)包達(dá)到目的地最快的選擇。這里面涉及到路由選擇算法，如果小伙伴們想要了解路由選擇算法，可以看看這篇文章 https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc3
ARP 請求
我看了很多篇文章都沒有提到這一點，那就是 ARP 請求的這個過程。
什么時候需要發(fā)送 ARP 請求呢？
這里其實有個前提條件
如果 DNS 服務(wù)器和我們的主機(jī)在同一個子網(wǎng)內(nèi)，系統(tǒng)會按照下面的 ARP 過程對 DNS 服務(wù)器進(jìn)行 ARP 查詢
如果 DNS 服務(wù)器和我們的主機(jī)在不同的子網(wǎng)，系統(tǒng)會按照下面的 ARP 過程對默認(rèn)網(wǎng)關(guān)進(jìn)行查詢
ARP 協(xié)議的全稱是 Address Resolution Protocol(地址解析協(xié)議)，它是一個通過用于實現(xiàn)從 IP 地址到 MAC 地址的映射，即詢問目標(biāo) IP 對應(yīng)的 MAC 地址 的一種協(xié)議。
簡而言之，ARP 就是一種解決地址問題的協(xié)議，它以 IP 地址為線索，定位下一個應(yīng)該接收數(shù)據(jù)分包的主機(jī) MAC 地址。如果目標(biāo)主機(jī)不在同一個鏈路上，那么會查找下一跳路由器的 MAC 地址。
關(guān)于為什么有了 IP 地址，還要有 MAC 地址概述可以參看知乎這個回答 https://www.zhihu.com/question/21546408
ARP 的大致工作流程如下
假設(shè) A 和 B 位于同一鏈路，不需要經(jīng)過路由器的轉(zhuǎn)換，主機(jī) A 向主機(jī) B 發(fā)送一個 IP 分組，主機(jī) A 的地址是 192.168.1.2 ，主機(jī) B 的地址是 192.168.1.3，它們都不知道對方的 MAC 地址是啥，主機(jī) C 和 主機(jī) D 是同一鏈路的其他主機(jī)。
主機(jī) A 想要獲取主機(jī) B 的 MAC 地址，通過主機(jī) A 會通過廣播 的方式向以太網(wǎng)上的所有主機(jī)發(fā)送一個 ARP 請求包，這個 ARP 請求包中包含了主機(jī) A 想要知道的主機(jī) B 的 IP 地址的 MAC 地址。
主機(jī) A 發(fā)送的 ARP 請求包會被同一鏈路上的所有主機(jī)/路由器接收并進(jìn)行解析。每個主機(jī)/路由器都會檢查 ARP 請求包中的信息，如果 ARP 請求包中的目標(biāo) IP 地址 和自己的相同，就會將自己主機(jī)的 MAC 地址寫入響應(yīng)包返回主機(jī) A
由此，可以通過 ARP 從 IP 地址獲取 MAC 地址，實現(xiàn)同一鏈路內(nèi)的通信。
所以，要想發(fā)送 ARP 廣播，我們需要有一個目標(biāo) IP 地址，同時還需要知道用于發(fā)送 ARP 廣播的接口的 MAC 地址。
這里會涉及到 ARP 緩存的概念。
現(xiàn)在你知道了發(fā)送一次 IP 分組前通過發(fā)送一次 ARP 請求就能夠確定 MAC 地址。那么是不是每發(fā)送一次都得經(jīng)過廣播 -> 封裝 ARP 響應(yīng) -> 返回給主機(jī)這一系列流程呢？
想想看，瀏覽器是如何做的？瀏覽器內(nèi)置了緩存能夠緩存你最近經(jīng)常使用的地址，那么 ARP 也是一樣的。ARP 高效運行的關(guān)鍵就是維護(hù)每個主機(jī)和路由器上的 ARP 緩存(或表)。這個緩存維護(hù)著每個 IP 到 MAC 地址的映射關(guān)系。通過把第一次 ARP 獲取到的 MAC 地址作為 IP 對 MAC 的映射關(guān)系到一個 ARP 緩存表中，下一次再向這個地址發(fā)送數(shù)據(jù)報時就不再需要重新發(fā)送 ARP 請求了，而是直接使用這個緩存表中的 MAC 地址進(jìn)行數(shù)據(jù)報的發(fā)送。每發(fā)送一次 ARP 請求，緩存表中對應(yīng)的映射關(guān)系都會被清除。
通過 ARP 緩存，降低了網(wǎng)絡(luò)流量的使用，在一定程度上防止了 ARP 的大量廣播。
一般來說，發(fā)送過一次 ARP 請求后，再次發(fā)送相同請求的幾率比較大，因此使用 ARP 緩存能夠減少 ARP 包的發(fā)送，除此之外，不僅僅 ARP 請求的發(fā)送方能夠緩存 ARP 接收方的 MAC 地址，接收方也能夠緩存 ARP 請求方的 IP 和 MAC 地址，如下所示
不過，MAC 地址的緩存有一定期限，超過這個期限后，緩存的內(nèi)容會被清除。
深入理解 ARP 協(xié)議的話，可以參考 cxuan 的這篇文章。
所以，瀏覽器會首先查詢 ARP 緩存，如果緩存命中，我們返回結(jié)果：目標(biāo) IP = MAC。
如果緩存沒有命中：
查看路由表，看看目標(biāo) IP 地址是不是在本地路由表中的某個子網(wǎng)內(nèi)。是的話，使用跟那個子網(wǎng)相連的接口，否則使用與默認(rèn)網(wǎng)關(guān)相連的接口。
查詢選擇的網(wǎng)絡(luò)接口的 MAC 地址
我們發(fā)送一個數(shù)據(jù)鏈路層的 ARP 請求：
根據(jù)連接主機(jī)和路由器的硬件類型不同，可以分為以下幾種情況：
直連：
如果我們和路由器是直接連接的，路由器會返回一個
ARP Reply（見下面）。
集線器：
如果我們連接到一個集線器，集線器會把 ARP 請求向所有其它端口廣播，如果路由器也連接在其中，它會返回一個
ARP Reply。
交換機(jī)：
如果我們連接到了一個交換機(jī)，交換機(jī)會檢查本地 CAM/MAC 表，看看哪個端口有我們要找的那個 MAC 地址，如果沒有找到，交換機(jī)會向所有其它端口廣播這個 ARP 請求。
如果交換機(jī)的 MAC/CAM 表中有對應(yīng)的條目，交換機(jī)會向有我們想要查詢的 MAC 地址的那個端口發(fā)送 ARP 請求
如果路由器也
連接在其中，它會返回一個ARP Reply
ARP Reply:
現(xiàn)在我們有了 DNS 服務(wù)器或者默認(rèn)網(wǎng)關(guān)的 IP 地址，我們可以繼續(xù) DNS 請求了：
使用 53 端口向 DNS 服務(wù)器發(fā)送 UDP 請求包，如果響應(yīng)包太大，會使用 TCP 協(xié)議
如果本地/ISP DNS 服務(wù)器沒有找到結(jié)果，它會發(fā)送一個遞歸查詢請求，一層一層向高層 DNS 服務(wù)器做查詢，直到查詢到起始授權(quán)機(jī)構(gòu)，如果找到會把結(jié)果返回。
（上述均來自：https://github.com/skyline75489/what-happens-when-zh_CN#dns）
封裝 TCP 數(shù)據(jù)包
瀏覽器得到目標(biāo)服務(wù)器的 IP 地址后，根據(jù) URL 中的端口可以知道端口號 （http 協(xié)議默認(rèn)端口號是 80， https 默認(rèn)端口號是 443），會準(zhǔn)備 TCP 數(shù)據(jù)包。數(shù)據(jù)包的封裝會經(jīng)過下面的層層處理，數(shù)據(jù)到達(dá)目標(biāo)主機(jī)后，目標(biāo)主機(jī)會解析數(shù)據(jù)包，完整的請求和解析過程如下。
這里就不再詳細(xì)介紹了，讀者朋友們可以閱讀 cxuan 的這篇文章 TCP/IP 基礎(chǔ)知識詳解詳細(xì)了解。
瀏覽器與目標(biāo)服務(wù)器建立 TCP 連接
在經(jīng)過上述 DNS 和 ARP 查找流程后，瀏覽器就會收到一個目標(biāo)服務(wù)器的 IP 和 MAC地址，然后瀏覽器將會和目標(biāo)服務(wù)器建立連接來傳輸信息。這里可以使用很多種 Internet 協(xié)議，但是 HTTP 協(xié)議建立連接所使用的運輸層協(xié)議是 TCP 協(xié)議。所以這一步驟是瀏覽器與目標(biāo)服務(wù)器建立 TCP 連接的過程。
TCP 的連接建立需要經(jīng)過 TCP/IP 的三次握手，三次握手的過程其實就是瀏覽器和服務(wù)器交換 SYN 同步和 ACK 確認(rèn)消息的過程。
假設(shè)圖中左端是客戶端主機(jī)，右端是服務(wù)端主機(jī)，一開始，兩端都處于CLOSED（關(guān)閉）狀態(tài)。
服務(wù)端進(jìn)程準(zhǔn)備好接收來自外部的 TCP 連接。然后服務(wù)端進(jìn)程處于
LISTEN狀態(tài)，等待客戶端連接請求。客戶端向服務(wù)器發(fā)出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數(shù)據(jù)，只消耗一個序號。此時，客戶端進(jìn)入
SYN-SEND狀態(tài)。服務(wù)器收到客戶端連接后，，需要確認(rèn)客戶端的報文段。在確認(rèn)報文段中，把 SYN 和 ACK 位都置為 1 。確認(rèn)號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。此時，TCP 服務(wù)器進(jìn)入
SYN-RECEIVED(同步收到)狀態(tài)。客戶端在收到服務(wù)器發(fā)出的響應(yīng)后，還需要給出確認(rèn)連接。確認(rèn)連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認(rèn)號為 ack = y + 1。TCP 規(guī)定，這個報文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個數(shù)據(jù)報文段的序號仍是 seq = x + 1。這時，客戶端進(jìn)入
ESTABLISHED (已連接)狀態(tài)服務(wù)器收到客戶的確認(rèn)后，也進(jìn)入
ESTABLISHED狀態(tài)。
這樣三次握手建立連接的階段就完成了，雙方可以直接通信了。
瀏覽器發(fā)送 HTTP 請求到 web 服務(wù)器
一旦 TCP 連接建立完成后，就開始直接傳輸數(shù)據(jù)辦正事了！此時瀏覽器會發(fā)送 GET 請求，要求目標(biāo)服務(wù)器提供 maps.google.com 的網(wǎng)頁，如果你填寫的是表單，則發(fā)起的是 POST 請求，在 HTTP 中，GET 請求和 POST 請求是最常見的兩種請求，基本上占據(jù)了所有 HTTP 請求的九成以上。
除了請求類型外，HTTP 請求還包含很多很多信息，最常見的有 Host、Connection 、User-agent、Accept-language 等
首先 Host 表示的是對象所在的主機(jī)。Connection: close 表示的是瀏覽器需要告訴服務(wù)器使用的是非持久連接。它要求服務(wù)器在發(fā)送完響應(yīng)的對象后就關(guān)閉連接。User-agent: 這是請求頭用來告訴 Web 服務(wù)器，瀏覽器使用的類型是 Mozilla/5.0，即 Firefox 瀏覽器。Accept-language 告訴 Web 服務(wù)器，瀏覽器想要得到對象的法語版本，前提是服務(wù)器需要支持法語類型，否則將會發(fā)送服務(wù)器的默認(rèn)版本。下面我們針對主要的實體字段進(jìn)行介紹（具體的可以參考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers MDN 官網(wǎng)學(xué)習(xí)）
HTTP 的請求標(biāo)頭分為四種： 通用標(biāo)頭、請求標(biāo)頭、響應(yīng)標(biāo)頭 和 實體標(biāo)頭。
這四種標(biāo)頭又分別有很多內(nèi)容，如果你想要深入理解一下關(guān)于 HTTP 請求頭的相關(guān)內(nèi)容，可以參考 cxuan 的這篇文章
服務(wù)器處理請求并發(fā)回一個響應(yīng)
這個服務(wù)器包含一個 Web 服務(wù)器，也就是 Apache 服務(wù)器，服務(wù)器會從瀏覽器接收請求并將其傳遞給請求處理程序并生成響應(yīng)。
請求處理程序也是一個程序，它一般是用 .net 、php、ruby 等語言編寫，用于讀取請求，檢查請求內(nèi)容，cookie，必要時更新服務(wù)器上的信息的這么一個程序。它會以特定的格式比如 JSON、XML、HTML 組合響應(yīng)。
服務(wù)器發(fā)送回一個 HTTP 響應(yīng)
服務(wù)器響應(yīng)包含你請求的網(wǎng)頁以及狀態(tài)代碼，壓縮類型（Content-Encoding），如何緩存頁面（Cache-Control），要設(shè)置的 cookie，隱私信息等。
比如下面就是一個響應(yīng)體
關(guān)于深入理解 HTTP 請求和響應(yīng)，可以參考這篇文章
瀏覽器顯示 HTML 的相關(guān)內(nèi)容
瀏覽器會分階段顯示 HTML 內(nèi)容。首先，它將渲染裸露的 HTML 骨架。然后它將檢查 HTML 標(biāo)記并發(fā)送 GET 請求以獲取網(wǎng)頁上的其他元素，例如圖像，CSS 樣式表，JavaScript 文件等。這些靜態(tài)文件由瀏覽器緩存，因此你再次訪問該頁面時，不用重新再請求一次。最后，您會看到 maps.google.com 顯示的內(nèi)容出現(xiàn)在你的瀏覽器中。
完
往期推薦
??
如何系統(tǒng)學(xué)習(xí)計算機(jī)網(wǎng)絡(luò)？
另外，cxuan 肝了六本 PDF，公號回復(fù) cxuan ，領(lǐng)取作者全部 PDF 。
