TCP短連接
我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然後雙方建立連接。client向server發送消息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起close操作。爲什麼呢，一般的server不會回覆完client後立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在client/server間傳遞一次讀寫操作
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段
TCP長連接
接下來我們再模擬一下長連接的情況，client向server發起連接，server接受client連接，雙方建立連接。Client與server完成一次讀寫之後，它們之間的連接並不會主動關閉，後續的讀寫操作會繼續使用這個連接。
首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要爲服務器應用提供，服務器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，則服務器將應遠等待客戶端的數據，保活功能就是試圖在服務器端檢測到這種半開放的連接。
如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一：
- 客戶主機依然正常運行，並從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時後將保活定時器復位。
- 客戶主機已經崩潰，並且關閉或者正在重新啓動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。服務器總共發送10個這樣的探測，每個間隔75秒。如果服務器沒有收到一個響應，它就認爲客戶主機已經關閉並終止連接。
- 客戶主機崩潰並已經重新啓動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。
- 客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。
從上面可以看出，TCP保活功能主要爲探測長連接的存活狀況，不過這裏存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連接的存活，屬於比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。
在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器爲顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。
剛接觸HTTP請求就聽說過HTTP請求有1.0和1.1兩個版本（其實還有個0.9版本，因爲只接受GET一種請求，不支持POST方法，因此客戶端無法向服務器傳遞太多信息而爲人們所忽略），而且還知道HTTP1.0協議不支持長連接，從HTTP1.1協議以後，連接默認都是長連接。但終究覺得對於長連接一直不明覺厲，有種抓不到關鍵點的感覺。
我們現在用的都是HTTP1.1版本，而HTTP1.1版本又是支持長連接的（也叫持久連接），因此我們平時用的都是長連接，我之前一直這麼認爲的。經過最近的探索發現，這話並不是這樣的。因爲HTTP協議根本就沒有長短連接這一說法。
衆所周知，HTTP協議是基於請求/響應模式的，因此只要服務端給了響應，本次HTTP連接就結束了。之所以網絡上說HTTP分爲長連接和短連接，其實本質上是說的TCP連接。TCP連接是一個雙向的通道，它是可以保持一段時間不關閉的，因此TCP連接纔有真正的長連接和短連接這一說。HTTP協議說到底是應用層的協議，而TCP纔是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連接。以後記住長連接，短連接都是指的傳輸層的TCP連接，而不是應用層的HTTP協議。HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有可靠，面向連接的特點。
1，如何理解HTTP協議是無狀態的
HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。
2，什麼是長連接、短連接？
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：Connection:keep-alive 服務器和客戶端都要設置
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
3，TCP連接
當網絡通信時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連接，當讀寫操作完成後，雙方不再需要這個連接 時它們可以釋放這個連接，連接的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的。
4，TCP短連接
我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然後雙方建立連接。client向server 發送消息，server迴應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。爲什麼呢，一般的server不會回覆完client後立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在client/server間傳遞一次讀寫操作。
短連接的操作步驟是：建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
5，TCP長連接
接下來我們再模擬一下長連接的情況，client向server發起連接，server接受client連接，雙方建立連接。Client與server完成一次讀寫之後，它們之間的連接並不會主動關閉，後續的讀寫操作會繼續使用這個連接。比如你請求了csdn的一個網頁，這個網頁裏肯定還包含了CSS、JS等等一系列資源，如果你是短連接（也就是每次都要重新建立TCP連接）的話，那你每打開一個網頁，基本要建立幾個甚至幾十個TCP連接，但如果是長連接的話，那麼這麼多次HTTP請求（這些請求包括請求網頁內容，
CSS文件，JS文件，圖片等等），其實使用的都是一個TCP連接，很顯然是可以節省很多消耗的。
另外，最後關於長連接還要多提一句，那就是，長連接並不是永久連接的。如果一段時間內（具體的時間長短，是可以在header當中進行設置的，也就是所謂的超時時間），這個連接沒有HTTP請求發出的話，那麼這個長連接就會被斷掉。這一點其實很容易理解，否則的話，TCP連接將會越來越多，直到把服務器的TCP連接數量撐爆到上限爲止。現在想想，對於服務器來說，服務器裏的這些個長連接其實很有數據庫連接池的味道，大家都是爲了節省連接重複利用嘛，對不對？
長連接的操作步驟是：建立連接——數據傳輸…（保持連接）…數據傳輸——關閉連接
6，長連接和短連接的優點和缺點
由上可以看出，長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長連接。不過這裏存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP連接的存活，屬於比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可 以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器爲顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累後端服務。短連接對於服務器來說管理較爲簡單， 存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。
7，什麼時候用長連接，短連接
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，
所以每個操作完後都不斷開，下次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，
如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。而像WEB網站的http服務一般都用短鏈接，因爲長連接對於服務端來說會耗費一定的資源， 而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都佔用一個連接的話，那可想而知吧。
轉自：http://www.nowamagic.net/academy/detail/23350382
心跳包
很多應用層協議都有HeartBeat機制，通常是客戶端每隔一小段時間向服務器發送一個數據包，通知服務器自己仍然在線，並傳輸一些可能必要的數據。使用心跳包的典型協議是IM，比如QQ/MSN/飛信等協議。
心跳包之所以叫心跳包是因爲：它像心跳一樣每隔固定時間發一次，以此來告訴服務器，這個客戶端還活着。事實上這是爲了保持長連接，至於這個包的內容，是沒有什麼特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。
在TCP的機制裏面，本身是存在有心跳包的機制的，也就是TCP的選項：SO_KEEPALIVE。系統默認是設置的2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般，如果只是用於保活還是可以的。
心跳包一般來說都是在邏輯層發送空的echo包來實現的。下一個定時器，在一定時間間隔下發送一個空包給客戶端，然後客戶端反饋一個同樣的空包回來，服務器如果在一定時間內收不到客戶端發送過來的反饋包，那就只有認定說掉線了。
其實，要判定掉線，只需要send或者recv一下，如果結果爲零，則爲掉線。但是，在長連接下，有可能很長一段時間都沒有數據往來。理論上說，這個連接是一直保持連接的，但是實際情況中，如果中間節點出現什麼故障是難以知道的。更要命的是，有的節點（防火牆）會自動把一定時間之內沒有數據交互的連接給斷掉。在這個時候，就需要我們的心跳包了，用於維持長連接，保活。
在獲知了斷線之後，服務器邏輯可能需要做一些事情，比如斷線後的數據清理呀，重新連接呀……當然，這個自然是要由邏輯層根據需求去做了。
總的來說，心跳包主要也就是用於長連接的保活和斷線處理。一般的應用下，判定時間在30-40秒比較不錯。如果實在要求高，那就在6-9秒。
TCP協議的KeepAlive機制
學過TCP/IP的同學應該都知道，傳輸層的兩個主要協議是UDP和TCP，其中UDP是無連接的、面向packet的，而TCP協議是有連接、面向流的協議。
所以非常容易理解，使用UDP協議的客戶端（例如早期的“OICQ”，聽說OICQ.com這兩天被搶注了來着，好古老的回憶）需要定時向服務器發送心跳包，告訴服務器自己在線。
然而，MSN和現在的QQ往往使用的是TCP連接了，儘管TCP/IP底層提供了可選的KeepAlive（ACK-ACK包）機制，但是它們也還是實現了更高層的心跳包。似乎既浪費流量又浪費CPU，有點莫名其妙。
具體查了下，TCP的KeepAlive機制是這樣的，首先它貌似默認是不打開的，要用setsockopt將SOL_SOCKET.SO_KEEPALIVE設置爲1纔是打開，並且可以設置三個參數 tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分別表示連接閒置多久開始發keepalive的ack包、發幾個ack包不回覆才當對方死了、兩個ack包之間間隔多長，在我測試的Ubuntu Server 10.04下面默認值是7200秒（2個小時，要不 要這麼蛋疼啊！）、9次、75秒。於是連接就了有一個超時時間窗口，如果連接之間沒有通信，這個時間窗口會逐漸減小，當它減小到零的時候，TCP協議會向對方發一個帶有ACK標誌的空數據包（KeepAlive探針），對方在收到ACK包以後，如果連接一切正常，應該回復一個ACK；如果連接出現錯誤了（例如對方重啓了，連接狀態丟失），則應當回覆一個RST；如果對方沒有回覆，服務器每隔intvl的時間再發ACK，如果連續probes個包都被無視了，說明連接被斷開了。
這裏有一篇非常詳細的介紹文章： http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO ，包括了KeepAlive的介紹、相關內核參數、C編程接口、如何爲現有應用（可以或者不可以修改源碼的）啓用KeepAlive機制，很值得詳讀。
這篇文章的2.4節說的是“Preventing disconnection due to network inactivity”，阻止因網絡連接不活躍（長時間沒有數據包）而導致的連接中斷，說的是，很多網絡設備，尤其是NAT路由器，由於其硬件的限制（例如內存、CPU處理能力），無法保持其上的所有連接，因此在必要的時候，會在連接池中選擇一些不活躍的連接踢掉。典型做法是LRU，把最久沒有數據的連接給T掉。通過使用TCP的KeepAlive機制（修改那個time參數），可以讓連接每隔一小段時間就產生一些ack包，以降低被T掉的風險，當然，這樣的代價是額外的網絡和CPU負擔。