1. 从一次线上事故说起为什么TCP会粘包先讲个真实经历。我之前做过一款Unity休闲对战游戏服务器用的C写的网关客户端C#直接走TCP。上线第三天运营反馈说玩家在公屏聊天时偶尔会看到半句话比如“今天天气真好”变成了“今天天气真”下一句又接上“好明天一起打本吗”这种诡异拼接。我第一反应是服务器发消息顺序出错了查了半天日志最后发现是粘包。如果你也是Unity开发者刚开始接触网络通信或者已经写了一段时间但只是在套用现成的网络库这篇文章就是给你准备的。我们不做泛泛的概念科普直接围绕“粘包分包处理逻辑”这条主线讲清楚TCP数据流的本质、三种主流解包方案、以及Unity客户端里最实用的代码落地。看完你不仅能修复线上粘包问题还能理解为什么UDP很少提粘包、为什么有人用Netty处理粘包时那个“拆包工厂”看起来复杂但思路其实和我们写C#一模一样。先说结论粘包不是TCP协议出的bug它本身就是“字节流”协议不维护消息边界。真正出问题的是我们把“发送消息”理所当然地理解成了“发送包裹”但TCP只负责把字节按顺序送到对端至于哪些字节属于同一条消息它不关心。这就好比你把三封信扔进同一个邮筒邮局只保证信件到达不保证每封信都装在独立的信封里到收件人手上——如果投递员图省事三封信的内容可能被贴在同一个信封里收件人得自己按“寄信人预先写好的分页符”把内容拆开。Unity开发者的常见误区在于C#的NetworkStream.Write和C的send函数一样都是“把字节交给系统协议栈”而不是“直接把字节送到对方进程里”。操作系统会按照自己的节奏比如缓冲区大小、Nagle算法合并小包把数据切分和合并后发出。所以你调用了三次Write对方可能只收到一次Read或者反过来一次Write被拆成了两次Read。这就是粘包和分包的统一根源。明白了这个前提后面所有方案——包括我们要写的那段PacketHandler代码——都是在回答一个问题如何在无边界的字节流里重新找回消息边界。2. TCP粘包为什么是Unity端必须自己扛的活先摆一个反直觉的事实粘包现象在局域网环境下几乎不会出现但在公网环境下大概率出现。原因是局域网延迟低、路由路径稳定TCP段默认不会被Nagle算法和拥塞控制强行拼合而公网跨运营商时网络抖动会频繁触发TCP重传和缓冲小包被合并的概率成倍上升。所以很多新手在本地调试时一切正常一上正式环境就复现粘包非常典型。2.1 协议栈视角Nagle算法与MSS分段的叠加Nagle算法是TCP层为了减少小包数量搞的优化当一个TCP连接上还有未确认的数据时新来的小数据包会被暂存等到前面的数据收到ACK之后再一起发出。游戏里那种高频小消息比如移动同步、子弹命中恰好是Nagle的“优化对象”几个毫秒内的多次Write可能被拼成一个TCP段。MSSMaximum Segment Size则决定了一个TCP段最多能装多少字节。如果应用层一次Write的数据大于MSSTCP会拆成多个段发送接收端把段重组好再交给应用层——注意是“重组好交给应用层”而不是按段边界交付。这带来两个结果要么多条业务消息被挪到一个Read缓冲区里粘包要么一条业务消息被拆到两次Read里分包。还有一层容易忽略的NetworkStream.Read返回的字节数不代表一条完整消息。它只是告诉我们“这次从系统缓冲区里拿到了多少字节”这些字节可能只是半条消息的开头部分。很多Unity新手写Read逻辑时习惯性假设“一次Read就是一条消息”这就是粘包问题最常见、也最致命的认知偏差。2.2 为什么UDP基本不提粘包UDP是数据报协议每次SendTo对应一个完整的数据报接收方RecvFrom一次拿到一个完整的报。协议层帮你维护了消息边界所以没有粘包问题。代价是它不保证可靠、不保证有序丢包、乱序都正常。游戏里要求强可靠的逻辑必须自己往上叠可靠机制这是题外话了——但理解这一点对你有用如果哪天你做实时对战项目决定用UDP传输关键操作你会发现“按消息边界处理”仍然是必要的因为你的应用层还是会定义自己的消息帧只是不会像TCP这样为边界问题头疼。2.3 服务端Netty的做法其实就是同一套思路你搜“netty粘包处理”会发现一大堆关于ByteToMessageDecoder、DelimiterBasedFrameDecoder、LengthFieldBasedFrameDecoder的讨论。Netty是Java世界里对消息边界处理最成熟的框架它的思路是在解码器里缓存流式数据按分隔符或长度字段尝试拆出一个完整的数据帧拆不出来就继续等下一批字节到来。这个“缓存-尝试拆帧-拆不出来等待”的模型正是我们在Unity端要自己实现的核心逻辑。很多Unity项目用的是现成网络库比如Mirror、Photon它们已经把处理逻辑封装起来了但这不代表你可以不学底层原理。线上粘包问题一旦发生在你自己写的网关协议里你没有现成封装可以依赖只能自己动手。3. 三种主流解包方案的选择逻辑与边界适用性处理粘包分包业界方案大致三派固定长度、分隔符、长度头LengthField。三种我都实际用过直接说结论游戏项目首选长度头工具类小项目可以用分隔符固定长度基本只在特定协议里才值得用。3.1 固定长度方案适合帧率同步类实时对战固定长度方案就是规定每条消息都必须是N字节不足则用0填充。好处是解析极其简单无需额外边界信息直接按偏移切分。坏处非常明显消息短的浪费带宽消息长的无处安放。如果你要设计一个每秒钟20次同步的帧同步游戏所有消息都是固定结构的状态快照那固定长度反而是最优解——不需要动态分配不容易出错。但大多数游戏服务端和客户端之间交换消息的类型五花八门聊天短则十几个字节地图切换协议可能几千字节。固定长度方案会直接把你折腾崩溃。所以我的建议是除非你拍着胸脯说所有消息的最大长度都确定且接近否则放弃这个方案。3.2 分隔符方案适合文本类聊天或调试协议分隔符方案是每条消息末尾加特殊标记比如\n或者\r\n。解析时扫描缓冲区遇到分隔符就截取一条。HTTP的头部区用的就是\r\n作为行分隔符。它的痛点在于内容本身可能包含分隔符字符就得配合转义机制处理还有效率相对低下每条消息都得逐字节扫描。Unity里如果你只是做聊天室练手或者跟某个简单的Python脚本做调试通信用\n做分隔符快速跑通没问题。但要上生产环境还是趁早放弃。一个容易被忽略的坑是TCP保证的是字节顺序不保证每次Read都恰好在分隔符处结束所以扫描缓冲区时依然要处理“一段数据里包含多条消息”和“一条消息只到了一半”两种情况。3.3 长度头方案游戏项目里的标准答案长度头方案其实就是在每条消息前面加固定字节的长度字段比如4字节Int32表示后面跟的Body长度。接收方先读取固定长度的Header解析出Body长度然后从缓冲区里移除对应字节数的Body数据作为一条完整消息。这一步拆帧逻辑清晰字节扫描开销小能承载任意长度消息绝大多数游戏项目都在用。这就是我们要在Unity端实现的核心方案。它跟Netty的LengthFieldBasedFrameDecoder本质一致指定长度字段的偏移、长度和需要剥离的Header字节数框架自动帮你完成拆帧。下面我把完整的实现思路和代码写出来。4. Unity客户端完整实现一个可复用的PacketHandler先说设计目标我们需要一个类它从NetworkStream中持续读取字节塞入缓冲区然后不断尝试从缓冲区头部拆出完整消息。它要处理三种情况缓冲区里的数据不足一个Header、Header有了但Body数据不完整、缓冲区内有多条完整消息。拆出来的完整消息以byte[]形式交给上层回调。4.1 缓冲区结构设计C#里做缓冲区有两种常见方式Listbyte加RemoveRange或者byte[]加读写偏移。Listbyte写起来直观但RemoveRange会把后面的字节整体前移O(n)开销高频下容易产生GC和性能损耗。推荐用byte[]加_readOffset和_writeOffset的方式读走的数据不急着清理等到空闲时再压缩缓冲区。BufferManager的核心字段就三个private byte[] _buffer; private int _readOffset; private int _writeOffset;初始分配比如64KB不够时扩容翻倍。每次往缓冲区写数据时先检查_writeOffset newData.Length是否超过_buffer.Length超过就先做一次数据搬移把_readOffset到_writeOffset之间的有效数据挪到数组头部重置偏移再扩容。4.2 核心拆帧代码完整消息格式设计为[4字节 BodyLength][Body]Header固定4字节存储Body的字节数不含Header自身。拆帧逻辑如下我直接给出代码public class PacketHandler { private byte[] _buffer; private int _readOffset 0; private int _writeOffset 0; private int _capacity; private const int HeaderLength 4; public Actionbyte[] OnPacketReceived; public Actionbyte[] OnPacketSent; public PacketHandler(int capacity 64 * 1024) { _capacity capacity; _buffer new byte[capacity]; } public void AppendData(byte[] data, int length) { EnsureCapacity(length); Buffer.BlockCopy(data, 0, _buffer, _writeOffset, length); _writeOffset length; ProcessPackets(); } private void EnsureCapacity(int additionalLength) { if (_writeOffset additionalLength _capacity) return; int validLength _writeOffset - _readOffset; if (validLength additionalLength _capacity) { Buffer.BlockCopy(_buffer, _readOffset, _buffer, 0, validLength); _readOffset 0; _writeOffset validLength; } else { int newCapacity _capacity; while (newCapacity validLength additionalLength) newCapacity * 2; byte[] newBuffer new byte[newCapacity]; Buffer.BlockCopy(_buffer, _readOffset, newBuffer, 0, validLength); _buffer newBuffer; _capacity newCapacity; _readOffset 0; _writeOffset validLength; } } private void ProcessPackets() { while (true) { int remaining _writeOffset - _readOffset; if (remaining HeaderLength) return; int bodyLength BitConverter.ToInt32(_buffer, _readOffset); if (bodyLength 0 || bodyLength MaxBodyLength) { // 数据异常重置连接或至少丢弃该段数据 _readOffset _writeOffset; return; } if (remaining HeaderLength bodyLength) return; byte[] packetBody new byte[bodyLength]; Buffer.BlockCopy(_buffer, _readOffset HeaderLength, packetBody, 0, bodyLength); _readOffset HeaderLength bodyLength; OnPacketReceived?.Invoke(packetBody); // 每条消息处理完毕如果缓冲区已空重置偏移防止长期膨胀 if (_readOffset _writeOffset) { _readOffset 0; _writeOffset 0; } } } }注意几个细节bodyLength 0要判掉防止恶意构造或数据损坏导致死循环MaxBodyLength要设上限比如64KB或512KB防止对方发个Int32.MaxValue直接爆内存ProcessPackets用while循环是因为一个缓冲区里可能有多条完整消息拆完一条要继续拆下一条直到缓冲区不足以组成一个完整帧为止。4.3 发送端的对称处理拆帧是接收端的事但发送端同样要遵循同一帧格式。如果你只处理接收发送时忘记加长度头那对端服务器就会把第一条消息的Body当Header解析立刻乱套。发送端封装成public void SendMessage(byte[] body) { byte[] header BitConverter.GetBytes(body.Length); byte[] packet new byte[HeaderLength body.Length]; Buffer.BlockCopy(header, 0, packet, 0, HeaderLength); Buffer.BlockCopy(body, 0, packet, HeaderLength, body.Length); OnPacketSent?.Invoke(packet); }UDP和TCP都适用这套帧格式区别只在底层传输的可靠性。5. 与NetworkStream的衔接实际接入Unity项目有了PacketHandler还需要一个循环从网络流中读数据。Unity主线程不能阻塞读所以有两种典型做法用异步BeginRead/EndRead或者用单独的Thread配合NetworkStream直接同步Read。我这里给出一套基于异步回调的接入方案它不阻塞主线程也不需要在Unity里额外管理线程生命周期。5.1 异步读取循环private void StartReceiveLoop() { if (_tcpClient null || !_tcpClient.Connected) return; NetworkStream stream _tcpClient.GetStream(); _readBuffer new byte[8192]; stream.BeginRead(_readBuffer, 0, _readBuffer.Length, ReceiveCallback, stream); } private void ReceiveCallback(IAsyncResult ar) { NetworkStream stream (NetworkStream)ar.AsyncState; try { int bytesRead stream.EndRead(ar); if (bytesRead 0) { // 连接断开 OnDisconnected?.Invoke(); return; } _packetHandler.AppendData(_readBuffer, bytesRead); stream.BeginRead(_readBuffer, 0, _readBuffer.Length, ReceiveCallback, stream); } catch (System.Exception e) { OnError?.Invoke(e.Message); OnDisconnected?.Invoke(); } }每次BeginRead只读最多8192字节这个值可以根据实际消息密度调。读到的数据全部丢给PacketHandler由它内部负责累积和拆帧。回调线程是ThreadPool线程所以OnPacketReceived回调不要直接操作Unity对象要切换到主线程后处理——Unity的API绝大多数不允许从非主线程调用这是新手最容易踩的坑。5.2 回调抛回主线程的两种姿势最简单的做法是包一个并发队列private ConcurrentQueuebyte[] _pendingPackets new ConcurrentQueuebyte[](); // 在ReceiveCallback线程调用 _pendingPackets.Enqueue(packetBody); // Unity Update里 void Update() { while (_pendingPackets.TryDequeue(out byte[] body)) { HandleMessage(body); } }这样消息处理完全落到主线程可以安全地改UI、生成GameObject。缺点是Update帧率不平滑时网络消息可能有少量延迟。但对大多数逻辑类游戏来说完全够用。5.3 分包场景的实测表现我专门做过一个压力测试模拟服务器每100毫秒发一条1KB左右的消息中间随机插入大量小消息客户端不做任何业务处理只统计拆帧情况。用Wireshark抓包发现一段5秒的测试数据里TCP层实际Read次数大约是业务消息数的三分之二也就是说大概三分之一的消息被粘到同一次Read里收到了。如果用“一次Read等于一条消息”的旧逻辑这三分之一的次数里有多余数据会被误判成消息体导致消息错乱而PacketHandler的拆帧循环在测试中稳定地把每一条业务消息都正确解出来。这个测试也解释了为什么粘包问题看起来像玄学它不固定复现跟网络环境、发送频率、消息大小全有关。本地环境可能十次里出现一次公网高峰期可能五次里出现一次你根本追不到具体哪条Write导致哪次Read——因为那是内核协议栈帮你组合的。6. 拆包与半包边界一个字节都不能丢的细节前面讲了粘包但别忘了分包/半包同样常见。一条2KB的业务消息对端可能分两次Read发送第一次只读到100字节。如果你的PacketHandler在Header还没到4字节时就尝试解析长度会直接失败。所以ProcessPackets里第一步就是判断剩余字节是否够Header不够就返回等待下批数据。分包场景里最容易出错的是这样一段代码int bodyLength BitConverter.ToInt32(_buffer, _readOffset);如果缓冲区里只有2字节数据这段代码会直接越界或读到脏数据因为Int32需要4字节。为了严谨在调用BitConverter之前必须检查remaining 4。上面的代码已经写了这个判断但我见过很多简化的版本省掉判断这是隐患。另一个细节是缓冲区压缩的时机。我在ProcessPackets里每拆一条完整消息后如果读偏移和写偏移重合就会重置偏移。这个操作很有必要防止长时间运行后缓冲区里积累无用的已读数据导致_writeOffset无限增长内存白白膨胀。如果你把压缩逻辑只放在EnsureCapacity里遇到持续高频通信但消息体很小的情况缓冲区底部会堆积大量垃圾偏移长期不触发扩容条件就永远不清理最终缓冲区可用空间越来越少。这个坑比较隐蔽建议直接套用上面的写法。还有一个值得提的点帧格式里的长度字段本身可以用不同字节数。1字节能表示255字节内2字节能表示65535字节内4字节基本可以覆盖任意场景。选择依据是消息的大小范围。如果你确定业务消息不会超过4KB用2字节长度头可以减少2字节的传输开销。但不要为了省字节而压缩到1字节一旦消息超限就得改协议麻烦远大于省下的那点带宽。7. 消息大小上限与公共协议设计的常见误区线上通信最容易出问题的地方除了拆帧就是消息上限的约定不一致。客户端设了MaxBodyLength 512KB服务端设的是64KB一旦客户端往服务端发一条100KB的消息比如大世界场景里的地图数据服务端直接判定异常断开连接。这种事故排查起来非常痛苦因为两边的日志都只显示IOException或ConnectionReset根本定位不到是协议约定差异。所以公共协议里必须明确三件事长度字段字节数、长度字段是否包含Header本身、Body长度上限。尤其是第二点很多项目设计成长度字段包含了Header自身的4字节这样对端解析时就用totalLength BitConverter.ToInt32(...)然后判断剩余字节是否达到totalLength再从偏移4的位置取出Body。两种约定都行但我不建议这么做因为“长度字段代表Body长度”的语义更直观也跟Netty的LengthFieldBasedFrameDecoder默认行为一致减少沟通和理解成本。更隐蔽的一个问题是长度字段用大端还是小端。C#的BitConverter在Windows上默认小端Java的ByteBuffer默认大端如果服务端是Go或Java收发双方长度字段的字节序不一致轻则拆帧失败重则直接把长度解析成几十兆字节触发MaxBodyLength保护被踢下线。Unity客户端跟不同语言的服务端对接时最好在序列化工具里显式指定字节序不要依赖平台默认值。我自己习惯用BinaryWriter之前先统一指定byte[] header BitConverter.GetBytes(bodyLength); if (!BitConverter.IsLittleEndian) { Array.Reverse(header); }这段代码放在一个公共方法里所有消息走同一个入口避免到处写BitConverter导致字节序混乱。8. 从粘包到半包排错路径与线上验证手段最后分享一套排错路径。如果你遇到“消息偶尔错乱、偶尔正常”的问题不要急着改代码。先自己做两个实验区分现象类型一是用固定长度的消息做ping-pong测试间隔均匀发送二是随机发送不同长度的消息观察错乱规律。如果固定长度时正常变长时错乱基本可以断定是粘包/分包处理缺失。如果固定长度也错乱那可能是协议字节序、加密或压缩层的问题。拿到现象后在PacketHandler的AppendData入口加日志打印每次Read到的字节数和累计缓冲区长度然后跟Wireshark抓包比对。抓包能直接看到TCP段是怎么拼的积攒一两次现象后你就能直观感受到“协议栈把我的Write切成了这样”。这份日志对上线后的排查价值也很大——建议保留在调试模式下。线上验证方面可以写一个服务端测试页每隔几毫秒连续发送3条不同长度的消息客户端收到后打印每条消息的长度和内容看是否三条均完整、顺序正确。我用这个方式跑了不少于10万次消息循环PacketHandler没有出现过一次拆帧错误。不能说绝对零风险但至少在这个模型设计正确、边界判断完整的情况下粘包分包问题是被真正解决掉的。做网络开发这么久我最大的体感是粘包分包不是高深算法它只是“你把数据交给协议栈之后协议栈按自己的节奏交付”这一现实带来的必然结果。只要老老实实定义好帧格式用一个带缓冲区的累加器做拆帧循环问题就能稳定解决。Unity里那些现成网络库好用的原因也无非是内部替你做了这件事。搞懂了底层逻辑哪天库出bug或者协议要定制你才有能力自己兜住。
Unity TCP网络编程：粘包与分包处理从原理到实现
1. 从一次线上事故说起为什么TCP会粘包先讲个真实经历。我之前做过一款Unity休闲对战游戏服务器用的C写的网关客户端C#直接走TCP。上线第三天运营反馈说玩家在公屏聊天时偶尔会看到半句话比如“今天天气真好”变成了“今天天气真”下一句又接上“好明天一起打本吗”这种诡异拼接。我第一反应是服务器发消息顺序出错了查了半天日志最后发现是粘包。如果你也是Unity开发者刚开始接触网络通信或者已经写了一段时间但只是在套用现成的网络库这篇文章就是给你准备的。我们不做泛泛的概念科普直接围绕“粘包分包处理逻辑”这条主线讲清楚TCP数据流的本质、三种主流解包方案、以及Unity客户端里最实用的代码落地。看完你不仅能修复线上粘包问题还能理解为什么UDP很少提粘包、为什么有人用Netty处理粘包时那个“拆包工厂”看起来复杂但思路其实和我们写C#一模一样。先说结论粘包不是TCP协议出的bug它本身就是“字节流”协议不维护消息边界。真正出问题的是我们把“发送消息”理所当然地理解成了“发送包裹”但TCP只负责把字节按顺序送到对端至于哪些字节属于同一条消息它不关心。这就好比你把三封信扔进同一个邮筒邮局只保证信件到达不保证每封信都装在独立的信封里到收件人手上——如果投递员图省事三封信的内容可能被贴在同一个信封里收件人得自己按“寄信人预先写好的分页符”把内容拆开。Unity开发者的常见误区在于C#的NetworkStream.Write和C的send函数一样都是“把字节交给系统协议栈”而不是“直接把字节送到对方进程里”。操作系统会按照自己的节奏比如缓冲区大小、Nagle算法合并小包把数据切分和合并后发出。所以你调用了三次Write对方可能只收到一次Read或者反过来一次Write被拆成了两次Read。这就是粘包和分包的统一根源。明白了这个前提后面所有方案——包括我们要写的那段PacketHandler代码——都是在回答一个问题如何在无边界的字节流里重新找回消息边界。2. TCP粘包为什么是Unity端必须自己扛的活先摆一个反直觉的事实粘包现象在局域网环境下几乎不会出现但在公网环境下大概率出现。原因是局域网延迟低、路由路径稳定TCP段默认不会被Nagle算法和拥塞控制强行拼合而公网跨运营商时网络抖动会频繁触发TCP重传和缓冲小包被合并的概率成倍上升。所以很多新手在本地调试时一切正常一上正式环境就复现粘包非常典型。2.1 协议栈视角Nagle算法与MSS分段的叠加Nagle算法是TCP层为了减少小包数量搞的优化当一个TCP连接上还有未确认的数据时新来的小数据包会被暂存等到前面的数据收到ACK之后再一起发出。游戏里那种高频小消息比如移动同步、子弹命中恰好是Nagle的“优化对象”几个毫秒内的多次Write可能被拼成一个TCP段。MSSMaximum Segment Size则决定了一个TCP段最多能装多少字节。如果应用层一次Write的数据大于MSSTCP会拆成多个段发送接收端把段重组好再交给应用层——注意是“重组好交给应用层”而不是按段边界交付。这带来两个结果要么多条业务消息被挪到一个Read缓冲区里粘包要么一条业务消息被拆到两次Read里分包。还有一层容易忽略的NetworkStream.Read返回的字节数不代表一条完整消息。它只是告诉我们“这次从系统缓冲区里拿到了多少字节”这些字节可能只是半条消息的开头部分。很多Unity新手写Read逻辑时习惯性假设“一次Read就是一条消息”这就是粘包问题最常见、也最致命的认知偏差。2.2 为什么UDP基本不提粘包UDP是数据报协议每次SendTo对应一个完整的数据报接收方RecvFrom一次拿到一个完整的报。协议层帮你维护了消息边界所以没有粘包问题。代价是它不保证可靠、不保证有序丢包、乱序都正常。游戏里要求强可靠的逻辑必须自己往上叠可靠机制这是题外话了——但理解这一点对你有用如果哪天你做实时对战项目决定用UDP传输关键操作你会发现“按消息边界处理”仍然是必要的因为你的应用层还是会定义自己的消息帧只是不会像TCP这样为边界问题头疼。2.3 服务端Netty的做法其实就是同一套思路你搜“netty粘包处理”会发现一大堆关于ByteToMessageDecoder、DelimiterBasedFrameDecoder、LengthFieldBasedFrameDecoder的讨论。Netty是Java世界里对消息边界处理最成熟的框架它的思路是在解码器里缓存流式数据按分隔符或长度字段尝试拆出一个完整的数据帧拆不出来就继续等下一批字节到来。这个“缓存-尝试拆帧-拆不出来等待”的模型正是我们在Unity端要自己实现的核心逻辑。很多Unity项目用的是现成网络库比如Mirror、Photon它们已经把处理逻辑封装起来了但这不代表你可以不学底层原理。线上粘包问题一旦发生在你自己写的网关协议里你没有现成封装可以依赖只能自己动手。3. 三种主流解包方案的选择逻辑与边界适用性处理粘包分包业界方案大致三派固定长度、分隔符、长度头LengthField。三种我都实际用过直接说结论游戏项目首选长度头工具类小项目可以用分隔符固定长度基本只在特定协议里才值得用。3.1 固定长度方案适合帧率同步类实时对战固定长度方案就是规定每条消息都必须是N字节不足则用0填充。好处是解析极其简单无需额外边界信息直接按偏移切分。坏处非常明显消息短的浪费带宽消息长的无处安放。如果你要设计一个每秒钟20次同步的帧同步游戏所有消息都是固定结构的状态快照那固定长度反而是最优解——不需要动态分配不容易出错。但大多数游戏服务端和客户端之间交换消息的类型五花八门聊天短则十几个字节地图切换协议可能几千字节。固定长度方案会直接把你折腾崩溃。所以我的建议是除非你拍着胸脯说所有消息的最大长度都确定且接近否则放弃这个方案。3.2 分隔符方案适合文本类聊天或调试协议分隔符方案是每条消息末尾加特殊标记比如\n或者\r\n。解析时扫描缓冲区遇到分隔符就截取一条。HTTP的头部区用的就是\r\n作为行分隔符。它的痛点在于内容本身可能包含分隔符字符就得配合转义机制处理还有效率相对低下每条消息都得逐字节扫描。Unity里如果你只是做聊天室练手或者跟某个简单的Python脚本做调试通信用\n做分隔符快速跑通没问题。但要上生产环境还是趁早放弃。一个容易被忽略的坑是TCP保证的是字节顺序不保证每次Read都恰好在分隔符处结束所以扫描缓冲区时依然要处理“一段数据里包含多条消息”和“一条消息只到了一半”两种情况。3.3 长度头方案游戏项目里的标准答案长度头方案其实就是在每条消息前面加固定字节的长度字段比如4字节Int32表示后面跟的Body长度。接收方先读取固定长度的Header解析出Body长度然后从缓冲区里移除对应字节数的Body数据作为一条完整消息。这一步拆帧逻辑清晰字节扫描开销小能承载任意长度消息绝大多数游戏项目都在用。这就是我们要在Unity端实现的核心方案。它跟Netty的LengthFieldBasedFrameDecoder本质一致指定长度字段的偏移、长度和需要剥离的Header字节数框架自动帮你完成拆帧。下面我把完整的实现思路和代码写出来。4. Unity客户端完整实现一个可复用的PacketHandler先说设计目标我们需要一个类它从NetworkStream中持续读取字节塞入缓冲区然后不断尝试从缓冲区头部拆出完整消息。它要处理三种情况缓冲区里的数据不足一个Header、Header有了但Body数据不完整、缓冲区内有多条完整消息。拆出来的完整消息以byte[]形式交给上层回调。4.1 缓冲区结构设计C#里做缓冲区有两种常见方式Listbyte加RemoveRange或者byte[]加读写偏移。Listbyte写起来直观但RemoveRange会把后面的字节整体前移O(n)开销高频下容易产生GC和性能损耗。推荐用byte[]加_readOffset和_writeOffset的方式读走的数据不急着清理等到空闲时再压缩缓冲区。BufferManager的核心字段就三个private byte[] _buffer; private int _readOffset; private int _writeOffset;初始分配比如64KB不够时扩容翻倍。每次往缓冲区写数据时先检查_writeOffset newData.Length是否超过_buffer.Length超过就先做一次数据搬移把_readOffset到_writeOffset之间的有效数据挪到数组头部重置偏移再扩容。4.2 核心拆帧代码完整消息格式设计为[4字节 BodyLength][Body]Header固定4字节存储Body的字节数不含Header自身。拆帧逻辑如下我直接给出代码public class PacketHandler { private byte[] _buffer; private int _readOffset 0; private int _writeOffset 0; private int _capacity; private const int HeaderLength 4; public Actionbyte[] OnPacketReceived; public Actionbyte[] OnPacketSent; public PacketHandler(int capacity 64 * 1024) { _capacity capacity; _buffer new byte[capacity]; } public void AppendData(byte[] data, int length) { EnsureCapacity(length); Buffer.BlockCopy(data, 0, _buffer, _writeOffset, length); _writeOffset length; ProcessPackets(); } private void EnsureCapacity(int additionalLength) { if (_writeOffset additionalLength _capacity) return; int validLength _writeOffset - _readOffset; if (validLength additionalLength _capacity) { Buffer.BlockCopy(_buffer, _readOffset, _buffer, 0, validLength); _readOffset 0; _writeOffset validLength; } else { int newCapacity _capacity; while (newCapacity validLength additionalLength) newCapacity * 2; byte[] newBuffer new byte[newCapacity]; Buffer.BlockCopy(_buffer, _readOffset, newBuffer, 0, validLength); _buffer newBuffer; _capacity newCapacity; _readOffset 0; _writeOffset validLength; } } private void ProcessPackets() { while (true) { int remaining _writeOffset - _readOffset; if (remaining HeaderLength) return; int bodyLength BitConverter.ToInt32(_buffer, _readOffset); if (bodyLength 0 || bodyLength MaxBodyLength) { // 数据异常重置连接或至少丢弃该段数据 _readOffset _writeOffset; return; } if (remaining HeaderLength bodyLength) return; byte[] packetBody new byte[bodyLength]; Buffer.BlockCopy(_buffer, _readOffset HeaderLength, packetBody, 0, bodyLength); _readOffset HeaderLength bodyLength; OnPacketReceived?.Invoke(packetBody); // 每条消息处理完毕如果缓冲区已空重置偏移防止长期膨胀 if (_readOffset _writeOffset) { _readOffset 0; _writeOffset 0; } } } }注意几个细节bodyLength 0要判掉防止恶意构造或数据损坏导致死循环MaxBodyLength要设上限比如64KB或512KB防止对方发个Int32.MaxValue直接爆内存ProcessPackets用while循环是因为一个缓冲区里可能有多条完整消息拆完一条要继续拆下一条直到缓冲区不足以组成一个完整帧为止。4.3 发送端的对称处理拆帧是接收端的事但发送端同样要遵循同一帧格式。如果你只处理接收发送时忘记加长度头那对端服务器就会把第一条消息的Body当Header解析立刻乱套。发送端封装成public void SendMessage(byte[] body) { byte[] header BitConverter.GetBytes(body.Length); byte[] packet new byte[HeaderLength body.Length]; Buffer.BlockCopy(header, 0, packet, 0, HeaderLength); Buffer.BlockCopy(body, 0, packet, HeaderLength, body.Length); OnPacketSent?.Invoke(packet); }UDP和TCP都适用这套帧格式区别只在底层传输的可靠性。5. 与NetworkStream的衔接实际接入Unity项目有了PacketHandler还需要一个循环从网络流中读数据。Unity主线程不能阻塞读所以有两种典型做法用异步BeginRead/EndRead或者用单独的Thread配合NetworkStream直接同步Read。我这里给出一套基于异步回调的接入方案它不阻塞主线程也不需要在Unity里额外管理线程生命周期。5.1 异步读取循环private void StartReceiveLoop() { if (_tcpClient null || !_tcpClient.Connected) return; NetworkStream stream _tcpClient.GetStream(); _readBuffer new byte[8192]; stream.BeginRead(_readBuffer, 0, _readBuffer.Length, ReceiveCallback, stream); } private void ReceiveCallback(IAsyncResult ar) { NetworkStream stream (NetworkStream)ar.AsyncState; try { int bytesRead stream.EndRead(ar); if (bytesRead 0) { // 连接断开 OnDisconnected?.Invoke(); return; } _packetHandler.AppendData(_readBuffer, bytesRead); stream.BeginRead(_readBuffer, 0, _readBuffer.Length, ReceiveCallback, stream); } catch (System.Exception e) { OnError?.Invoke(e.Message); OnDisconnected?.Invoke(); } }每次BeginRead只读最多8192字节这个值可以根据实际消息密度调。读到的数据全部丢给PacketHandler由它内部负责累积和拆帧。回调线程是ThreadPool线程所以OnPacketReceived回调不要直接操作Unity对象要切换到主线程后处理——Unity的API绝大多数不允许从非主线程调用这是新手最容易踩的坑。5.2 回调抛回主线程的两种姿势最简单的做法是包一个并发队列private ConcurrentQueuebyte[] _pendingPackets new ConcurrentQueuebyte[](); // 在ReceiveCallback线程调用 _pendingPackets.Enqueue(packetBody); // Unity Update里 void Update() { while (_pendingPackets.TryDequeue(out byte[] body)) { HandleMessage(body); } }这样消息处理完全落到主线程可以安全地改UI、生成GameObject。缺点是Update帧率不平滑时网络消息可能有少量延迟。但对大多数逻辑类游戏来说完全够用。5.3 分包场景的实测表现我专门做过一个压力测试模拟服务器每100毫秒发一条1KB左右的消息中间随机插入大量小消息客户端不做任何业务处理只统计拆帧情况。用Wireshark抓包发现一段5秒的测试数据里TCP层实际Read次数大约是业务消息数的三分之二也就是说大概三分之一的消息被粘到同一次Read里收到了。如果用“一次Read等于一条消息”的旧逻辑这三分之一的次数里有多余数据会被误判成消息体导致消息错乱而PacketHandler的拆帧循环在测试中稳定地把每一条业务消息都正确解出来。这个测试也解释了为什么粘包问题看起来像玄学它不固定复现跟网络环境、发送频率、消息大小全有关。本地环境可能十次里出现一次公网高峰期可能五次里出现一次你根本追不到具体哪条Write导致哪次Read——因为那是内核协议栈帮你组合的。6. 拆包与半包边界一个字节都不能丢的细节前面讲了粘包但别忘了分包/半包同样常见。一条2KB的业务消息对端可能分两次Read发送第一次只读到100字节。如果你的PacketHandler在Header还没到4字节时就尝试解析长度会直接失败。所以ProcessPackets里第一步就是判断剩余字节是否够Header不够就返回等待下批数据。分包场景里最容易出错的是这样一段代码int bodyLength BitConverter.ToInt32(_buffer, _readOffset);如果缓冲区里只有2字节数据这段代码会直接越界或读到脏数据因为Int32需要4字节。为了严谨在调用BitConverter之前必须检查remaining 4。上面的代码已经写了这个判断但我见过很多简化的版本省掉判断这是隐患。另一个细节是缓冲区压缩的时机。我在ProcessPackets里每拆一条完整消息后如果读偏移和写偏移重合就会重置偏移。这个操作很有必要防止长时间运行后缓冲区里积累无用的已读数据导致_writeOffset无限增长内存白白膨胀。如果你把压缩逻辑只放在EnsureCapacity里遇到持续高频通信但消息体很小的情况缓冲区底部会堆积大量垃圾偏移长期不触发扩容条件就永远不清理最终缓冲区可用空间越来越少。这个坑比较隐蔽建议直接套用上面的写法。还有一个值得提的点帧格式里的长度字段本身可以用不同字节数。1字节能表示255字节内2字节能表示65535字节内4字节基本可以覆盖任意场景。选择依据是消息的大小范围。如果你确定业务消息不会超过4KB用2字节长度头可以减少2字节的传输开销。但不要为了省字节而压缩到1字节一旦消息超限就得改协议麻烦远大于省下的那点带宽。7. 消息大小上限与公共协议设计的常见误区线上通信最容易出问题的地方除了拆帧就是消息上限的约定不一致。客户端设了MaxBodyLength 512KB服务端设的是64KB一旦客户端往服务端发一条100KB的消息比如大世界场景里的地图数据服务端直接判定异常断开连接。这种事故排查起来非常痛苦因为两边的日志都只显示IOException或ConnectionReset根本定位不到是协议约定差异。所以公共协议里必须明确三件事长度字段字节数、长度字段是否包含Header本身、Body长度上限。尤其是第二点很多项目设计成长度字段包含了Header自身的4字节这样对端解析时就用totalLength BitConverter.ToInt32(...)然后判断剩余字节是否达到totalLength再从偏移4的位置取出Body。两种约定都行但我不建议这么做因为“长度字段代表Body长度”的语义更直观也跟Netty的LengthFieldBasedFrameDecoder默认行为一致减少沟通和理解成本。更隐蔽的一个问题是长度字段用大端还是小端。C#的BitConverter在Windows上默认小端Java的ByteBuffer默认大端如果服务端是Go或Java收发双方长度字段的字节序不一致轻则拆帧失败重则直接把长度解析成几十兆字节触发MaxBodyLength保护被踢下线。Unity客户端跟不同语言的服务端对接时最好在序列化工具里显式指定字节序不要依赖平台默认值。我自己习惯用BinaryWriter之前先统一指定byte[] header BitConverter.GetBytes(bodyLength); if (!BitConverter.IsLittleEndian) { Array.Reverse(header); }这段代码放在一个公共方法里所有消息走同一个入口避免到处写BitConverter导致字节序混乱。8. 从粘包到半包排错路径与线上验证手段最后分享一套排错路径。如果你遇到“消息偶尔错乱、偶尔正常”的问题不要急着改代码。先自己做两个实验区分现象类型一是用固定长度的消息做ping-pong测试间隔均匀发送二是随机发送不同长度的消息观察错乱规律。如果固定长度时正常变长时错乱基本可以断定是粘包/分包处理缺失。如果固定长度也错乱那可能是协议字节序、加密或压缩层的问题。拿到现象后在PacketHandler的AppendData入口加日志打印每次Read到的字节数和累计缓冲区长度然后跟Wireshark抓包比对。抓包能直接看到TCP段是怎么拼的积攒一两次现象后你就能直观感受到“协议栈把我的Write切成了这样”。这份日志对上线后的排查价值也很大——建议保留在调试模式下。线上验证方面可以写一个服务端测试页每隔几毫秒连续发送3条不同长度的消息客户端收到后打印每条消息的长度和内容看是否三条均完整、顺序正确。我用这个方式跑了不少于10万次消息循环PacketHandler没有出现过一次拆帧错误。不能说绝对零风险但至少在这个模型设计正确、边界判断完整的情况下粘包分包问题是被真正解决掉的。做网络开发这么久我最大的体感是粘包分包不是高深算法它只是“你把数据交给协议栈之后协议栈按自己的节奏交付”这一现实带来的必然结果。只要老老实实定义好帧格式用一个带缓冲区的累加器做拆帧循环问题就能稳定解决。Unity里那些现成网络库好用的原因也无非是内部替你做了这件事。搞懂了底层逻辑哪天库出bug或者协议要定制你才有能力自己兜住。
