面試官問我:一個 TCP 連接可以發(fā)多少個 HTTP 請求?我竟然回答不上來...

作者:松若章 來源:知乎

鏈接:https://zhuanlan.zhihu.com/p/61423830

一道經(jīng)典的面試題是從 URL 在瀏覽器被被輸入到頁面展現(xiàn)的過程中發(fā)生了什么削葱,大多數(shù)回答都是說請求響應(yīng)之后 DOM 怎么被構(gòu)建,被繪制出來。但是你有沒有想過,收到的 HTML 如果包含幾十個圖片標(biāo)簽材原,這些圖片是以什么方式、什么順序季眷、建立了多少連接余蟹、使用什么協(xié)議被下載下來的呢?

要搞懂這個問題子刮,我們需要先解決下面五個問題:

  1. 現(xiàn)代瀏覽器在與服務(wù)器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開威酒?什么情況下會斷開?

  2. 一個 TCP 連接可以對應(yīng)幾個 HTTP 請求?

  3. 一個 TCP 連接中 HTTP 請求發(fā)送可以一起發(fā)送么(比如一起發(fā)三個請求兼搏,再三個響應(yīng)一起接收)?

  4. 為什么有的時候刷新頁面不需要重新建立 SSL 連接沙郭?

  5. 瀏覽器對同一 Host 建立 TCP 連接到數(shù)量有沒有限制佛呻?

先來談?wù)劦谝粋€問題:現(xiàn)代瀏覽器在與服務(wù)器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開?什么情況下會斷開病线?

在 HTTP/1.0 中吓著,一個服務(wù)器在發(fā)送完一個 HTTP 響應(yīng)后,會斷開 TCP 鏈接送挑。但是這樣每次請求都會重新建立和斷開 TCP 連接绑莺,代價過大。所以雖然標(biāo)準中沒有設(shè)定惕耕,某些服務(wù)器對 Connection: keep-alive 的 Header 進行了支持纺裁。

意思是說,完成這個 HTTP 請求之后司澎,不要斷開 HTTP 請求使用的 TCP 連接欺缘。這樣的好處是連接可以被重新使用,之后發(fā)送 HTTP 請求的時候不需要重新建立 TCP 連接挤安,以及如果維持連接谚殊,那么 SSL 的開銷也可以避免,兩張圖片是我短時間內(nèi)兩次訪問 github.com 的時間統(tǒng)計:

image

頭一次訪問蛤铜,有初始化連接和 SSL 開銷

image

初始化連接和 SSL 開銷消失了嫩絮,說明使用的是同一個 TCP 連接

持久連接:既然維持 TCP 連接好處這么多,HTTP/1.1 就把 Connection 頭寫進標(biāo)準围肥,并且默認開啟持久連接剿干,除非請求中寫明 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)雪隧。

至于標(biāo)準為什么這么設(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ā)送了幾個請求熄诡。按照標(biāo)準可很,服務(wù)器應(yīng)該按照收到請求的順序返回結(jié)果,假設(shè)服務(wù)器在處理首個請求時花費了大量時間凰浮,那么后面所有的請求都需要等著首個請求結(jié)束才能響應(yīng)我抠。

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

但是袜茧,HTTP2 提供了 Multiplexing 多路傳輸特性菜拓,可以在一個 TCP 連接中同時完成多個 HTTP 請求。至于 Multiplexing 具體怎么實現(xiàn)的就是另一個問題了笛厦。我們可以看一下使用 HTTP2 的效果纳鼎。

image

綠色是發(fā)起請求到請求返回的等待時間,藍色是響應(yīng)的下載時間裳凸,可以看到都是在同一個 Connection贱鄙,并行完成的

所以這個問題也有了答案:在 HTTP/1.1 存在 Pipelining 技術(shù)可以完成這個多個請求同時發(fā)送,但是由于瀏覽器默認關(guān)閉姨谷,所以可以認為這是不可行的逗宁。在 HTTP2 中由于 Multiplexing 特點的存在,多個 HTTP 請求可以在同一個 TCP 連接中并行進行梦湘。

