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詳解 卷一
來源：http://www.cnblogs.com/beifei/archive/2011/06/26/2090611.html
什么是“長連接”和“短連接”？
解釋1
所謂長連接指建立SOCKET連接后不管是否使用都保持連接，但安全性較差；
所謂短連接指建立SOCKET連接后發送后接收完數據后馬上斷開連接，一般銀行都使用短連接
解釋2
長連接就是指在基於tcp的通訊中，一直保持連接，不管當前是否發送或者接收數據。
而短連接就是只有在有數據傳輸的時候才進行連接，客戶－服務器通信/傳輸數據完畢就關閉連接。
解釋3
長連接和短連接這個概念好像只有移動的CMPP協議中提到了，其他的地方沒有看到過。
通信方式
各網元之間共有兩種連接方式：長連接和短連接。所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接。短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成后，則斷開此TCP連接，即每次TCP連接只完成一對 CMPP消息的發送。
現階段，要求ISMG之間必須采用長連接的通信方式，建議SP與ISMG之間采用長連接的通信方式。
解釋4
短連接：比如http的，只是連接、請求、關閉，過程時間較短,服務器若是一段時間內沒有收到請求即可關閉連接。
長連接：有些服務需要長時間連接到服務器，比如CMPP，一般需要自己做在線維持。
HTTP協議之長、短連接
一、長連接與短連接：
長連接：client方與server方先建立連接，連接建立后不斷開，然后再進行報文發送和接收。
這種方式下由於通訊連接一直存在。此種方式常用於P2P通信。
短連接：Client方與server每進行一次報文收發交易時才進行通訊連接，交易完畢后立即斷開連接。
此方式常用於一點對多點通訊。C/S通信。
二、長連接與短連接的操作過程：
短連接的操作步驟是：
建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接
長連接的操作步驟是：
建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接
三、長連接與短連接的使用時機：
長連接：長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多的情況。
每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。
如果每次操作都要建立連接然后再操作的話處理速度會降低，所以每次操作后，下次操作時直接發送數據就可以了，不用再建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創建也是對資源的浪費。
短連接：web網站的http服務一般都用短連接。因為長連接對於服務器來說要耗費一定的資源。像web網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都占有一個連接的話，可想而知服務器的壓力有多大。所以並發量大，但是每個用戶又不需頻繁操作的情況下需要短連接。總之：長連接和短連接的選擇要根據需求而定。
四、發送接收方式：
1、異步：報文發送和接收是分開的，相互獨立，互不影響的。這種方式又分兩種情況：
異步雙工：接收和發送在同一個程序中，有兩個不同的子進程分別負責發送和接送。
異步單工：接送和發送使用兩個不同的程序來完成。
2、同步：報文發送和接收是同步進行，即報文發送后等待接送返回報文。同步方式一般需要考慮超時問題，試想我們發送報文以后也不能無限等待啊，所以我們要設定一個等待
時候。超過等待時間發送方不再等待讀返回報文。直接通知超時返回。
五、報文格式：
通信報文格式多樣性更多，相應地就必須設計對應的讀寫報文的接收和發送報文函數。
阻塞與非阻塞方式
1、非阻塞方式：讀函數不停的進行讀動作，如果沒有報文接收到，等待一段時間后超時返回，這種情況一般需要指定超時時間。
2、阻塞方式：如果沒有接收到報文，則讀函數一直處於等待狀態，知道報文到達。
循環讀寫方式
1、一次直接讀寫報文：在一次接收或發送報文動作中一次性不加分別地全部讀取或全部發送報文字節。
2、不指定長度循環讀寫：這一版發生在短連接進程中，受網絡路由等限制，一次較長的報文可能在網絡傳輸過程中被分解成很多個包，一次讀取可能不能全部讀完一次報文，這就需要循環讀取報文，直到讀完為止。
3、帶長度報文頭循環讀寫：這種情況一般在長連接中，由於在長連接中沒有條件能夠判斷循環讀寫什么時候結束。必須要加長度報文頭。讀函數先是讀取報文頭的長度，再根據這個長度去讀報文，實際情況中，報頭碼制格式還經常不一樣，如果是非ASCII的報文頭，還必須轉換成ASCII常見的報文頭編制有：
1、n個字節的ASCII碼。
2、n個字節的BCD碼。
3、n個字節的網絡整型碼。
以上是幾種比較典型的讀寫報文方式，可以與通信方式模板一起預先提供一些典型的API讀寫函數。當然在實際問題中，可能還必須編寫與對方報文格式配套的讀寫API. 在實際情況中，往往需要把我們自己的系統與別人的系統進行連接， 有了以上模板與API,可以說連接任何方式的通信程序都不存在問題。
來源：http://www.360doc.com/content/14/0412/16/16726605_368309628.shtml
總之，長連接和短連接的選擇要視情況而定。
公司的服務器端使用的是resin做中間件，通過客戶端每隔幾秒發送請求來進行互動。
這種就應該是短連接了吧？
短連接需要頻繁的建立與斷開連接，是不是對服務器的資源浪費很大？
如果換成長連接呢？長連接的缺點在哪里？
回答：
從網絡技術層面來說：TCP本身是長連接的。
當然從業務層面來說：每次連接只處理一筆請求的可以稱為短連接；處理業務后不斷開連接而是等待處理下一筆可以稱為長連接。
至於實際場合究竟需要使用短連接還是長連接，主要看實時性要求、數據流向 和 並發量 這三個問題。
由於你沒有說明請求關於這三個問題上的特點，所以沒法給你具體建議。
長連接優點：節約TCP握手時間，可以保證高實時性，數據流向可以采用服務器端的主動推模式。
長連接缺點：並發量不宜太高，持續占用服務端口（相對消耗資源）。
我有一個基於長連接推模型的聊天室的簡單樣例，你可以看看：
http://blog.csdn.net/ldh911/article/details/7268879
1.現在游戲中的玩家與玩家之間的聊天無法實現實時性，而且系統有郵件或信息時也不能及時的通知玩家
—— 如果涉及到聊天的話，一般來說還是用長連接會更合適，否則大量時間浪費到握手上了；
—— 但是手機的網絡長連接網絡質量可能會比較撮，你需要嚴重考慮容錯和重鏈機制。
2.客戶端每隔幾秒就會發送一個請求，這樣服務器的壓力豈不是很大？
—— 壓力會比較大，關鍵是聊天往往對時間的要求很高，如果是團戰的話，1秒內沒看到信息，可能就會覺得完全受不了了；當然也看你聊天的場景如何，是群聊還是單聊，以后會不會發展為語音啥的；
NIO沒有任何問題，大規模長連接處理的主流都是用NIO；而且也不是Java發明的，本身就是借助了操作系統的網絡管理能力。