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/2
HTTP 3.0
http3.0是基於UDP的，通信初始化的成本本身就很低，而且還實現了流復用，所以效率和復用率更高。
關於持久連接的保活驗活機制
網絡狀況是多變的，雙方不可能一直維持着某個TCP連接，而是有一套完整而且可以配置的保活驗活機制，具體是當鏈路空閑時間到達7200秒時，就會發送探測包，探測連接和對端是否正常，如果正常，就繼續等待重復這個流程；如果沒有正常收到ACK回包，就會以默認75s的間隔重復發送探測包，直至發送次數到達9次，如果還沒有收到，就會認為這個連接已失效，不再維持。上面提到的兩個間隔和一個次數上限，都是可配的。
這就是持久連接的保活驗活機制。通過這個機制服務器可以定時清理失效連接，釋放資源。
參考：