那么在 HTTP/1.1 時代瞎颗,瀏覽器是如何提高頁面加載效率的呢件甥?主要有下面兩點:

  1. 維持和服務(wù)器已經(jīng)建立的 TCP 連接,在同一連接上順序處理多個請求哼拔。

  2. 和服務(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 功能在這個連接上進行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取昔案,但是可以確定的是 Multiplexing 很可能會被用到尿贫。

如果發(fā)現(xiàn)用不了 HTTP2 呢?或者用不了 HTTPS(現(xiàn)實中的 HTTP2 都是在 HTTPS 上實現(xiàn)的爱沟,所以也就是只能使用 HTTP/1.1)帅霜。那瀏覽器就會在一個 HOST 上建立多個 TCP 連接,連接數(shù)量的最大限制取決于瀏覽器設(shè)置呼伸,這些連接會在空閑的時候被瀏覽器用來發(fā)送新的請求身冀,如果所有的連接都正在發(fā)送請求呢钝尸?那其他的請求就只能等等了。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末搂根,一起剝皮案震驚了整個濱河市珍促,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌剩愧,老刑警劉巖猪叙,帶你破解...
    沈念sama閱讀 206,839評論 6 482
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異仁卷,居然都是意外死亡穴翩,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,543評論 2 382
  • 文/潘曉璐 我一進店門锦积,熙熙樓的掌柜王于貴愁眉苦臉地迎上來芒帕,“玉大人,你說我怎么就攤上這事丰介”丑。” “怎么了?”我有些...
    開封第一講書人閱讀 153,116評論 0 344
  • 文/不壞的土叔 我叫張陵哮幢,是天一觀的道長带膀。 經(jīng)常有香客問我,道長橙垢,這世上最難降的妖魔是什么垛叨? 我笑而不...
    開封第一講書人閱讀 55,371評論 1 279
  • 正文 為了忘掉前任,我火速辦了婚禮柜某,結(jié)果婚禮上点额,老公的妹妹穿的比我還像新娘。我一直安慰自己莺琳,他們只是感情好还棱,可當(dāng)我...
    茶點故事閱讀 64,384評論 5 374
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著惭等,像睡著了一般珍手。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上辞做,一...
    開封第一講書人閱讀 49,111評論 1 285
  • 那天琳要,我揣著相機與錄音,去河邊找鬼秤茅。 笑死稚补,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的框喳。 我是一名探鬼主播课幕,決...
    沈念sama閱讀 38,416評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼厦坛,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了乍惊?” 一聲冷哼從身側(cè)響起杜秸,我...
    開封第一講書人閱讀 37,053評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎润绎,沒想到半個月后撬碟,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,558評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡莉撇,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,007評論 2 325
  • 正文 我和宋清朗相戀三年呢蛤,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片棍郎。...
    茶點故事閱讀 38,117評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡顾稀,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出坝撑,到底是詐尸還是另有隱情,我是刑警寧澤粮揉,帶...
    沈念sama閱讀 33,756評論 4 324
  • 正文 年R本政府宣布巡李,位于F島的核電站,受9級特大地震影響扶认,放射性物質(zhì)發(fā)生泄漏侨拦。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,324評論 3 307
  • 文/蒙蒙 一辐宾、第九天 我趴在偏房一處隱蔽的房頂上張望狱从。 院中可真熱鬧,春花似錦叠纹、人聲如沸季研。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,315評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽与涡。三九已至,卻和暖如春持偏,著一層夾襖步出監(jiān)牢的瞬間驼卖,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,539評論 1 262
  • 我被黑心中介騙來泰國打工鸿秆, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留酌畜,地道東北人。 一個月前我還...
    沈念sama閱讀 45,578評論 2 355
  • 正文 我出身青樓卿叽,卻偏偏與公主長得像桥胞,于是被迫代替她去往敵國和親恳守。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,877評論 2 345

推薦閱讀更多精彩內(nèi)容