介绍

本网关是一个游戏用网关，它负责客户端和服务端之间的消息转发。

通过网关，我们预期达到以下目的：

• 减少暴露在公网的服务器
• 提升网络故障转移的效率
• 复用客户端网络连接
• 使服务端主动连接客户端成为可能
• 不修改服务端的情况下引入断线重连机制和加密机制

说明

图1 - 拓扑结构

基本逻辑：

• 每个系统允许部署任意个网关
• 每个网关启动时守护对外和对内两个网络端口
• 游戏服务端启动时主动连接到所有网关的对内端口，并告知网关自己的ID
• 新的客户端连接产生时，随机连接到一个网关的对外端口
• 客户端使用服务端ID来建立虚拟连接，每个客户端可以建立多个虚拟连接
• 网关为每个虚拟连接分配一个ID，并告知服务端有一个新的虚拟连接产生
• 客户端和服务端拿到虚拟连接ID之后即可使用此虚拟连接进行后续通讯
• 通讯过程中通过在消息头部附加虚拟连接ID来告知网关此消息的去处
• 服务端在已知客户端连接ID的情况下，可以主动连接客户端

设计意图和实现细节：

• 允许部署任意个网关的目的是实现负载均和防单点故障
• 网关可以开启reuseport特性，提升多核利用率
• 由服务端主动连接网关目的是倒置依赖性，降低网关复杂度，网关服务注册和发现由用户自定义
• 客户端具体如何连接到网关可以由用户自定义，可以是根据负载情况或地域分配等
• 为防止恶意攻击，网关可以限制每个客户端虚拟连接数
• 网关运用零拷贝和内存池来提升消息处理效率
• 服务端主动连接客户端时，客户端连接ID可以是RPC获取或Redis存储，具体实现由用户自定义

网关

本网关提供了一个命令行程序用来对外提供服务，命令行支持以下参数：

网关相关参数：

客户端相关参数：

服务端相关参数：

命令行程序启动时会自动把当前进程ID记录到fastway.pid，并且监听SIGTERM和SIGINT。

当网关以前台模式运行时，可以用Ctrl + C安全退出网关进程。

网关可以使用docker、nohup、start-stop-daemon来做后台运行。

以nohup为例，可以这样启动网关，并把日志输入重定向到文件中：

nohup fastway 1>fastway.out 2>fastway.err &

网关的日志输出可以使用logrotate做自动分卷。

当网关以后台模式运行时，可以使用以下命令安全退出网关进程：

kill `cat fastway.pid`

此外，还可以对网关进程发送指令来获取网关的运行状态。

以开始cpuprof为例，可以通过以下方式开启：

echo "cpuprof start" > fastway.cmd && kill -SIGUSR1 `cat fastway.pid`

当网关进程收到SIGUSR1信号时，将读取fastway.cmd文件的内容作为指令执行。

网关指令通过cmd包实现，可以自行扩展自定义的指令。

网关支持的完整指令：

API

本网关目前支持以下编程语言的调用：

• Go版
• C#版

通讯协议

客户端和服务端均采用相同的协议格式与网关进行通讯，消息由4个字节包长度信息和变长的包体组成：

+--------+--------+
| Length | Packet |
+--------+--------+
  4 byte   Length

每个消息的包体可以再分解为4个字节的虚拟连接ID和变长的消息内容两部分：

+---------+-------------+
| Conn ID |   Message   |
+---------+-------------+
   4 byte    Length - 4

Conn ID是虚拟连接的唯一标识，网关通过识别Conn ID来转发消息。

当Conn ID为0时，Message的内容被网关进一步解析并作为指令进行处理。

网关指令固定以一个字节的指令类型字段开头，指令参数根据指令类型而定：

+--------+------------------+
|  Type  |       Args       |
+--------+------------------+
  1 byte    Length - 4 - 1

目前支持的指令如下：

特殊说明：

• 协议允许客户端主动连接服务端，也允许服务端主动连接客户端。
• 新建虚拟连接的时候，网关会把虚拟连接信息发送给两端。
• 客户端连接服务端时：
  • 网关回发的Accept指令中RemoteID为服务端ID
  • 发送给服务端的Connect指令中RemoteID为客户端ID。
• 服务端连接客户端时：
  • 网关回发的Accept指令中RemoteID为客户端ID
  • 发送给客户端的Connect指令中RemoteID为服务端ID。

握手协议

服务端在连接网关时需要先进行握手来验证服务端的合法性。

握手过程如下：

0. 合法的服务端应持有正确的网关秘钥。
1. 网关在接受到新的服务端连接之后，向新连接发送一个uint64范围内的随机数作为挑战码。
2. 服务端收到挑战码后，拿出秘钥，计算 MD5(挑战码 + 秘钥)，得到验证码。
3. 服务端将验证码和自身节点ID一起发送给网关。
4. 网关收到消息后同样计算 MD5(挑战码 + 秘钥)，跟收到的验证码比对是否一致。
5. 验证码比对一致，网关将新连接登记为对应节点ID的连接。

握手下行数据格式：

+----------------+
| Challenge Code |
+----------------+
      8 byte

握手上行数据格式：

+-----------+----------+
|    MD5    | ServerID |
+-----------+----------+
   16 byte     4 byte

协议示例

客户端请求网关创建虚拟连接到服务端：

+------------+------------+---------+--------------+
| Length = 9 | ConnID = 0 | CMD = 0 | ServerID = 1 |
+------------+------------+---------+--------------+
    4 byte       4 byte      1 byte      4 byte

网关响应虚拟连接创建请求：

+-------------+------------+---------+---------------+--------------+
| Length = 13 | ConnID = 0 | CMD = 1 | ConnID = 9527 | ServerID = 1 |
+-------------+------------+---------+---------------+--------------+
    4 byte        4 byte      1 byte       4 byte         4 byte

网关告知服务端有新的虚拟连接：

+-------------+------------+---------+---------------+--------------+
| Length = 13 | ConnID = 0 | CMD = 2 | ConnID = 9527 | ServerID = 1 |
+-------------+------------+---------+---------------+--------------+
    4 byte        4 byte      1 byte       4 byte         4 byte

客户端通过虚拟连接发送"Hello"到服务端：

+------------+---------------+-------------------+
| Length = 9 | ConnID = 9527 | Message = "Hello" |
+------------+---------------+-------------------+
    4 byte        4 byte            5 byte

客户端关闭虚拟连接：

+------------+------------+---------+---------------+
| Length = 9 | ConnID = 0 | CMD = 5 | ConnID = 9527 |
+------------+------------+---------+---------------+
    4 byte       4 byte      1 byte      4 byte

相关资料

• 通讯协议代码生成
• slab算法的内存池
• 支持断线重连和加密的流协议
• 用来实现后台进程指令的包
• SO_REUSEPORT学习笔记 by 聂永

参与项目

欢迎提交通过github的issues功能提交反馈或提问。

技术群：474995422