• 粘包/拆包问题一直都存在,只是到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 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缓冲区的大小或达到TCP等待时长,分别发送两个包;
    • 粘包:两个包较小,间隔时间短,发生粘包,合并成一个包发送;
    • 拆包:一个包过大,超过缓存区大小,拆分成两个或多个包发送;
    • 拆包和粘包:Packet1过大,进行了拆包处理,而拆出去的一部分又与Packet2进行粘包处理。

    image.png

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


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

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

    image.png

    旁白

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

  • 相关阅读:
    信息学奥赛一本通:1310:【例2.2】车厢重组
    kubernetes日志收集 fluent-operator 动态索引名的实现
    网络协议 从入门到精通系列讲解 - 总目录
    android绘制心电图
    什么是谐波?谐波的危害
    C#里氏替换
    MyCat 管理及监控
    如何写出一篇好文章——不动笔就能学会写文章的训练法
    Java 网络编程 —— 创建非阻塞的 HTTP 服务器
    ThingsBoard IoT Gateway 实战(一)- 入手
  • 原文地址:https://www.cnblogs.com/JulianHuang/p/17386121.html