UnrealEngine - 网络同步之连接篇_unreal ds server

1 连接过程 - 握手

传统的 C/S 架构下，Client 和 Server 通常会建立一条抽象的 Connection，用来进行两端的通信。
UE 的官方文档中提供了 Client 连接到 Server 的示例 ，简单来说分为如下几步：

• 打包构建好 Client 和 Server 进程
• 启动 Server 进程，启动参数为 ./Binaries/Win64/<PROJECT_NAME>Server.exe -log
• 启动 Client 进程，启动参数为 ./Binaries/Win64/<PROJECT_NAME>Client.exe 127.0.0.1:7777 -WINDOWED -ResX=800 -ResY=450

默认情况下，专用服务器在 localhost Ip 地址（ 127.0.0.1 ）的端口 7777 处监听。可以添加命令行参数 -port=<PORT_NUMBER> ，更改专用服务器的端口。如果要更改服务器正在使用的端口，则还需要更改将客户端连接到服务器时的端口。

1.1 启动 Server

Client 连接到 Server 的前提是 Server 启动完毕，监听完毕端口，准备好接收连接了。UE 中监听的核心接口如下：

其接口核心参数为一个 FURL ，UE 中会根据启动参数和配置等构建一个 FURL，其结构如下 (只展示部分变量)：

可以看到里面有关键的 Host 和 Port 等信息。
Listen 接口具体做了什么呢？

• 通过 UEngine:: CreateNamedNetDriver 创建 NetDriver，主要驱动网络同步
• UNetDriver::InitListen 解析 FURL，监听端口
  网络相关的流程在这里开始就交付给了 UNetDriver，显然它是一个比较重要的网络管理类，这里简单看下其结构

可以看到主要负责：

• Server 端初始化监听端口
• 初始化连接
• 管理 UNetConnection，UNetConnection 显然就是抽象出来的连接
  • 这里有 ServerConnection 和 ClientConnections，当拥有 ServerConnection 时表示当前是 Client 端，拥有 ClientConnection 时表示当前时 Server 端

同时其派生了不同的类，如：

• UDemoNetDriver：用来支持游戏录像和回放（类似守望先锋的击杀回放）
• UWebSocketNetDriver：用于实现 WebSocket 协议的网络通信。WebSocket 是一种基于 TCP 的网络协议，允许在客户端和服务器之间进行双向通信，可以实现实时通信和数据传输。通过使用 UWebSocketNetDriver，可以在 UE4中使用 WebSocket 协议进行网络通信
• UIpNetDriver：用于实现基于 IP（Internet Protocol）的网络通信
  Server 端完整的绑定端口监听的流程大致如下：

可以看到其实和普通的 C++ 创建 TCP C/S 连接类似，最终都是创建一个 Socket 并且 Bind 到指定端口。

1.2 Client 初始化

客户端启动之后，也是类似的流程，创建 NetDriver 驱动网络相关的流程，对比 Server，其多了一个 UPendingNetGame 的对象。UPendingNetGame 类是一个用于处理网络游戏连接过程的类。它在客户端尝试连接到服务器时创建，并在连接成功或失败后销毁。

关于 UPendingNetGame

1. 用处：
   UPendingNetGame 主要负责处理客户端与服务器之间的连接流程。主要功能包括：
   a. 处理连接请求：客户端向服务器发起连接请求时，UPendingNetGame 负责处理这个请求，包括创建套接字连接、发送握手请求等。
   b. 加载关卡：在连接过程中，若服务器需要客户端加载一个关卡，UPendingNetGame 负责处理这个请求，包括加载关卡资源、同步关卡状态等。
   c. 状态同步：在连接过程中，UPendingNetGame 负责与服务器进行状态同步，包括玩家数据、游戏规则等。
   d. 错误处理：若连接过程中出现错误，如超时、被拒绝等，UPendingNetGame 负责处理这些错误，通知用户并做出相应处理

2. 创建与销毁：
   a. 创建：当客户端尝试连接到服务器时，会创建一个 UPendingNetGame 实例。
   b. 销毁：当客户端成功连接到服务器并完成状态同步后，UPendingNetGame 完成其任务并被销毁。如果连接过程中出现错误，如超时、被拒绝等, UPendingNetGame 也会在处理完错误后被销毁

Client 的初始化流程大致如下：

• UEngine::Browse 解析 FURL
• UPendingNetGame::InitNetDriver 初始化网络驱动
• UIpNetDriver::InitConnect 初始化连接
  • 创建 UIpNetConnection
  • UIpNetConnection::InitLocalConnection 初始化连接信息
• 调用 Connection 的 Handler 的 BeginHandshaking 发握手包
  其大致执行堆栈如下：

1.3 Server 收包

