我們都知道，HTTP協議採用“請求-應答”模式，當使用普通模式，即非Keep-alive模式時，每個請求/應答客戶和服務器都要新建一個連接，完成之後立即斷開連接（HTTP協議爲無連接的協議）；當使用Keep-alive模式時（又稱持久連接，連接重用）時，Keep-alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後續請求時，Keep-alive避免了重新建立連接。
在老的HTTP版本中，每個請求都將被創建一個新的客戶端到服務器端的連接，在這個連接上發送請求，然後接受請求。這樣的模式有一個很大的優點，它很簡單，很容易理解和編程實現；它也有一個很大的缺點，它的效率很低，Keep-alive就是用來解決這個問題的。
Keep-alive使客戶端到服務器端的連接持續有效，當出現對服務器的後續請求時，Keep-alive功能避免了建立或者重新建立連接。現在的大多數Web服務器都支持Keep-alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裏存在另一個問題：雖然爲客戶保留打開的連接有一定的好處，但它同樣影響了性能，因爲在處理暫停期間，本來可以釋放的資源讓舊被佔用。此功能爲HTTP1.1預設的功能,但在HTTP1.0上我們加上Keep-Aliveheader同樣可以使用這個功能。
我們來舉個例子說一下：
Keep-alive：timeout=5，max=100
意思是說：過期時間5秒，max是最多100次請求，強制斷掉連接，也就是在timeout時間內每來一個新的請求，max會自動減1,直到爲0，強制斷掉連接。
在HTTP1.0版本中並沒有官方的標準來規定Keep-alive如何工作，因此實際上他是被附加到HTTP1.0協議上的，如果客戶端瀏覽器支持Keep-alive，那麼就在HTTP請求中加一個字段：Connection：Keep-alive，當服務器收到附帶有Connection：Keep-alive的請求時，它也會在響應頭中加一個同樣的字段來使用Keep-alive。這樣一來客戶端和服務器之間的HTTP連接就會保持，不會斷開（除非超過timeout規定的時間），當客戶端發送另外一個請求時，就使用這條已經建立的連接。
在HTTP1.1版本中，官方規定的Keep-alive使用標準和HTTP/1.0版本中有些不同，默認情況下HTTP/1.1中所有連接都被保持，除非在請求頭或響應頭中指明要關閉，：Connection：Close。
HTTP是一個無狀態協議，這意味着每個請求都是獨立的，Keep-alive沒能改變這個結果。另外，Keep-alive也不能保證客戶端和服務器端之間的連接一定是活躍的，在HTTP/1.1中也是如此。唯一能保證的就是當連接被關閉時你能得到一個通知，所以我們不應該讓程序依賴Keep-alive的保持連接性，否則會與一些意想不到的後果。
通過使用Keep-alive機制，可以減少tcp連接建立的次數，也以爲這可以減少TIME_WAIT狀態連接，以此提高性能和提高HTTP服務器的吞吐率（更少的tcp連接意味着更少的系統內核調用，socket的accept（）和close（）調用）。但是長時間的tcp連接容易導致系統資源無效佔用，配置不當的Keep-alive有事比重複利用連接帶來的損失還更大。所以正確地設置Keep-alive timeout時間非常重要。
下面我們來說說這個Keep-alive timeout參數：
Httpd守護進程，一般都提供了Keep-alivetimeout時間設置參數。這個時間值意味着：一個http產生的tcp連接在傳送完最後一個響應後，還需要還需要保持keep-alive timeout秒後，纔開始關閉這個連接。
當httpd守護進程發送完一個響應後，理應馬上主動關閉相應的tcp連接，設置keepalive_timeout後，httpd守護進程會說：再等等吧，看瀏覽器還有沒有請求過來，這個等待的時間就是keepalive_timeout時間，如果守護進程在這個等待的時間裏，一直沒有收到瀏覽器發過來的http請求，則關閉這個http連接。
總之，我們應更好的使用這個機制給我們帶來一些好處。