游戏开发—协议设计-CSDN博客

本篇是游戏开发系列第一篇，如若你有兴趣，请持续关注，后期会持续更新。其他文章列表如下:

游戏开发—协议设计

游戏开发—协议-protobuf

游戏开发-协议-protobuf原理详解

通俗地说，协议就是通信双方能够理解的一种数据格式。维基百科这么定义网络协议：

网络协议为计算机网络中进行数据交换而建立的规则、标准或约定的集合。

协议设计包含三要素：

语法：语法是用户数据与控制信息的结构与格式，以及数据出现的顺序。

语义：解释控制信息每个部分的意义。它规定了需要发出何种控制信息，以及完成的动作与做出什么样的响应。

时序：时序是对事件发生顺序的详细说明

也就是说，语义表示要做什么，语法表示要怎么做，时序表示做的顺序。我们要基于此来设计我的协议。

通常游戏有一些特殊性，比如流量要尽量的少，安全性要求更高，以及对平台支持足够多等等。这一切的需求就要求游戏协议设计，尽量简单、通用，以及代码层上易扩展、解析效率足够高等特点。

基于此，我需要从以下几个层次来考虑游戏协议的设计方案。

一、知识图谱

因为知识点比较多，建议先读知识图谱，对整体结构有一个清晰的综括。

二、协议三个层次

应用层

应用层主要是常用是解析方式定义和解析，主要的选型，主要是看你基于什么需求了，适用于实际需求就好。我们常用的协议类型，主要有这两种：文本协议、二进制协议

1、文本协议：

文本协议设计的目的就是方便人们理解，读懂。如常见的http协议，一般的常见http协议如下：

GET/sample.Jsp HTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=test&password=1234复制代码

这种格式非常贴近我们的文字描述，方便阅读，而且目前HTTP也是客户端浏览器或其他程序与Web服务器之间的应用层通信协议，适用非常广泛。但你也看到，有时候基于一个很简单应答，就要带上很多其他的头信息，这对于对流量有要求的游戏应用来说，还是很浪费的。

优点：

1、通用，适用广泛

2、方便理解，可读性好

缺点:

1、基于行读，解析效率一般

2、携带附带信息过多，传输的效率低下

3、无状态，服务器不知道客户端的状态，必须基于客户端的请求来回应，实时性低

4、很难嵌入其他数据，对二进制支持差

如果你的游戏对实时性要求不高，而且对流量要求不也是太高，文本协议也是个不错的方式。一般短连接游戏多适用这个。

2、二进制协议

二进制协议就是一串字节流，是一个典型的Ip协议，一般通常包括消息头(header)和变长的消息体(body)，消息头的长度固定，消息体长度不固定，包含主要的内容主体。一般消息头会包含消息体的长度，这样就能基于头信息从数据流中解析出一个完整的二机制消息了。

一般的格式如下：

我们看到head部分定义包含:

cmd:命令字

sign：验证串

content-leg:消息体长度

HeaderCRC：头验证（不是必须）

其中命令字是双方协议文档中规定好的，比如0x01表示登陆，0x02表示注册等等，这些就是一个命令号。

sign是一个验证字符串，对消息体数据进行一定加密验证，保证数据安全。

content-leg是本次消息体的长度。

body部分，比如我们如下定义:

message:login{

string username;

int64 passwoard;

}

我们看到，因为字段的数据类型有定义，顺序也有定义（第一个是string,第二个是int64），整个二进制流读取的的时候，基于顺序读取就可以很快的取出了。

优点：

1、没有冗余字段，传输高效，耗费流量小

2、解析速度快，基于基础数据类型操作

缺点:

1、可读性差，不利于调试

2、扩展性差，对复杂数据结构支持不够

如果你的游戏，对实时性要求比较高，流量有要求，用二进制比较好，一般大型多人网游，使用二进制协议来设计。

3、数据格式

以上我们看到了两种协议类型，但对于消息体的解析介绍很少，消息体的格式决定了的他的语义和时序，格式不同数据的序列化和反序列化也是不同。比如message:login，你可以基于json来定义，也可以基于xml来定义，定义不同解析方式也各不相同。

一般的消息体格式主要有以下几种:json、protocolBuff、xml、自定义

json

json 是一种轻量级的数据交换格式,互联网应用的很广泛了。常用的框架也很多，推荐fastJson,解析速度还是不错的。json的好处是，开源，格式统一，解析速度也还可以。缺点就是会有一些冗余字符，不够简洁。

protocolBuff

protocolBuff是是google提供的一个开源序列化框架，类似于XML，JSON这样的数据表示语言。但是比这些占用空间都小，没有冗余字段。而且好处是灵活，解析速度快，易于开发（基于配置自动生成代码），可支持语言也比较多。一条消息数据，用protobuf序列化后的大小是json的10分之一，xml格式的20分之一，是二进制序列化的10分之一

xml