Server 端上 PacketHandler 处理的数据包的结构如下：

1.3.1 收包流程

Server 监听完端口之后就要处理客户端发过来的连接请求，由于是 UDPSocket，所以只需要简单的 Bind + RecvFrom 就能接收数据了。其主流程主要由 NetDriver 的 TickDispatch 驱动，如下：

• UIpNetDriver::TickDispatch
• FPacketIterator (UIpNetDriver*) ++，UE 实现了一个 Iterator 遍历消费 Socket 的 Packet
• UIpNetDriver::AdvanceCurrentPacket
• FPacketIterator::ReceiveSinglePacket 迭代器收包
  • UIpNetDriver 中检查 SocketReceiveThreadRunnable 如果存在这个线程（默认情况下应该是没开的，这个时候就相当于这个线程的逻辑在 GameThread 跑了），从 SocketReceiveThreadRunnable->ReceiveQueue 这个 Packet 队列弹出，这里主要是区分用 GameThread 还是用 SocketReceiveThread 来取包。
    • FReceiveThreadRunnable::Run 本身是生产者，可以将 ReceiveQueue 理解为一个数据中间件，IpNetDriver 的 TickDispatch 则是消费者，一直消费 ReceiveQueue 的数据
    • ReceiveQueue 在 SocketReceiveThreadRunnable 线程中一直使用 FSocket::RecvFrom（抽象接口，大部分情况下都是为 FSocketBSD::RecvFrom）接收数据，其底层实现就是使用 recvfrom 这个操作系统接口

SocketReceiveThreadRunnable 默认是没有打开的，官方说明如下：
// If the cvar is set and the socket subsystem supports it, create the receive thread.
CVarNetIpNetDriverUseReceiveThread.GetValueOnAnyThread() != 0 && SocketSubsystem->IsSocketWaitSupported()

1.3.2 处理客户端连接

首先 Server 需要检查这个 Packet 是否已经有连接了，这里引出一个问题，Server 端是如何管理和查询 Connection 的？主要是通过解析 Packet 的 Address，在 UNetDriver 中查询缓存地址映射关系。

接下来是处理 Packet

• TickDispatch 正常消费到 Packet 之后，要确定 Packet 该丢给哪一层
• 由于未建立连接，下一层交由 UIpNetDriver::ProcessConnectionlessPacket
  • PacketHandler::IncomingConnectionless 校验 Packet 正确性
    • PacketHandler::Incoming_Internal
      • 遍历 HandlerComponent 对包进行处理
      • StatelessConnectHandlerComponent::IncomingConnectionless 处理无连接的 Packet
        • StatelessConnectHandlerComponent::ParseHandshakePacket 检查是否为握手包，根据 Packet 时间戳确定是否是 bInitialConnect
        • 握手包回一个 Challenge 包 StatelessConnectHandlerComponent::SendConnectChallenge
  • StatelessConnectHandlerComponent::HasPassedChallenge 校验
  • 检查是否是重连，处理重连逻辑
  • 创建 UIpConnection
  • UIpConnection::InitRemoteConnection
    • UNetConnection 的 ClientLoginState 初始化为 EClientLoginState::Type::LoggingIn
  • FNetworkNotify::NotifyAcceptedConnection 通知接收连接
  • UNetDriver::AddClientConnection 添加 UIpConnection

关于 Challenge
Challenge 消息是 Unreal Engine 4（UE4）中的一种网络消息，用于在客户端和服务器之间进行身份验证。在 UE4 中，客户端和服务器之间的通信是通过一种称为 Unreal Network Protocol（简称 UNet）的协议实现的。UNet 通过在客户端和服务器之间发送各种类型的网络消息来管理通信。

在 UE4 中，当客户端第一次连接到服务器时，服务器会向客户端发送一个 Challenge 消息，其中包含一个随机生成的 Challenge 令牌。客户端必须将这个 Challenge 令牌使用预共享密钥（PSK）进行签名，并将签名后的结果发送回服务器。服务器会验证签名是否正确，如果正确，则表示客户端是一个合法的用户，并将向客户端发送一个 ChallengeAck 消息，其中包含服务器的签名和一些其他的验证信息。客户端必须验证 ChallengeAck 消息是否正确，并将消息发送回服务器，以便进行最终的身份验证。

关于 NMT_Hello
可以看到收到客户端连接包之后，除了回复正常的 Ack 包之外，会主动给客户端发送一个 NMT_Hello 包，这里的 NMT_Hello 是一个枚举。UE4 中 NMT 开头的枚举是指 NetworkMessageTypes，是 Unreal Engine 4（UE4）中用于管理网络消息类型的一组枚举。在 UE4 中，网络消息是通过一种称为 Unreal Network Protocol（简称 UNet）的协议进行传输和管理的。UNet 通过在客户端和服务器之间发送各种类型的网络消息来管理通信。

