我遇到過的最喜歡的面試問題是“你輸入'google. com'到一個瀏覽器的地址欄中，並按下 <enter>，之後會發生什麼呢？”/<enter>
有人可以滔滔不絕地說上幾天，試圖以某種形式的完備性來回答此問題。不過他們對此會有多深入的理解呢？這裡我純粹出於興趣，想把我的答案羅列在此。當我在一次實際面試中被問到這個問題時，在他們阻止我之前我漫談了 10 分鐘。之後即使在面試結束後，我一直記得當時我所遺漏的東西。
我將把這個格式化為文本牆，因為在談話中回答這個問題就是這樣的感覺。
那麼發生了什麼呢？
瀏覽器將分析輸入。通常情況下，如果輸入中有". com"，它不會認為你在輸入搜索詞。一旦它決定其必定是一個 url 時, 它會檢查輸入是否有協議頭，如果沒有，它會在其開頭添加"http://"。由於你沒有指定一系列 http 協議功能, 因此它將假定使用默認值，如 80 端口、GET 方法和無基礎身份認證。
然後，它將創建一個 http 請求併發送該請求。我對我的底層網絡知識沒有信心，但如果我確實要說，我會說一些關於 MAC 地址、TCP 數據包傳輸、丟包處理等。但無論如何，一個對"google. com"DNS 的查找將會發生，如果它還沒有對此的緩存，DNS 服務將響應一系列 IP 地址列表，因為"google. com"不是單 IP 的網站。我認為在默認情況下瀏覽器會選擇第一個。不確定它們是區域性的以及它是如何工作的，但我知道它就在那裡。
因此，http 請求從一個節點跳轉到另一個節點，直到它找到 google. com 負載均衡器的 IP 地址。這不會持續很久，谷歌會回應說，你需要使用 https —— 假定是 301 永久重定向。因此，它會原路返回到你的瀏覽器，瀏覽器將協議更改為 https，默認使用 443 端口並重新發送。這一次，TLS 握手將在負載均衡器和瀏覽器客戶端之間進行。我不是 100% 確定其工作原理，但我知道該請求會告訴谷歌，它支持什麼協議(TLS 1.0, 1.1, 1.2)，然後谷歌將響應 "讓我們使用 1.2 吧"。之後使用 TLS 加密發送請求。
我認為谷歌接下來要做的是將其放到負載均衡器的網絡應用程序防火牆規則集上，看看它是否是一個惡意請求。當這通過之後，安全連接可能已被終止（因為 PCI-DSS 規則規定你不需要加密內部流量），請求將被分配到其 CDN 中的某個池上，而 google 端緩存主頁將在 http 響應中返回 —— 可能是預先壓縮的。
谷歌的響應頭將由瀏覽器讀取，根據響應頭的緩存策略進行緩存，然後正文將被解壓。而且因為這是谷歌，它可能是超優化的：壓縮，可能是許多預渲染內容、內聯 CSS、JavaScript 和圖像，以減少網絡請求和首次渲染時間。但該請求將觸發一系列其他請求，所有這些請求都是併發的，因為它應該運行HTTP/2。當這些請求正在進行時，JavaScript 會被解析，可能沒有阻塞，因為他們在標籤上使用了 defer 屬性 - 或者 async，我從來沒有單獨閱讀過這裡他們做了些什麼的資料。
但瀏覽器可能已經渲染了搜索框並且正在頂部的工具欄上工作，這將需要一些額外的網絡請求 —— 我可能已經有一個 cookie 或可能是帶有 OAuth 令牌的本地存儲 —— 或我可能是使用 Chrome 並且它已經知道我是誰，並且使用 auth 的請求會被髮送到他們的 Google+ API 上，告訴 Google 搜索頁面的應用程序我的身份。
另一個請求將被髮送，以獲取我的頭像圖片。在這一點上，他們已經在進行嗅探我的瀏覽器，看看我是否未使用 Chrome, 在這種情況下, 他們會有彈出一個工具欄提示，告訴我：chrome 是真棒，我應該使用它，而不是其他任何瀏覽器。
我想此時需要冷靜下來 —— 因為所有這些都發生在一秒的時間內。
何為顯著地不同?
讓我們看看對應的 DNS：
我知道我以前見過 google.com 返回包中帶有多個 IP 地址，但目前看來似乎不再是這種情況了。似乎他們之前常常使用輪詢策略，但現在也不再使用了。這個 StackOverflow 提問涉及了此情況。我已忘記了它被稱為輪詢調度算法 (Round-Robin)。
網絡層...
在一個正式結構化回答中，你可能會參考我有所瞭解但並不精通的 OSI 模型。在查閱資料之後，我將它視為如下的網絡分層映射：
應用 - 觸發請求的邏輯
表示層 - HTTP
會話 - TLS
傳輸 - TCP
網絡 - 路由 (IP)
數據鏈路 - 幀 (可看做數據包的容器)
物理層 - 比特流
我記得在 TLS 中他們會在協議協商時交換證書。
網絡並不是我的強項。
在我的瀏覽器中打開 google.com，並禁用緩存：
- 我記得主機名規範化 —— 這是一個 301。
- 從 HTTP 到 HTTPS 的校正是一個 307 內部重定向。
- 然後它下載字體、商標圖像和我的頭像圖像。如果沒有 API 調用，這意味著他們會在頁面中推送我的個人資料信息並將其與返回數據捆綁在一起 —— 因此當你點擊 google.com 而不僅僅是提供緩存資產時，他們會進行實際的數據檢索。
以上是 IE 11 和 Chrome 響應數據的對比 —— 所有都處於退出狀態。
- IE11 和 Chrome 之間沒有太大的差別。但這意味著他們是用戶代理嗅探服務器端而不是客戶端。在我的答案中可能提到了這一點。
- 出乎意料的是，Chrome 的響應體大了 22kB。我想知道它是否是由在 IE 11 中明顯缺席的語音搜索功能引起的。IE11 可能需要 polyfill 和 Chrome 的廣告，但它都被混淆了，我不會再進一步折磨自己了。
- 即使我在 Chrome 中清除了 Cookie，它仍會在第一次請求時發送 Cookie。但在 IE 11 中並沒有這樣做。
深入理解渲染！
上圖是 Chrome 將為你提供的第一個屏幕截圖。
- 腳本標籤中沒有任何 async 或 defer 屬性，只有 nonce 屬性。我目前正在學習有關 nonce 的知識，這似乎與安全性有關。我估計他們想要那些阻塞式腳本。我確信他們在某些方面嘗試過有/無aync/defer的情況，並決定反對之。
- 自我提示：完全響應是對 JavaScript、CSS 和 HTML的亂七八糟的混合體。相比於其獨立性，他們沒有遵守任何控制其位置的規則。
閱讀更多 北漂十年的程序員 的文章
