最經典的前端面試題之一，你能答出什麼幺蛾子？

本文的目標是以「輸入 URL 後發生了什麼」這個經典面試題爲引子，寫一篇既可以涵蓋面試中大部分網絡試題，又可以將「輸入 URL 後發生什麼」講得有深度的文章。之前寫過一篇相似的文章，但實在過於簡單。另外，HTTPS 逐漸普及，文章中沒有這部分過程也說不過去。不想修改原來的文章，就從新寫一篇吧。文中以我所在的項目「興趣部落」的官網 https://buluo.qq.com/index.html 爲例子。

生成 HTTP 請求消息

解析完要訪問的目標服務器是啥了，接下來瀏覽器就會用 HTTP 協議生成請求消息去 web服務器請求資源，消息格式以下：

請求信息主要包括：

• 請求行：請求的方法（POST/GET/…）、URL、HTTP版本（1.1/2）；
• 消息頭：請求的附加信息，以空行結束；
• 消息體：數據，好比 POST 請求時的表單數據。

對應的，響應消息也有 3 個部分組成：

• 狀態行：HTTP版本、狀態碼（200/304/404/…）、解釋狀態的響應短語；
• 消息頭
• 消息體：返回的數據。

用圖表示：

DNS

生成 HTTP 消息後，瀏覽器委託操做系統將消息發送給 web服務器。而經過 web服務器的名稱是無法找到服務器在哪的，比如知道一我的的名字無法找到他家在哪同樣，網絡中的地址是用 IP 地址表示的，因此要想跟服務器通訊，得先找到它的 IP 地址，使用 DNS（Domain Name System，域名服務系統） 服務器能夠將 web服務器名稱轉換成 IP 地址。那這個過程是怎樣的呢？

操做系統有一個 Socket 庫，這個庫中的程序主要是讓應用程序調用操做系統的網絡功能，而在這些功能中，瀏覽器須要調取操做系統的 DNS 解析功能。DNS 解析器生成一條表示「告訴我 https://buluo.qq.com/index.html 的 IP 地址」的消息，而後委託操做系統的協議棧發送 UDP 消息到 DNS 服務器。那這條消息是如何發送到 DNS 服務器又是如何將 IP 地址返回的呢？

首先介紹下操做系統中 DNS 解析器發送給 DNS 服務器的消息內容，消息中包含 1）域名：buluo.qq.com；2）Class: IN，表明當前的網絡是因特網，DNS 設計之初還考慮了其餘網絡，雖然如今只有互聯網，但這個字段仍是保留了下來；3）記錄類型：A，表示域名對應的是 IP 地址，由於 DNS 還能解析其餘地址，好比類型爲 MX 時 DNS 服務器會查詢郵件服務器地址。DNS 服務器中維護一張表，表的每一項包含上面三個字段還有服務器地址，當域名、Class、記錄類型所有匹配時，DNS 服務器返回地址，在例子中會返回興趣部落首頁的 IP 地址。

但這個時候問題來了，世界上有不可勝數的服務器，將這些全部的服務器信息都保存在一個 DNS 的表中確定是不現實的，因此確定有不少臺 DNS 服務器一塊兒配合完成這個域名解析過程的，那具體過程是什麼樣的呢？

