Netty--原理--TCP--粘包与拆包

我会带着你远行 2022-10-17 05:28 3阅读 0赞

原文网址：[Netty--原理--TCP--粘包与拆包\_IT利刃出鞘的博客-CSDN博客][Netty--_--TCP--_IT_-CSDN]

# 其他网址 #

[Netty 中的粘包和拆包 - rickiyang - 博客园][Netty _ - rickiyang -]

[netty 之 解决tcp粘包拆包\_学习笔记cmj的博客-CSDN博客][netty _ _tcp_cmj_-CSDN]  
[Netty是如何解决TCP的粘包和拆包问题的？\_LMR的博客-CSDN博客\_netty解决tcp粘包和拆包][Netty_TCP_LMR_-CSDN_netty_tcp]  
[Netty框架进阶篇 - 解决TCP粘包和拆包问题以及集成MessagePack序列化框架实战\_wzljiayou的博客-CSDN博客][Netty_ - _TCP_MessagePack_wzljiayou_-CSDN]

# 简介 #

## 什么是TCP粘包/拆包 ##

> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlaXlpbmcwY2FuZ2xhbmc_size_16_color_FFFFFF_t_70][]
> 
> 假设msg1的数据为：abc，msg2的数据为：def，服务端每收到数据就把它加上个\#然后输出。对应上边四种情况为：
> 
> <table style="width:535px;"> 
>  <thead> 
>   <tr> 
>    <th style="width:281px;">结论</th> 
>    <th style="width:251px;">服务端输出结果</th> 
>   </tr> 
>  </thead> 
>  <tbody> 
>   <tr> 
>    <td style="width:281px;">正常接受，没有发生粘包/拆包</td> 
>    <td style="width:251px;">abc# def#</td> 
>   </tr> 
>   <tr> 
>    <td style="width:281px;">异常接受，发生拆包</td> 
>    <td style="width:251px;">ab# c# def#</td> 
>   </tr> 
>   <tr> 
>    <td style="width:281px;">异常接受，发生粘包</td> 
>    <td style="width:251px;">abcdef#</td> 
>   </tr> 
>   <tr> 
>    <td style="width:281px;">异常接受，发生粘包和拆包</td> 
>    <td style="width:251px;">ab# cdef#</td> 
>   </tr> 
>  </tbody> 
> </table>

## **为什么TCP 会粘包拆包但UDP不会？** ##

> **TCP**
> 
> TCP是面向流的。就像河水一样, 只要有水, 就会一直流向低处, 不会间断。
> 
> TCP为了提高传输效率，发送数据的时候，并不是直接发送数据到网路，而是先暂存到系统缓冲，超过时间或者缓冲满了，才把缓冲区的内容发送出去，这样，就可以有效提高发送效率。
> 
> 所以会造成所谓的粘包/拆包，即前一份Send的数据跟后一份Send的数据可能会暂存到缓冲当中，然后一起发送。

> **UDP**
> 
> UDP面向报文形式，系统是不会缓冲的，也不会做优化。
> 
> Send的时候，直接Send到网络上，对方收不收到也不管，所以这块数据总是能够能一包一包的形式接收到，而不会出现前一个包跟后一个包都写到缓冲然后一起Send。

# 粘包/拆包的原因 #

1.  Socket 缓冲区与滑动窗口
    
    1.  写入的字节长度大于socket缓冲区的大小(通常产生拆包)
    2.  写入的字节长度小于socket缓冲去的大小(通常产生粘包)
2.  MSS/MTU限制
    
    1.  MTU (Maxitum Transmission Unit,最大传输单元)是链路层对一次可以发送的最大数据的限制。
    2.  MSS(Maxitum Segment Size,最大分段大小)是 TCP 报文中 data 部分的最大长度，是传输层对一次可以发送的最大数据的限制。
3.  Nagle算法

## 1. Socket缓冲区与滑动窗口 ##

对于 TCP 协议而言，它传输数据是基于字节流传输的。应用层在传输数据时，实际上会先将数据写入到 TCP 套接字的缓冲区，当缓冲区被写满后，数据才会被写出去。每个TCP Socket 在内核中都有一个发送缓冲区(SO\_SNDBUF )和一个接收缓冲区(SO\_RCVBUF)，TCP 的全双工的工作模式以及 TCP 的滑动窗口便是依赖于这两个独立的 buffer 以及此 buffer 的填充状态。

**SO\_SNDBUF：**

进程发送的数据的时候假设调用了一个 send 方法，将数据拷贝进入 Socket 的内核发送缓冲区之中，然后 send 便会在上层返回。换句话说，send 返回之时，数据不一定会发送到对端去(和write写文件有点类似)，send 仅仅是把应用层 buffer 的数据拷贝进 Socket 的内核发送 buffer 中。

**SO\_RCVBUF：**

把接收到的数据缓存入内核，应用进程一直没有调用 read 进行读取的话，此数据会一直缓存在相应 Socket 的接收缓冲区内。不管进程是否读取 Socket，对端发来的数据都会经由内核接收并且缓存到 Socket 的内核接收缓冲区之中。read 所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的 buffer 里面，仅此而已。

