TCP 这套东西在游戏网络同步里算是老资历了但真到 Unity 里落地很多人第一反应还是“找个现成库接上就行”结果联调时被粘包、半包、线程阻塞轮番教育。我见过不少项目单机跑得飞起一开网络就各种玄学延迟、消息错乱最后翻日志才发现是NetworkStream.Read读到的字节数跟想象中不一样。这篇就围绕 Unity3D 里 TCP 通讯的核心意涵和基本原理展开把“为什么这么设计”“底层到底发生了什么”“代码怎么写才不踩坑”这几件事讲透。适合已经能写 C# 脚本、但对网络层还停留在“调个 API 就完事”阶段的开发者也适合想回头补一补底层原理的老手。读完你至少能明白TCP 在 Unity 里为什么不能直接照搬控制台那套写法粘包到底是怎么产生的以及一个能跑的主从通讯框架该长什么样。1. TCP 在 Unity 项目里到底承担什么角色1.1 先搞清楚 TCP 给游戏带来了什么、又拿走了什么TCP 的本质是一条面向连接的、可靠的、基于字节流的传输通道。这句话每个字都有分量。面向连接意味着通信前必须先握手建立通路可靠意味着丢包会重传、乱序会重排字节流意味着你发出去的数据在接收端看来就是源源不断的字节没有“消息边界”这个概念。对游戏来说可靠性是双刃剑登录验证、房间状态同步、聊天、指令下发这类不能丢、不能乱的数据TCP 是天然合适的但位置同步这种高频、可容忍少量丢失的数据TCP 的重传机制反而会放大延迟这也是为什么很多实时对战项目会转向 UDP 或可靠 UDP 方案。我在实际项目里通常这样划分控制通道走 TCP状态通道走 UDP。比如某模拟项目里玩家移动的每帧坐标用 UDP 发而“进入房间”“切换武器”“结算上报”这些关键事件走 TCP。这样既保证了关键逻辑的强一致又不会让位置同步被重传拖累。你要做的第一件事就是先想清楚自己这条连接承载的是哪类数据别一股脑全塞进 TCP 然后抱怨延迟高。1.2 Unity 里 TCP 的两种典型拓扑客户端主动、服务端监听Unity 客户端绝大多数场景是主动发起连接的一方用TcpClient.Connect去连一个固定地址和端口。而服务端可以是独立的 C# 控制台程序也可以是跑在 Unity 里的一个“主机模式”Host后者在小型联机 Demo 里很常见——一个客户端同时充当服务端其他客户端连它。这两种拓扑在代码上的差别主要在于谁调Start、谁调Connect但底层用的都是同一套System.Net.Sockets。需要提醒的是Unity 里跑服务端监听要特别注意不要把阻塞式 Accept 放在主线程。我早期就干过这事在Start里直接listener.AcceptTcpClient()结果编辑器直接卡死因为主线程被阻塞在那里等连接渲染循环全停了。正确做法是丢到后台线程或者用异步 Accept。这个坑后面还会细说。1.3 为什么很多团队最终还是选了 TCP 而不是自己造轮子自己基于 UDP 实现可靠传输类似 KCP 那套思路听起来很酷但工作量不小重传策略、拥塞控制、有序交付、心跳保活全得自己写还要处理各种边界情况。对于中小团队或者非实时性要求极高的项目TCP 的成熟度和系统级优化Nagle 算法、滑动窗口、拥塞控制都是内核帮你做的能省下大量调试时间。我的经验是除非你的核心玩法对延迟极度敏感否则先用 TCP 把业务跑通等真有性能瓶颈再考虑替换传输层。过早优化传输协议往往是给自己挖坑。2. 粘包与半包TCP 字节流绕不开的第一道坎2.1 粘包不是 bug是字节流的本来面目很多人第一次遇到粘包会以为是库的问题其实这是 TCP 的设计使然。TCP 只保证字节按序到达不保证你一次 Send 对应一次 Receive。发送端连续调两次Send接收端可能一次Read就把两段数据全读出来粘包也可能一段数据被拆成两次Read才读完半包。这跟网络状况、缓冲区大小、Nagle 算法都有关系。举个具体例子客户端先发一条 20 字节的“登录请求”紧接着发一条 50 字节的“心跳”。服务端如果直接Read(buffer, 0, 1024)很可能一次读到 70 字节把两条消息糊在一起。你要是按“一次 Read 就是一条消息”来解析逻辑立刻错乱。这就是为什么任何基于 TCP 的应用层协议都必须自己定义消息边界。2.2 长度前缀法最朴素也最可靠的分包方案解决粘包半包的主流方案有三种固定长度、分隔符、长度前缀。固定长度太浪费且不灵活分隔符要处理转义且怕数据里出现分隔符长度前缀法是游戏里最常用的每条消息前面加一个固定字节数的“长度头”接收端先读头、解析出正文长度再精确读够这么多字节。我一般用 4 字节int做长度头小端或大端要两端约定一致我习惯用BitConverter默认的机器字节序但跨平台时务必统一。协议格式如下字段字节数说明Length4正文的字节长度不含头本身BodyLength实际业务数据通常是序列化后的字节接收端的解析逻辑必须写成状态机先攒够 4 字节解析长度再攒够 Length 字节解析正文攒不够就继续等下一次 Read。这个“攒”的过程就是处理半包的核心。2.3 一个能直接用的分包器实现思路下面这段是我常用的接收缓冲逻辑核心是把“读到的字节”和“已解析的消息”解耦private Listbyte _cache new Listbyte(); private void OnReceive(byte[] data, int length) { _cache.AddRange(data.Take(length)); while (true) { if (_cache.Count 4) break; // 头都不够继续等 int bodyLen BitConverter.ToInt32(_cache.ToArray(), 0); if (_cache.Count 4 bodyLen) break; // 正文不够继续等 byte[] body _cache.GetRange(4, bodyLen).ToArray(); _cache.RemoveRange(0, 4 bodyLen); Dispatch(body); // 交给业务层 } }这里有个容易忽略的点_cache用Listbyte频繁AddRange/RemoveRange在消息量大时会有 GC 压力正式项目里我会换成环形缓冲区或者预分配的byte[]加读写指针。但作为理解原理的起点上面这段足够直观。关键是要意识到一次 Read 可能喂进来半条、一条或多条消息解析必须循环到攒不够为止。注意BitConverter.ToInt32依赖运行环境的字节序如果服务端和客户端跑在不同架构上比如一边 x86 一边 ARM务必显式统一大小端别偷懒。3. 线程模型别让网络阻塞拖垮主线程3.1 Unity 主线程的脾气卡一帧都算事故Unity 的渲染、物理、脚本生命周期全在主线程上跑任何阻塞操作都会直接反映为掉帧甚至假死。而NetworkStream.Read默认是阻塞的——没数据来就一直等。你要是把它放在Update里同步调用网络一抖动整个游戏就卡住。所以网络接收必须放到独立线程或者用异步 API。我推荐两种做法一是开一个后台线程专门跑Read循环读到数据后通过线程安全队列交给主线程处理二是用async/await配ReadAsync但要注意 Unity 里async的回调默认不在主线程操作 GameObject 前必须切回主线程比如用主线程调度器或者SynchronizationContext。前者更直观、可控后者代码更简洁但调试时调用栈跳来跳去新手容易懵。3.2 后台接收线程 主线程消费队列的标准套路我项目里最稳的结构是这样后台线程死循环Read把解析好的完整消息塞进ConcurrentQueuebyte[]主线程在Update里TryDequeue逐条处理。这样网络线程只管收和拆包业务逻辑全在主线程避免了跨线程操作 Unity 对象的风险。private ConcurrentQueuebyte[] _msgQueue new ConcurrentQueuebyte[](); // 后台线程 private void ReceiveLoop() { byte[] buffer new byte[4096]; while (_running) { try { int len _stream.Read(buffer, 0, buffer.Length); if (len 0) break; // 对端关闭 OnReceive(buffer, len); // 内部拆包后入队 } catch (Exception e) { Debug.LogError($接收异常: {e.Message}); break; } } } // 主线程 Update private void Update() { while (_msgQueue.TryDequeue(out var msg)) { HandleMessage(msg); } }这里有个细节Read返回 0 表示对端正常关闭连接返回负数或抛异常则是异常断开两种情况都要走清理逻辑关流、关 socket、通知业务层。我见过有人只判断len 0却漏了异常分支结果断线后线程还在空转。3.3 发送端也别在主线程裸调发送看似不阻塞但Send在缓冲区满时同样会阻塞。高频发送场景下我一般也把发送放到独立线程或者用发送队列 单线程消费。简单项目里直接在主线程Send问题不大但一旦你发现偶发的卡顿跟发包频率相关就该怀疑发送阻塞了。另外多线程同时Send同一个流是非线程安全的必须加锁或者串行化这点后面还会提。4. 连接生命周期握手、心跳、断线与重连4.1 建立连接时那些容易忽略的细节TcpClient.Connect是阻塞的连不上会等到超时。生产环境里我会设ConnectTimeout或者用BeginConnect配超时控制避免用户点“开始游戏”后界面卡死十几秒。连接成功后第一件事是关掉 Nagle 算法client.NoDelay true因为 Nagle 会把小包攒起来再发对需要低延迟的指令类消息很不友好。这个设置一行代码但很多人不知道联调时发现“明明发了却延迟几十毫秒”往往就是它。4.2 心跳机制怎么判断对方还活着TCP 连接在物理断开拔网线、进程崩溃时本地 socket 可能长时间感知不到因为 TCP 本身没有应用层心跳。所以业务层必须自己做定时心跳客户端每隔 N 秒发一个心跳包服务端收到后回一个超过 M 秒没收到回应就判定断线并触发重连。N 一般取 3~5 秒M 取 2~3 倍 N。心跳包本身可以极简甚至就一个特定消息 ID不携带业务数据。我踩过的坑是心跳和业务消息共用一条连接时如果服务端处理慢心跳可能排在业务消息后面被延迟导致误判断线。解决办法是心跳走独立优先级或者服务端收到心跳立即回、不排队。4.3 断线重连的状态管理重连不是简单再Connect一次。要区分“主动断开”和“被动断开”被动断开后要有退避策略比如 1s、2s、4s 递增重试避免服务端刚重启就被大量客户端瞬间打满。重连成功后还要重新走登录/鉴权流程因为服务端那边的会话已经没了。我通常把连接状态抽象成一个枚举Disconnected / Connecting / Connected / Reconnecting所有网络操作前先检查状态避免在错误状态下发包导致异常。5. 序列化与协议设计字节怎么变成有意义的数据5.1 为什么不能直接传对象C# 对象在内存里的布局受运行时影响直接Marshal或者二进制强转跨平台、跨版本都不可靠。游戏里常用的做法是手动序列化或者用成熟的序列化库如 Protobuf、MessagePack。手动序列化虽然啰嗦但对字节布局完全可控调试时也容易对照协议文档。小项目里我常用BinaryWriter/BinaryReader配MemoryStream写起来直观// 序列化 using var ms new MemoryStream(); using var writer new BinaryWriter(ms); writer.Write((int)MsgType.Login); writer.Write(userId); writer.Write(password); byte[] body ms.ToArray(); // 反序列化 using var reader new BinaryReader(new MemoryStream(body)); var type (MsgType)reader.ReadInt32(); var uid reader.ReadString();5.2 消息 ID 与协议版本管理每条消息开头带一个MsgType枚举值接收端据此分发到不同处理函数。这里有个经验协议一旦上线就很难改所以设计时给消息 ID 留足空间并且考虑加一个协议版本号字段。客户端和服务端版本不一致时服务端可以拒绝连接并提示升级而不是让旧客户端解析新协议导致崩溃。我在某项目里就因为没做版本校验热更后新旧客户端混连解析错位直接闪退排查了半天。5.3 大消息与分片单条消息过大比如超过几十 KB时一次性Send可能被拆成多次虽然长度前缀法能处理但大消息会长时间占用接收缓冲影响其他消息的实时性。我的做法是限制单条消息上限比如 64KB超过的业务数据自己分片传输并在应用层做重组。这样既控制了内存峰值也让延迟更可控。6. 实操中反复踩到的几个坑6.1 关闭连接时的顺序问题关闭时如果直接client.Close()可能触发RST而不是优雅的FIN对端会收到异常。正确顺序是先Shutdown(SocketShutdown.Send)通知对端我要关了等对端也关再Close。虽然很多场景下粗暴关闭也能用但在需要保证“最后一条消息送达”的场景比如结算上报优雅关闭很关键。6.2 多线程同时写同一个流前面提过NetworkStream的写操作不是线程安全的。如果心跳线程和业务线程同时Send字节可能交错接收端解析直接崩。解决办法是给发送加一把锁或者统一走一个发送队列由单线程消费。我倾向后者因为锁在高压下容易成为瓶颈。6.3 编辑器里能跑、真机连不上这个坑太经典了。常见原因有几个一是防火墙拦了端口二是真机和服务器不在同一网段三是移动端切后台后 socket 被系统挂起。排查时先确认端口通不通用telnet或简单的连通性测试再检查代码里地址是不是写死成了127.0.0.1。移动端还要处理切后台再回来的连接恢复很多系统会直接断掉后台 socket回来必须重连。6.4 缓冲区大小拍脑袋定Read的 buffer 大小不是越大越好。太小会导致频繁系统调用太大浪费内存且可能一次读进多条消息增加拆包压力。我一般用 4KB~8KB配合长度前缀法足够应对大多数游戏消息。真正的大数据传输如资源下载应该走独立通道别和指令通道混在一起。7. 从原理到落地一个最小可运行框架的骨架把上面这些串起来一个能跑的最小 TCP 框架大概包含这几块连接管理Connect/Disconnect/重连状态机、收发线程后台 Read 循环 发送队列、分包器长度前缀 状态机解析、消息分发按 MsgType 路由到 handler、心跳与超时检测。这五块职责清晰、互不耦合任何一块出问题都容易定位。我建议新手按这个顺序搭先写死一个“回声”服务端收到什么原样发回验证连接和收发通路再加长度前缀验证粘包半包处理然后加消息 ID 分发验证业务路由最后补心跳和重连。每加一层都单独测别一上来就全堆上去出问题时根本不知道是哪层的锅。这套流程我在好几个项目里复用虽然土但真的省时间。最后分享一个我个人的习惯所有网络收发的关键节点都打带时间戳的日志包括连接建立、每条消息的 ID 和长度、断线原因。联调时这些日志比断点调试管用得多尤其是多端并发的时候翻日志能快速还原时序。日志级别做成可开关的正式包关掉避免影响性能。这套东西搭顺了之后后面换 UDP 或者加加密层改动面都很小因为分包和分发的骨架是通用的。