一道經(jīng)典的面試題是從 URL 在瀏覽器被輸入到頁面展現(xiàn)的過程中發(fā)生了什么，大多數(shù)回答都是說請求響應(yīng)之后 DOM 怎么被構(gòu)建，被繪制出來。
圖片來自 Pexels
但是你有沒有想過，收到的 html 如果包含幾十個圖片標簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來的呢？
要搞懂這個問題，我們需要先解決下面五個問題：
- 現(xiàn)代瀏覽器在與服務(wù)器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？
- 一個 TCP 連接可以對應(yīng)幾個 HTTP 請求？
- 一個 TCP 連接中 HTTP 請求發(fā)送可以一起發(fā)送么（比如一起發(fā)三個請求，再三個響應(yīng)一起接收）？
- 為什么有的時候刷新頁面不需要重新建立 SSL 連接？
- 瀏覽器對同一 Host 建立 TCP 連接到數(shù)量有沒有限制？
先來談?wù)劦谝粋€問題：現(xiàn)代瀏覽器在與服務(wù)器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？
在 HTTP 1.0 中，一個服務(wù)器在發(fā)送完一個 HTTP 響應(yīng)后，會斷開 TCP 連接。但是這樣每次請求都會重新建立和斷開 TCP 連接，代價過大。
所以雖然標準中沒有設(shè)定，某些服務(wù)器對 Connection: keep-alive 的 Header 進行了支持。
意思是說，完成這個 HTTP 請求之后，不要斷開 HTTP 請求使用的 TCP 連接。
這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請求的時候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開銷也可以避免，兩張圖片是我短時間內(nèi)兩次訪問 Github.com 的時間統(tǒng)計：
頭一次訪問，有初始化連接和 SSL 開銷
初始化連接和 SSL 開銷消失了，說明使用的是同一個 TCP 連接
持久連接：既然維持 TCP 連接好處這么多，HTTP 1.1 就把 Connection 頭寫進標準，并且默認開啟持久連接。
除非請求中寫明 Connection：close，那么瀏覽器和服務(wù)器之間是會維持一段時間的 TCP 連接，不會一個請求結(jié)束就斷掉。
所以第一個問題的答案是：默認情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection：close 才會在請求完成后關(guān)閉連接。
詳細文檔見下面的鏈接：
https://tools.ietf.org/html/rfc2616#section-8.1
第二個問題：一個 TCP 連接可以對應(yīng)幾個 HTTP 請求？
了解了第一個問題之后，其實這個問題已經(jīng)有了答案，如果維持連接，一個 TCP 連接是可以發(fā)送多個 HTTP 請求的。
第三個問題：一個 TCP 連接中 HTTP 請求發(fā)送可以一起發(fā)送么（比如一起發(fā)三個請求，再三個響應(yīng)一起接收）？
HTTP 1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求，意思是說：兩個請求的生命周期不能重疊，任意兩個 HTTP 請求從開始到結(jié)束的時間在同一個 TCP 連接里不能重疊。
雖然 HTTP 1.1 規(guī)范中規(guī)定了 Pipelining 來試圖解決這個問題，但是這個功能在瀏覽器中默認是關(guān)閉的。
先來看一下 Pipelining 是什么，RFC 2616 中規(guī)定了：
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.
一個支持持久連接的客戶端可以在一個連接中發(fā)送多個請求（不需要等待任意請求的響應(yīng)）。收到請求的服務(wù)器必須按照請求收到的順序發(fā)送響應(yīng)。
至于標準為什么這么設(shè)定，我們可以大概推測一個原因：由于 HTTP 1.1 是個文本協(xié)議，同時返回的內(nèi)容也并不能區(qū)分對應(yīng)于哪個發(fā)送的請求，所以順序必須維持一致。
比如你向服務(wù)器發(fā)送了兩個請求 GET /query?q=A 和 GET /query?q=B，服務(wù)器返回了兩個結(jié)果，瀏覽器是沒有辦法根據(jù)響應(yīng)結(jié)果來判斷響應(yīng)對應(yīng)于哪一個請求的。
Pipelining 這種設(shè)想看起來比較美好，但是在實踐中會出現(xiàn)許多問題：
- 一些代理服務(wù)器不能正確的處理 HTTP Pipelining。
- 正確的流水線實現(xiàn)是復(fù)雜的。
- Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設(shè)客戶端在這個連接連續(xù)向服務(wù)器發(fā)送了幾個請求。按照標準，服務(wù)器應(yīng)該按照收到請求的順序返回結(jié)果，假設(shè)服務(wù)器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結(jié)束才能響應(yīng)。
所以現(xiàn)代瀏覽器默認是不開啟 HTTP Pipelining 的。
但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求。至于 Multiplexing 具體怎么實現(xiàn)的就是另一個問題了。
我們可以看一下使用 HTTP2 的效果：
綠色是發(fā)起請求到請求返回的等待時間，藍色是響應(yīng)的下載時間，可以看到都是在同一個 Connection，并行完成的。
所以這個問題也有了答案：在 HTTP 1.1 存在 Pipelining 技術(shù)可以完成這個多個請求同時發(fā)送，但是由于瀏覽器默認關(guān)閉，所以可以認為這是不可行的。
在 HTTP2 中由于 Multiplexing 特點的存在，多個 HTTP 請求可以在同一個 TCP 連接中并行進行。
那么在 HTTP 1.1 時代，瀏覽器是如何提高頁面加載效率的呢？主要有下面兩點：
- 維持和服務(wù)器已經(jīng)建立的 TCP 連接，在同一連接上順序處理多個請求。
- 和服務(wù)器建立多個 TCP 連接。
第四個問題：為什么有的時候刷新頁面不需要重新建立 SSL 連接？
在第一個問題的討論中已經(jīng)有答案了，TCP 連接有的時候會被瀏覽器和服務(wù)端維持一段時間。TCP 不需要重新建立，SSL 自然也會用之前的。
第五個問題：瀏覽器對同一 Host 建立 TCP 連接到數(shù)量有沒有限制？
假設(shè)我們還處在 HTTP 1.1 時代，那個時候沒有多路傳輸，當瀏覽器拿到一個有幾十張圖片的網(wǎng)頁該怎么辦呢？
肯定不能只開一個 TCP 連接順序下載，那樣用戶肯定等的很難受，但是如果每個圖片都開一個 TCP 連接發(fā) HTTP 請求，那電腦或者服務(wù)器都可能受不了。
要是有 1000 張圖片的話總不能開 1000 個TCP 連接吧，你的電腦同意 NAT 也不一定會同意。
所以答案是：有。Chrome 最多允許對同一個 Host 建立六個 TCP 連接。不同的瀏覽器有一些區(qū)別。
https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requestsevelopers.google.com
那么回到最開始的問題，收到的 HTML 如果包含幾十個圖片標簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來的呢？
如果圖片都是 HTTPS 連接并且在同一個域名下，那么瀏覽器在 SSL 握手之后會和服務(wù)器商量能不能用 HTTP2，如果能的話就使用 Multiplexing 功能在這個連接上進行多路傳輸。
不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會被用到。
如果發(fā)現(xiàn)用不了 HTTP2 呢？或者用不了 HTTPS（現(xiàn)實中的 HTTP2 都是在 HTTPS 上實現(xiàn)的，所以也就是只能使用 HTTP 1.1）。
那瀏覽器就會在一個 Host 上建立多個 TCP 連接，連接數(shù)量的最大限制取決于瀏覽器設(shè)置，這些連接會在空閑的時候被瀏覽器用來發(fā)送新的請求，如果所有的連接都正在發(fā)送請求呢？那其他的請求就只能等等了。
