粘包/拆包问题一直都存在,只是到TCP就拆不动了。
- OSI open-system-Interconnection
- TCP/IP 5层协议栈
- 应用层和操作系统的边界是 系统调用 ,对应到网络编程是socket api
- TCP/UDP 概况
- TCP粘包问题
- TCP/IP报头深思
OSI开放系统互联
定义了网络框架,以层为单位实现协议,同时控制权逐层传递。
OSI实际并没有落地,TCP/IP 5层协议栈是目前主流的落地实现。
TCP/IP 5层协议栈
TCP/IP协议栈不止是传输层tcp/网络层ip, 还包括应用层等,这是一个协议簇,只是因为TCP/IP很具代表性。
不管是OSI还是TCP/IP5层协议栈,均会出现应用程序和操作系统边界(代码执行在用户态/内核态)。
边界调用被称为系统调用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层的时候我们就没办法识别应用层的请求/调用了, 所以解决方法是:一开始就需要在字节流中加入[特殊分隔符]或者[长度+偏移量]含义。
HTTP 超文本传输协议的规定如下:
旁白
梳理了整个TCP/IP协议栈各层封包逻辑, 我们就知道粘包、拆包一直都存在,只是拆到TCP层的时候,我们没有办法区分应用层断续发送的请求/调用, 这就是我们口口相传的TCP粘包/拆包问题, 需要应用层用特殊分隔符或者长度解析。
本文来自博客园,作者:{有态度的马甲},转载请注明原文链接:https://www.cnblogs.com/JulianHuang/p/17386121.html
欢迎关注我的原创技术、职场公众号, 加好友谈天说地,一起进化![](https://blog-static.cnblogs.com/files/JulianHuang/QR.gif)