TCP長連接與短連接的區別
1. TCP連接
當網絡通信時采用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接時它們可以釋放這個連接，連接的建立是需要三次握手的，而釋放則需要4次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的
經典的三次握手示意圖：
經典的四次握手關閉圖：
2. TCP短連接
我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然后雙方建立連接。client向server發送消息，server回應client，然后一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起close操作。為什么呢，一般的server不會回復完client后立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在client/server間傳遞一次讀寫操作
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段
3.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端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累后端服務。
長連接和短連接的產生在於client和server采取的關閉策略，具體的應用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。
參考：
1. TCP/IP詳解 卷一
TCP/IP通信程序設計的豐富多樣性
剛接觸TCP/IP通信設計的人根據范例可以很快編出一個通信程
序，據此一些人可能會認為TCP/IP編程很簡單。其實不然，
TCP/IP編程具有較為豐富的內容。其編程的豐富性主要體現在
通信方式和報文格式的多樣性上。
一。通信方式
主要有以下三大類:
(一)SERVER/CLIENT方式
1.一個Client方連接一個Server方，或稱點對點(peer to peer)：
2.多個Client方連接一個Server方，這也是通常的並發服務器方式。
3.一個Client方連接多個Server方，這種方式很少見，主要
用於一個客戶向多個服務器發送請求情況。
(二)連接方式
1.長連接
Client方與Server方先建立通訊連接，連接建立后不斷開，
然后再進行報文發送和接收。這種方式下由於通訊連接一直
存在，可以用下面命令查看連接是否建立：
netstat –f inet|grep 端口號(如5678)。
此種方式常用於點對點通訊。
2.短連接
Client方與Server每進行一次報文收發交易時才進行通訊連
接，交易完畢后立即斷開連接。此種方式常用於一點對多點
通訊，比如多個Client連接一個Server.
(三)發送接收方式
1.異步
報文發送和接收是分開的，相互獨立的，互不影響。這種方
式又分兩種情況：
(1)異步雙工：接收和發送在同一個程序中，有兩個不同的
子進程分別負責發送和接收
(2)異步單工：接收和發送是用兩個不同的程序來完成。
2.同步
報文發送和接收是同步進行，既報文發送后等待接收返回報文。
同步方式一般需要考慮超時問題，即報文發上去后不能無限等
待，需要設定超時時間，超過該時間發送方不再等待讀返回報
文，直接通知超時返回。
實際通信方式是這三類通信方式的組合。比如一般書上提供的
TCP/IP范例程序大都是同步短連接的SERVER/CLIENT程序。有的
組合是基本不用的，比較常用的有價值的組合是以下幾種：
同步短連接Server/Client
同步長連接Server/Client
異步短連接Server/Client
異步長連接雙工Server/Client
異步長連接單工Server/Client
其中異步長連接雙工是最為復雜的一種通信方式，有時候經
常會出現在不同銀行或不同城市之間的兩套系統之間的通信。
比如金卡工程。由於這幾種通信方式比較固定，所以可以預
先編制這幾種通信方式的模板程序。
二.報文格式
通信報文格式多樣性更多，相應地就必須設計對應的讀寫報文的接
收和發送報文函數。
(一)阻塞與非阻塞方式
1.非阻塞方式
讀函數不停地進行讀動作，如果沒有報文接收到，等待一段時間后
超時返回，這種情況一般需要指定超時時間。
2.阻塞方式
如果沒有報文接收到，則讀函數一直處於等待狀態，直到有報文到達。
(二)循環讀寫方式
1.一次直接讀寫報文
在一次接收或發送報文動作中一次性不加分別地全部讀取或全部
發送報文字節。
2.不指定長度循環讀寫
這一般發生在短連接進程中，受網絡路由等限制，一次較長的報
文可能在網絡傳輸過程中被分解成了好幾個包。一次讀取可能不
能全部讀完一次報文，這就需要循環讀報文，直到讀完為止。
3.帶長度報文頭循環讀寫
這種情況一般是在長連接進程中，由於在長連接中沒有條件能夠
判斷循環讀寫什么時候結束，所以必須要加長度報文頭。讀函數
先是讀取報文頭的長度，再根據這個長度去讀報文.實際情況中，
報頭的碼制格式還經常不一樣，如果是非ASCII碼的報文頭，還必須
轉換成ASCII,常見的報文頭碼制有：
(1)n個字節的ASCII碼
(2)n個字節的BCD碼
(3)n個字節的網絡整型碼
以上是幾種比較典型的讀寫報文方式，可以與通信方式模板一起
預先提供一些典型的API讀寫函數。當然在實際問題中，可能還
必須編寫與對方報文格式配套的讀寫API.
在實際情況中，往往需要把我們自己的系統與別人的系統進行連接，
有了以上模板與API,可以說連接任何方式的通信程序都不存在問題。