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

• 
  

• • OSI open-system-Interconnection

• • TCP/IP 5层协议栈

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

• • TCP/UDP 概况

• • TCP粘包问题

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

OSI开放系统互联

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

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

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协议本就规定字节流式传输（算法决定：利用缓冲区，有拥塞控制，大小包合并），它不含消息、数据包等概念，需要应用层自己设计消息边界。

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

---

附:TCP报头、IP报头

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

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

旁白

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

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

点“赞”戳“在看”

体现态度很有必要!