文章目錄
- 一、隊頭堵塞
- 1、非管線化
- 2、管線化
- 二、如何解決？
一、隊頭堵塞
1、非管線化
如圖，http 請求必須等到上一個請求響應后才能發送，后面的以此類推，由此可以看出，在一個 tcp 通道中，如果某個 http 請求的響應因為某種原因沒能及時返回，那后面的請求都會被阻塞
2、管線化
管線化限制服務器端需按照請求的發送順序返回響應，如果其中某個響應因為某種原因延遲了幾秒，那后面的響應都會被阻塞
HTTP/1.1 管線化解決了請求的隊頭阻塞，但沒有解決響應的隊頭阻塞
二、如何解決？
HTTP/1.1 建議客戶端使用并發長連接，RFC2616 明確限制每個客戶端對同一個域名可以建立兩個長連接，但是一般瀏覽器會增加到 6 ~ 8 個，其中，谷歌瀏覽器是 6 個，也就是頁面中如果對同一個域名有多個 http 請求，谷歌瀏覽器會對這個域名建立 6 個 tcp 長連接，在每個長連接里面再去處理 http 請求，但是這種方案對服務器的挑戰非常大，甚至有些 web 優化方案中還會突破 6 ~ 8 的限制，那就是域名切片，因為長連接針對的是同一個域名，如果開發人員將資源分布在不同的域名上，那么長連接的數量是可以被突破的，但這樣做無疑會增大服務器的連接數，當服務器面對海量請求的話，可能會出現問題，那怎么辦呢？HTTP/2.0
)
