面試官：為什麼要合併 HTTP 請求?
來源：https://www.jianshu.com/p/9a3f0e84c2b0
思考路徑：
為什麼要實現batch call? -> 減少網路中的傳輸損耗 -> 如何減少的? -> 通過合併HTTP請求 -> 合併HTTP請求是如何減少網路損耗的？
本文將解決這個問題。一起看看單個請求攜載大量資訊和多個請求攜載小量資訊對於整個時間的影響。
1. Client發出請求
1.1 HTTP 1.1
可以保持長連線，但是每個不同的請求之間，client要向server發一個請求頭
請求無法並行執行的，在一個連線裡面
假設如果不合並的話需要建立N個連線，那麼合併就可以省去(N-1)*RTT的時間，RTT指網路延遲（在傳輸介質中傳輸所用的時間，即從報文開始進入網路到它開始離開網路之間的時間）。
1.2 TCP丟包問題
慢啟動，擁塞控制視窗
TCP報文亂序到達，合併後的檔案可以允許隊首丟包以後在隊中補上來，但是分開資源的時候，前一個資源未載入完成後面的資源是不能載入的，會有更嚴重的隊首阻塞問題，丟包率會嚴重影響Keep alive情況下多個檔案的傳輸速率。
1.3 瀏覽器執行緒數限制
多為2-6個執行緒，會在每個連線上序列傳送若干個請求。TCP連線太多，會給伺服器造成很大的壓力的。
1.4 DNS快取問題
每次請求都需要找DNS快取，多個請求就需要查詢多次，而且快取有可能被無故清空
2. 伺服器處理請求
每個請求需要使用一個連線，建立一個執行緒，分配一部分CPU, 對於CPU而言，是種負擔，尤其是一般來說建立了連線以後，哪怕發回了請求，這個連線還會保持一段時間才會timeout。
這種時候，維持連線是對伺服器資源的一種巨大的浪費。
3. HTTP 2.0
上面描述的所有都是基於HTTP/1.1的一些特性，或者說弊端，有長連線但是無法並行處理請求，TCP的慢啟動和擁塞控制，隊首阻塞問題都給整個效能帶來很多弊端，因此我們有了HTTP2.0來做針對性的改進。很有意思的東西，直接看圖：
就是這麼酷炫，HTTP/2多了很多特性來解決HTTP/1.1的很多問題
3.1 Fully multiplexed
解決了隊首阻塞的問題。對於同一個TCP連線，現在可以傳送多個請求，接收多個迴應了！在HTTP/1.1裡面，如果在一個連線裡上一個請求發生了丟包，那麼後面的所有請求都必須等第一個請求補上包，收到迴應以後才能繼續執行。而在HTTP/2裡面，可以直接並行處理。
3.2 Header Compression
所有的HTTP request和response都有header，但是header裡很可能包含快取資訊，導致他的大小會迅速增大的。但是在一個連線裡大部分請求的請求頭其實攜帶的資訊都很類似，所以HTTP/2使用了索引表，儲存了第一次出現的請求的請求頭，然後後面的類似的請求只需要攜帶這個索引的數字就好了。頭部壓縮平均減少了30%的頭部大小，加快了整體的網路中傳輸的速度。
這兩點是和本文關係最大的，有了這兩點，實質上合併HTTP請求的好處在HTTP/2的協議下，已經基本上消失了。合併不合並請求，更多的是看業務上的需求，後端的一些配置。
4. 總結
It’s a trade-off. 其實最重要的是看你傳輸什麼東西，因為合併HTTP請求實質上是減少了網路延時，但是如果你在伺服器上處理的時間遠遠大於網路延時的時間的時候，那麼合併HTTP請求並不會給你帶來很多效能上的提升。
而且大資料量的傳輸一定會降低瀏覽器的cache hit rate,對於快取的利用率會降低很多。但是對於HTTP請求攜帶的資料量比較少的情況，合併請求帶來的效能提升會是顯而易見的。
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
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什麼新語法？
4.Spring Boot 2.5 重磅釋出，黑暗模式太炸了！
覺得不錯，別忘了隨手點贊+轉發哦！