HTTP協議的Connection: keep-alive header是爲了解決性能問題而產生的。
HTTP作爲一個應用層協議，其性能在很大程度上取決於TCP（傳輸層協議）通道的性能。而keep-alive就是HTTP對其下的TCP通道性能優化的一種策略。
影響HTTP高併發時性能的若干個因素
建立TCP連接的網絡延時
下圖描繪了HTTP事務主要的連接、傳輸以及處理時延。
注意到，在很多情況下，服務器真正“處理”事務的時間並不長。絕大部分時間都被消耗在了建立TCP連接、傳輸請求和響應報文上。
當客戶端請求的資源在一臺服務器上，請求被串聯執行時，這種時延將會被進一步放大。如下圖客戶端向服務器請求了3個資源。
TCP慢啓動
TCP數據傳輸的性能還取決於TCP的使用期（age），連接會隨着時間進行自我“調諧”。比如一個TCP連接建立後，一個TCP端點在任意時刻可以傳輸的分組數是有限的。每成功接收一個分組，發送端就有了發送另外兩個分組的權限。隨着傳輸的數據越來越多，任意時刻可發送的分組數就會大大增加，這種方式被稱爲“打開擁塞窗口”。
持久化解決的問題
HTTP/1.0+ keep-alive連接
首先需要了解的一點是，在HTTP/1.0的各種增強版本中，通訊雙方默認是不使用持久化連接的。當客戶端請求中含有Connection: Keep-Alive首部，服務器響應中也有Connection: Keep-Alive首部時，雙方纔會成功建立持久連接。
在服務器返回客戶端Connection: Keep-Alive首部的同時，它還可以添加一條Keep-Alive首部。
Connection: Keep-Alive
Keep-Alive: max=5, timeout=120
上面個例子說明，服務器最多還會爲另外5個事務保持TCP連接的打開狀態，或者將打開狀態保持到連接空閒了2分鐘之後。
在HTTP/1.0+中還存在啞代理與相關解決方案的知識點，此處不再展開。實際上在新的HTTP/1.1規範中已經沒有了Keep-Alive的相關說明，它已被標準拋棄。但瀏覽器和服務器對HTTP/1.0+的支持依舊廣泛，因此瞭解其相關知識並未過時。
HTTP/1.1持久連接
HTTP/1.1在廢棄Keep-Alive後，提出了一種持久連接（persistent connection）的改進型設計取代它。它們目的相同，但後者工作機制更優。
持久連接在默認情況下都是支持的。除非特別指明，否則HTTP/1.1假定所有連接都是持久的。如果客戶端需要事務處理完之後直接關閉TCP連接，需要顯式地添加一個Connection: close首部。同樣如果服務器返回的首部中沒有Connection: close首部，客戶端會認爲連接仍維持在打開狀態。
管道化連接
HTTP/1.1允許在持久連接上可選地使用請求管道。在響應到達之前，可以將多餘請求放入隊列。下圖顯示了持久化連接是怎樣消除TCP連接時延，以及管道化請求是如何消除傳輸時延的。
