HTTP是一個請求<->響應模式的典型範例，即客戶端向服務器發送一個請求信息，服務器來響應這個信息。在老的HTTP版本中，每個請求都將被創建一個新的客戶端->服務器的連接，在這個連接上發送請求，然後接收請求。這樣的模式有一個很大的優點就是，它很簡單，很容易理解和編程實現；它也有一個很大的缺點就是，它效率很低，因此Keep-Alive被提出用來解決效率低的問題。
Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上 的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裏存在另外一個問題：雖然爲客戶保留打開的連 接有一定的好處，但它同樣影響了性能，因爲在處理暫停期間，本來可以釋放的資源仍舊被佔用。當Web服務器和應用服務器在同一臺機器上運行時，Keep- Alive功能對資源利用的影響尤其突出。 此功能爲HTTP 1.1預設的功能，HTTP 1.0加上Keep-Aliveheader也可以提供HTTP的持續作用功能。
Keep-Alive: timeout=5, max=100
timeout：過期時間5秒（對應httpd.conf裏的參數是：KeepAliveTimeout），max是最多一百次請求，強制斷掉連接
就是在timeout時間內又有新的連接過來，同時max會自動減1，直到爲0，強制斷掉。見下面的四個圖，注意看Date的值（前後時間差都是在5秒之內）！
HTTP/1.0
在HTTP/1.0版本中，並沒有官方的標準來規定Keep-Alive如何工作，因此實際上它是被附加到HTTP/1.0協議上，如果客戶端瀏覽器支持Keep-Alive，那麼就在HTTP請求頭中添加一個字段 Connection: Keep-Alive，當服務器收到附帶有Connection: Keep-Alive的請求時，它也會在響應頭中添加一個同樣的字段來使用Keep-Alive。這樣一來，客戶端和服務器之間的HTTP連接就會被保持，不會斷開（超過Keep-Alive規定的時間，意外斷電等情況除外），當客戶端發送另外一個請求時，就使用這條已經建立的連接
HTTP/1.1
在HTTP/1.1版本中，官方規定的Keep-Alive使用標準和在HTTP/1.0版本中有些不同，默認情況下所在HTTP1.1中所有連接都被保持，除非在請求頭或響應頭中指明要關閉：Connection: Close ，這也就是爲什麼Connection: Keep-Alive字段再沒有意義的原因。另外，還添加了一個新的字段Keep-Alive:，因爲這個字段並沒有詳細描述用來做什麼，可忽略它
Not reliable（不可靠）
HTTP是一個無狀態協議，這意味着每個請求都是獨立的，Keep-Alive沒能改變這個結果。另外，Keep-Alive也不能保證客戶端和服務器之間的連接一定是活躍的，在HTTP1.1版本中也如此。唯一能保證的就是當連接被關閉時你能得到一個通知，所以不應該讓程序依賴於Keep-Alive的保持連接特性，否則會有意想不到的後果
Keep-Alive和POST
在HTTP1.1細則中規定了在一個POST消息體後面不能有任何字符，還指出了對於某一個特定的瀏覽器可能並不遵循這個標準（比如在POST消息體的後面放置一個CRLF符）。而據我所知，大部分瀏覽器在POST消息體後都會自動跟一個CRLF符再發送，如何解決這個問題呢？根據上面的說明在POST請求頭中禁止使用Keep-Alive，或者由服務器自動忽略這個CRLF，大部分服務器都會自動忽略，但是在未經測試之前是不可能知道一個服務器是否會這樣做。