2.1.1.1 核心特性#

• 面向连接：数据传输前需通过“三次握手”建立连接，传输完成后通过“四次挥手”释放连接，确保通信双方状态同步。

• 可靠传输：采用确认重传机制，接收方收到数据后会向发送方反馈确认信息，若发送方超时未收到确认，则重传数据；同时保证数据按发送顺序到达，避免乱序。

• 流量控制与拥塞控制：通过滑动窗口机制控制发送方数据发送速率，避免接收方过载；当网络拥堵时，自动降低发送速率，减少数据包丢失。

• 数据分段：自动将大于MTU（最大传输单元）的数据包拆分，接收方自动重组，无需应用层额外处理。

2.1.1.2 适用场景#

适用于对数据可靠性要求高、实时性要求中等的游戏场景，核心是确保关键数据不丢失、不紊乱，具体包括：

• 回合制游戏（如《梦幻西游》《三国杀》）：回合间数据交互量小，对实时性要求低，需确保玩家操作指令、回合结果等关键数据可靠传输。

• MMO游戏非战斗场景（如《魔兽世界》）：角色登录、道具交易、聊天信息、任务提交等，这些数据一旦丢失会影响游戏体验，需可靠传输。

• 游戏资源下载（如更新包、自定义地图）：大文件传输需确保完整性，TCP的可靠传输的分段机制可避免文件损坏。

2.1.1.3 优缺点#

优点：数据传输可靠、有序，无需应用层额外处理重传、排序问题，开发成本低；支持大文件传输，适配多种网络环境。

缺点：连接建立和释放耗时，协议开销大（TCP头部+IP头部共40字节）；重传机制会导致延迟增加，网络拥堵时延迟波动大，不适用于实时性要求极高的场景（如FPS游戏战斗）。

2.1.1.4 游戏应用案例#

《英雄联盟》非战斗场景：玩家登录、英雄选择、战绩查询等功能采用TCP协议，确保账号信息、英雄数据等关键数据可靠传输；战斗场景则结合UDP协议优化实时性。

《绝地求生》资源下载：新玩家加入游戏时，通过TCP协议下载自定义地图、资源包等，确保资源完整性，避免因资源缺失导致游戏异常。

2.1.2.1 核心特性#

• 无连接：无需建立连接即可直接发送数据，发送方无需等待接收方确认，传输效率高。

• 不可靠传输：不保证数据到达、不保证数据顺序，无重传机制，数据包丢失后需应用层自行处理。

• 低开销：UDP头部仅8字节，远小于TCP，数据传输延迟低，适合高频次、小数据包传输。

• 无拥塞控制：发送速率由应用层决定，不受网络拥堵影响，可保证实时性，但可能加剧网络拥堵。

2.1.2.2 适用场景#

适用于对实时性要求极高、数据可容忍少量丢失的游戏场景，核心是降低延迟，具体包括：

• 实时竞技游戏（如《CS》《王者荣耀》《绝地求生》）：玩家移动、技能释放、攻击等实时操作，需高频次传输小数据包，少量丢包可通过客户端预测、服务器校正弥补，不会明显影响体验。

• 游戏实时状态同步（如FPS游戏玩家位置、角度）：这类数据更新频繁，即使少量丢包，后续数据包可覆盖旧数据，无需重传。

• 语音聊天（如游戏内组队语音）：语音数据对实时性要求高，少量丢包仅导致短暂杂音，比延迟更易被接受。

2.1.2.3 优缺点#

优点：延迟低、协议开销小，适合高频次、小数据包传输，能满足实时竞技游戏的核心需求；无连接特性可支持大量并发连接。

缺点：数据不可靠、无序，需应用层自行实现重传、排序、校验等机制，开发成本高；无拥塞控制，网络拥堵时易出现大量丢包，影响游戏体验。

2.1.2.4 游戏应用案例#

《王者荣耀》战斗场景：玩家移动、技能释放、普攻等操作通过UDP协议传输，每帧高频发送小数据包，确保操作响应延迟在100ms以内；同时在应用层实现关键操作重传机制，避免核心指令丢失。

