游戏开发那些事——部分安利

部分安利

客户端部分，暂时就写到这里，因为本文主要讲述的是服务器的那些事。

进入服务器部分的分享前，我们先一起来回顾一些做游戏服务器开发所需要的一些基础知识，以方便对后文加深理解。

网络协议

什么是网络协议呢？

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

网络协议等同于需要通讯的个体之间的语言，双方必须能够解析对方的语言，并且能把自己要表达的思想，转换成对方能解析的语言，这样双方才能够进行沟通。在实际表现上，是对网络传输的数据包的规则进行的描述和约定。

C/S公有协议

标题里的C/S是指client,server的简写， 本文中，以后再遇到C均指消息的发送者，S为接收者 ，他们可能一个是客户端，一个是服务端，也可能是两个服务端相互间通讯。

TCP,UDP,HTTP,TELNET,WEBSOCKET,TLSV……等等等等，诸如此类的协议，我都把它们称作公有协议。

下面是一张TCP/IP协议族的图

 

上面图中，各协议到底是什么鬼，请自行学习，不在本文介绍范围。并且理解本文后续内容，仅需要知道协议是什么东西即可。

C/S私有协议

一般而言，所谓的私有协议，是我们利用公有协议，在它们基础上，进一步对数据包进行的描述和约定。

当网络上的C通过TCP/IP协议发了一个完整的数据包给S，那么S怎么知道该数据包多大，每个字节代表的是什么含义呢？

方法很多，下面举几个例子来帮助大家理解：

1. 以特定字节标识结尾，开头指明行为，类似keycode

2. 固定数据包长度，不足补齐

3. 动态长度，数据包长度放在包头

   第一种情况，当S接到数据包后，从里面读取数据，一直读到某字节的值是约定的字节标识停止，当做一个完整的数据包来使用，该特定字节可能是'\n'、'\t'等等。

   第二种情况，C和S就直接约定好，说我们业务不繁琐，干脆简单粗暴点，我发给你的每一个数据包的长度，都是32字节。那么S就可以把收到C发来的数据包，每读32个字节，就当做一个完整的数据包来解析。

   第三种情况就要灵活强大得多了，C和S约定好，每个数据包最初的两个字节，来存放数据包的长度。当S拿到数据后，首先做的就是先读两个字节，来得到数据包的长度，再向后面读到指定长度的字节。

   以上的1，3情况比较常见。

    

协议报文示例——WEBSOCKET

 

只需大体了解，无需细看

1. FIN:1位，用于描述消息是否结束，如果为1则该消息为消息尾部,如果为零则还有后续数据包;
2. RSV1,RSV2,RSV3：各1位，用于扩展定义的,如果没有扩展约定的情况则必须为0
3. OPCODE:4位，用于表示消息接收类型，如果接收到未知的opcode，接收端必须关闭连接。
4. MASK:1位，用于标识PayloadData是否经过掩码处理，客户端发出的数据帧需要进行掩码处理，所以此位是1。数据需要解码。
5. PayloadData的长度：7位，7+16位，7+64位
6. 如果其值在0-125，则是payload的真实长度。
7. 如果值是126，则后面2个字节形成的16位无符号整型数的值是payload的真实长度。
8. 如果值是127，则后面8个字节形成的64位无符号整型数的值是payload的真实长度。

粘包问题

当C想要发数据给S时，发送缓冲区满了，此时，底层会把一个完整的数据包拆成多个数据包发送给S，这时对S而言，接收到的数据包就有多个。可能存在下图的多种情况。

 

上图摘自网上，水印有博客地址，侵权请通知，我来删……

解包、路由

数据包到达了B后，接下来会发生什么情况呢？

一般而言，都会有一个监听进程，通过约定好的协议，讲数据包解开，然后把该数据包丢给指定的处理模块。

关于数据包到达服务器后所发生的事情，有一个程序员的童话：

      有一个大怪物，守在一座山前，山上有很多山洞，每个洞口都有一个小怪兽。大怪物把来到自己面前的人类抓起，甩给身后拥有不繁忙小怪兽的山洞，该小怪兽会把人类进行洗剥干净，然后根据肉质类型，丢给山的另一面的对应的怪兽进行进一步处理。

在很久很久之前，这些都要我们自己搞定。

S通过数据包中解析出两个字节的长度，读取完整的数据包，再读取两个字节的模块ID,再把数据丢给相应的模块，该模块再按照和前端的约定，后面是什么类型的，读取几个自己，代表什么含义,just so so……

后端程序员定好协议，然后写出文档，表明每个字段的类型，丢给前端程序员，前端程序员按照该文档去写封包或者解包代码（有的数据包是服务端发给前端的）

幸运的是，现在我们不这么做了。

---

OK，至此，我们的服务端已经可以接收到我们服务端程序员，需要处理的数据了。