一道經(jīng)典的面試題是從 URL 在瀏覽器被輸入到頁(yè)面展現(xiàn)的過(guò)程中發(fā)生了什么，大多數(shù)回答都是說(shuō)請(qǐng)求響應(yīng)之后 DOM 怎么被構(gòu)建，被繪制出來(lái)。

[[286177]] 

圖片來(lái)自 Pexels

但是你有沒(méi)有想過(guò)，收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來(lái)的呢?

要搞懂這個(gè)問(wèn)題，我們需要先解決下面五個(gè)問(wèn)題：

• 現(xiàn)代瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開?什么情況下會(huì)斷開?
• 一個(gè) TCP 連接可以對(duì)應(yīng)幾個(gè) HTTP 請(qǐng)求?
• 一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么(比如一起發(fā)三個(gè)請(qǐng)求，再三個(gè)響應(yīng)一起接收)?
• 為什么有的時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接?
• 瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制?

先來(lái)談?wù)劦谝粋€(gè)問(wèn)題：現(xiàn)代瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開?什么情況下會(huì)斷開?

在 HTTP 1.0 中，一個(gè)服務(wù)器在發(fā)送完一個(gè) HTTP 響應(yīng)后，會(huì)斷開 TCP 連接。但是這樣每次請(qǐng)求都會(huì)重新建立和斷開 TCP 連接，代價(jià)過(guò)大。

所以雖然標(biāo)準(zhǔn)中沒(méi)有設(shè)定，某些服務(wù)器對(duì) Connection: keep-alive 的 Header 進(jìn)行了支持。

意思是說(shuō)，完成這個(gè) HTTP 請(qǐng)求之后，不要斷開 HTTP 請(qǐng)求使用的 TCP 連接。

這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請(qǐng)求的時(shí)候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開銷也可以避免，兩張圖片是我短時(shí)間內(nèi)兩次訪問(wèn) Github.com 的時(shí)間統(tǒng)計(jì)：

頭一次訪問(wèn)，有初始化連接和 SSL 開銷

初始化連接和 SSL 開銷消失了，說(shuō)明使用的是同一個(gè) TCP 連接

持久連接：既然維持 TCP 連接好處這么多，HTTP 1.1 就把 Connection 頭寫進(jìn)標(biāo)準(zhǔn)，并且默認(rèn)開啟持久連接。

除非請(qǐng)求中寫明 Connection：close，那么瀏覽器和服務(wù)器之間是會(huì)維持一段時(shí)間的 TCP 連接，不會(huì)一個(gè)請(qǐng)求結(jié)束就斷掉。

所以第一個(gè)問(wèn)題的答案是：默認(rèn)情況下建立 TCP 連接不會(huì)斷開，只有在請(qǐng)求報(bào)頭中聲明 Connection：close 才會(huì)在請(qǐng)求完成后關(guān)閉連接。

詳細(xì)文檔見(jiàn)下面的鏈接：

https://tools.ietf.org/html/rfc2616#section-8.1 

第二個(gè)問(wèn)題：一個(gè) TCP 連接可以對(duì)應(yīng)幾個(gè) HTTP 請(qǐng)求?

了解了第一個(gè)問(wèn)題之后，其實(shí)這個(gè)問(wèn)題已經(jīng)有了答案，如果維持連接，一個(gè) TCP 連接是可以發(fā)送多個(gè) HTTP 請(qǐng)求的。

第三個(gè)問(wèn)題：一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么(比如一起發(fā)三個(gè)請(qǐng)求，再三個(gè)響應(yīng)一起接收)?

HTTP 1.1 存在一個(gè)問(wèn)題，單個(gè) TCP 連接在同一時(shí)刻只能處理一個(gè)請(qǐng)求，意思是說(shuō)：兩個(gè)請(qǐng)求的生命周期不能重疊，任意兩個(gè) HTTP 請(qǐng)求從開始到結(jié)束的時(shí)間在同一個(gè) TCP 連接里不能重疊。

雖然 HTTP 1.1 規(guī)范中規(guī)定了 Pipelining 來(lái)試圖解決這個(gè)問(wèn)題，但是這個(gè)功能在瀏覽器中默認(rèn)是關(guān)閉的。

先來(lái)看一下 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.

一個(gè)支持持久連接的客戶端可以在一個(gè)連接中發(fā)送多個(gè)請(qǐng)求(不需要等待任意請(qǐng)求的響應(yīng))。收到請(qǐng)求的服務(wù)器必須按照請(qǐng)求收到的順序發(fā)送響應(yīng)。

至于標(biāo)準(zhǔn)為什么這么設(shè)定，我們可以大概推測(cè)一個(gè)原因：由于 HTTP 1.1 是個(gè)文本協(xié)議，同時(shí)返回的內(nèi)容也并不能區(qū)分對(duì)應(yīng)于哪個(gè)發(fā)送的請(qǐng)求，所以順序必須維持一致。

