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次，如果還沒有收到，就會認為這個連線已失效，不再維持。上面提到的兩個間隔和一個次數上限，都是可配的。
這就是持久連線的保活驗活機制。通過這個機制伺服器可以定時清理失效連線，釋放資源。
參考：