首先，DNS 服務器中的全部信息都是按照域名來劃分層次的，這個層次是用 . 來分隔的，越靠右層次越高，好比 「buluo.qq.com」 中 「com」 層次最高，「qq」 次之，「buluo」 最後，其中每一層都被稱爲「域」，好比 「com 域」下是 「qq」 域，再下是 「buluo」 域，域的層次劃分是爲了更好地分配給不一樣國家、公司和組織等，典型的例子像南京市政府的官網：「www.nanjing.gov.cn」，「cn」 表明中國這個國家的域，「gov」 表明這個國家下的政府組織，「nanjing」 表明南京市政府。域有層次之分，那 DNS 服務器呢？規定將管理下級域的 DNS 服務器的 IP地址註冊到上級的 DNS 服務器中，好比管理 「buluo.qq.com」 這個域的 DNS 服務器的 IP地址須要註冊到 「qq.com」 域的 DNS 服務器中，以此類推，一直到「根域」，就是 「cn」、「com」 這類域的上一層次，根域中就保存了 「cn」、「com」 等域名的 DNS 服務器信息。此外，還須要將根域的 DNS 服務器信息保存在全部的 DNS 服務器中，這樣只要找到一臺 DNS 服務器就能夠順藤摸瓜找到下層任何一個 DNS 服務器。知道了域的層次劃分以及 DNS 服務器的分佈，下面就正式介紹如何尋找到相應的 DNS 服務器並獲取 IP 地址。

首先，客戶端會訪問最近的一臺 DNS 服務器，但因爲這臺 DNS 服務器上沒有 「buluo.qq.com」 這個域名的對應的信息，因此就向根域 DNS 服務器發請求詢問，但根域中也沒有，但斷定這個域名是屬於 「com」 域的，因此就返回其管理的 「com」 域的 DNS 服務器的 IP 地址，意思是「雖然我不知道，但你能夠去某某處問問，他應該知道」。而後 最近的那個 DNS 服務器又向 「com」 域的 DNS 服務器發請求，同理，也不知道，而後返回 「qq.com」 域的 DNS 服務器，而後這臺最近的 DNS 服務器又向 「qq.com」 域 DNS 服務器發請求，仍然沒有，直到最後，向 「buluo.qq.com」 這個域下的 DNS 服務器發請求才拿到 IP 地址。接着，這臺最近的 DNS 服務器將得到的 「buluo.qq.com」 的 IP 地址返回給客戶端，客戶端再拿着這個 IP 地址去請求資源。以上的過程用圖表示以下：

以上就是經過 DNS 服務獲取目標服務器 IP 地址的過程，能夠說是很是耗時，爲了優化性能，DNS 服務器會對中間的查詢結果作個緩存，爲了保存緩存的實時性，每隔一段時間就會將緩存設爲過時。

委託協議棧發送消息

如今客戶端拿到了目標服務器的 IP 地址，下面就要與其鏈接併發送消息了，這個過程一樣不是瀏覽器作的，而是委託協議棧來完成的，具體過程是：

1. 操做系統建立一個套接字，協議棧返回一個描述符，瀏覽器存儲起來，這個描述符是套接字的 ID，用於識別套接字，緣由是同一個客戶端可能跟不少服務器同時鏈接；
2. 客戶端的套接字與服務端的套接字進行鏈接，鏈接成功後，協議棧將目標服務器的 IP 地址和端口號保存在套接字中，下面就能夠收發數據；
3. 發送的數據是 HTTP 請求消息，發送的過程是：瀏覽器經過描述符查找到指定的套接字，並向套接字發送數據，數據便會經過網絡傳輸到服務端的套接字，服務器接收到消息後處理而後返回響應消息；
4. 消息返回後會被放入一塊內存緩衝區內，瀏覽器能夠直接讀取這段消息。以後，操做系統斷開套接字鏈接，本地的套接字也會被刪除。

TCP 鏈接

在「委託協議棧發送消息」部分簡單地提了下客戶端和服務端利用套接字進行鏈接，那這個鏈接具體是什麼樣的呢？

首先什麼是套接字？套接字其實就是個放在內存的備忘錄，協議棧在發送數據時先看一眼備忘錄，瞭解這個數據是發到哪一個端口，當數據發送出去後，這個備忘錄還得記錄什麼時間收到響應、何時斷開等控制信息，協議棧須要根據這些信息來決定下一步作什麼。

