軌跡系列7——Socket總結及實現基於TCP或UDP的809協議方法

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1.背景

在上一篇博客中我詳細介紹了809協議的內容。809協議規範了通訊的報文，通訊的規則等，可是並沒限制通訊使用的傳輸協議。這裏，我將分別介紹利用TCP和UDP傳輸協議來實現的809協議對接的方法。

2.TCP和UDP的介紹

TCP協議和UDP協議均是面向傳輸層的一種協議。而咱們常說的HTTP協議則是面向應用層的一種協議。

咱們常說的TCP/IP協議，則是一個協議簇，其中TCP、UDP協議均包含於這個協議簇。至於這個協議爲何叫TCP/IP，是由於TCP和IP協議是其中最重要的兩個協議。

2.1TCP協議介紹

TCP（Transmission Control Protocol，傳輸控制協議）是面向鏈接的協議，也就是說，在收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來，其中的過程很是複雜，只簡單的描述下這三次對話的簡單過程：主機A向主機B發出鏈接請求數據包：「我想給你發數據，能夠嗎？」，這是第一次對話；主機B向主機A發送贊成鏈接和要求同步（同步就是兩臺主機一個在發送，一個在接收，協調工做）的數據包：「能夠，你何時發？」，這是第二次對話；主機A再發出一個數據包確認主機B的要求同步：「我如今就發，你接着吧！」，這是第三次對話。三次「對話」的目的是使數據包的發送和接收同步，通過三次「對話」以後，主機A才向主機B正式發送數據。

總結上面這段話，主要包含了兩個關鍵詞：三次握手、可靠鏈接:     

　　   

如創建鏈接通常複雜，TCP協議斷開也相對複雜，須要進行四次揮手：

　　           

2.2UDP協議介紹

UDP（User Data Protocol），即用戶數據報協議，其包含的特徵主要以下:
a.UDP是一個非鏈接的協議，傳輸數據以前，源端和終端不創建鏈接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
b.因爲傳輸數據不創建鏈接，所以也就不須要維護鏈接狀態，包括收發狀態等，所以一臺服務機可同時向多個客戶機傳輸相同的消息。
c.UDP信息包的標題很短，只有8個字節，相對於TCP的20個字節信息包的額外開銷很小。
d.吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。
e.UDP使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態表（這裏面有許多參數）。
f.UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，所以，應用程序須要選擇合適的報文大小。
咱們常用「ping」命令來測試兩臺主機之間TCP/IP通訊是否正常，其實「ping」命令的原理就是向對方主機發送UDP數據包，而後對方主機確認收到數據包，若是數據包是否到達的消息及時反饋回來，那麼網絡就是通的。

總結UDP協議，其最大的特色是其無鏈接性，支持廣播通訊（支持一對多、多對多通訊）。廣播地址(Broadcast Address)是專門用於同時向網絡中全部工做站進行發送的一個地址。在使用TCP/IP 協議的網絡中，主機標識段host ID 爲全1 的IP 地址爲廣播地址，廣播的分組傳送給host ID段所涉及的全部計算機。例如，對於10.1.1.0 （255.255.255.0 ）網段，其廣播地址爲10.1.1.255 （255 即爲2 進制的11111111 ），當發出一個目的地址爲10.1.1.255 的分組（封包）時，它將被分發給該網段上的全部計算機。

      

2.3協議對比

TCP與UDP區別總結：
 a.TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接。
 b.TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付 。
 c.TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）。
d.每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊 。
e.TCP首部開銷20字節;UDP的首部開銷小，只有8個字節。
f.TCP的邏輯通訊信道是全雙工的可靠信道，UDP則是不可靠信道。

3.Socket編程

3.1基本概念

網絡上的兩個程序經過一個雙向的通訊鏈接實現數據的交換，這個鏈接的一端稱爲一個socket。

創建網絡通訊鏈接至少要一對端口號(socket)。socket本質是編程接口(API)，對TCP/IP的封裝，TCP/IP也要提供可供程序員作網絡開發所用的接口，這就是Socket編程接口；HTTP是轎車，提供了封裝或者顯示數據的具體形式;Socket是發動機，提供了網絡通訊的能力。

