轉載：https://www.shangmayuan.com/a/0648d9157e584bf7931bddd6.html

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

相信大多數準備過的同窗都能回答出來，可是若是繼續問：收到的 HTML 若是包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、建立了多少連結、使用什麼協議被下載下來的呢？github

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

1. 現代瀏覽器在與伺服器建立了一個 TCP 連結後是否會在一個 HTTP 請求完成後斷開？什麼狀況下會斷開？面試

2. 一個 TCP 連結能夠對應幾個 HTTP 請求？chrome

3. 一個 TCP 連結中 HTTP 請求傳送能夠一塊兒傳送麼（好比一塊兒發三個請求，再三個響應一塊兒接收）？瀏覽器

4. 為何有的時候重新整理頁面不須要從新建立 SSL 連結？伺服器

5. 瀏覽器對同一 Host 建立 TCP 連結到數量有沒有限制？併發

第一個問題

現代瀏覽器在與伺服器建立了一個 TCP 連結後是否會在一個 HTTP 請求完成後斷開？什麼狀況下會斷開？app

在 HTTP/1.0 中，一個伺服器在傳送完一個HTTP 響應後，會斷開 TCP 連線。可是這樣每次請求都會從新建立和斷開 TCP 連結，代價過大。因此雖然標準中沒有設定，某些伺服器對 Connection: keep-alive 的 Header 進行了支援。意思是說，完成這個 HTTP 請求以後，不要斷開 HTTP 請求使用的 TCP 連結。這樣的好處是連結能夠被從新使用，以後傳送 HTTP 請求的時候不須要從新建立 TCP 連結，以及若是維持連結，那麼 SSL 的開銷也能夠避免，兩張圖片是我短期內兩次訪問 https://www.github.com 的時間統計：chrome-devtools

頭一次訪問，有初始化連結和 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 時代，瀏覽器是如何提升頁面載入效率的呢？主要有下面兩點：

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-requestsdevelopers.google.com

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

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

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