轉(zhuǎn)自：面試官問我：一個 TCP 連接可以發(fā)多少個 HTTP 請求妨退？我竟然回答不上來...
一道經(jīng)典的面試題是從 URL 在瀏覽器被被輸入到頁面展現(xiàn)的過程中發(fā)生了什么讽坏，大多數(shù)回答都是說請求響應(yīng)之后 DOM 怎么被構(gòu)建锭魔，被繪制出來。但是你有沒有想過震缭，收到的 HTML 如果包含幾十個圖片標(biāo)簽赂毯，這些圖片是以什么方式、什么順序拣宰、建立了多少連接党涕、使用什么協(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 連接蚜锨，代價過大。所以雖然標(biāo)準(zhǔn)中沒有設(shè)定慢蜓，某些服務(wù)器對 Connection: keep-alive 的 Header 進(jìn)行了支持亚再。（在HTTP/1.1中被加入到標(biāo)準(zhǔn)中了）
意思是說，完成這個 HTTP 請求之后晨抡，不要斷開 HTTP 請求使用的 TCP 連接氛悬。這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請求的時候不需要重新建立 TCP 連接耘柱，以及如果維持連接如捅，那么 SSL 的開銷也可以避免，兩張圖片是我短時間內(nèi)兩次訪問 github.com 的時間統(tǒng)計(jì)：
所以第一個問題的答案是：默認(rèn)情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection: close 才會在請求完成后關(guān)閉連接汛蝙。
（詳細(xì)文檔見下面的鏈接）https://tools.ietf.org/html/rfc2616#section-8.1
第二個問題：一個 TCP 連接可以對應(yīng)幾個 HTTP 請求烈涮？
了解了第一個問題之后朴肺，其實(shí)這個問題已經(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 來試圖解決這個問題，但是這個功能在瀏覽器中默認(rèn)是關(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)堪伍。
至于標(biāo)準(zhǔn)為什么這么設(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è)想看起來比較美好，但是在實(shí)踐中會出現(xiàn)許多問題：
- 一些代理服務(wù)器不能正確的處理 HTTP Pipelining室叉。
- 正確的流水線實(shí)現(xiàn)是復(fù)雜的睹栖。
- Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后硫惕，假設(shè)客戶端在這個連接連續(xù)向服務(wù)器發(fā)送了幾個請求茧痕。按照標(biāo)準(zhǔn)，服務(wù)器應(yīng)該按照收到請求的順序返回結(jié)果恼除，假設(shè)服務(wù)器在處理首個請求時花費(fèi)了大量時間踪旷，那么后面所有的請求都需要等著首個請求結(jié)束才能響應(yīng)。
所以現(xiàn)代瀏覽器默認(rèn)是不開啟 HTTP Pipelining 的豁辉。
但是令野，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求徽级。至于 Multiplexing 具體怎么實(shí)現(xiàn)的就是另一個問題了气破。我們可以看一下使用 HTTP2 的效果。
綠色是發(fā)起請求到請求返回的等待時間餐抢，藍(lán)色是響應(yīng)的下載時間现使，可以看到都是在同一個 Connection低匙，并行完成的
所以這個問題也有了答案：在 HTTP/1.1 存在 Pipelining 技術(shù)可以完成這個多個請求同時發(fā)送，但是由于瀏覽器默認(rèn)關(guān)閉碳锈，所以可以認(rèn)為這是不可行的顽冶。在 HTTP2 中由于 Multiplexing 特點(diǎn)的存在，多個 HTTP 請求可以在同一個 TCP 連接中并行進(jìn)行售碳。
那么在 HTTP/1.1 時代强重，瀏覽器是如何提高頁面加載效率的呢？主要有下面兩點(diǎn)：
- 維持和服務(wù)器已經(jīng)建立的 TCP 連接贸人，在同一連接上順序處理多個請求间景。
- 和服務(wù)器建立多個 TCP 連接。
第四個問題：為什么有的時候刷新頁面不需要重新建立 SSL 連接艺智？
在第一個問題的討論中已經(jīng)有答案了拱燃，TCP 連接有的時候會被瀏覽器和服務(wù)端維持一段時間。TCP 不需要重新建立力惯，SSL 自然也會用之前的碗誉。
第五個問題：瀏覽器對同一 Host 建立 TCP 連接到數(shù)量有沒有限制？
假設(shè)我們還處在 HTTP/1.1 時代父晶，那個時候沒有多路傳輸哮缺，當(dāng)瀏覽器拿到一個有幾十張圖片的網(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 如果包含幾十個圖片標(biāo)簽红柱，這些圖片是以什么方式、什么順序蓖乘、建立了多少連接锤悄、使用什么協(xié)議被下載下來的呢？
如果圖片都是 HTTPS 連接并且在同一個域名下嘉抒，那么瀏覽器在 SSL 握手之后會和服務(wù)器商量能不能用 HTTP2零聚。
如果能的話就使用 Multiplexing 功能在這個連接上進(jìn)行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會被用到隶症。
如果發(fā)現(xiàn)用不了 HTTP2 呢容诬？或者用不了 HTTPS（現(xiàn)實(shí)中的 HTTP2 都是在 HTTPS 上實(shí)現(xiàn)的，所以也就是只能使用 HTTP/1.1）沿腰。那瀏覽器就會在一個 HOST 上建立多個 TCP 連接览徒，連接數(shù)量的最大限制取決于瀏覽器設(shè)置，這些連接會在空閑的時候被瀏覽器用來發(fā)送新的請求颂龙，如果所有的連接都正在發(fā)送請求呢习蓬？那其他的請求就只能等等了。
