粘包问题:
所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。
两种情况下会发生粘包。
- 发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会合到一起，产生粘包）
- 接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
只有tcp协议才会发送粘包,udp不会发生
EX: 发送端发送数据,接收端不知道应该如何去接收,造成的一种数据混乱的现象
在tcp协议中,
有一个合包机制(nagle算法): 将多次连续发送且间隔较小的数据,进行打包成一块数据传送.
还有一个机制是拆包机制: 在发送端,因为受到网卡的MTU限制,会将大的超过MTU限制的数据,进行拆分,拆分成多个小的数据,进行传输. 当传输到目标主机的操作系统层时,会重新将多个小的数据合并成原本的数据
针对使用udp协议发送数据,一次收发大小究竟多少合适?
num < 1472 是比较理想的状态
udp不会发生粘包,udp协议本层对一次收发数据大小的限制是:
65535 - ip包头(20) - udp包头(8) = 65507
站在数据链路层,因为网卡的MTU一般被限制在了1500,
所以对于数据链路层来说,一次收发数据的大小被限制在 1500 - ip包头(20) - udp包头(8) = 1472
得到结论:
如果sendto(num)
num > 65507 报错
1472 < num < 65507 会在数据链路层拆包,而udp本身就是不可靠协议,所以一旦拆包之后,造成的多个小数据包在网络传输中,如果丢任何一个,那么此次数据传输失败
num < 1472 是比较理想的状态
使用struct解决黏包
借助struct模块，我们知道长度数字可以被转换成一个标准大小的4字节数字。因此可以利用这个特点来预先发送数据长度。
我们还可以把报头做成字典，字典里包含将要发送的真实数据的详细信息，然后json序列化，然后用struck将序列化后的数据长度打包成4个字节（4个自己足够用了）
