在 socket 网络编程中，都是端到端通信，由客户端端口 + 服务端端口 + 客户端 IP+ 服务端 IP+ 传输协定组成的五元组能够明确的标识一条连贯。在 TCP 的 socket 编程中，发送端和接收端都有成对的 socket。发送端为了将多个发往接收端的包，更加高效的的发给接收端，于是采纳了优化算法（Nagle 算法），将屡次距离较小、数据量较小的数据，合并成一个数据量大的数据块，而后进行封包。那么这样一来，接收端就必须应用高效迷信的拆包机制来分辨这些数据。
1.Q：什么是 TCP 粘包问题？
TCP 粘包就是指发送方发送的若干包数据达到接管方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，呈现粘包的起因是多方面的，可能是来自发送方，也可能是来自接管方。
2.Q：造成 TCP 粘包的起因
（1）发送方起因
TCP 默认应用 Nagle 算法（次要作用：缩小网络中报文段的数量），而 Nagle 算法次要做两件事：
只有上一个分组失去确认，才会发送下一个分组
收集多个小分组，在一个确认到来时一起发送
Nagle 算法造成了发送方可能会呈现粘包问题
（2）接管方起因
TCP 接管到数据包时，并不会马上交到应用层进行解决，或者说应用层并不会立刻解决。实际上，TCP 将接管到的数据包保留在接管缓存里，而后应用程序被动从缓存读取收到的分组。这样一来，如果 TCP 接管数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
3.Q：什么时候须要解决粘包景象？
如果发送方发送的多组数据原本就是同一块数据的不同局部，比如说一个文件被分成多个局部发送，这时当然不须要解决粘包景象
如果多个分组毫不相干，甚至是并列关系，那么这个时候就肯定要解决粘包景象了
4.Q：如何解决粘包景象？
（1）发送方
对于发送方造成的粘包问题，能够通过敞开 Nagle 算法来解决，应用 TCP_NODELAY 选项来敞开算法。
（2）接管方
接管方没有方法来解决粘包景象，只能将问题交给应用层来解决。
（2）应用层
应用层的解决办法简略可行，不仅能解决接管方的粘包问题，还能够解决发送方的粘包问题。
解决办法：循环解决，应用程序从接管缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被解决实现，然而如何判断每条数据的长度呢？
格式化数据：每条数据有固定的格局（开始符，结束符），这种办法简单易行，然而抉择开始符和结束符时肯定要确保每条数据的外部不蕴含开始符和结束符。
发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前 4 位是数据的长度，应用层在解决时能够依据长度来判断每个分组的开始和完结地位。
5.Q：UDP 会不会产生粘包问题呢？
TCP 为了保障牢靠传输并缩小额定的开销（每次发包都要验证），采纳了基于流的传输，基于流的传输不认为音讯是一条一条的，是无爱护音讯边界的（爱护音讯边界：指传输协定把数据当做一条独立的音讯在网上传输，接收端一次只能承受一条独立的音讯）。
UDP 则是面向音讯传输的，是有爱护音讯边界的，接管方一次只承受一条独立的信息，所以不存在粘包问题。
举个例子：有三个数据包，大小别离为 2k、4k、6k，如果采纳 UDP 发送的话，不论接受方的接管缓存有多大，咱们必须要进行至多三次以上的发送能力把数据包发送完，然而应用 TCP 协定发送的话，咱们只须要接受方的接管缓存有 12k 的大小，就能够一次把这 3 个数据包全副发送结束。
————————————————
版权申明：本文为 CSDN 博主「渔溪大王」的原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接及本申明。
原文链接：https://blog.csdn.net/weixin_…