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默认的机器字节序，但跨平台时务必统一）。协议格式如下：
| 字段 | 字节数 | 说明 |
|---|---|---|
| Length | 4 | 正文的字节长度，不含头本身 |
| Body | Length | 实际业务数据（通常是序列化后的字节） |
接收端的解析逻辑必须写成状态机：先攒够 4 字节解析长度，再攒够 Length 字节解析正文，攒不够就继续等下一次 Read。这个“攒”的过程就是处理半包的核心。
2.3 一个能直接用的分包器实现思路
下面这段是我常用的接收缓冲逻辑，核心是把“读到的字节”和“已解析的消息”解耦：
private List<byte> _cache = new List<byte>(); 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用List<byte>频繁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，把解析好的完整消息塞进ConcurrentQueue<byte[]>，主线程在Update里TryDequeue逐条处理。这样网络线程只管收和拆包，业务逻辑全在主线程，避免了跨线程操作 Unity 对象的风险。
private ConcurrentQueue<byte[]> _msgQueue = new ConcurrentQueue<byte[]>(); // 后台线程 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 或者加加密层，改动面都很小，因为分包和分发的骨架是通用的。
