tcp連接發(fā)起的http請求

五個問題:

  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ù)量有沒有限制婆硬?

第一個問題

現(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 請求之后,不要斷開 HTTP 請求使用的 TCP 連接炼杖。這樣的好處是連接可以被重新使用灭返,之后發(fā)送 HTTP 請求的時候不需要重新建立 TCP 連接,以及如果維持連接嘹叫,那么 SSL 的開銷也可以避免婆殿,兩張圖片是我短時間內(nèi)兩次訪問 https://www.github.com 的時間統(tǒng)計:

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

瘋了吧罩扇!面試官 5 連問一個 TCP 連接可以發(fā)多少個 HTTP 請求婆芦?

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

持久連接:既然維持 TCP 連接好處這么多喂饥,HTTP/1.1 就把 Connection 頭寫進(jìn)標(biāo)準(zhǔn)消约,并且默認(rèn)開啟持久連接,除非請求中寫明 Connection: close员帮,那么瀏覽器和服務(wù)器之間是會維持一段時間的 TCP 連接或粮,不會一個請求結(jié)束就斷掉。

所以第一個問題的答案是:默認(rèn)情況下建立 TCP 連接不會斷開捞高,只有在請求報頭中聲明 Connection: close 才會在請求完成后關(guān)閉連接氯材。

第二個問題

一個 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 的效果。

瘋了吧语御!面試官 5 連問一個 TCP 連接可以發(fā)多少個 HTTP 請求峻贮?

綠色是發(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):

  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ū)別。

那么回到最開始的問題碍舍,收到的 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ā)送請求呢?那其他的請求就只能等等了呐伞。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末敌卓,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子伶氢,更是在濱河造成了極大的恐慌趟径,老刑警劉巖瘪吏,帶你破解...
    沈念sama閱讀 216,372評論 6 498
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異蜗巧,居然都是意外死亡掌眠,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,368評論 3 392
  • 文/潘曉璐 我一進(jìn)店門幕屹,熙熙樓的掌柜王于貴愁眉苦臉地迎上來扇救,“玉大人,你說我怎么就攤上這事香嗓⊙盖唬” “怎么了?”我有些...
    開封第一講書人閱讀 162,415評論 0 353
  • 文/不壞的土叔 我叫張陵靠娱,是天一觀的道長沧烈。 經(jīng)常有香客問我,道長像云,這世上最難降的妖魔是什么锌雀? 我笑而不...
    開封第一講書人閱讀 58,157評論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮迅诬,結(jié)果婚禮上腋逆,老公的妹妹穿的比我還像新娘。我一直安慰自己侈贷,他們只是感情好惩歉,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,171評論 6 388
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著俏蛮,像睡著了一般撑蚌。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上搏屑,一...
    開封第一講書人閱讀 51,125評論 1 297
  • 那天争涌,我揣著相機(jī)與錄音,去河邊找鬼辣恋。 笑死亮垫,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的伟骨。 我是一名探鬼主播饮潦,決...
    沈念sama閱讀 40,028評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼底靠!你這毒婦竟也來了害晦?” 一聲冷哼從身側(cè)響起特铝,我...
    開封第一講書人閱讀 38,887評論 0 274
  • 序言:老撾萬榮一對情侶失蹤暑中,失蹤者是張志新(化名)和其女友劉穎壹瘟,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體鳄逾,經(jīng)...
    沈念sama閱讀 45,310評論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡稻轨,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,533評論 2 332
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了雕凹。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片殴俱。...
    茶點(diǎn)故事閱讀 39,690評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖枚抵,靈堂內(nèi)的尸體忽然破棺而出线欲,到底是詐尸還是另有隱情,我是刑警寧澤汽摹,帶...
    沈念sama閱讀 35,411評論 5 343
  • 正文 年R本政府宣布李丰,位于F島的核電站,受9級特大地震影響逼泣,放射性物質(zhì)發(fā)生泄漏趴泌。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,004評論 3 325
  • 文/蒙蒙 一拉庶、第九天 我趴在偏房一處隱蔽的房頂上張望嗜憔。 院中可真熱鬧,春花似錦氏仗、人聲如沸吉捶。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽帚稠。三九已至,卻和暖如春床佳,著一層夾襖步出監(jiān)牢的瞬間滋早,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,812評論 1 268
  • 我被黑心中介騙來泰國打工砌们, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留杆麸,地道東北人。 一個月前我還...
    沈念sama閱讀 47,693評論 2 368
  • 正文 我出身青樓浪感,卻偏偏與公主長得像昔头,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子影兽,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,577評論 2 353

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