云计算

服务器通信

2019-02-16  本文已影响58人  JunChow520

服务器S和客户端C仅仅是角色

image.png

CS通信

CS的连接方式是使用socket建立连接来进行数据交互，数据交互的过程分为：

  1. Server创建socket，监听（listen）特定端口（ip+port）
  2. Client创建socket，连接到Server监听的端口
  3. Server接收Client连接，创建socket与之进行通信
  4. Client和Server进行数据交互
  5. Client和Server断开连接回收资源
网页访问的数据交互

传输协议

案例分析

PC上QQ的CS交互

手机上微信的CS交互（有钱了）

应用层协议

数据包格式

UDP的分包

假设每个分片丢包概率为10%，每个数据包有3次重发的逻辑。 如果发送一个10K数据包，成功的概率是多少呢？如果发送10个1K的数据包，全部成功的概率是多少呢？

UDP的分片MTU为1480，由于还包含8字节的包头，实际上应该是1472。

10K的数据可以划分为7个分片，单次成功概率为90%^7=47.8%。 再经过3次重发修正，最终成功概率为(1-47.8%)^3=86%。

10个1K的数据包相当于10个分片，单包成功概率（1-10%）^3=99.9%。 最终全部成功的概率为99.9%^10=99.9%。

虽然成功的概率相差不大，但是失败的概率却相差了14倍。 另外UDP中不要让单个包的数据量超过1K。

设计CS交互时的问题

case1: 客户端收到的数值总是跟服务器对不上
可能是字节序问题，有的不同CPU在不同的OS上字节序可能不同， 可通过字节序转换来解决。
在将数据发送到网络前，会对数据包做一次字节序转换，转换成网络字节序，网络字节序是一个BIG ENDING的。

case2: 服务器下发的小包数据，客户端常常延迟一段时间才收到。

服务器下发的小包数据 客户端常常会延迟一段时间才收到，一般会延迟200ms。网络良好时发送大包时经常隔个十几毫秒就收到了。原因是nagle算法延迟导致小包延迟发送，nagle算法是小包不是立即发送而是先缓存起来，等其他包过来时再一起发送，或者等超时才发送。 在一些延迟比较敏感的应用中， 可以禁用nagle算法。

case3: 实时交互中数据量较大或网络波动较大时容易发送失败

实时交互中数据量较大或网络抖动比较厉害， 例如平常单个玩家在地图上跑来跑去或打个怪什么的，这时数据量是很小的。但如果几百个玩家聚集在一起，每个人动一下或喊一声话，那数据量会瞬间变得非常大， 此时发送的数据超过接收容量， 导致发送的缓冲区爆满，传输速度变慢。此时会导致客户端断掉等各种问题，解决的方案是适当地发送缓冲加大一点儿。注意的是适当地加大 ，一般是1M或2M左右。

要点

为什么要使用非阻塞的IO呢？为什么要把socket设计成non-blocking呢。因为一个服务器是为好多个客户当一起去服务的，如果使用阻塞IO的话，客户端发送一个数据过来，那么数据库就会直接卡在那里了。如果在客户端没有上行的数据的时候， 服务器一直处于等待状态，后续操作无法进行。而非阻塞IO是如果receive没有的话服务器会马上返回。

多路复用主要是检测文件与描述符的状态变化， 用于提高运行效率。不用针对每个描述符 ，例如很多个socket，不用去一个个去检查。 而是可以采取各种方式
（select、poll、epoll）找出里面那些有状态变化了，有数据来了或者可以继续给它追加数据了。

服务器上的通信方式

服务器上的通信方式

从客户端client这边来说，它看到的可能就只有一个接入服务器，它并不知道后面有一个很庞大的服务器组。
在简化的游戏服务器架构中，有一个连接服务器、一个世界服务器以及很多个scene，以及其他的logicsvr等。这些服务器之间有什么特点呢？有的服务器是在同一个物理机上的，也有可能在不同物理机上 ，所以它们的交互方式会更为多样一点儿。

服务器之间SS的连接方式

UDP协议使用时数据包不要定太大一般不要超过1K，而在进程间通信一般在内网环境中，是可以超过这个MTU设定值的。这样的话，不用在协议层去做分包逻辑。UDP本身包的最大限制是64KB，还需要剪掉一个IP包头，再减去一个UDP包头，减下来也就不到64KB了。

用户登录老是登录不上，或者登陆上去后，玩一下就会断掉，会是什么原因呢？

上一篇下一篇

猜你喜欢

热点阅读