阅读量:0
服务器设计：原则综述：
通用服务器框架：游戏，网络交易，通讯框架，聚焦在业务逻辑上；
收发包：格式问题提出；
例子：第一条命令出拳【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