接收缓冲区保存收到的数据一直到应用进程读走为止。对于 TCP，如果应用进程一直没有读取，buffer 满了之后发生的动作是：通知对端 TCP 协议中的窗口关闭。这个便是滑动窗口的实现。保证 TCP 套接口接收缓冲区不会溢出，从而保证了 TCP 是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是 TCP 的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方 TCP 将丢弃它。

**滑动窗口：**

TCP连接在三次握手的时候，会将自己的窗口大小(window size)发送给对方，其实就是 SO\_RCVBUF 指定的值。之后在发送数据的时，发送方必须要先确认接收方的窗口没有被填充满，如果没有填满，则可以发送。

每次发送数据后，发送方将自己维护的对方的 window size 减小，表示对方的 SO\_RCVBUF 可用空间变小。

当接收方处理开始处理 SO\_RCVBUF 中的数据时，会将数据从 Socket 在内核中的接受缓冲区读出，此时接收方的 SO\_RCVBUF 可用空间变大，即 window size 变大，接受方会以 ack 消息的方式将自己最新的 window size 返回给发送方，此时发送方将自己的维护的接受的方的 window size 设置为ack消息返回的 window size。

此外，发送方可以连续的给接受方发送消息，只要保证对方的 SO\_RCVBUF 空间可以缓存数据即可，即 window size>0。当接收方的 SO\_RCVBUF 被填充满时，此时 window size=0，发送方不能再继续发送数据，要等待接收方 ack 消息，以获得最新可用的 window size。

## 2. MSS/MTU分片 ##

MTU (Maxitum Transmission Unit,最大传输单元)是链路层对一次可以发送的最大数据的限制。

MSS(Maxitum Segment Size,最大分段大小)是 TCP 报文中 data 部分的最大长度，是传输层对一次可以发送的最大数据的限制。

![5370fac6d5a707947fe3f4ac6c1ce813.png][]

数据在传输过程中，每经过一层，都会加上一些额外的信息：

*  应用层：只关心发送的数据 data，将数据写入 Socket 在内核中的缓冲区 SO\_SNDBUF 即返回，操作系统会将 SO\_SNDBUF 中的数据取出来进行发送；
 *  传输层：会在 data 前面加上 TCP Header(20字节)；
 *  网络层：会在 TCP 报文的基础上再添加一个 IP Header，也就是将自己的网络地址加入到报文中。IPv4 中 IP Header 长度是 20 字节，IPV6 中 IP Header 长度是 40 字节；
 *  链路层：加上 Datalink Header 和 CRC。会将 SMAC(Source Machine，数据发送方的MAC地址)，DMAC(Destination Machine，数据接受方的MAC地址 )和 Type 域加入。SMAC+DMAC+Type+CRC 总长度为 18 字节；
 *  物理层：进行传输。

在回顾这个基本内容之后，再来看 MTU 和 MSS。MTU 是以太网传输数据方面的限制，每个以太网帧最大不能超过 1518bytes。刨去以太网帧的帧头(DMAC+SMAC+Type域) 14Bytes 和帧尾 (CRC校验 ) 4 Bytes，那么剩下承载上层协议的地方也就是 data 域最大就只能有 1500 Bytes 这个值 我们就把它称之为 MTU。

MSS 是在 MTU 的基础上减去网络层的 IP Header 和传输层的 TCP Header 的部分，这就是 TCP 协议一次可以发送的实际应用数据的最大大小。

`MSS = MTU(1500) -IP Header(20 or 40)-TCP Header(20)`

由于 IPV4 和 IPV6 的长度不同，在 IPV4 中，以太网 MSS 可以达到 1460byte。在 IPV6 中，以太网 MSS 可以达到 1440byte。

发送方发送数据时，当 SO\_SNDBUF 中的数据量大于 MSS 时，操作系统会将数据进行拆分，使得每一部分都小于 MSS，也形成了拆包。然后每一部分都加上 TCP Header，构成多个完整的 TCP 报文进行发送，当然经过网络层和数据链路层的时候，还会分别加上相应的内容。

另外需要注意的是：对于本地回环地址(lookback)不需要走以太网，所以不受到以太网 MTU=1500 的限制。linux 服务器上输入 ifconfig 命令，可以查看不同网卡的 MTU 大小，如下：

![87ca485c3a637e1a77d2fa61202eab4a.png][]

上图显示了 2 个网卡信息：

*  eth0 需要走以太网，所以 MTU 是 1500；
 *  lo 是本地回环，不需要走以太网，所以不受 1500 的限制。

## **3. Nagle 算法** ##

TCP/IP 协议中，无论发送多少数据，总是要在数据(data)前面加上协议头(TCP Header+IP Header)，同时，对方接收到数据，也需要发送 ACK 表示确认。

即使从键盘输入的一个字符，占用一个字节，可能在传输上造成 41 字节的包，其中包括 1 字节的有用信息和 40 字节的首部数据。这种情况转变成了 4000% 的消耗，这样的情况对于重负载的网络来是无法接受的。称之为"糊涂窗口综合征"。