通过接收不同的 NMT 消息，从而在客户端服务器连接过程中，不同阶段执行不同的操作，比如当前收到这个消息应该加载地图或者创建 PlayerController。

1.4 握手小结

至此大致梳理完了 Client 和 Server 的握手流程：

• 创建网络驱动 UNetDriver
• Server 端 Listen
• Client 端先创建 UIpConnection 发起连接
• Server 端接收连接，回复 ConnectChallenge 包
• Client 收包，回复 ChallengeResponse 包
• Server 回复 ChallengeAck
• 握手完毕
  其中重点内容主要有：
• UNetDriver 是网络同步核心，用于驱动网络同步
• Client 会有一个 UPendingNetGame 在正式连接前驱动握手过程
• Client 会先创建 Connection，Server 收到后才创建对应的 Connection，Connection 用于收发握手过程中的数据包
• Server 和 Client 收包底层使用 Connection 的 PacketHandler
• 握手过程主要利用 PacketHandler 的 HandlerComponent 中的 StatelessConnectHandlerComponent，其负责整个握手过程，此外 PacketHandler 的 HandlerComponent 可以挂载各种组件来支持对数据包的处理，比如 RSA，加密解密等
  双方完整握手的流程如下：

1.5 QA

1.5.1 丢包处理

握手过程中显然有丢包的可能，在 CS 握手过程中，大致发送的 Packet 如下：

Client 主要发送两个包，Handshake 和 ChallengeResponse，当 Client 没有收到回应时，对应阶段在 StatelessConnectHandlerComponent::Tick 都会有一个重发机制。参考代码如下：

1.5.2 连接过程用到了哪些关键 Class

大致如下：

2 连接过程 - Enter Game

握手完毕后就要准备一些 Gameplay 层的相关操作，比如加载地图等，Packet 对于应用层还是太底层了，UE 为此引入了 Bunch 和 Channel 的概念

2.1 Bunch

2.1.1 Bunch 和 Packet 的区别

首先 Bunch 和 Packet 的关系如下：

1. Bunch：Bunch是UE4中的一个基本网络数据单位。它可以被看作是一组数据的集合，这些数据代表了某个特定时刻的游戏状态变化。Bunch充当了一种中介，将游戏的状态信息打包成可以在网络上发送和接收的格式。它包含了一些关于对象、事件和属性的信息，以及一些控制网络通信的元数据。
2. Packet：Packet是一个更大的网络数据单位，用于在网络上实际传输数据。一个Packet通常包含多个Bunch，以及其他一些网络层所需的信息，如包序号、时间戳等。Packet在网络上发送时，会被分割成更小的数据包，以适应各种网络环境和传输协议。
   Bunch和Packet之间的关系是层次性的。Bunch负责打包游戏状态的变化，而Packet负责在网络上传输这些Bunch。在数据传输过程中，Bunch被组合成Packet，Packet在发送端被编码为可以在网络上传输的二进制数据，然后在接收端被解码还原为Bunch，以便在游戏中应用状态变化。

2.1.2 Bunch 的结构

Bunch 分为 FInBunch 和 FOutBunch，根据这个名字可以看出分别对应收到的 Bunch 结构和 发送的 Bunch 结构，其继承链如下：

FInBunch 的结构如下：

FOutBunch 的结构如下：

Bunch 的信息中，除了一些分包相关的信息，最主要的便是 Channel 相关的信息了，比如这个 Bunch 属于哪个 Channel？Channel 的类型是什么？那么什么是 Channel ？其用处是什么？

2.2 Channel 定义

UE 中，Channel 主要分为三种类型：

• ActorChannel： 用于在服务器和客户端之间同步Actor状态的通道。它负责在网络上移动、旋转、缩放等操作，并确保所有客户端都具有相同的Actor状态。它还负责同步Actor的变量和属性。
• ControlChannel：一个特殊类型的网络通道，主要负责处理底层的网络连接和控制消息。与其他类型的通道（如UActorChannel）主要用于游戏数据传输不同，UControlChannel处理的消息与游戏逻辑关系较少，主要用于维护网络连接状态、通知连接事件以及传输核心控制信息。ControlChannel 的一些职责示例如下：