客戶端和服務端的鏈接是經過套接字鏈接的，那「鏈接」又是什麼意思呢？鏈接其實是客戶端和服務端互相交換控制信息的過程，控制信息主要包含兩種，一種是上面提到的套接字裏要來幫助協議棧進行下一步操做的信息，另外一種是客戶端和服務端通訊時交換的控制信息，這種控制信息就是咱們俗稱的 TCP 頭部。 那鏈接的過程是怎樣的呢？

這個鏈接過程就是咱們平時常常聽到的三次握手。

• 首先客戶端建立 TCP 頭部，頭部包含目標服務器的端口號等，同時將頭部的 SYN 設爲 1，表示開始請求鏈接。TCP 頭部建立好了以後，TCP 模塊便將信息傳遞給 IP 模塊並委託它發送，而後信息通過網絡到達服務器的 IP 模塊再到 TCP 模塊，TCP 模塊則會根據 TCP 頭部的信息找到端口號對應的套接字，套接字則會寫入相應的信息，而後將狀態改成「正在鏈接」；
• 服務端的 TCP 模塊收到鏈接請求後就要回應，與客戶端同樣， 須要在 TCP 頭部設置發送方和接收方的端口號，以及將 SYN 設爲 1，同時，返回響應時還要將 ACK 設爲 1，表示已經接收到相應的包。接着，將信息打包好，發送給客戶端；
• 客戶端收到消息後，發現 SYN 爲 1，則表示鏈接成功，因此在套接字中寫入服務器的端口號，同時將狀態改成鏈接完畢。爲了告訴服務器收到消息，客戶端也要將 ACK 設爲 1，接着發送給服務端。

整個過程用圖表示以下：

HTTPS 的握手過程

上面的過程是最簡單的 HTTP 三次握手，但如今愈來愈多的網站使用了 HTTPS 協議，那與 HTTP 鏈接有什麼不一樣呢？

先介紹一下什麼是 HTTPS。HTTPS 正如其名字，HTTP 表明其並非本身建立一個新的協議，而是創建在 HTTP 的基礎之上，S 表明其是安全的，如何保證安全？利用 SSL/TLS。SSL（Secure Sockets Layer，安全套接層）是網景設計的安全傳輸協議，經歷了 1.0、2.0 和 3.0 版本，但由於 1.0 有嚴重安全缺陷，因此從未公佈。後來 IETF 將 SSL 標準化，稱爲 TLS（Transport Layer Security， 傳輸層安全協議） ，TLS 1.0 與 SSL 3.0 差異很小。TLS 經歷了 1.0、1.1 到如今最新的 1.2。在 HTTPS 通訊中具體使用哪種還要看客戶端和服務端的支持程度。那 SSL/TLS 在網絡模型中屬於哪一層呢？直接上圖：

在客戶端和服務端經過 HTTPS 鏈接的過程當中，除了正常的 HTTP 鏈接中的事情，還有身份驗證和加密信息兩件事，下面看看具體過程（更詳細內容能夠查看標準：RFC5246）。

• Client Hello：此次握手是客戶端向服務端發起加密通訊請求，請求中包含如下關鍵信息：

  • Version：客戶端支持的協議版本，好比 TLS 1.2；
  • Random：第一個隨機數，做用在後面的握手步驟中介紹；
  • Session ID：「空」表示這是一次新的鏈接，「不爲空」表示維持前面的鏈接；
  • Cipher Suites：密碼套件；
  • Compression：客戶端支持的壓縮方法；
  • Extensions：擴展。
• Server Hello：服務端收到客戶端消息後返回響應，響應信息跟 ClientHello 相似，只不過每一個字段都是一個肯定的值，是服務端根據客戶端傳過來的候選值的最終選擇結果，若是服務端沒有在候選值中找到合適的，那麼將會返回錯誤提示，須要提一下的是，此次的響應信息中包含第二個隨機數。
• Server Certificate：服務端緊接着向客戶端發送證書；
• Server Key Exchange Message：當上一條證書消息中的信息不全時，服務端會再次發送一些額外數據到客戶端；
• Certificate Request：若是服務端要求客戶端提供證書，會發出這樣一個請求；
• Server Hello Done：這條消息表示服務端這階段數據發送完畢，下面就是等待客戶端的響應；
• Client Certificate：若是服務端要求客戶端提供證書，那麼客戶端會返回本身的證書；

