2、Unreal网络架构：UE网络子系统、NetDriver、Connection、Channel、Actor Channel与Property Channel
好，咱们今天来啃一块硬骨头——Unreal的网络架构。说实话，我刚接触UE网络时，也被这一堆名词搞得头晕：NetDriver、Connection、Channel……它们到底是个什么关系？
别急，我带你一层层剥开。你想想看，整个网络系统就像一家快递公司。有调度中心、有运输车、有包裹、还有打包员。咱们一个个来认识。
2.1 网络子系统（Network Subsystem）
这是整个网络模块的入口。UE里叫UNetSubsystem，它负责管理网络的生命周期。说白了，它就是那个「调度中心」。
我在项目中遇到过一个问题：客户端连不上服务器，查了半天，发现是网络子系统初始化顺序不对。嗯，这里要注意——UNetSubsystem是在游戏实例启动时创建的，你得确保它在PreInitializeComponents阶段就已经就绪。
核心职责：
- 创建和管理NetDriver
- 处理网络地址解析
- 管理网络流量统计
- 提供网络状态查询接口
2.2 NetDriver——网络驱动
NetDriver是真正的「运输车队」。每个游戏世界（World）都有一个NetDriver，它负责底层的网络通信。UE默认提供了UPendingNetGame和UGameNetDriver两种。
我个人习惯把NetDriver理解为「网络引擎」。它管理着所有连接（Connection），处理数据包的收发，还负责调用序列化函数。
// 获取当前世界的NetDriver
UNetDriver* NetDriver = GetWorld()->GetNetDriver();
if (NetDriver)
{
// 检查网络模式
if (NetDriver->ServerConnection == nullptr)
{
// 我们是服务器
UE_LOG(LogTemp, Log, TEXT("This is a dedicated server"));
}
}
避坑指南：我曾经在自定义NetDriver时忘了重写IsNetRelevantFor方法，结果导致客户端看到了不该看到的Actor。记住：NetDriver的关联性检查直接影响网络带宽。
2.3 Connection——网络连接
每个连接到服务器的客户端，都对应一个UNetConnection。它就像一条「运输专线」。服务器端有一个ClientConnections数组，里面存着所有客户端的连接。
Connection里藏着很多好东西：
- PlayerId：玩家唯一标识
- InternalAck：是否启用内部确认机制
- PacketId：当前数据包序号
- Out：发送缓冲区
- In：接收缓冲区
你想想看，如果连接断了怎么办？UE有一套重连机制，但说实话，我在项目中更倾向于自己实现心跳检测。默认的UNetConnection超时时间有点长，对实时性要求高的游戏不太友好。
2.4 Channel——通信通道
Channel是Connection内部更细粒度的通信单元。每个Connection可以拥有多个Channel。它们负责传输不同类型的数据。
| Channel类型 | 用途 | 创建时机 |
|---|---|---|
| Control Channel | 控制消息（如连接握手） | 连接建立时自动创建 |
| Actor Channel | 同步Actor状态 | 当Actor被复制时创建 |
| Voice Channel | 语音数据 | 需要语音时创建 |
| File Channel | 文件传输 | 需要下载资源时创建 |
注意：每个Connection最多支持255个Channel（0-254）。Channel 0是Control Channel，永远存在。我曾经遇到过Channel耗尽的问题，那是在一个大型MMO项目中，每个玩家同时同步了太多Actor。解决方案是优化Actor的复制范围，减少不必要的Channel创建。
2.5 Actor Channel——演员通道
这是最常用的Channel。每个需要网络同步的Actor，都会在对应的Connection上创建一个UActorChannel。
我记得有一次调试一个奇怪的bug：客户端上的某个Actor位置总是不对。查了半天，发现是Actor Channel的RelevantTime设置有问题。Actor Channel会记录上次同步的时间戳，如果时间间隔太短，它会跳过同步。
// 手动打开一个Actor Channel
UActorChannel* Channel = Connection->CreateChannel(CHTYPE_Actor);
if (Channel)
{
Channel->SetActor(MyActor);
// 现在这个Actor会通过这个Channel同步
}
Actor Channel内部维护了一个PendingBunch列表。说白了，就是待发送的数据包队列。UE会把这些数据包打包成Bunch（数据束），然后通过NetDriver发送出去。
2.6 Property Channel——属性通道
Property Channel其实是Actor Channel内部的一个子机制。它负责同步Actor的各个属性（Property）。每个标记了Replicated的属性，都会在Actor Channel里有一个对应的Property Channel。
你可能会问：为什么不直接同步整个Actor？嗯，这里有个性能考量。如果每次同步都发送整个Actor的状态，带宽根本扛不住。Property Channel只同步发生变化了的属性。
属性同步的三种模式：
- Conditional：根据条件判断是否同步（如
COND_OwnerOnly） - RepNotify：属性变化时触发回调函数
- Lifetime：属性的生命周期管理
我在项目中踩过一个坑：某个属性明明标记了Replicated，但客户端就是收不到更新。后来发现是NetUpdateFrequency设置得太低，导致Actor Channel的更新频率跟不上。记住：属性同步的频率受限于Actor的更新频率。
2.7 它们是如何协同工作的？
来，咱们捋一捋整个流程：
- 服务器启动，
UNetSubsystem创建UGameNetDriver - 客户端连接，NetDriver创建
UNetConnection - 连接建立后，自动创建Control Channel（Channel 0）
- 当服务器需要同步某个Actor时，在对应的Connection上创建
UActorChannel - Actor Channel内部，为每个标记了
Replicated的属性创建Property Channel - 属性变化时，Property Channel将数据打包成Bunch
- Actor Channel将多个Bunch组合成数据包
- Connection通过NetDriver发送数据包
个人经验：调试网络问题时，我经常在UActorChannel::ReplicateActor和UNetConnection::SendBunch这两个函数里加断点。它们能告诉你：哪个Actor正在同步、同步了哪些属性、数据包是否成功发送。
说实话，理解这套架构需要一点时间。但一旦你搞清楚了NetDriver、Connection、Channel这三层的关系，UE的网络同步对你来说就不再是黑盒了。下次遇到网络不同步的问题，你至少知道该从哪里入手排查。
嗯，今天就先到这里。下一章咱们聊聊「RPC调用与属性同步的底层实现」，到时候会用到今天讲的这些知识。