1. 连接建立和断开：UControlChannel会处理网络连接建立和断开的消息。例如，当客户端与服务器建立连接时，UControlChannel会发送和接收连接请求和响应，以便双方建立通信。同样，当连接断开时，UControlChannel会负责发送断开通知，通知另一方连接已关闭。
2. 心跳检测：为了确保连接保持活跃，UControlChannel会定期发送和接收心跳消息。这些消息用于检测双方是否仍在线，以便在一方掉线时及时处理连接断开事件。
3. 通道管理：UControlChannel负责处理通道的打开和关闭。例如，当需要创建一个新的UActorChannel以传输游戏对象数据时，UControlChannel会发送相应的打开通道请求。同样，当某个通道不再需要时，UControlChannel会负责发送关闭通道请求。
4. 控制消息：UControlChannel还可以处理其他一些控制消息，如暂停、恢复游戏等。这些消息通常对游戏逻辑产生一定影响，但主要用于维护游戏状态和连接。

• VoiceChannel：主要处理语音数据，比如常见的游戏中的队伍聊天

2.3 Channel 的创建

• Client ：Client 上 Channel 的创建接口为 UNetDriver::CreateInitialCilentChannels ，其实就是在 InitNetDriver 的时候就创建好了 Channel

  

• Server ：Server 上 Channel 的创建时机如下：

  

基本上都是在握手过程中就创建好了 Channel。其关系如下：

2.3 Client 发送 NMT_Hello

Server 端在 InitRemoteConnection 之后，会执行 UNetConnection::SetExpectedClientLoginMsgType(NMT_Hello) ，表示等待 Client 端发送 NMT_Hello 的消息，而 Client 端发送该消息的时机就在握手完毕之后。
Client 端在调用 BeginHandshake 的时候，会传入一个 Delegates，Handshake 完毕之后会调用 Delegates. Broadcast，通知握手完毕，绑定了该 Delegate 的接口都会被执行，大致如下：

因此握手完毕后，Client 端就会调用 UPendingNetGame::SendInitialJoin ，发送 NMT_Hello 给 Server 端。
这里还有个问题，如何确定这个 Message 会发送给 ControlChannel ？实际上这里由 FNetControlMessage<>::Send 接口处理，其内部实现会直接发送一个 FControlChannelOutBunch，该 Bunch 会直接使用 Channel[0] 初始化，Channel[0] 默认情况下就是 ControlChannel。

2.5 ControlChannel 处理 ControlMessage

2.5.1 Server

Server 端处理 Bunch 的 CallStack 如下：

其大致流程如下：

• NetDriver 收到 Packet
• NetConnection 拆分 Packet 成多个 Bunch
• 根据 Bunch.ChIndex 找到对应的 Channel（Channel 缓存在 NetConnection）
• Channel 调用 ReceivedBunch (不同的 Channel 会各自重写该接口)
• ControlChannel 收到 Message 后调用 NotifyControlMessage 进行广播，执行回调，其中 Server 登录流程相关的最主要的就是 UWorld::NotifyControlMessage 接口

2.5.2 Client

Client 端登录过程中主要处理 ControlMessage 的接口为 UPendingNetGame::NotifyControlMessage

2.6 登录，加载地图，创建 PlayerController

• Server 端收到 NMT_Hello 后，会回复 NMT_Challenge
• Client 收到 NMT_Challenge 后，整合玩家数据 NickName，PlayerId 等，发送 NMT_Login
• Server 收到 NMT_Login：
  • 设置 Connection 的 PlayerId
  • 调用 GameMode::PreLogin，这里我们也可以定义自己的 PreLogin，来加一些 Token 校验之类的确定是否让玩家进入游戏。
  • 返回 NMT_Welcome，同时会设置 LevelName，这样客户端就可以知道连接什么地图。
• Client 收到 NMT_Welcome：
  • 设置地图路径，在 UPendingNetGame 的 URL 中，UEngine::TickWorldTravel 会一直轮询 UPendingNetGame 的地图 URL
  • Travel 到目标地图
  • 返回 NMT_NetSpeed 表示成功连接
• Server 收到 NMT_NetSpeed，没有什么特殊操作，只是简单设置下 NetSpeed
• Client 加载地图完毕，发送 NMT_Join。UPendingNetGame::LoadMapCompleted -> UPendingNetGame::SendJoin

  

• Server 收到 NMT_Join：
  • 如果对应的 Connection 没有 PlayerController 则创建一个
  • 触发 AGameModeBase::Login
  • 如果当前 World 的 Map 是 Transition 的或者在一个错误的 World，则也通知 Client 再次进行 Travel
    总体流程图如下：

    

3. 总结

个人将 UE 中，Client 和 Server 建立连接到进入游戏中的过程分为了 2 步：

1. 建立一个 UDP 连接（其实 UDP 没有连接的概念），并且在 Server 和 Client 都维护一个 UNetConnection
2. 利用 Control Message 和 Control Channel 进行通信，进入游戏，执行 GameMode 的登录，加载地图，创建 PlayerController 等跟 Gameplay 密切相关的操作