1. TCP連線

當網路通訊時採用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連線，當讀寫操作完成後，雙方不再需要這個連線 時它們可以釋放這個連線，連線的建立是需要三次握手的，而釋放則需要4次揮手，所以說每個連線的建立都是需要資源消耗和時間消耗的

經典的三次握手示意圖：

經典的四次揮手圖：

tcp的十種狀態圖：

注意:

當一端收到一個FIN，核心讓read返回0來通知應用層另一端已經終止了向本端的資料傳送；
傳送FIN通常是應用層對socket進行關閉的結果。

tcp的2MSL問題

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

所謂長連線指建立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,可以說連線任何方式的通訊程式都不存在問題。

什麼時候用長連線，短連線？

長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多情況，。每個TCP連線都需要三步握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接傳送資料包就OK了，不用建立TCP連線。例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。

而像WEB網站的http服務一般都用短連結，因為長連線對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的 連線用短連線會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。所以併發量大，但每個使用者無需頻 繁操作情況下需用短連好。
總之，長連線和短連線的選擇要視情況而定。