可能會搞砸你的面試：你知道一個TCP鏈接上能發起多少個HTTP請求嗎？

本文由原做者鬆若章原創發佈，做者主頁：zhihu.com/people/hrsonion/posts，感謝原做者的無私分享。

一、引言

一道經典的面試題是：從 URL 在瀏覽器被被輸入到頁面展示的過程當中發生了什麼？

大多數回答都是說請求響應以後 DOM 怎麼被構建，被繪製出來。可是你有沒有想過，收到的 HTML 若是包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、創建了多少鏈接、使用什麼協議被下載下來的呢？

要搞懂這個問題，咱們須要先解決下面五個問題：

1）現代瀏覽器在與服務器創建了一個 TCP 鏈接後是否會在一個 HTTP 請求完成後斷開？什麼狀況下會斷開？

2）一個 TCP 鏈接能夠對應幾個 HTTP 請求？

3）一個 TCP 鏈接中 HTTP 請求發送能夠一塊兒發送麼（好比一塊兒發三個請求，再三個響應一塊兒接收）？

4）爲何有的時候刷新頁面不須要從新創建 SSL 鏈接？

5）瀏覽器對同一 Host 創建 TCP 鏈接到數量有沒有限制？

好了，帶着上面的問題，我來閱讀本文內容。

（本文同步發佈於：http://www.52im.net/thread-2680-1-1.html）

二、相關文章

• 《網絡編程懶人入門(七)：深刻淺出，全面理解HTTP協議》
• 《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
• 《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
• 《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》

三、第一個問題：與服務器創建的鏈接是否會在一個HTTP請求後斷開？什麼狀況下斷開？

如題所示，先來談談第一個問題：現代瀏覽器在與服務器創建了一個 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 纔會在請求完成後關閉鏈接。（詳細文檔請見：https://tools.ietf.org/html/rfc2616#section-8.1）

四、第二個問題：一個 TCP 鏈接能夠對應幾個 HTTP 請求？

瞭解了第一個問題以後，其實這個問題已經有了答案：若是維持鏈接，一個 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 這種設想看起來比較美好，可是在實踐中會出現許多問題：

1）一些代理服務器不能正確的處理 HTTP Pipelining；

2）正確的流水線實現是複雜的。詳見《HTTP/1.x 的鏈接管理》；

3）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 時代，瀏覽器是如何提升頁面加載效率的呢？

主要有下面兩點：

1）維持和服務器已經創建的 TCP 鏈接，在同一鏈接上順序處理多個請求；

2）和服務器創建多個 TCP 鏈接。

六、第四個問題：爲何有的時候刷新頁面不須要從新創建 SSL 鏈接？

在第一個問題的討論中已經有答案了：TCP 鏈接有的時候會被瀏覽器和服務端維持一段時間。TCP 不須要從新創建，SSL 天然也會用以前的。

七、第五個問題：瀏覽器對同一 Host 創建 TCP 鏈接到數量有沒有限制？

假設咱們還處在 HTTP/1.1 時代，那個時候沒有多路傳輸，當瀏覽器拿到一個有幾十張圖片的網頁該怎麼辦呢？

確定不能只開一個 TCP 鏈接順序下載，那樣用戶確定等的很難受，可是若是每一個圖片都開一個 TCP 鏈接發 HTTP 請求，那電腦或者服務器均可能受不了，要是有 1000 張圖片的話總不能開 1000 個TCP 鏈接吧，你的電腦贊成 NAT 也不必定會贊成。

因此答案是：有。Chrome 最多容許對同一個 Host 創建六個 TCP 鏈接。不一樣的瀏覽器有一些區別，詳見：https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requests。

那麼回到最開始的問題：收到的 HTML 若是包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、創建了多少鏈接、使用什麼協議被下載下來的呢？

若是圖片都是 HTTPS 鏈接而且在同一個域名下，那麼瀏覽器在 SSL 握手以後會和服務器商量能不能用 HTTP2，若是能的話就使用 Multiplexing 功能在這個鏈接上進行多路傳輸。不過也未必會全部掛在這個域名的資源都會使用一個 TCP 鏈接去獲取，可是能夠肯定的是 Multiplexing 極可能會被用到。

若是發現用不了 HTTP2 呢？或者用不了 HTTPS（現實中的 HTTP2 都是在 HTTPS 上實現的，因此也就是隻能使用 HTTP/1.1）。那瀏覽器就會在一個 HOST 上創建多個 TCP 鏈接，鏈接數量的最大限制取決於瀏覽器設置，這些鏈接會在空閒的時候被瀏覽器用來發送新的請求，若是全部的鏈接都正在發送請求呢？那其餘的請求就只能等等了。

（原文連接：點此進入）

附錄：更多網絡編程基礎資料

《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP鏈接的創建與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深刻理解TCP協議（上）：理論基礎》
《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通信協議關係圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器併發TCP鏈接數到底能夠有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K併發鏈接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M併發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《鮮爲人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》
《鮮爲人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》
《鮮爲人知的網絡編程(三)：關閉TCP鏈接時爲何會TIME_WAIT、CLOSE_WAIT》
《鮮爲人知的網絡編程(四)：深刻研究分析TCP的異常關閉》
《鮮爲人知的網絡編程(五)：UDP的鏈接性和負載均衡》
《鮮爲人知的網絡編程(六)：深刻地理解UDP協議並用好它》
《鮮爲人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《鮮爲人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《網絡編程懶人入門(一)：快速理解網絡通訊協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通訊協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差別》
《網絡編程懶人入門(五)：快速理解爲何說UDP有時比TCP更有優點》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深刻淺出，全面理解HTTP協議》
《網絡編程懶人入門(八)：手把手教你寫基於TCP的Socket長鏈接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，爲什麼還要用MAC地址？》
《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長鏈接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟着動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：咱們在讀寫Socket時，究竟在讀寫什麼？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：天天都在用的Ping命令，它究竟是什麼？》
《腦殘式網絡編程入門(六)：什麼是公網IP和內網IP？NAT轉換又是什麼鬼？》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》
《Android程序員必知必會的網絡通訊傳輸層協議——UDP和TCP》
《IM開發者的零基礎通訊技術入門(一)：通訊交換技術的百年發展史(上)》
《IM開發者的零基礎通訊技術入門(二)：通訊交換技術的百年發展史(下)》
《IM開發者的零基礎通訊技術入門(三)：國人通訊方式的百年變遷》
《IM開發者的零基礎通訊技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通訊技術入門(五)：1G到5G，30年移動通訊技術演進史》
《IM開發者的零基礎通訊技術入門(六)：移動終端的接頭人——「基站」技術》
《IM開發者的零基礎通訊技術入門(七)：移動終端的千里馬——「電磁波」》
《IM開發者的零基礎通訊技術入門(八)：零基礎，史上最強「天線」原理掃盲》
《IM開發者的零基礎通訊技術入門(九)：無線通訊網絡的中樞——「核心網」》
《IM開發者的零基礎通訊技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通訊技術入門(十一)：爲何WiFi信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：爲何手機信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通訊技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡鏈接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗乾貨總結》
《可能會搞砸你的面試：你知道一個TCP鏈接上能發起多少個HTTP請求嗎？》
>> 更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-2680-1-1.html）