服务器设计：原则综述：

通用服务器框架：游戏，网络交易，通讯框架，聚焦在业务逻辑上；

收发包：格式问题提出；

例子：第一条命令出拳【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