服务器设计:原则综述:

通用服务器框架:游戏,网络交易,通讯框架,聚焦在业务逻辑上;

收发包:格式问题提出;

例子:第一条命令出拳【1abc2】,第二条命令加血【1def2|30】

【1abc2|1def2|30】两条命令在一起了怎么服务器解决粘包问题

粘包: TCP粘包问题

client发送 send(“abc”) send(“def”) send(“hij”)

服务器端粘包问题:不管你客户端是否粘包,服务器端都会存在粘包问题

服务器两次recv的间隔可能在100毫秒,在这100毫秒内客户端发送的这三个包都会收到,保存到服务器端的读缓冲区,你recv的时候可能拿到了全部“abcdefhij”

当你发送很多数据时,服务器一次性拿不完send(“abc。。。。。”)//8000字节,可能被操作系统拆成6个包发送过去

网络出现延迟或者阻塞:“ab” “c。。”“。。de。。”缺包;

TCP粘包、缺包解决

面试经常考:

解决粘包的方案很多:严谨,有效的一种解决方案

(我们要考虑恶意数据包):不能只用什么分割符号来分割数据包,因为客户端会伪造可能会发一些没有分割符号的数据包;

如何解决拆包问题:给收发的数据包定义个统一的格式;c、s都按照这个格式来就能解决粘包问题;

包格式:用包头包体的格式,

结构:

包头是固定长度(10字节),在包头中有一个成员变量会记录整个包(包头加包体)的长度

原理:

1.这样的话,先收包头,从包头中知道了整个包的长度,然后整个包的长度-10个字节(包头的固定长度)=包体的长度

2.然后我在收包体的长度这么多的字节,收满了包体的长度的字节数,我就认为,一个完成的数据包收完了

收包总结:

1.先收固定包头10字节

2.收满后,根据包头的内容,计算出包体的长度:整个长度-10

3.我再收包体的字节数据,收完了,一个包就解决了

我们就认为收到了一个完整的数据包,从而解决了粘包的问题;

官方nginx专用 web服务器,我们的是通用的服务器;

可以应用各种领域,不太适合web服务器;需要固定格式;

收包解包实战:

收包 包头结构:

发包:采用包头加包体的结构,包头记录了整个包的(包头+包体)的长度;

我们定义一个包的长度的不能超过30000,必须要有最大值,以防伪造的大数据包卡住我们

在网络通讯的时候,我们会有结构的内存对齐问题,有可能你发送的8数据的字节数在对端被成了16字节,这不乱套了,那么我们要同意给成内存紧挨着的,而不是让系统在传输中用空白内存补齐对齐

收包状态宏定义

//收包:粘包,缺包

//收包思路:先收包头→根据包头中的内容确定包体的长度并接受包体,收包状态(状态机)

定义四种收包的状态;

从连接池获取一个连接的时候,把状态设置为收包头

收包实战代码

聚焦在ngxwait_request_handler()函数;

同时设置好各种收包状态

服务器按照包头加包体的格式收包

引入消息头用来记录额外信息

服务器收包时,收到:包头加包体,我在额外附加一个消息头→

消息头+包头+包体

再介绍一个分配和释放内存类的Cmemory

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部