首先：HTTP的長連接和短連接本質上是TCP長連接和短連接。
1. 在HTTP1.0中，默認的是短連接，沒有正式規定 Connection:Keep-alive 操作；在HTTP1.1中所有連接都是Keep-alive的，也就是默認都是持續連接的（Persistent Connection）。
2. 兩種的連接方式的區別如下圖所示
3. 從上圖可以看出，客戶端與服務器建立持續連接后，在連接期間可以處理多個請求/響應（Request/Response）
HTTP權威指南：
HTTP/1.1 允許HTTP設備在事務處理結束以后將TCP連接保持在打開狀態，后面的HTTP Request/Response 依然可以通過這個TCP連接繼續傳送。
在事務結束之后仍然保持在打開狀態的TCP連接成為持久鏈接。非持久連接會在每個事務結束后關閉，持久連接會在不同事務（Request/Response）之間保持打開狀態，知道客戶端或服務器決定將其關閉為止。
可以提高HTTP連接性能的方法：
並行連接
通過多條連接發起並發的HTTP請求。並行連接可以提高復合頁面的傳輸速度，但其連接也有一些缺點
每個事務都會打開/關閉一條新的連接，會耗費時間和帶寬。由於TCP慢啟動特性存在，每條連接的性能都會有所降低。可打開的並行連接數量實際上是有限的
持久化連接
Web客戶端經常會打開到同一個站點的連接。比如，一個Web頁面上的大部分內嵌圖片通常來自同一個Web站點，而且相當一部分指向其他對象的超鏈通常都指向同一個站點。初始化了對某服務器HTTP請求的應用程序很可能會不久的將來對那台服務器發起更多的請求，這種性質稱為站點局部性。
因此，HTTP/1.1允許HTTP設備在事務處理結束之后將TCP連接保持在打開狀態，以便為未來的HTTP請求重用現存的連接。在事務處理結束之后仍然保持在打開狀態的TCP連接稱之為持久連接。持久連接會在不同事務之間保持打開狀態，直到客戶端或服務器決定其關閉為之。重用已對目標服務器打開的空閑持久連接，就可以避開緩慢的連接建立階段。而且，已經打開的連接還可以避免慢啟動的擁塞適應階段，以便更快速地進行數據傳輸。所以，持久連接降低了時延和連接建立的開銷，將連接保持在已調諧狀態，而且減少了打開連接的潛在數量。
持久連接和並行連接配合使用可能是最高效的方式。很多Web應用程序都會打開少量的並行連接，其中每個都是持久連接。持久連接有兩種類型
1）HTTP/1.0 + keep-alive 連接
2) HTTP/1.1 + persistent 連接
HTTP/1.0 keep-alive連接
現在很多客戶端和服務器仍然在使用這些早期的keep-live連接。
實現HTTP/1.0 keep-live連接的客戶端可以通過包含Connection:Keep-Alive 首部請求將一條連接保持在打開狀態。
如果服務器願意為下一條請求將連接保持在打開狀態，就在響應中包含相同的首部，如果響應中沒有Connection:Keep-Alive 首部，客戶端就認為服務器不支持keep-live，會在發回響應報文后關閉連接。
響應中Keep-Alive首部是可選的，但只有在提供Connection：Keep-Alive時才能使用它。
Connection:Keep-Alive
Keep-Alive:max=5,timeout=120
這個例子說明了服務器最多還會為另外5個事務保持連接的打開狀態，或者將打開狀態保持到連接空閑了2分鍾以后。
注意：
1 在HTTP/1.0中，keep-alive並不是默認使用的。客戶端必需發送一個Connection：Keep-Alive 請求首部來激活keep-alive連接。
2 如果服務器願意為下一條請求將連接保持在打開狀態，就在響應中包含相同的首部，如果響應中沒有Connection:Keep-Alive 首部，客戶端就認為服務器不支持keep-live，會在發回響應報文后關閉連接。
3 只有在無需檢測到連接的關閉就可以確定報文實體主體部分長度的情況下，才能將連接保持在打開狀態--也就是說實體的主體部分必需有正確的Content-Length，
有多部件媒體類型（multipart/form-data ? 有boundary）或者用分塊傳輸編碼的方式進行了編碼。在一條keep-live信道中回送錯誤的Content-Length是很糟糕的事情，這樣的話，事務處理的另一端就無法精確地檢測出一條報文的結束和另一條報文的開始了。
HTTP/1.1 持久連接 Persistent Connection
HTTP/1.1逐漸停止了對keep-alive連接的支持，用一種名為持久連接的改進型設計取代了它。持久連接的目的與keep-alive連接的目的相同，但是工作機制更優些。HTTP/1.1就吃連接在默認情況下是激活的，除非特別指明，否則HTTP/1.1假定所有的連接都是持久的，要在事務處理結束之后將連接關閉，HTTP/1.1應用程序必須向報文中顯示地添加一個Connection：close首部。
HTTP1.1客戶端加載在收到響應后，除非響應中包含了Connection：close首部，不然HTTP/1.1連接就仍然維持在打開狀態。但是，客戶端和服務器仍然可以隨時關閉空閑的連接。不發送Connection：close並不意味這服務器承諾永遠將連接保持在打開狀態。
注意：
1 只有當連接所有的報文都有正確的、自定義報文長度時，也就是說，實體主體部分的長度都和相應的Content-Length一致，或者用分塊傳輸編碼方式編碼的，連接誒才能持久保持。
2 如果客戶端不想在連接上發送其他請求了，就應該在最后一條請求中發送一個Connection：close請求首部
管道化連接
HTTP/1.1允許在持久連接上可選的使用請求管道。是相對於keep-alive連接的又一性能優化。在響應到達之前，可以將多條請求放入隊列，當第一條請求通過網絡流向服務器時，第二條和第三條請求也可以開始發送了。在高時延網絡條件下，這樣做可以降低網絡的環回時間，提高性能。
對管道連接的說明：
1）如果HTTP客戶端無法確認連接是持久的，就不應該使用管道
2）必須按照與請求相同的順序回送HTTP響應。
3）HTTP客戶端必須做好連接會在任意時刻關閉的准備，還要准備好重發所有未完成管道化的請求。
4）出錯的時候，管道連接會阻礙客戶端了解服務器執行的是一些列管道化請求中的哪一些。由於無法安全地重試POST這樣的非冪請求，所以出錯時，就存在某些方法永遠不會被執行的風險。
