面試官：為什么要合并 HTTP 請(qǐng)求?

點(diǎn)擊關(guān)注公眾號(hào)，回復(fù)“2T”獲取2TB學(xué)習(xí)資源！

互聯(lián)網(wǎng)架構(gòu)師后臺(tái)回復(fù) 2T 有特別禮包

上一篇：深夜看了張一鳴的微博，讓我越想越后怕

來(lái)源：https://www.jianshu.com/p/9a3f0e84c2b0

思考路徑：

為什么要實(shí)現(xiàn)batch call? -> 減少網(wǎng)絡(luò)中的傳輸損耗 -> 如何減少的? -> 通過(guò)合并HTTP請(qǐng)求 -> 合并HTTP請(qǐng)求是如何減少網(wǎng)絡(luò)損耗的？

本文將解決這個(gè)問(wèn)題。一起看看單個(gè)請(qǐng)求攜載大量信息和多個(gè)請(qǐng)求攜載小量信息對(duì)于整個(gè)時(shí)間的影響。

1. Client發(fā)出請(qǐng)求

1.1 HTTP 1.1

可以保持長(zhǎng)連接，但是每個(gè)不同的請(qǐng)求之間，client要向server發(fā)一個(gè)請(qǐng)求頭

請(qǐng)求無(wú)法并行執(zhí)行的，在一個(gè)連接里面

假設(shè)如果不合并的話需要建立N個(gè)連接，那么合并就可以省去(N-1)*RTT的時(shí)間，RTT指網(wǎng)絡(luò)延遲（在傳輸介質(zhì)中傳輸所用的時(shí)間，即從報(bào)文開始進(jìn)入網(wǎng)絡(luò)到它開始離開網(wǎng)絡(luò)之間的時(shí)間）。

1.2 TCP丟包問(wèn)題

慢啟動(dòng)，擁塞控制窗口

TCP報(bào)文亂序到達(dá)，合并后的文件可以允許隊(duì)首丟包以后在隊(duì)中補(bǔ)上來(lái)，但是分開資源的時(shí)候，前一個(gè)資源未加載完成后面的資源是不能加載的，會(huì)有更嚴(yán)重的隊(duì)首阻塞問(wèn)題，丟包率會(huì)嚴(yán)重影響Keep alive情況下多個(gè)文件的傳輸速率。

1.3 瀏覽器線程數(shù)限制

多為2-6個(gè)線程，會(huì)在每個(gè)連接上串行發(fā)送若干個(gè)請(qǐng)求。TCP連接太多，會(huì)給服務(wù)器造成很大的壓力的。

1.4 DNS緩存問(wèn)題

每次請(qǐng)求都需要找DNS緩存，多個(gè)請(qǐng)求就需要查找多次，而且緩存有可能被無(wú)故清空

2. 服務(wù)器處理請(qǐng)求

每個(gè)請(qǐng)求需要使用一個(gè)連接，建立一個(gè)線程，分配一部分CPU, 對(duì)于CPU而言，是種負(fù)擔(dān)，尤其是一般來(lái)說(shuō)建立了連接以后，哪怕發(fā)回了請(qǐng)求，這個(gè)連接還會(huì)保持一段時(shí)間才會(huì)timeout。

這種時(shí)候，維持連接是對(duì)服務(wù)器資源的一種巨大的浪費(fèi)。

3. HTTP 2.0

上面描述的所有都是基于HTTP/1.1的一些特性，或者說(shuō)弊端，有長(zhǎng)連接但是無(wú)法并行處理請(qǐng)求，TCP的慢啟動(dòng)和擁塞控制，隊(duì)首阻塞問(wèn)題都給整個(gè)性能帶來(lái)很多弊端，因此我們有了HTTP2.0來(lái)做針對(duì)性的改進(jìn)。很有意思的東西，直接看圖：

就是這么酷炫，HTTP/2多了很多特性來(lái)解決HTTP/1.1的很多問(wèn)題

3.1 Fully multiplexed

