拋磚引玉

• 曾經有這么一道面試題：從 URL 在瀏覽器被被輸入到頁面展現的過程中發生了什么？
• 相信大多數準備過的同學都能回答出來，但是如果繼續問：收到的 HTML 如果包含幾十個圖片標簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協議被下載下來的呢？
• 要搞懂這個問題，我們需要先解決下面五個問題：
  • ① 現代瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？
  • ② 一個 TCP 連接可以對應幾個 HTTP 請求？
  • ③ 一個 TCP 連接中 HTTP 請求發送可以一起發送么（比如一起發三個請求，再三個響應一起接收）？
  • ④ 為什么有的時候刷新頁面不需要重新建立 SSL 連接？
  • ⑤ 瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？

逐個擊破

一、現代瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？

• 在 HTTP 1.0 中，一個服務器在發送完一個 HTTP 響應后，會斷開 TCP 鏈接。但是這樣每次請求都會重新建立和斷開 TCP 連接，代價過大。
• 雖然標準中沒有設定，某些服務器對 Connection: keep-alive 的 Header 進行了支持。意思是說，完成這個 HTTP 請求之后，不要斷開 HTTP 請求使用的 TCP 連接。
• 這樣的好處是連接可以被重新使用，之后發送 HTTP 請求的時候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開銷也可以避免，以下兩張圖片是短時間內兩次訪問 https://www.github.com 的時間統計；
• 第一次訪問，有初始化連接和 SSL 開銷，如下所示：

• 第二次初始化連接和 SSL 開銷消失了，說明使用的是同一個 TCP 連接：

• 持久連接：既然維持 TCP 連接好處這么多，HTTP 1.1 就把 Connection 頭寫進標準，并且默認開啟持久連接，除非請求中寫明 Connection: close，那么瀏覽器和服務器之間是會維持一段時間的 TCP 連接，不會一個請求結束就斷掉。
• 所以第一個問題的答案是：默認情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection: close 才會在請求完成后關閉連接。

二、一個 TCP 連接可以對應幾個 HTTP 請求？

了解了第一個問題之后，其實這個問題已經有了答案，如果維持連接，一個 TCP 連接是可以發送多個 HTTP 請求的。

三、一個 TCP 連接中 HTTP 請求發送可以一起發送么（比如一起發三個請求，再三個響應一起接收）？

• HTTP 1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求，意思是說：兩個請求的生命周期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接里不能重疊。
• 雖然 HTTP 1.1 規范中規定了 Pipelining 來試圖解決這個問題，但是這個功能在瀏覽器中默認是關閉的。
• 先來看一下 Pipelining 是什么，RFC 2616 中規定了：

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一個支持持久連接的客戶端可以在一個連接中發送多個請求（不需要等待任意請求的響應）。收到請求的服務器必須按照請求收到的順序發送響應。

• 至于標準為什么這么設定，我們可以大概推測一個原因：由于 HTTP 1.1 是個文本協議，同時返回的內容也并不能區分對應于哪個發送的請求，所以順序必須維持一致。比如向服務器發送了兩個請求 GET/query?q=A 和 GET/query?q=B，服務器返回了兩個結果，瀏覽器是沒有辦法根據響應結果來判斷響應對應于哪一個請求的。
• Pipelining 這種設想看起來比較美好，但是在實踐中會出現許多問題：
  • 一些代理服務器不能正確的處理 HTTP Pipelining。
  • 正確的流水線實現是復雜的。
  • Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設客戶端在這個連接連續向服務器發送了幾個請求。按照標準，服務器應該按照收到請求的順序返回結果，假設服務器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結束才能響應。
• 所以現代瀏覽器默認是不開啟 HTTP Pipelining 的。
• 但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求。至于 Multiplexing 具體怎么實現的就是另一個問題了。我們可以看一下使用 HTTP2 的效果。
• 如下圖所示：綠色是發起請求到請求返回的等待時間，藍色是響應的下載時間，可以看到都是在同一個 Connection，并行完成的：

• 所以這個問題也有了答案：在 HTTP 1.1 存在 Pipelining 技術可以完成這個多個請求同時發送，但是由于瀏覽器默認關閉，所以可以認為這是不可行的。在 HTTP2 中由于 Multiplexing 特點的存在，多個 HTTP 請求可以在同一個 TCP 連接中并行進行。
• 那么在 HTTP 1.1 時代，瀏覽器是如何提高頁面加載效率的呢？主要有下面兩點：
  • 維持和服務器已經建立的 TCP 連接，在同一連接上順序處理多個請求。
  • 和服務器建立多個 TCP 連接。

四、為什么有的時候刷新頁面不需要重新建立 SSL 連接？

• 在第一個問題的討論中已經有答案了，TCP 連接有的時候會被瀏覽器和服務端維持一段時間。
• TCP 不需要重新建立，SSL 自然也會用之前的。

五、瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？

• 假設我們還處在 HTTP 1.1 時代，那個時候沒有多路傳輸，當瀏覽器拿到一個有幾十張圖片的網頁該怎么辦呢？肯定不能只開一個 TCP 連接順序下載，那樣用戶肯定等的很難受，但是如果每個圖片都開一個 TCP 連接發 HTTP 請求，那電腦或者服務器都可能受不了，要是有 1000 張圖片的話總不能開 1000 個TCP 連接吧，你的電腦同意 NAT 也不一定會同意。
• 所以答案是：有。Chrome 最多允許對同一個 Host 建立六個 TCP 連接。不同的瀏覽器有一些區別。請參考：Network Issues Guide
• 那么回到最開始的問題，收到的 HTML 如果包含幾十個圖片標簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協議被下載下來的呢？
• 如果圖片都是 HTTPS 連接并且在同一個域名下，那么瀏覽器在 SSL 握手之后會和服務器商量能不能用 HTTP2，如果能的話就使用 Multiplexing 功能在這個連接上進行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會被用到。
• 如果發現用不了 HTTP2 呢？或者用不了 HTTPS（現實中的 HTTP2 都是在 HTTPS 上實現的，所以也就是只能使用 HTTP 1.1）。
• 那瀏覽器就會在一個 HOST 上建立多個 TCP 連接，連接數量的最大限制取決于瀏覽器設置，這些連接會在空閑的時候被瀏覽器用來發送新的請求，如果所有的連接都正在發送請求呢？那其他的請求就只能等待了。

總結

以上是生活随笔為你收集整理的【网络通信与信息安全】之深入分析一个TCP连接可以发多少个HTTP请求相关问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。