《传送门2》实时互动：游戏通过UDP协议传输玩家操作数据，结合数据压缩和预测性同步技术，减少传输开销，保证全球玩家互动的流畅性。

2.1.3.1 核心特性#

ICMP是IP协议的辅助协议，不用于传输游戏业务数据，主要用于网络状态检测和错误反馈，核心功能包括回声请求与响应（ping命令）、错误通知（如目标不可达、超时）等。

其数据包包含校验和、标识符、顺序号等字段，校验和用于确保数据包完整性，标识符和顺序号用于匹配回声请求与响应，便于计算往返延迟。

2.1.3.2 适用场景#

网络游戏中主要用于服务器延迟检测，即玩家登录时，客户端通过发送ICMP回声请求包，测量与各个游戏服务器的往返时间（延迟），自动选择延迟最低的服务器连接，提升玩家体验。

2.1.3.3 游戏应用案例#

多数网络游戏（如《英雄联盟》《绝地求生》）的服务器选择界面，会显示各个服务器的延迟，其数据来源就是ICMP协议的回声请求与响应机制，通过多次发送请求取平均值，确保延迟数据准确。

2.2.1.1 核心特性#

游戏开发中最常用的应用层协议，基于二进制格式封装数据，结构灵活，可根据游戏需求自定义字段，核心结构包括消息头和消息体：

• 消息头：包含魔数（验证数据包有效性）、协议版本、消息ID（区分不同业务指令）、序列号（用于乱序处理和丢包检测）、消息体长度、校验和（防止数据篡改）、时间戳等字段。

• 消息体：存储具体业务数据（如玩家ID、操作指令、角色状态等），采用二进制编码，体积小、解析效率高。

2.2.1.2 适用场景#

适用于各类网络游戏，尤其是对传输效率、数据安全性要求高的场景，可灵活适配状态同步、帧同步等不同同步模式，是绝大多数端游、手游的首选应用层协议。

2.2.1.3 优缺点#

优点：数据体积小、解析速度快，传输效率高；结构灵活，可根据游戏业务需求定制，适配不同同步模式；二进制格式不易被篡改，安全性较高。

缺点：开发成本高，需自行定义协议结构、序列化/反序列化逻辑；可读性差，调试难度大，需专用工具解析数据包。

2.2.1.4 协议示例（状态同步指令）#

以玩家移动指令为例，协议结构如下（二进制格式）：

• 消息头（20字节）：魔数（2字节）+ 协议版本（2字节）+ 消息ID（4字节，如0x00010001表示玩家移动）+ 序列号（4字节）+ 消息体长度（4字节）+ 校验和（4字节）。

• 消息体（16字节）：玩家ID（4字节）+ 目标X坐标（4字节）+ 目标Y坐标（4字节）+ 移动速度（4字节）。

2.2.2.1 核心特性#

基于TCP协议的全双工通信协议，通过一次HTTP升级请求（Upgrade: websocket）完成握手，之后切换至二进制或文本帧传输模式，摆脱传统HTTP请求-响应模型的限制，实现客户端与服务器的持久化双向通信。

核心优势是低开销、实时性强，支持心跳机制（Ping/Pong）维持连接，可灵活传输文本（JSON）或二进制数据，适配高并发场景。

2.2.2.2 适用场景#

• 网页游戏（如《三国杀Online》网页版）：无需安装客户端，通过浏览器即可实现实时通信，WebSocket可满足游戏内聊天、操作指令传输等需求。

• 跨平台游戏（端游、手游、网页端互通）：WebSocket协议兼容性强，可统一各平台的通信方式，降低开发成本。

• 轻量级实时互动场景（如游戏内排行榜更新、邮件通知）：无需高频传输大量数据，WebSocket的持久化连接可减少连接开销。

2.2.2.3 优缺点#

优点：全双工通信，实时性强；协议开销低，摆脱HTTP长轮询的频繁连接开销；兼容性强，支持多平台、多浏览器；可灵活传输文本或二进制数据。