为了尽可能的利用网络带宽，TCP 总是希望尽可能的发送足够大的数据。(一个连接会设置 MSS 参数，因此，TCP/IP 希望每次都能够以 MSS 尺寸的数据块来发送数据)。Nagle 算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。

Nagle 算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓 “小段”，指的是小于 MSS 尺寸的数据块；所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的 ACK 确认该数据已收到。

Nagle 算法的规则：

1.  如果 SO\_SNDBUF 中的数据长度达到 MSS，则允许发送；
2.  如果该 SO\_SNDBUF 中含有 FIN，表示请求关闭连接，则先将 SO\_SNDBUF 中的剩余数据发送，再关闭；
3.  设置了 `TCP_NODELAY=true` 选项，则允许发送。TCP\_NODELAY 是取消 TCP 的确认延迟机制，相当于禁用了 Negale 算法。正常情况下，当 Server 端收到数据之后，它并不会马上向 client 端发送 ACK，而是会将 ACK 的发送延迟一段时间(一般是 40ms)，它希望在 t 时间内 server 端会向 client 端发送应答数据，这样 ACK 就能够和应答数据一起发送，就像是应答数据捎带着 ACK 过去。当然，TCP 确认延迟 40ms 并不是一直不变的， TCP 连接的延迟确认时间一般初始化为最小值 40ms，随后根据连接的重传超时时间(RTO)、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置 TCP\_QUICKACK 选项来取消确认延迟；
4.  未设置 TCP\_CORK 选项时，若所有发出去的小数据包(包长度小于MSS)均被确认，则允许发送；
5.  上述条件都未满足，但发生了超时(一般为200ms)，则立即发送。

基于以上问题，TCP层肯定是会出现当次接收到的数据是不完整数据的情况。出现粘包可能的原因有：

1.  发送方每次写入数据 < 套接字缓冲区大小；
2.  接收方读取套接字缓冲区数据不够及时。

出现半包的可能原因有：

1.  发送方每次写入数据 > 套接字缓冲区大小；
2.  发送的数据大于协议 MTU，所以必须要拆包。

解决问题肯定不是在4层来做而是在应用层，通过定义通信协议来解决粘包和拆包的问题。发送方 和 接收方约定某个规则：

1.  当发生粘包的时候通过某种约定来拆包；
2.  如果在拆包，通过某种约定来将数据组成一个完整的包处理。

# 粘包/拆包解决方案 #

**1. 定长协议**

> 指定一个报文具有固定长度。比如约定一个报文的长度是 5 字节，那么：报文：1234，只有4字节，但是还差一个怎么办呢，不足部分用空格补齐。就变为：1234 。
> 
> 如果不补齐空格，那么就会读到下一个报文的字节来填充上一个报文直到补齐为止，这样粘包了。
> 
> 定长协议的优点是使用简单，缺点很明显：浪费带宽。
> 
> Netty 中提供了 FixedLengthFrameDecoder ，支持把固定的长度的字节数当做一个完整的消息进行解码。

**2. 特殊字符分割协议**

> 很好理解，在每一个你认为是一个完整的包的尾部添加指定的特殊字符，比如：\\n，\\r等等。
> 
> 需要注意的是：约定的特殊字符要保证唯一性，不能出现在报文的正文中，否则就将正文一分为二了。
> 
> Netty 中提供了 DelimiterBasedFrameDecoder 根据特殊字符进行解码，LineBasedFrameDecoder默认以换行符作为分隔符。

**3. 变长协议**

> 变长协议的核心就是：将消息分为消息头和消息体，消息头中标识当前完整的消息体长度。
> 
> 1.  发送方在发送数据之前先获取数据的二进制字节大小，然后在消息体前面添加消息大小；
> 2.  接收方在解析消息时先获取消息大小，之后必须读到该大小的字节数才认为是完整的消息。
> 
> Netty 中提供了 LengthFieldBasedFrameDecoder ，通过LengthFieldPrepender 来给实际的消息体添加 length 字段。

# Netty粘包/拆包解决方案 #

[Netty--_--TCP--_IT_-CSDN]: https://knife.blog.csdn.net/article/details/117456247
[Netty _ - rickiyang -]: https://www.cnblogs.com/rickiyang/p/12904552.html
[netty _ _tcp_cmj_-CSDN]: https://blog.csdn.net/qq_29499107/article/details/108696913
[Netty_TCP_LMR_-CSDN_netty_tcp]: https://blog.csdn.net/qq_16669583/article/details/106255404
[Netty_ - _TCP_MessagePack_wzljiayou_-CSDN]: https://blog.csdn.net/wzljiayou/article/details/110481251
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlaXlpbmcwY2FuZ2xhbmc_size_16_color_FFFFFF_t_70]: /images/20221014/af186ec097a4473a9b565560a191b6b0.png
[5370fac6d5a707947fe3f4ac6c1ce813.png]: /images/20221014/bb8658a8057b412fafee794e6e2988f8.png
[87ca485c3a637e1a77d2fa61202eab4a.png]: /images/20221014/412ed1df7b1d4da48c8b71772c8e214c.png