短連接與長連接

通俗來講，瀏覽器和服務器每進行一次通信，就建立一次連接，任務結束就中斷連接，即短連接。相反地，假如通信結束（如完成了某個HTML文件的信息獲取）後保持連接則為長連接。在HTTP/1.0中，默認使用短連接。從HTTP/1.1起，默認使用長連接，這樣做的優點是顯而易見的，一個網頁的加載可能需要HTML文件和多個CSS或者JS，假如每獲取一個靜態文件都建立一次連接，那麽就太浪費時間了，而在保持連接的情況下，繼續GET即可。

對於頻繁請求資源的客戶來說，較適用長連接。但連接數最好進行限制，防止建立太多連接拖累服務端。一般瀏覽器對一個網站的連接是有限制的幾個，所以網站會將資源部署在多個域名上以實現瀏覽器同時請求。

短/長連接應當在TCP連接的範疇中來討論。有人常說HTTP的短連接和長連接如何如何，但是HTTP只是一個應用層協議，又是無狀態的，最終實質性的保持連接還是得靠傳輸層，即TCP。

舉個例子，NginX作為代理的一種常見配置方式是在NginX與客戶端之間的連接使用長連接，NginX與後端服務器之間的連接使用短連接。

keep-alive

我們使用瀏覽器的開發者工具查看網絡請求和響應信息時經常在HTTP請求頭部看到Connection: keep-alive，一般的瀏覽器都會帶著個頭去請求數據，假如有特殊需求可以用Connection: close斷開。HTTP頭部的Connection也不一定就被客戶端或服務端老老實實地遵循，畢竟各有各的考慮，尤其是在HTTP/1.0這還只是個實驗性的功能，而在HTTP/1.1默認長連接於是沒有對長連接做特殊的規定。

長連接也不能無限期地長，服務端有可能在頭部放Keep-Alive，其中timeout等於一個值來規定保持連接的秒數，還可以用max來規定多少次請求後斷開。如果沒有說明怎麽斷開，主動發起四次握手也可以實現連接的斷開。

現在有一個問題就是HTTP的keep-alive與TCP的keep-alive到底是什麽關系。其實這是兩種不同的機制，可以認為沒有什麽關系。HTTP在頭部的Connection中聲明keep-alive可以告訴對方要長連接不立即斷開，但是TCP的keep-alive則是一種檢查對方是否仍舊和自己保持著連接的機制以避免自作多情半開放的連接。假如發出一個探測段，成功收到響應，這證明連接正常保持；假如發出一個探測段一段時間後，一個響應都沒收到，對方可能已掛斷、機器異常或網絡異常；假如對方收到探測段但重置，說明原來的連接已經因為某些原因掛斷，目前是因為未進行三次握手新建立連接而被掛斷。

參考資料

http://stackoverflow.com/.../relation-between-http-keep-alive-duration-and-tcp-timeout-duration

http://www.cnblogs.com/cswuyg/p/3653263.html

http://www.cnblogs.com/sunada2005/p/3304593.html

短連接、長連接與keep-alive