服务器通信

  • 互联网应用中各个组成部分的协作方式
  • 客户端与服务端通信方式
  • 服务器之间通信方式
  • 工程实践中的问题和解决方案

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

4933701-0cd569b61cda8658.png
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断开连接回收资源
4933701-69541ca1e50ab061.png
网页访问的数据交互

传输协议

  • UDP 可靠性要求不高、小数据量、性能更佳
  • TCP 可靠、适合大数据量、频繁交互的

案例分析

PC上QQ的CS交互

  • 一般情况下 UDP
  • 网络情况差 TCP
  • 拉去图片等大文件 TCP

手机上微信的CS交互(有钱了)

  • 前台运行时:TCP长连接
  • 后台运行时:TCP短链接
  • 查看文章等:HTTP(TCP短链接)

应用层协议

  • 从传输层拿到的原始数据,应该如何使用?
  • 字符串
  • 自定义
  • protobuf
  • 序列化和反序列化
4933701-7447bdf1b4788d9b.png
数据包格式

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)找出里面那些有状态变化了,有数据来了或者可以继续给它追加数据了。

服务器上的通信方式

4933701-031da75cf621f8c7.png
服务器上的通信方式

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

服务器之间SS的连接方式

  • TCP:最为常用
  • UDP:非关键数据上报(如在线)、日志服务
  • 非socket通信
    进程间通信除了socket之外还有管道pipe、signal、shm、message queue、file。

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

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

  • 最有可能是网路状况不佳
  • 连接错了接入服务器
    国内的网络环境比较特殊,存在多个网络运营商,而且运营商之间的交互式比较差的,有可能是一个电信的用户连入了联通的一个接入点,就会出现经常卡顿或断线等各种问题。
  • 服务器的网路故障
    如网卡烧掉了或网线弄断了
  • 数据同步量太大
  • 服务器卡顿
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值