一個TCP鏈接能夠發送多少個HTTP請求？

一道經典的面試題是從URL在瀏覽器被輸入到頁面展示的過程當中發生了什麼？大多數回答都是請求響應以後DOM是怎麼被構建、被繪製出來。

可是你有沒想過，收到的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的開銷也能夠避免。

如下兩張圖片是短期內訪問某站點的時間統計:

頭一次訪問，有初始化鏈接和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 中規定了：一個支持持久鏈接的客戶端能夠在一個鏈接中發送多個請求（不須要等待任意請求的響應）。收到請求的服務器必須按照請求收到的順序發送響應。

至於標準爲何這麼設定，咱們能夠大概推測一個緣由：因爲 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鏈接。不一樣的瀏覽器有一些區別。

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

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

若是發現用不了HTTP2呢？或者用不了HTTPS（現實中的HTTP2都是在HTTPS上實現的，因此也就是隻能使用HTTP/1.1）。

那瀏覽器就會在一個HOST上創建多個TCP鏈接，鏈接數量的最大限制取決於瀏覽器設置，這些鏈接會在空閒的時候被瀏覽器用來發送新的請求，若是全部的鏈接都正在發送請求呢？那其餘的請求就只能等等了。