本文的目標是以“輸入 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 緩存;
• 滑動窗口;
• 握手與揮手過程中的異常處理。

好，坑就挖這么多，再多怕自己不想填，等填完再繼續挖。