C#網絡程式設計入門之TCP

C#網絡程式設計入門之TCP

目錄：

C#網絡程式設計入門系列包括三篇文章：

（一）C#網絡程式設計入門之UDP

（二）C#網絡程式設計入門之TCP

（三）C#網絡程式設計入門之HTTP

一、概述

UDP和TCP是網絡通訊常用的兩個傳輸協定，C#一般可以通過Socket來實作UDP和TCP通訊，由于.NET架構通過UdpClient、TcpListener 、TcpClient這幾個類對Socket進行了封裝，使其使用更加友善， 本文就通過這幾個封裝過的類講解一下相關應用。

二、基本應用：連接配接、發送、接收

服務端建立偵聽并等待連接配接：

TcpListener tcpListener = new TcpListener(IPAddress.Parse("127.0.0.1"), 9000);

tcpListener.Start();

if (tcpListener.Pending())

{

TcpClient client = tcpListener.AcceptTcpClient();
      Console.WriteLine("Connected");              

}

服務端是通過AcceptTcpClient方法獲得TcpClient對象，而用戶端是直接建立TcpClient對象。

TcpClient tcpClient = new TcpClient();

tcpClient.Connect("127.0.0.1", 9000);

發送資料TcpClient對象建立後，發送接收都通過TcpClient對象完成。

發送資料：

TcpClient tcpClient = new TcpClient();
            tcpClient.Connect("127.0.0.1", 9000);
            NetworkStream netStream = tcpClient.GetStream();

            int Len = 1024;
            byte[] datas = new byte[Len];

            netStream.Write(datas, 0, Len);               

            netStream.Close();
            tcpClient.Close();
           

接收資料：

TcpClient client = tcpListener.AcceptTcpClient();

Console.WriteLine("Connected");

NetworkStream stream = client.GetStream();

var remote = client.Client.RemoteEndPoint;

byte[] data = new byte[1024];

while (true)

{

if (stream.DataAvailable)
     {
            int len = stream.Read(data, 0, 1024);
            Console.WriteLine($"From:{remote}:Received ({len})");
      }
    Thread.Sleep(1);           

三、 粘包問題

和UDP不太一樣，TCP連接配接不會丢包，但存在粘包問題。（嚴格來說粘包這個說法是不嚴謹的，因為TCP通訊是基于流的，沒有包的概念，包隻是使用者自己的了解。） 下面分析一下粘包産生的原因及解決辦法。

TCP資料通訊是基于流來實作的，類似一個隊列，當有資料發送過來時，作業系統就會把發送過來的資料依次放到這個隊列中，對發送者而言，資料是一片一片發送的，是以自然會認為存在資料包的概念，但對于接收者而言，如果沒有及時去取這些資料，這些資料依次存放在隊列中，彼此之間并無明顯間隔，自然就粘包了。

還有一種情況粘包是發送端造成的，有時我們調用發送代碼時，作業系統可能并不會立即發送，而是放到緩存區，當緩存區達到一定數量時才真正發送。

要解決粘包問題，大緻有以下幾個方案。

1、 約定資料長度，發送端的資料都是指定長度，比如1024；接收端取資料時也取同樣長度，不夠長度就等待，保證取到的資料和發送端一緻；

2、 接收端取資料的頻率遠大于發送端，比如發送端每1秒發送一段資料，接收端每0.1秒去取一次資料，這樣基本可以保證資料不會粘起來；

以上兩個方案都要求發送端需要立即發送，不可緩存資料。而且這兩種方案都有缺陷：首先，第一種方案：如果要包大小一緻的話，如果約定的包比較大，肯定有較多資料備援，浪費網絡資源，如果包較小，連接配接就比較頻繁，效率不高。

其次，第二種方案：這個方案隻能在理想環境下可以實作，當服務端遭遇一段時間的計算壓力時可能會出現意外，不能完全保證。

比較完善的解決方案就是對接收到的資料進行預處理：首先通過定義特殊的字元組合作為標頭和包尾，如果傳輸ASCII字元，可以用0x02表示開始（STX），用0x03表示結束（ETX），比如：STX ‘H’ ‘e’ ‘l’ ‘l’ ‘o’ ETX (二進制資料： 02 48 65 6C 6C 6F 03)。如果資料較長可以在標頭留出固定位置存放包長度， 如：

02 00 05 48 65 6C 6C 6F 03

其中02 05 就表示正文長度為5個位元組，可以進行校驗。

雖然第三種方案比較嚴謹，但相對複雜，在傳輸比較可靠、應用比較簡單的場景下，也可以采用前面兩種解決方案。

四、 一個完整的例程

服務端：

 View Code

用戶端：

原文位址

https://www.cnblogs.com/seabluescn/p/12972632.html