NewLife.Net——管道處理器解決粘包
Tcp網絡編程，必須要解決的一個問題就是粘包，盡管解決辦法有很多，這里講一個比較簡單的方法。
老規矩，先上代碼：https://github.com/NewLifeX/NewLife.Net
一、管道處理器
新建管道處理器項目HandlerTest，源碼復制自第一節課的EchoTest項目，增加一個管道處理器類
class EchoHandler : Handler { public override Object Read(IHandlerContext context, Object message) { var session = context.Session; var pk = message as Packet; session.WriteLog("收到：{0}", pk.ToStr()); // 把收到的數據發回去 session.Send(pk); return null; } }
EchoHandler繼承自處理器基類Handler，重載Read方法，當網絡層收到數據包時，會調用該方法。
這里我們實現了Echo功能，并打印日志。返回null告知不再執行管道上的后續處理器。
既然有了處理器，第一節課中的MyNetServer就用不上啦，在TestServer中改回來標準的NetServer
// 實例化服務端，指定端口，同時在Tcp/Udp/IPv4/IPv6上監聽 var svr = new NetServer { Port = 1234, Log = XTrace.Log }; svr.Add<EchoHandler>(); svr.Start();
這里的svr.Add<EchoHandler>()把上面的處理器給注冊進去，大意就是由這個處理器來負責處理收到的網絡數據包。
跑起來服務端和客戶端看看效果：
可以看到，收發正常！
二、粘包的產生
真實應用場景中，不可能允許我們間隔1秒才發出一個網絡包，直接就不該有等待。連續發送多個數據包，就很容易產生粘包。
static void TestClient() { var uri = new NetUri("tcp://127.0.0.1:1234"); //var uri = new NetUri("tcp://net.newlifex.com:1234"); var client = uri.CreateRemote(); client.Log = XTrace.Log; client.Received += (s, e) => { XTrace.WriteLine("收到：{0}", e.Packet.ToStr()); }; client.Open(); // 定時顯示性能數據 _timer = new TimerX(ShowStat, client, 100, 1000); // 循環發送數據 for (var i = 0; i < 5; i++) { //Thread.Sleep(1000); var str = "你好" + (i + 1); client.Send(str); } //client.Dispose(); }
這里注釋了睡眠語句，讓它緊密發出5個數據包。注釋后面的Dispose，讓其有機會收到響應包。
跑起來看到，粘包了！！！
客戶端發送5次，服務端作為一個包給接收了，整體處理，然后返回給客戶端。
粘包的解決辦法很多，一般是加頭部長度或者分隔符，也有取巧的辦法直接設置NoDelay。
從使用上來講，相對可靠的做法是加頭部長度。因為除了多個包粘在一起，還可能出現一個包被拆成兩半，分別在前后兩個包里面。
三、普通粘包解法
我們加上頭部長度來解決解包問題。
修改一下服務端，增加一個處理器
static void TestServer() { // 實例化服務端，指定端口，同時在Tcp/Udp/IPv4/IPv6上監聽 var svr = new NetServer { Port = 1234, Log = XTrace.Log }; //svr.Add(new LengthFieldCodec { Size = 4 }); svr.Add<StandardCodec>(); svr.Add<EchoHandler>(); // 打開原始數據日志 var ns = svr.Server; ns.LogSend = true; ns.LogReceive = true; svr.Start(); _server = svr; // 定時顯示性能數據 _timer = new TimerX(ShowStat, svr, 100, 1000); }
StandardCodec處理器是新生命團隊標準封包。https://github.com/NewLifeX/X/tree/master/NewLife.Core/Net
其固定4字節作為頭部，其中后面兩個字節標識負載長度。
也可以使用LengthFieldCodec編碼器（如上注釋部分），并制定頭部加4字節作為長度。
編碼器順序非常重要，網絡層收到數據包以后，會從前向后走過每一個處理器；SendAsync/SendMessage發送消息時，會從后向前走過每一個過濾器，逆序。
客戶端也要增加相應過濾器
static void TestClient() { var uri = new NetUri("tcp://127.0.0.1:1234"); //var uri = new NetUri("tcp://net.newlifex.com:1234"); var client = uri.CreateRemote(); client.Log = XTrace.Log; client.Received += (s, e) => { var pk = e.Message as Packet; XTrace.WriteLine("收到：{0}", pk.ToStr()); }; //client.Add(new LengthFieldCodec { Size = 4 }); client.Add<StandardCodec>(); // 打開原始數據日志 var ns = client; ns.LogSend = true; ns.LogReceive = true; client.Open(); // 定時顯示性能數據 _timer = new TimerX(ShowStat, client, 100, 1000); // 循環發送數據 for (var i = 0; i < 5; i++) { var str = "你好" + (i + 1); var pk = new Packet(str.GetBytes()); client.SendAsync(pk); } }
發送函數改為SendAsync，原來的Send(Packet pk)會繞過管道處理器。
客戶端接收時，e.Message表示經過處理器處理得到的消息，e.Packet表示原始數據包。
同時，通過LogSend/LogReceive打開收發數據日志。
上圖效果，客戶端發出第5個包，頭部多了4個字節，其中07-00表示后續負載數據長度為7字節（NewLife）。
服務端先收到第一個包11字節，然后收到44字節，這是4個包粘在一起。
然后StandardCodec編碼器成功將其拆分成為4個，并依次通過EchoHandler。
到了客戶端這邊，也是后面4個粘在一起，并且也得到了正確拆分。
如果一個大包被拆分為幾個，StandardCodec也能緩沖合并，半包超過500~5000ms仍未能組合完整時將拋棄。
四、總結
借助管道處理器架構，我們輕易解決了粘包問題！
顯然，管道架構并非單純為了粘包問題而設計，它有著非常重要的意義，加解密、壓縮、各種協議處理，等等。
管道架構的設計，參考了Netty，因此大部分Netty的編解碼器都可以在此使用。
浙公網安備 33010602011771號