TCP粘包、拆包原因与解决方案

简介: TCP粘包、拆包原因与解决方案

TCP粘包、拆包原因与解决方案


文章目录

TCP粘包和拆包

问题背景

TCP是一个“流”协议,所谓流,就是没有界限的一长串二进制数据

TCP作为传输层协议并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行数据包的划分,所以在业务上认为是一个完整的包,可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

当客户端与服务端进行TCP通信时,最理想的包的传输过程是这样的

举例说明

我从浏览器中访问了一个网站,网站服务器给我发了200k的数据。建立连接的时候,通告的MSS是50k,所以为了防止ip层分片,tcp每次只会发送50k的数据,一共发了4个tcp数据包。如果我又访问了另一个网站,这个网站给我发了100k的数据,这次tcp会发出2个包,问题是,客户端收到6个包,怎么知道前4个包是一个页面,后两个是一个页面。既然是tcp将这些包分开了,那tcp会将这些包重组吗,它送给应用层的是什么?这是我自己想的一个场景,正式一点讲的话,这个现象叫拆包

tcp中有一个negal算法,用途是这样的:通信两端有很多小的数据包要发送,虽然传送的数据很少,但是流程一点没少,也需要tcp的各种确认,校验。这样小的数据包如果很多,会造成网络资源很大的浪费,negal算法做了这样一件事,当来了一个很小的数据包,我不急于发送这个包,而是等来了更多的包,将这些小包组合成大包之后一并发送,不就提高了网络传输的效率的嘛。这个想法收到了很好的效果,但是我们想一下,如果是分属于两个不同页面的包,被合并在了一起,那客户那边如何区分它们呢?这就是粘包问题。

从粘包问题我们更可以看出为什么tcp被称为流协议,因为它就跟水流一样,是没有边界的,没有消息的边界保护机制,所以tcp只有流的概念,没有包的概念。

产生原因

我们知道TCP是以流动的方式传输数据的,传输的最小单位为一个报文段(Segment)。TCP Header中有个Options标识位。常见的标识位为MSS(Maximum Segment Size)指的是,连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit),一般是1500bit,超过这个量要分成多个报文段,MSS则是这个最大限制减去TCP的header,光是要传输的数据的大小,一般为1460bit。换算成字节,也就是180多字节。

发生TCP粘包、拆包主要是以下原因:

(1)应用程序写入数据大于套接字缓冲区大小,会发生拆包;

(2)应用程序写入数据小于套接字缓冲区大小,网卡将应用多次写入的数据发送到网络上,这将会发送粘包;

(3)进行MSS(最大报文长度)大小的TCP分段,当TCP报文长度——TCP header长度>MSS的时候会发生拆包;

(4)接收方法不及时读取套接字缓冲区数据,这将发生粘包。

解决方案

我们还需要知道两个概念:

(1)长连接: Client方与Server方先建立通讯连接,连接建立后不断开, 然后再进行报文发送和接收。

(2)短连接:Client方与Server每进行一次报文收发交易时才进行通讯连接,交易完毕后立即断开连接。此种方式常用于一点对多点 通讯,比如多个Client连接一个Server。

实际,我想象的关于粘包的场景是不对的,http连接是短连接,请求之后,收到回答,立马断开连接,不会出现粘包。 但是拆包现象是有可能存在的

处理拆包这里提供两种方法:

(1)通过包头+包长+包体的协议形式,当服务器端获取到指定的包长时才说明获取完整。

(2) 指定包的结束标识,这样当我们获取到指定的标识时,说明包获取完整。

处理粘包我们从上面的分析看到,虽然像http这样的短连接协议不会出现粘包的现象,但是一旦建立了长连接,粘包还是有可能会发生的。

处理粘包的方法如下:

(1)发送方对于发送方造成的粘包问题,可以通过关闭Nagle算法来解决,使用TCP_NODELAY选项来关闭算法。

(2)接收方没有办法来处理粘包现象,只能将问题交给应用层来处理。应用层的解决办法简单可行,不仅能解决接收方的粘包问题,还可以解决发送方的粘包问题。

解决办法:循环处理,应用程序从接收缓存中读取分组时,读完一条数据,就应该循环读取下一条数据,直到所有数据都被处理完成,判断每条数据的长度的方法有两种:

a. 格式化数据:每条数据有固定的格式(开始符,结束符),这种方法简单易行,但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

b. 发送长度:发送每条数据时,将数据的长度一并发送,例如规定数据的前4位是数据的长度,应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

思考:UDP会不会产生粘包问题呢?

不存在粘包。

TCP为了保证可靠传输并减少额外的开销(每次发包都要验证),采用了基于流的传输,基于流的传输不认为消息是一条一条的,是无保护消息边界的(保护消息边界:指传输协议把数据当做一条独立的消息在网上传输,接收端一次只能接受一条独立的消息)。UDP则是面向消息传输的,是有保护消息边界的,接收方一次只接受一条独立的信息,所以不存在粘包问题。

举个例子:有三个数据包,大小分别为2k、4k、6k,如果采用UDP发送的话,不管接受方的接收缓存有多大,我们必须要进行至少三次以上的发送才能把数据包发送完,但是使用TCP协议发送的话,我们只需要接受方的接收缓存有12k的大小,就可以一次把这3个数据包全部发送完毕。


相关文章
|
7月前
|
编解码 缓存 移动开发
TCP粘包/拆包与Netty解决方案
TCP粘包/拆包与Netty解决方案
110 0
|
7月前
|
网络协议
解决TCP粘包问题
解决TCP粘包问题
|
移动开发 网络协议 算法
TCP中的粘包、拆包问题产生原因及解决方法
TCP中的粘包、拆包问题产生原因及解决方法
908 0
TCP中的粘包、拆包问题产生原因及解决方法
|
7月前
|
XML 缓存 网络协议
面试题:TCP的粘包和拆包
面试题:TCP的粘包和拆包
64 1
|
存储 消息中间件 缓存
计网 - TCP 的封包格式:TCP 为什么要粘包和拆包?
计网 - TCP 的封包格式:TCP 为什么要粘包和拆包?
144 0
|
网络协议 算法
第 9 章 TCP 粘包和拆包及解决方案
第 9 章 TCP 粘包和拆包及解决方案
236 0
|
存储 网络协议
TCP拆包和粘包的作用是什么
首先我们思考一个问题,应用层的传输一个10M的文件是一次性传输完成,而对于传输层的协议来说,为什么不是一次性传输完成呢。 这个有很多原因,比如稳定性,一次发送的数据越多,出错的概率越大。再比如说为了效率,网络中有时候存在并行的路径,拆分数据包就就能更好的利用这些并行的路径。再有,比如发送和接收数据的时候,都存在缓冲区,缓冲区是在内存中开辟的一块空间,目的是缓冲大量的应用频繁的通过网卡收发数据,这个时候,网卡只能一个一个处理应用的请求。当网卡忙不过来的时候,数据就需要排队了。也就是将数据放入缓冲区。如果每个应用都随意发送很大的数据,可能导致其他应用的实时性遭到破坏。
79 0
|
网络协议 图形学
Socket TCP协议解决粘包、半包问题的三种解决方案
Socket TCP协议解决粘包、半包问题的三种解决方案
327 2
|
移动开发 网络协议 Java
TCP 粘包/拆包问题
《基础系列》
166 0
TCP 粘包/拆包问题
|
移动开发 网络协议
TCP的粘包拆包问题+解决方案
TCP的粘包拆包问题+解决方案
165 0
TCP的粘包拆包问题+解决方案