http連接復用進化論
HTTP協議是應用層協議，它定義萬維網客戶端如何與伺服器進行通訊。它在傳輸層的TCP協議的基礎上進行數據傳輸
HTTP 1.0
在HTTP 1.0時代，默認一個http請求對應一個TCP連接，沒有任何復用。也就是每發起一個http請求，就會創建一個TCP連接，請求完成後，TCP連接便會斷開。也可以通過Connection和Keep-Alive兩個頭部欄位配置使用持久連接。
HTTP 1.1
到了http1.1，底層的TCP默認是持久連接，前後串列的請求可以復用一個TCP連接。對後面的http請求來說，節約了等待TCP建立的時間。
使用持久連接時，如果上一個請求還沒完成，此時發起的http請求，還是要建立新的TCP，所以TCP整體的利用率比較低，因此HTTP1.1也定義了一種管道化Pipelining機制，它允許先後發起多個請求，然後再依次接收這些請求的響應，不必等前一個請求結束後就可以發送下一個，但是因為它會導致隊頭阻塞，高優先順序的請求很可能會被前面的阻塞，而且實現比較複雜，且只支援get和head請求，所以實現的瀏覽器很少，應用並不廣泛。
不論是持久連接還是管道化，對連接的復用都不夠完美，復用率比較低，所以當時前端會通過資源合併的方式減少請求數，以提升網頁載入性能，比如雪碧圖，css和JS打包、內聯等等
HTTP 2.0
後來有了http2.0協議，定義了二進位分幀和多路復用，支援在一個TCP連接中同時雙向傳輸多個請求和響應，多個http請求數據同時復用一個TCP連接。
HTTP 3.0
http3.0是基於UDP的，通訊初始化的成本本身就很低，而且還實現了流復用，所以效率和復用率更高。
關於持久連接的保活驗活機制
網路狀況是多變的，雙方不可能一直維持著某個TCP連接，而是有一套完整而且可以配置的保活驗活機制，具體是當鏈路空間時間到達7200秒時，就會發送探測包，探測連接和對端是否正常，如果正常，就繼續等待重複這個流程；如果沒有正常收到回包，就會以默認75s的間隔重複發送探測包，直至發送次數到達9次，如果還沒有收到，就會認為這個連接已失效，不再維持。上面提到的兩個間隔和一個次數上限，都是可配的。
這就是持久連接的保活驗活機制。通過這個機制伺服器可以定時清理失效連接，釋放資源。
