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

2023-06-12,,

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 callsocket 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粘包。


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

附录: ip报头结构:[源ip、目标ip在这定义]

旁白

梳理了整个TCP/IP协议栈的流程,结合TCP报头/IP报头, 我们就知道粘包、拆包一直都存在,只是拆到TCP层的时候,我们没有办法区分应用层断续发送的请求/调用, 这就是我们口口相传的TCP粘包/拆包问题, 需要应用层用特殊分隔符或者长度解析。

粘包/拆包问题一直都存在,只是到TCP就拆不动了。的相关教程结束。

《粘包/拆包问题一直都存在,只是到TCP就拆不动了。.doc》

下载本文的Word格式文档,以方便收藏与打印。