缺点：基于TCP协议，延迟高于UDP，不适用于实时竞技类游戏的核心战斗场景；面对海量并发连接时，需依赖服务器架构优化（如协程、负载均衡）。

2.2.2.4 游戏应用案例#

StackTiger在线游戏系统：基于WebSocket协议构建，采用Go语言开发，通过WebSocket实现玩家操作指令传输、游戏状态广播、排行榜更新等功能，支持大量并发连接，借助心跳机制维持连接稳定性，同时采用二进制序列化提升传输效率。

《堡垒之夜》网页版：通过WebSocket协议实现玩家与服务器的实时通信，处理角色操作、物品拾取等指令，结合HTTP协议完成资源下载，兼顾实时性与兼容性。

2.2.3.1 核心特性#

HTTP是基于TCP的无状态请求-响应协议，通过URL定位资源，采用文本格式传输数据；HTTPS是HTTP的加密版本，通过SSL/TLS协议实现数据加密，确保传输安全。

核心特点是无状态、简单易用，支持GET（获取资源）、POST（提交数据）等请求方式，无需持久化连接，适合非实时性数据传输。

2.2.3.2 适用场景#

网络游戏中仅用于非实时性场景，不用于核心战斗、实时操作等高频交互场景，具体包括：

• 游戏登录验证（如账号密码校验、Token验证）：通过HTTPS协议提交登录信息，确保账号安全。

• 游戏配置更新（如服务器列表、活动配置）：通过GET请求获取最新配置文件，无需实时同步。

• 玩家数据查询（如战绩、排行榜、背包信息）：通过HTTP请求获取非实时更新的数据。

2.2.3.3 优缺点#

优点：开发简单、兼容性强，无需自定义协议；HTTPS可实现数据加密，安全性高；适合传输非实时性、小体积数据。

缺点：无状态，每次请求需重新建立连接，开销大；请求-响应模式无法实现实时双向通信，延迟高，不适用于实时交互场景。

2.2.4.1 核心特性#

并非独立的通信协议，而是用于游戏数据序列化/反序列化的工具，常与TCP/UDP、自定义二进制协议结合使用，解决数据传输中的格式统一、体积优化问题。

• Protobuf（Protocol Buffers）：由Google开发，采用二进制编码，数据体积小、解析效率高，支持跨语言、可扩展，可自定义消息结构，适合传输复杂游戏数据（如角色状态、场景信息）。

• FlatBuffers：由Google开发，采用零拷贝技术，解析时无需反序列化整个数据包，直接访问所需字段，延迟更低，适合实时性要求极高的场景（如FPS游戏帧同步）。

2.2.4.2 适用场景#

适用于各类网络游戏的数据传输，尤其是数据结构复杂、传输频繁的场景：

• Protobuf：MMO游戏角色状态同步、任务数据传输、道具信息同步等，如《魔兽世界》中角色属性、装备数据的传输。

• FlatBuffers：实时竞技游戏帧同步、高频状态更新，如《CS》玩家位置、武器状态的实时传输。

2.2.4.3 优缺点#

优点：数据体积小，传输效率高；解析速度快，支持跨语言（C++、Java、Python等）；可扩展性强，便于游戏版本迭代时新增数据字段，无需修改旧协议。

缺点：需提前定义消息结构，开发成本略高；可读性差，调试需专用工具。

2.2.4.4 协议示例（Protobuf定义）#

玩家操作指令的Protobuf定义：

1
// 操作指令消息定义
2
message PlayerAction {
3
  int32 player_id = 1; // 玩家ID
4
  ActionType action = 2; // 操作类型（移动、攻击、技能等）
5
  int64 timestamp = 3; // 客户端时间戳
6
  bytes action_data = 4; // 操作具体数据（如移动坐标、技能ID）
7
  uint32 sequence = 5; // 序列号，用于乱序处理和丢包检测
8
}
9

10
// 移动操作的具体数据
11
message MoveAction {
12
  float target_x = 1; // 目标X坐标
13
  float target_y = 2; // 目标Y坐标
14
  float target_z = 3; // 目标Z坐标（3D游戏）
15
  float speed = 4; // 移动速度
16
}