粘包/拆包问题一直都存在，只是到TCP就拆不动了。-Toy模板网

这篇具有很好参考价值的文章主要介绍了粘包/拆包问题一直都存在，只是到TCP就拆不动了。。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

OSI open-system-Interconnection
TCP/IP 5层协议栈
- 应用层和操作系统的边界是系统调用，对应到网络编程是socket api
TCP/UDP 概况
TCP粘包问题
TCP/IP报头深思

OSI开放系统互联

定义了网络框架，以层为单位实现协议，同时控制权逐层传递。
粘包/拆包问题一直都存在，只是到TCP就拆不动了。

OSI实际并没有落地，TCP/IP 5层协议栈是目前主流的落地实现。

TCP/IP 5层协议栈

TCP/IP协议栈不止是传输层tcp/网络层ip，还包括应用层等，这是一个协议簇，只是因为TCP/IP很具代表性。

不管是OSI还是TCP/IP5层协议栈，均会出现应用程序和操作系统边界(代码执行在用户态/内核态)。

粘包/拆包问题一直都存在，只是到TCP就拆不动了。

边界调用被称为系统调用system call， socket api便是TCP/IP协议栈中应用层的网络编程接口。

TCP/UDP概览

TCP： Transmission Control Protocol是面向连接的，可靠的，基于字节的、双向流式传输层协议。
UDP： USer Datagram Protocol面向消息的传输服务，传输的数据是有边界的。
区别：

TCP可靠性是tcp三次握手的基础，在此之上，增加了seq、ack数据确认机制、拥塞控制，其中ack= seq+len(data)。

UDP：想法就发，不用三次握手建立连接。

我们目前常见的应用场景底层都是tcp，比如http请求、sql数据库请求。

建立TCP连接之后，才能做http请求、sql请求，tcp连接很耗时，故服务器都存在连接池化机制。

这里我要给自己强调的是：开发者对于tcp一定不要带入http请求-响应模型,tcp是双向通信流。

TCP粘包/拆包

TCP粘包并不是TCP协议造成的问题，因为tcp协议本就规定字节流式传输，

正常的理想情况，应用层下发的两个原始包恰好满足TCP缓冲区的大小或达到TCP等待时长，分别发送两个包；
粘包：两个包较小，间隔时间短，发生粘包，合并成一个包发送；
拆包：一个包过大，超过缓存区大小，拆分成两个或多个包发送；
拆包和粘包：Packet1过大，进行了拆包处理，而拆出去的一部分又与Packet2进行粘包处理。

粘包/拆包问题一直都存在，只是到TCP就拆不动了。

粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。
数据链路层，网络层的粘包和拆包问题都由协议自行处理了，我们日常的网络应用开发都在对接传输层，故面临的粘包问题指的是TCP粘包。

粘包/拆包问题一直都存在，只是到TCP就拆不动了。

当粘包、拆到TCP层的时候我们就没办法识别应用层的请求/调用了，所以解决方法是：一开始就需要在字节流中加入[特殊分隔符]或者[长度+偏移量]含义。

HTTP 超文本传输协议的规定如下：

粘包/拆包问题一直都存在，只是到TCP就拆不动了。

旁白

梳理了整个TCP/IP协议栈各层封包逻辑，我们就知道粘包、拆包一直都存在，只是拆到TCP层的时候，我们没有办法区分应用层断续发送的请求/调用，这就是我们口口相传的TCP粘包/拆包问题，需要应用层用特殊分隔符或者长度解析。文章来源地址https://www.toymoban.com/news/detail-437441.html

到了这里，关于粘包/拆包问题一直都存在，只是到TCP就拆不动了。的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！