解決了隊(duì)首阻塞的問(wèn)題。對(duì)于同一個(gè)TCP連接，現(xiàn)在可以發(fā)送多個(gè)請(qǐng)求，接收多個(gè)回應(yīng)了！在HTTP/1.1里面，如果在一個(gè)連接里上一個(gè)請(qǐng)求發(fā)生了丟包，那么后面的所有請(qǐng)求都必須等第一個(gè)請(qǐng)求補(bǔ)上包，收到回應(yīng)以后才能繼續(xù)執(zhí)行。而在HTTP/2里面，可以直接并行處理。

另外，HTTP 系列面試題和答案全部整理好了，微信搜索互聯(lián)網(wǎng)架構(gòu)師，在后臺(tái)發(fā)送：2T，可以在線閱讀。

3.2 Header Compression

所有的HTTP request和response都有header，但是header里很可能包含緩存信息，導(dǎo)致他的大小會(huì)迅速增大的。但是在一個(gè)連接里大部分請(qǐng)求的請(qǐng)求頭其實(shí)攜帶的信息都很類似，所以HTTP/2使用了索引表，存儲(chǔ)了第一次出現(xiàn)的請(qǐng)求的請(qǐng)求頭，然后后面的類似的請(qǐng)求只需要攜帶這個(gè)索引的數(shù)字就好了。頭部壓縮平均減少了30%的頭部大小，加快了整體的網(wǎng)絡(luò)中傳輸?shù)乃俣取?/span>

這兩點(diǎn)是和本文關(guān)系最大的，有了這兩點(diǎn)，實(shí)質(zhì)上合并HTTP請(qǐng)求的好處在HTTP/2的協(xié)議下，已經(jīng)基本上消失了。合并不合并請(qǐng)求，更多的是看業(yè)務(wù)上的需求，后端的一些配置。

4. 總結(jié)

It’s a trade-off. 其實(shí)最重要的是看你傳輸什么東西，因?yàn)楹喜TTP請(qǐng)求實(shí)質(zhì)上是減少了網(wǎng)絡(luò)延時(shí)，但是如果你在服務(wù)器上處理的時(shí)間遠(yuǎn)遠(yuǎn)大于網(wǎng)絡(luò)延時(shí)的時(shí)間的時(shí)候，那么合并HTTP請(qǐng)求并不會(huì)給你帶來(lái)很多性能上的提升。

而且大數(shù)據(jù)量的傳輸一定會(huì)降低瀏覽器的cache hit rate,對(duì)于緩存的利用率會(huì)降低很多。但是對(duì)于HTTP請(qǐng)求攜帶的數(shù)據(jù)量比較少的情況，合并請(qǐng)求帶來(lái)的性能提升會(huì)是顯而易見的。

Reference

https://www.zhihu.com/question/34689035
https://www.zhihu.com/question/34401250
https://deliciousbrains.com/performance-best-practices-http2/
https://www.tutorialdocs.com/article/merge-parallel-http-request.html

感謝您的閱讀，也歡迎您發(fā)表關(guān)于這篇文章的任何建議，關(guān)注我，技術(shù)不迷茫！小編到你上高速。

    · END ·

最后，關(guān)注公眾號(hào)互聯(lián)網(wǎng)架構(gòu)師，在后臺(tái)回復(fù)：2T，可以獲取我整理的 Java 系列面試題和答案，非常齊全。

正文結(jié)束

推薦閱讀 ↓↓↓

1.不認(rèn)命，從10年流水線工人，到谷歌上班的程序媛，一位湖南妹子的勵(lì)志故事

2.如何才能成為優(yōu)秀的架構(gòu)師？

3.從零開始搭建創(chuàng)業(yè)公司后臺(tái)技術(shù)棧

4.程序員一般可以從什么平臺(tái)接私活？

5.37歲程序員被裁，120天沒找到工作，無(wú)奈去小公司，結(jié)果懵了...

6.IntelliJ IDEA 2019.3 首個(gè)最新訪問(wèn)版本發(fā)布，新特性搶先看

7.這封“領(lǐng)導(dǎo)痛批95后下屬”的郵件，句句扎心！

8.15張圖看懂瞎忙和高效的區(qū)別！

一個(gè)人學(xué)習(xí)、工作很迷茫？

點(diǎn)擊「閱讀原文」加入我們的小圈子！