一道經典的面試題是從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，服務器返回了兩個結果，瀏覽器是沒有辦法根據響應結果來判斷響應對應於哪一個請求的（因爲TCP都是綁定到一個網絡端口的，筆者注！！）。
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連接，連接數量的最大限制取決於瀏覽器設置，這些連接會在空閒的時候被瀏覽器用來發送新的請求，如果所有的連接都正在發送請求呢？那其他的請求就只能等等了。