TCP粘包问题

TCP和UDP关于粘包问题的讨论

UDP不存在粘包问题，因为UDP是数据报传输，每一个消息都是独立的。但也有不足之处，当数据量发送较小时，就会发生数据包有效载荷较小的情况，也会增加多次发送数据的系统发送开销和接收开销。

因此，设置一个较为合适的UDP数据包的包长就很重要了，UDP的最大载荷为1472，最好每次传输接近这个数据的数据量，比较适合视频、音频等大块数据的发送。同时，通过减少握手来保证流媒体的实时性。

TCP为了保证可靠运输，尽量减少额外开销，因此采用了字节流传输，减少了发送包的数量，从而减少了额外开销。但是对于数据传输较为频繁的程序来说，使用TCP可能导致粘包问题。

什么是TCP粘包？

TCP粘包是指发送方发送的数据到接收方接收时粘成一包。从接收缓冲区看，后一包的数据的头部紧接着前一包数据的尾部，使得接收方不能准确的读取一包数据，接收方多读或少读一包数据所造成的现象。

为什么会出现粘包？

粘包可能是发送方需要等待缓冲区满之后才发送数据造成粘包，也可能是接收方来不及接收缓冲区的包，造成多个包一起接收的现象。TCP粘包可能是发送方导致的，也可能是接收方导致的。

1.发送方引起的粘包

由TCP协议本身造成的，TCP为了提高传输效率，发送方一般会收集到足够多的数据然后一次性发送，若连续几次发送的数据都很少，接收方就接收到了粘包数据。

2.接收方引起的粘包

由于接收方用户进程不及时接收数据，从而导致粘包问题。

HTTP中避免粘包问题的方法：

1. 固定的读取数据方式，按行读取。
2. 以空行来区分报头结束，即以回车换行符作为分隔符。
3. 报头中包含Content-Length字段，标记消息正文的大小。

由HTTP的启发，我们的方案如下：

1. 发送方将数据结构化，接收方按照该结构来读取。
2. 添加分割符，来标记每一数据的起始和结束。
3. 发送方在发送数据时，将数据正文的大小也一并发给接收方，接收方接收到数据时，将消息解析出来，按照正文的大小读取数据。