• Client Key Exchange Message：這一步很是關鍵，客戶端會生成 premaster secret（預主密鑰），爲何叫 premaster secret？由於後面客戶端和服務端會根據 premaster secret 和前面過程當中兩個隨機數共同生成一個 master secret（主密鑰，48字節），後面通訊的安全全靠這個 master secret。前兩個隨機數客戶端和服務端都知道了，這個步驟最主要的就是協商一個 premaster secret，這個過程叫作「密鑰交換」，這裏介紹兩個方法：

  • RSA 密鑰交換：客戶端生成 46 字節的隨機數，使用服務器的公鑰加密，而後發送出去，服務器即可以用私鑰解密。但這種方式不太安全，因此如今逐漸使用 DH 密鑰交換；
  • Diffie-Hellman 密鑰交換：DH 的精髓就是正向計算簡單，反向計算困難，比如兩種顏色的顏料，混在一塊兒你知道什麼顏色，但就給你一種顏色，你幾乎無法說出其是由哪兩種顏色混合而來。具體生成 premaster secret 的方式能夠看Diffie–Hellman key exchange，這裏簡單提一下，密鑰交換須要 6 個參數，其中 2 個叫「域參數」，由服務器選取，交換過程當中客戶端和服務器各自生成 2 個參數，可是隻相互發送 1 個，因此客戶端和服務器各自知道 5 個參數，根據這 5 個參數，雙方計算獲得一個一樣的 premaster secret。

• Certificate Verify：驗證客戶端的私鑰和以前發送的客戶端證書中的公鑰是對應的；
• Finished：客戶端的握手已經完成，消息內容加密，而且包含 verify_data 字段，值是整個握手過程當中全部消息的摘要，供服務端驗證消息完整性；
• Finished：表示服務端握手結束，同時也發送前面過程的消息的摘要。

用圖表示一下就是：

整個握手過程總結一下就是：

• 客戶端提出 HTTPS 鏈接請求；
• 服務器代表身份，表示本身是李逵而不是李鬼；
• 客戶端生成一個用於之後通訊的密鑰，並把密鑰也告訴了服務器；
• 客戶端和服務器結束握手。

以上就是握手的整個通訊細節，但細心的同窗可能會發現少了一個重要步驟，客戶端收到服務器發來的證書時是如何斷定對方就是本身想要找的服務器呢？這時候就要驗證證書的有效性，證書就像現實中的身份證，能夠確認某個網站的確是我要訪問的網站。那怎麼驗證證書的有效性呢？首先，數字證書和身份證同樣由權威機構簽發，不一樣的是身份證只能由政府簽發，而數字證書由 CA（Certification Authorities，數字證書認證機構）簽發，Mac 用戶能夠經過「文件-應用程序-實用工具-鑰匙串訪問」來查看根 CA，根 CA 能夠簽發其餘 CA，因此一個網站的簽發者不是根 CA 也不要緊，只要這個 CA 的簽發者是根 CA 也行。瞭解了 CA，下面看一下證書包含什麼，先看圖：

證書中包含：網站的基本信息、網站的公鑰、CA 的名字等信息（詳細請看 X.509），而後 CA 根據這幾個內容生成摘要（digest），再對摘要用 CA 的私鑰加密，加密後的結果即數字簽名，最後將數字簽名也放入到證書中。那麼當系統收到一個證書後，先用公鑰解密，解得開說明對方是由權威 CA 簽發的，而後再根據證書的信息生成摘要，跟解密出來的摘要對比。

數據傳輸