比如你向服務(wù)器發(fā)送了兩個(gè)請(qǐng)求 GET /query?q=A 和 GET /query?q=B，服務(wù)器返回了兩個(gè)結(jié)果，瀏覽器是沒(méi)有辦法根據(jù)響應(yīng)結(jié)果來(lái)判斷響應(yīng)對(duì)應(yīng)于哪一個(gè)請(qǐng)求的。

Pipelining 這種設(shè)想看起來(lái)比較美好，但是在實(shí)踐中會(huì)出現(xiàn)許多問(wèn)題：

• 一些代理服務(wù)器不能正確的處理 HTTP Pipelining。
• 正確的流水線實(shí)現(xiàn)是復(fù)雜的。
• Head-of-line Blocking 連接頭阻塞：在建立起一個(gè) TCP 連接之后，假設(shè)客戶端在這個(gè)連接連續(xù)向服務(wù)器發(fā)送了幾個(gè)請(qǐng)求。

按照標(biāo)準(zhǔn)，服務(wù)器應(yīng)該按照收到請(qǐng)求的順序返回結(jié)果，假設(shè)服務(wù)器在處理首個(gè)請(qǐng)求時(shí)花費(fèi)了大量時(shí)間，那么后面所有的請(qǐng)求都需要等著首個(gè)請(qǐng)求結(jié)束才能響應(yīng)。

所以現(xiàn)代瀏覽器默認(rèn)是不開啟 HTTP Pipelining 的。

但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個(gè) TCP 連接中同時(shí)完成多個(gè) HTTP 請(qǐng)求。至于 Multiplexing 具體怎么實(shí)現(xiàn)的就是另一個(gè)問(wèn)題了。

我們可以看一下使用 HTTP2 的效果：

綠色是發(fā)起請(qǐng)求到請(qǐng)求返回的等待時(shí)間，藍(lán)色是響應(yīng)的下載時(shí)間，可以看到都是在同一個(gè) Connection，并行完成的。

所以這個(gè)問(wèn)題也有了答案：在 HTTP 1.1 存在 Pipelining 技術(shù)可以完成這個(gè)多個(gè)請(qǐng)求同時(shí)發(fā)送，但是由于瀏覽器默認(rèn)關(guān)閉，所以可以認(rèn)為這是不可行的。

在 HTTP2 中由于 Multiplexing 特點(diǎn)的存在，多個(gè) HTTP 請(qǐng)求可以在同一個(gè) TCP 連接中并行進(jìn)行。

那么在 HTTP 1.1 時(shí)代，瀏覽器是如何提高頁(yè)面加載效率的呢?主要有下面兩點(diǎn)：

• 維持和服務(wù)器已經(jīng)建立的 TCP 連接，在同一連接上順序處理多個(gè)請(qǐng)求。
• 和服務(wù)器建立多個(gè) TCP 連接。

第四個(gè)問(wèn)題：為什么有的時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接?

在第一個(gè)問(wèn)題的討論中已經(jīng)有答案了，TCP 連接有的時(shí)候會(huì)被瀏覽器和服務(wù)端維持一段時(shí)間。TCP 不需要重新建立，SSL 自然也會(huì)用之前的。

第五個(gè)問(wèn)題：瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制?

假設(shè)我們還處在 HTTP 1.1 時(shí)代，那個(gè)時(shí)候沒(méi)有多路傳輸，當(dāng)瀏覽器拿到一個(gè)有幾十張圖片的網(wǎng)頁(yè)該怎么辦呢?

肯定不能只開一個(gè) TCP 連接順序下載，那樣用戶肯定等的很難受，但是如果每個(gè)圖片都開一個(gè) TCP 連接發(fā) HTTP 請(qǐng)求，那電腦或者服務(wù)器都可能受不了。

要是有 1000 張圖片的話總不能開 1000 個(gè)TCP 連接吧，你的電腦同意 NAT 也不一定會(huì)同意。

所以答案是：有。Chrome 最多允許對(duì)同一個(gè) Host 建立六個(gè) TCP 連接。不同的瀏覽器有一些區(qū)別。

https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requestsevelopers.google.com 

那么回到最開始的問(wèn)題，收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來(lái)的呢?

如果圖片都是 HTTPS 連接并且在同一個(gè)域名下，那么瀏覽器在 SSL 握手之后會(huì)和服務(wù)器商量能不能用 HTTP2，如果能的話就使用 Multiplexing 功能在這個(gè)連接上進(jìn)行多路傳輸。

不過(guò)也未必會(huì)所有掛在這個(gè)域名的資源都會(huì)使用一個(gè) TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會(huì)被用到。

如果發(fā)現(xiàn)用不了 HTTP2 呢?或者用不了 HTTPS(現(xiàn)實(shí)中的 HTTP2 都是在 HTTPS 上實(shí)現(xiàn)的，所以也就是只能使用 HTTP 1.1)。

那瀏覽器就會(huì)在一個(gè) Host 上建立多個(gè) TCP 連接，連接數(shù)量的最大限制取決于瀏覽器設(shè)置，這些連接會(huì)在空閑的時(shí)候被瀏覽器用來(lái)發(fā)送新的請(qǐng)求，如果所有的連接都正在發(fā)送請(qǐng)求呢?那其他的請(qǐng)求就只能等等了。