一道經典的面試題是從 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 的開銷也可以避免，兩張圖檔是我短時間内兩次通路 github.com 的時間統計：
頭一次通路，有初始化連接配接和 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 的效果。讓面試官顫抖的 HTTP 2.0 協定面試題，這篇也看下吧。
綠色是發起請求到請求傳回的等待時間，藍色是響應的下載下傳時間，可以看到都是在同一個 Connection，并行完成的。一次完整的HTTP請求與響應涉及哪些知識？這篇了解下。
是以這個問題也有了答案：在 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 連接配接，連接配接數量的最大限制取決于浏覽器設定，這些連接配接會在空閑的時候被浏覽器用來發送新的請求，如果所有的連接配接都正在發送請求呢？那其他的請求就隻能等等了。 那浏覽器就會在一個 HOST 上建立多個 TCP 連接配接，連接配接數量的最大限制取決于浏覽器設定，這些連接配接會在空閑的時候被浏覽器用來發送新的請求，如果所有的連接配接都正在發送請求呢？那其他的請求就隻能等等了。