創建鏈接以後，客戶端和服務端即可以開始進行數據傳輸。一樣，瀏覽器委託協議棧來幫忙收發消息，協議棧收到消息後不會當即發送出去，而是先放入到緩存區中，由於向協議棧發送的數據長度由瀏覽器控制，若是協議棧一收到數據就發送出去，那麼可能會發送大量小包，致使網絡效率下降，因此協議棧通常會等數據量積累到必定程度再發送出去，那這個程度具體是啥樣？

首先，在以太網中，一個包的MTU（Maximum Transmission Unit，最大傳輸單元）是 1500 字節，除去 TCP、IP 頭部的 40字節，MSS（Maximum Segment Size，最大分段大小）就是 1460 字節，但由於加密須要，頭部可能會增長，相對的 MSS 就會減小。當緩存區內的數據接近 MSS 時再發送，能夠避免發送小包。可是若是數據量原本就很小，或者應用程序發送數據的頻率很小，那協議棧就不得不等很長時間，因此協議棧內部還有一個定時器，必定時間以後就會將包發送出去。若是數據較小，那就幾個拼個車，放在一個包裏發出去，若是數據很大，就要進行拆分。大概是下面這樣：

本地一切就緒以後，協議棧就會將消息發送出去，這時還沒完，客戶端還要確保服務器收到了消息。咱們一直都說 TCP 是面向鏈接的協議，由於它能夠糾正丟包錯誤、鏈接失敗提示等等，使得傳輸更加可靠。那具體又是怎麼樣的呢？

首先 TCP 模塊在拆分數據時會先算好每一塊數據至關於從頭開始是第幾個字節，而後將這個數字寫入到 TCP 頭部的「序號」字段中，經過這個字段，接收方就能知道包有沒有丟失，好比一個消息長度爲 4380（1460 * 3），那麼這條消息就被拆分到三個數據塊中，三個數據塊的 TCP 頭部的「序號」依次是 0、1460 和 2920，因此接收方先收到一個序號爲 0 的包，再收到一個序號爲 2920 的包，可是沒收到序號爲 1460 的包，說明這個包丟失了，現實中的序號爲了安全不會從 0 開始，而是以一個隨機數做爲初始值。若是確認沒有遺漏，那麼接收方會將到目前爲止收到的數據長度加起來，寫入 TCP 的 「ACK 號」中發送給對方，注意 「ACK 號」與 ACK 標記位不是一回事，前者是數字，後者就是一個比特的標記位，可是 「ACK 號」只有在 ACK 標記位爲 1 是纔有效。

斷開鏈接

當數據發送完畢後，一方（多是客戶端，多是服務端）就會發起斷開鏈接過程。這個過程也是你們很熟悉的，即四次揮手。下面以客戶端發起斷開請求爲例：

• 瀏覽器調用 Socket 庫關閉鏈接程序，客戶端的協議棧生成 TCP 頭部，將 FIN 標記位設爲 1，告訴服務器打算斷開鏈接，後面不會再發送數據，同時套接字也記錄斷開鏈接操做；
• 服務器收到 FIN 爲 1 的 TCP 頭部時，協議棧將套接字記錄爲進入斷開操做狀態，同時向客戶端發送一個 ACK 號，告訴客戶端已經收到消息；
• 服務器收到斷開鏈接信息時，可能還有數據沒有傳完，因此等待數據所有傳輸結束後，再發送一條 FIN 爲 1 的信息，告訴對方也作了斷開鏈接的準備，但沒有斷開；
• 一段時間後，客戶端返回確認信號，到此，鏈接結束。

以上就是輸入 URL 後大概發生的一些事情，可是從面試角度看，仍然還有不少部分沒有涉及。後續還會繼續更新這篇文章，添加一些重要內容，這裏先挖個坑：

• 常見狀態碼解析；
• HTTP 緩存；
• 滑動窗口；
• 握手與揮手過程當中的異常處理。

好，坑就挖這麼多，再多怕本身不想填，等填完再繼續挖。