tcp流式服务和粘包问题

时间:2024-03-11 10:29:00

目录

 1.概念

2.流式服务

3.粘包问题


 1.概念

套接字是一个全双工的

使用TCP协议通信的双方必须先建立连接,然后才能开始数据的读写,双方都必须为该连接分配必要的内核资源,以管理连接的状态和连接上数据的传输.

TCP连接是全双工的,即双方的数据读写可以通过一个连接进行,完成数据交换之后,通信双方都必须断开连接以释放系统资源.

TCP协议的这种连接是一对一的,所以基于广播和多播(目标是多个主机地址)的应用程序不能使用TCP服务.而无连接协议UDP则非常适合于广播和多播. 

2.流式服务

tcp的服务特点:

tcp是一个字节流服,TCP 字节流的特点,发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系,应用程序对数据的发送和接收是没有边界限制的。

 因此,TCP模块发送出的TCP报文段的个数和应用程序执行的写操作次数之间没有固定的数量关系即,发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系,这就是字节流的概念.应用程序对数据的发送和接收是没有边界限制的.

3.粘包问题

 粘包问题有时候有影响,有时候没有影响;

沾包(粘包)有影响就解决,没有影响就不用解决(比如文件传输就没有影响);

演示粘包:

如果我们将服务器的代码改动一下,将一次接收127个字符改为一次接收1个字符;

int n=recv(c,buff,1,0);

 第二次服务器返回的确认信息只有一个ok,但是客户端发送的数据长度并不是1。

 原因如下:

利用netstat命令我们可以看到在接收缓冲区中有6个字节的数据,说明服务器发送的确认信息是先发送到缓冲区的,没来的及打印。所以上图中只有一个“ok”,还有3个在缓冲区中。

因为TCP是面向流,没有边界,而操作系统在发送TCP数据时,会通过缓冲区来进行优化,例如缓冲区为1024个字节大小。如果一次请求发送的数据量比较小,没达到缓冲区大小,TCP则会将多个请求合并为同一个请求进行发送,这就形成了粘包问题。如果一次请求发送的数据量比较大,超过了缓冲区大小,TCP就会将其拆分头多次发送,这就是拆包。

粘包要解决吗?如何解决?(常见的面试题目)

没有影响就不用处理(如文件发送),有影响尤其是多个数据是并列的关系,就必须要处理格式化数据,发送长度等等