目前各大主流語言基本都支持socket編程。C#基於socket封裝了TCPClient以及UDPClient類，使得socket編程更加簡單。

在進行網絡編程時，咱們經常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：
同步：所謂同步，就是在發出一個功能調用時，在沒有獲得結果以前，該調用就不返回。也就是必須一件一件事作,等前一件作完了才能作下一件事。例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能幹任何事。

異步：異步的概念和同步相對。當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。 例如 ajax請求（異步）: 請求經過事件觸發->服務器處理（這是瀏覽器仍然能夠做其餘事情）->處理完畢。

阻塞：阻塞調用是指調用結果返回以前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在獲得結果以後纔會返回。有人也許會把阻塞調用和同步調用等同起來，實際上他是不一樣的。對於同步調用來講，不少時候當前線程仍是激活的，只是從邏輯上當前函數沒有返回而已。 例如，咱們在socket中調用recv函數，若是緩衝區中沒有數據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各類各樣的消息。

非阻塞:非阻塞和阻塞的概念相對應，指在不能馬上獲得結果以前，該函數不會阻塞當前線程，而會馬上返回。
對象的阻塞模式和阻塞函數調用:
對象是否處於阻塞模式和函數是否是阻塞調用有很強的相關性，可是並非一一對應的。阻塞對象上能夠有非阻塞的調用方式，咱們能夠經過必定的API去輪詢狀 態，在適當的時候調用阻塞函數，就能夠避免阻塞。而對於非阻塞對象，調用特殊的函數也能夠進入阻塞調用。函數select就是這樣的一個例子。

總結爲：

a.同步，就是我調用一個功能，該功能沒有結束前，我死等結果。

b.異步，就是我調用一個功能，不須要知道該功能結果，該功能有結果後通知我（回調通知）。

c.阻塞，就是調用我（函數），我（函數）沒有接收完數據或者沒有獲得結果以前，我不會返回。

d.非阻塞,就是調用我（函數），我（函數）當即返回，經過select通知調用者。

3.2同步和異步的實現

3.2.1阻塞通訊

　　

3.2.2非阻塞通訊

實現非阻塞通訊有兩種方式，一種是利用異步方式，另外一種使用多線程方式實現。二者的原理也是各不相同：

a.線程本質上是進程中一段併發運行的代碼，因此線程須要操做系統投入CPU資源來運行和調度；

b.異步本質上是計算機硬件功能，其操做無須消耗CPU時間的I/O操做；

編寫異步操做的複雜程度較高，程序主要使用回調方式進行處理，處理函數能夠沒必要使用共享變量；

 c.多線程是順序執行，編程簡單。可是線程的使用（濫用）會給系統帶來上下文切換的額外負擔。而且線程間的共享變量可能形成死鎖的出現。

 當須要執行I/O操做時，使用異步操做比使用線程+同步 I/O操做更合適。I/O操做不只包括了直接的文件、網絡的讀寫，還包括數據庫操做、Web Service、HttpRequest以及.net Remoting 等跨進程的調用。

       線程適用那種須要長時間CPU運算的場合，例如耗時較長的圖形處理和算法執行。

3.2.2.1多線程實現

　　  

3.2.2.2異步實現

　　 

4.809協議對接的實現

　　

4.1TCP協議對接（部分）

因爲TCP是長鏈接，因此這裏須要用非阻塞方式通訊，選擇多線程方法解決：

　　

4.2UDP協議對接（部分）

  UDP不需保持鏈接狀態，因此監聽端口完成操做便可，因爲接受消息後操做基本不耗時，因此沒有啓用多線程：

　

4.3對809協議解析的實現（部分）

　　

5.總結

在研究生期間時，研究過一段時間的socket通訊。當時對P2P模式，以及UDP打洞都還挺感興趣。之後有機會和你們在一塊兒探討。

 

   　　　　　　　　　　　　　　　　　　　　　　　     -----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                      　　　　      若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^