Socket/TCP粘包、断包

TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。即面向流的通信是无消息保护边界的。

UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。不会使用块的合并优化算法， 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。即面向消息的通信是有消息保护边界的。

由于TCP无消息保护边界, 需要在消息接收端处理消息边界问题。

粘包的原因

发送端需要等缓冲区满才发送出去，造成粘包

接收方不及时接收缓冲区的包，造成多个包接收

断包的原因

以太网中存在一个对于帧的有效数据大小的限制，即MTU，以太网的MTU为1500字节。所谓断包就是说发送端一次发送的消息长度过大，如果超过了MTU，那么ip会对其进行分片，导致接收端接收到消息后，无法确定是否是一个完整的消息。

粘包/断包的解决思路

粘包/断包问题的最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪。

通过使用某种方案给出边界，例如：

发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息；

包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界；

包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体；

使用更加复杂的应用层协议。