tcp粘包的原因,tcp粘包的处理方式

粘包概念： TCP粘包，是将发送端发送的几个包数据在接收端接收之前汇总成一个包，从接收缓冲器来看，下一个包数据的开头紧跟在前一个包数据的末尾。发送方和接收方都可能进行数据包的粘贴。只有TCP有粘着现象，UDP永远不粘着。粘合包通过粘合原因：http://www.Sina.com/http://www.Sina.com/TCP协议本身的机制(用于连接的可信协议-三次握手机制)，客户端和服务器保持一个连接) channnna可以连续向服务器发送多个数据包，但如果发送的网络数据包太小，可以启用Nagle算法(可以设置是否启用) 因此，当接收到该消息(数据流)时，服务器变得无法区分哪些分组是客户端本身单独发送的，从而分组.所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。服务器接收到该数据库下次接收数据时，一次检索多个数据包，数据包可能会粘在一起。

在什么情况下，需要处理粘性包现象(1) (在• 发送端原因：的情况下，不需要考虑粘性包的状况)；2 )如果发送端发送的多个分组本来是相同数据的不同部分，例如例如，文件传输只要发送即可，可以全面接收存储装置； )3)但是，如果多个群体书不相关，或者是并行的关系，我们一定要处理粘合包问题。例如，我当时-收到的各组是固定格式的商品信息，如果不处理粘合包的问题，读入的各组只处理最前面的商品，后面的商品被丢弃。这显然不是我想要的结果。基本上如何处理• 接收端原因：粘包现象(1)发送方关闭发送方粘包现象的Nagle算法可以解决，并使用TCP_NODELAY选项解决Nagle算法

TCP_NODELAY Nagle详细信息3359 blog.csdn.net/LCL wjl/article/details/80154565

)2)很遗憾，接收方TCP没有处理接收方分组粘贴现象的机制，只能在APP应用层进行处理。

高速APP应用层处理

处理APP应用层很简单！另外，不仅可以解决接收方的包装问题，还可以解决发送方的包装问题。

解决方法是循环处理。当APP应用程序处理从高速缓存中读取的数据包时，在读取完一个数据后，它应该循环读取下一个数据，直到处理完所有数据。但是，如何判断各数据的长度？

两种方法：短连接各数据有固定格式(起始符、结束符)，该方法简单，但在选择起始符和结束符时，各数据内部一定不会出现起始符或结束符

注意发送控制符转义长连接各数据时，将数据长度汇总发送。例如，可以选择每个数据的前四位是数据长度，并且可以在处理APP应用层时根据长度来确定每个数据的开始和结束。

可变格式，表示3358 www.Sina.com/http://www.Sina.com/type类型、长度和值；

类型和长度是固定的，一般是2、4字节；

值的长度有长度的指定；

TLV是tag、length、value的缩写。基本数据元素包括上面的三个域。 tag唯一标识该数据元素，length是value域的长度。 value就是数据本身。举个例子，以下是TLV格式的aid (APP应用程序标识符(字节串) ) 9f0607a00000000000

余谈：1）格式化数据：