HTTP協議之長串連與短串連

 

什麼是“長串連”和“短串連”？

解釋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,可以說串連任何方式的通訊程式都不存在問題。