C/S通訊模型和相關技術要點

標籤：android   style   blog   http   java   color   使用   資料   

    幾乎所有的項目中，都會涉及到用戶端和服務端。而用戶端與伺服器之間的通訊又是一個很常見但又有需要問題的技術問題。

    首先，串連方式有長串連和短串連。先看看概念。

    長串連短串連只是一個概念性的問題,只要知道其概念，不是一個特殊的東西：
    長串連：系統通訊串連建立後就一直保持。
    短串連：只有系統需要相互發訊息串連才建立（用戶端發起），請求訊息得到響應後串連關閉；
通訊實體間使用長串連，一般還需要定義心跳訊息，定期發送來檢測系統間鏈路是否異常，每隔一定時間發送一次心跳，如果一定次數沒有收到心跳訊息，這認為此串連出現問題，需要中斷連線重建立立。
具體心跳訊息的格式，以及發送間隔，以及多少次沒有收到心跳就認為鏈路異常，以及資料部是否算作心跳訊息（有的系統如果接收到資料包則會清除心跳計時器也就相當於系統中的資料包也算作心跳訊息）；這個需要兩端進行協商。比如GSM常用的短訊息中心和其他網路實體互連的SMPP協議，要求建立的就是長串連。

    很顯然，長串連要複雜些。對於服務端，要對串連上來的用戶端進行管理，還要檢查心跳包。很多商務服務器都用的長串連，而介面伺服器一般用短串連。

    其次，資料的同步和非同步請求。

    在用戶端請求到伺服器後，用戶端可以等待結果返回後，再處理其他的事情，也可以把請求放到隊列，繼續做其他的事情，有結果返回後，在做處理。這裡就是同步和非同步問題。

一般來說，同步等待也是有個逾時時間的，不能一直等待下去。而非同步處理的話，都會有個訊息佇列和請求隊列。當伺服器的訊息返回後，放到訊息佇列中，另外有一個線程來處理這個訊息佇列中的訊息，以及和請求隊列的資料做相應的處理。

    另外，就是阻塞和非阻塞。

    阻塞的結果就是這個線程將會等到這個結果返回，非阻塞就是只發送請求，不等待結果。

在很多時候，都會用非同步和非阻塞，這樣可以提高處理效能和資源的高效使用。

    最後，就是報文。資料報文是自己定義的。一般有2種：資料結構和xml資料。

這2種各有利弊。對於資料結構，程式內部處理比較容易，看在多版本相容方面沒那麼好，比如結構增加了欄位，低版本處理的時候，可能就有問題了。xml資料的相容性比較好，你可以只關心自己想要的欄位，而不用管那些不關心的欄位，所以對版本的相容也比較好。所以現在很多都採用xml資料。而對xml資料，現在用的比較多的就是json，並且C++、java、android等都支援。另外就是在傳輸的過程中加密。當然了，對於跨平台，還要考慮位元組序的問題。

 

最後，在總結一下：

1 串連方式：長串連和短串連。

2 資料的同步和非同步請求。

3 阻塞和非阻塞。

4 報文：協議，加密，位元組序。

 

轉載請註明原創連結：http://blog.csdn.net/wujunokay/article/details/38211079