面試官：為什么要合并 HTTP 請(qǐng)求?
點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)
來源：https://www.jianshu.com/p/9a3f0e84c2b0
思考路徑：
本文將解決這個(gè)問題。一起看看單個(gè)請(qǐng)求攜載大量信息和多個(gè)請(qǐng)求攜載小量信息對(duì)于整個(gè)時(shí)間的影響。
1. Client發(fā)出請(qǐng)求
1.1 HTTP 1.1
可以保持長連接，但是每個(gè)不同的請(qǐng)求之間，client要向server發(fā)一個(gè)請(qǐng)求頭
請(qǐng)求無法并行執(zhí)行的，在一個(gè)連接里面
1.2 TCP丟包問題
1.3 瀏覽器線程數(shù)限制
多為2-6個(gè)線程，會(huì)在每個(gè)連接上串行發(fā)送若干個(gè)請(qǐng)求。TCP連接太多，會(huì)給服務(wù)器造成很大的壓力的。
1.4 DNS緩存問題
每次請(qǐng)求都需要找DNS緩存，多個(gè)請(qǐng)求就需要查找多次，而且緩存有可能被無故清空
2. 服務(wù)器處理請(qǐng)求
每個(gè)請(qǐng)求需要使用一個(gè)連接，建立一個(gè)線程，分配一部分CPU, 對(duì)于CPU而言，是種負(fù)擔(dān)，尤其是一般來說建立了連接以后，哪怕發(fā)回了請(qǐng)求，這個(gè)連接還會(huì)保持一段時(shí)間才會(huì)timeout。
這種時(shí)候，維持連接是對(duì)服務(wù)器資源的一種巨大的浪費(fèi)。
3. HTTP 2.0
上面描述的所有都是基于HTTP/1.1的一些特性，或者說弊端，有長連接但是無法并行處理請(qǐng)求，TCP的慢啟動(dòng)和擁塞控制，隊(duì)首阻塞問題都給整個(gè)性能帶來很多弊端，因此我們有了HTTP2.0來做針對(duì)性的改進(jìn)。很有意思的東西，直接看圖：
就是這么酷炫，HTTP/2多了很多特性來解決HTTP/1.1的很多問題
3.1 Fully multiplexed
解決了隊(duì)首阻塞的問題。對(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 系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺(tái)發(fā)送：面試，可以在線閱讀。
3.2 Header Compression
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ì)給你帶來很多性能上的提升。
而且大數(shù)據(jù)量的傳輸一定會(huì)降低瀏覽器的cache hit rate,對(duì)于緩存的利用率會(huì)降低很多。但是對(duì)于HTTP請(qǐng)求攜帶的數(shù)據(jù)量比較少的情況，合并請(qǐng)求帶來的性能提升會(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
關(guān)注Java技術(shù)棧看更多干貨
