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

全栈码农画像

共 1456字,需浏览 3分钟

 ·

2023-05-24 13:24

  • be4e33570c191fa4ec8faae136ed8d06.webp

  • • OSI open-system-Interconnection

  • • TCP/IP 5层协议栈

    • • 应用层和操作系统的边界是 系统调用 ,对应到网络编程是socket api

  • • TCP/UDP 概况

  • • TCP粘包问题

  • • 结合TCP/IP报头再回顾,柳暗花明

OSI开放系统互联

定义了网络框架,以层为单位实现协议,同时控制权逐层传递。

e71b386fb9960f88163f6897c7ff30ef.webp

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

TCP/IP 5层协议栈

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

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

2e3b6957d262513c9abc697912ed8c61.webp

边界调用被称为系统调用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粘包。

de9b1260049aa2ef9a221819cf4e5021.webp

TCP粘包并不是TCP协议造成的问题,因为tcp协议本就规定字节流式传输(算法决定:利用缓冲区,有拥塞控制,大小包合并),它不含消息、数据包等概念,需要应用层自己设计消息边界。

fb5fa5c7dea6cdbe33a9df41959c9ee0.webp

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

b6e8112a634a42ac69451bba9dfc0377.webp

附:TCP报头、IP报头

tcp报头结构:[源端口、目标端口、SEQ/ACK在这定义]

eecc73322606fbff1ff54dcc71aa5767.webp

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

82970e3f8015b2ffa53d066db6db5adb.webp

旁白

结合TCP报头/IP报头, 我们知道粘包、拆包一直都存在(TCP/IP报头附录里利用数据长度/偏移量,协助封包、拆包)。

只是协议栈一层层帮我们拆到TCP层的时候,如果没有特殊机制,我们是没有办法区分应用层断续发送的请求/调用。 故同理应对TCP粘包问题,上次应用层需要使用特殊分隔符或者长度来协助封包/拆包。

点“aea2b4587421f50afa14e454f8065012.webp戳“在看aea2b4587421f50afa14e454f8065012.webp

体现态度很有必要!

浏览 43
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报