我已遇到過的最喜歡的面試問題是”你鍵入’google. com’到一個瀏覽器的地址欄中,並點擊<Enter>,之後會發生什麼呢？”有人可以滔滔不絕幾天,試圖以某種形式的完備性來回答此問題。他們會走多深？純粹出於興趣,我要把我的答案羅列在此。當我在一次實際面試中被問到這個問題時,在他們阻止我之前我漫談了1 0分鐘。之後即使在面試結束後，我一直記得當時我所遺漏的東西。

我將把這個格式化為文本牆, 因為在談話中回答這個問題就是這樣的感覺.

那麼發生了什麼呢?

瀏覽器將分析輸入。通常情況下, 如果輸入中有”. 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提問涉及了此情況。我已忘記了它被稱為輪2。

網絡層

在一個正式結構化回答中，你可能會參考我有所了解但並不精通的OSI模型。在查閱資料之後，我將它視為如下的網絡分層映射：

1. 應用- 觸發請求的邏輯
2. 表示層- HTTP
3. 會話 – TLS
4. 傳輸- TCP
5. 網絡- 路由(IP)
6. 數據鏈路- 幀 (可看做數據包的容器)
7. 物理層- 比特流

我記得在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的亂七八糟的混合體。相比於其獨立性，他們沒有遵守任何控制其位置的規則。

問題本身是什麼呢?

你知道嗎？對於人員而言，這可能不是一個很好的面試問題，因為答案涉及到如此多的網絡知識。這是我喜歡的問題的格式，一些開放的事物，包括一些猜測。這使得面試官有機會跟進諸如“你認為TLS是如何建立的？”之類的問題，以查看候選人如何思考，看看他們有多少創意，看看他們的極限何在（有多耐心？） 。

你最喜歡的面試問題是什麼？