19.Netty源码之粘包/拆包

本节课开始我们将学习 Netty 通信过程中的编解码技术。

编解码技术这是实现网络通信的基础，让我们可以定义任何满足业务需求的应用层协议。

在网络编程中，我们经常会使用各种网络传输协议，其中 TCP 是最常用的协议。

我们首先需要了解的是 TCP 最基本的拆包/粘包问题以及常用的解决方案，才能更好地理解 Netty 的编解码框架。

为什么会出现拆包/粘包现象呢？

UDP没有拆包半包

提醒：UDP 像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一个签收， 所以无粘包、半包问题。

☆为什么TCP有拆包/粘包

根本原因:TCP传输协议是面向流的,是流式协议，没有数据包界限。客户端向服务端发送数据时，可能将一个完整的报文拆分成多个小报文进行发送，也可能将多个报文合并成一个大的报文进行发送。因此就有了拆包和粘包。

在网络通信的过程中，每次可以发送的数据包大小受多种因素限制，如 MTU 传输单元大小、MSS 最大分段大小、滑动窗口等。

如果一次传输的网络包数据大小超过传输单元大小，那么我们的数据可能会拆分为多个数据包发送出去。

如果每次请求的网络包数据都很小，一共请求了 10000 次，TCP 并不会分别发送 10000 次。

因为 TCP 采用的 Nagle 算法对此作出了优化。

tcp为什么会粘包

粘包的根本原因: TCP 传输协议是面向流的,是流式协议,没有数据包界限。 粘包的主要原因： • 发送方每次写入数据小于套接字缓冲区大小,需要多次发送 • 接收方读取套接字缓冲区数据不够及时 ​ 半包的主要原因： • 发送方写入数据大于套接字缓冲区大小 • 发送的数据大于协议的 MTU(Maximum Transmission Unit，最大传输单元)，必须拆包 ​ 换个角度看： • 收发 一个发送可能被多次接收，多个发送可能被一次接收 • 传输 一个发送可能占用多个传输包，多个发送可能公用一个传输包 ​

MTU 最大传输单元和 MSS 最大分段大小

MTU(Maxitum Transmission Unit) 是链路层一次最大传输数据的大小。MTU 一般来说大小为 1500 byte。

MSS(Maximum Segement Size)是指 TCP 最大报文段长度，它是传输层一次发送最大数据的大小。MSS一般大小是1460

如下图所示，MTU 和 MSS 一般的计算关系为：MSS = MTU - IP 首部 - TCP首部，如果 MSS + TCP 首部 + IP 首部 > MTU，那么数据包将会被拆分为多个发送。这就是拆包现象。

滑动窗口:限制发送方单次发送数据大小

滑动窗口是 TCP 传输层用于流量控制的一种有效措施，也被称为通告窗口。

滑动窗口是数据接收方设置的窗口大小，数据接收方会把窗口大小告诉发送方，以此限制发送方每次发送数据的大小，从而达到流量控制的目的。

这样数据发送方不需要每发送一组数据就阻塞等待接收方确认，允许发送方同时发送多个数据分组，每次发送的数据都会被限制在窗口大小内。

由此可见，滑动窗口可以大幅度提升网络吞吐量。

那么 TCP 报文是怎么确保数据包按次序到达且不丢数据呢？

首先，所有的数据帧都是有编号的，TCP 并不会为每个报文段都回复 ACK 响应，它会对多个报文段回复一次 ACK。假设有三个报文段 A、B、C，发送方先发送了B、C，接收方则必须等待 A 报文段到达，如果一定时间内仍未等到 A 报文段，那么 B、C 也会被丢弃，发送方会发起重试。如果已接收到 A 报文段，那么将会回复发送方一次 ACK 确认。

Nagle 算法:批量发送

Nagle 算法于 1984 年被福特航空和通信公司定义为 TCP/IP 拥塞控制方法。它主要用于解决频繁发送小数据包而带来的网络拥塞问题。试想如果每次需要发送的数据只有 1 字节，加上 20 个字节 IP Header 和 20 个字节 TCP Header，每次发送的数据包大小为 41 字节，但是只有 1 字节是有效信息，这就造成了非常大的浪费。Nagle 算法可以理解为批量发送，也是我们平时编程中经常用到的优化思路，它是在数据未得到确认之前先写入缓冲区，等待数据确认或者缓冲区积攒到一定大小再把数据包发送出去。

Linux 在默认情况下是开启 Nagle 算法的，在大量小数据包的场景下可以有效地降低网络开销。 但如果你的业务场景每次发送的数据都需要获得及时响应，那么 Nagle 算法就不能满足你的需求了，因为 Nagle 算法会有一定的数据延迟。

你可以通过 Linux 提供的 TCP_NODELAY 参数禁用 Nagle 算法。

Netty 中为了使数据传输延迟最小化，就默认禁用了 Nagle 算法，这一点与 Linux 操作系统的默认行为是相反的。

拆包/粘包解决方案:消息边界

在客户端和服务端通信的过程中，服务端一次读到的数据大小是不确定的。如上图所示，拆包/粘包可能会出现以下五种情况：

• 服务端恰巧读到了两个完整的数据包 A 和 B，没有出现拆包/粘包问题；
• 服务端接收到 A 和 B 粘在一起的数据包，服务端需要解析出 A 和 B；
• 服务端收到完整的 A 和 B 的一部分数据包 B-1，服务端需要解析出完整的 A，并等待读取完整的 B 数据包；
• 服务端接收到 A 的一部分数据包 A-1，此时需要等待接收到完整的 A 数据包；
• 数据包 A 较大，服务端需要多次才可以接收完数据包 A。

由于拆包/粘包问题的存在，数据接收方很难界定数据包的边界在哪里，很难识别出一个完整的数据包。所以需要提供一种机制来识别数据包的界限，这也是解决拆包/粘包的唯一方法：定义应用层的通信协议。

下面我们一起看下主流协议的解决方案。

消息长度固定

每个数据报文都需要一个固定的长度。当接收方累计读取到固定长度的报文后，就认为已经获得一个完整的消息。

当发送方发送的数据小于固定长度时，则需要将空位补齐再发送。

``` +----+------+------+---+----+

| AB | CDEF | GHIJ | K | LM |

+----+------+------+---+----+ ```

假设我们的固定长度为 4 字节，那么如上所示的 5 条数据一共需要发送 4 个报文：

+------+------+------+------+ | ABCD | EFGH | IJKL | M000 | +------+------+------+------+

长度如何设置是问题

消息定长法使用非常简单，但是缺点也非常明显，无法很好设定固定长度的值，如果长度太大会造成字节浪费，长度太小又会影响消息传输，所以在一般情况下消息定长法不会被采用。

特定分隔符:redis

既然接收方无法区分消息的边界，那么我们可以在每次发送报文的尾部加上特定分隔符，接收方就可以根据特殊分隔符进行消息拆分。以下报文根据特定分隔符 \n 按行解析，即可得到 AB、CDEF、GHIJ、K、LM 五条原始报文。

``` +-------------------------+

| AB\nCDEF\nGHIJ\nK\nLM\n |

+-------------------------+ ```

由于在发送报文时尾部需要添加特定分隔符，所以对于分隔符的选择一定要避免和消息体中字符相同，以免冲突。否则可能出现错误的消息拆分。

比较推荐的做法是将消息进行编码，例如 base64 编码，然后可以选择 64 个编码字符之外的字符作为特定分隔符。

base64编码中的64 指代的是64个字符

A-Z a-z 0-9 + / 26 + 26 + 10 + 2 = 64

特定分隔符法在消息协议足够简单的场景下比较高效，例如大名鼎鼎的 Redis 在通信过程中采用的就是换行分隔符。

消息长度+变长消息:dubbo&rocketMQ

消息头 消息体 +--------+----------+ | Length | Content | +--------+----------+

消息长度 + 消息内容是项目开发中最常用的一种协议，如上展示了该协议的基本格式。

消息头中存放消息的总长度，例如使用 4 字节的 int 值记录消息的长度，消息体实际的二进制的字节数据。

接收方在解析数据时，首先读取消息头的长度字段 Len，然后紧接着读取长度为 Len 的字节数据，该数据即判定为一个完整的数据报文。

依然以上述提到的原始字节数据为例，使用该协议进行编码后的结果如下所示：

+-----+-------+-------+----+-----+ | 2AB | 4CDEF | 4GHIJ | 1K | 2LM | +-----+-------+-------+----+-----+

消息长度 + 消息内容的使用方式非常灵活，且不会存在消息定长法和特定分隔符法的明显缺陷。当然在消息头中不仅只限于存放消息的长度，而且可以自定义其他必要的扩展字段，例如消息版本、算法类型等。

使用JSON

每种都不同，例如JSON 可以看{}是否应已经成对.

Netty 对三种常用封帧方式的支持

| 方式 | 解码 | 编码 | | --------------- | ---------------------------- | -------------------- | | 固定长度 | FixedLengthFrameDecoder | 简单 | | 分割符 | DelimiterBasedFrameDecoder | 简单 | | 固定长度字段存个内容的长度信息 | LengthFieldBasedFrameDecoder | LengthFieldPrepender | | JSON | 可以看{}是否应已经成对. | 简单 |

总结

本节课我们详细讨论了 TCP 中的拆包/粘包问题，以及如何通过应用层的通信协议来解决拆包/粘包问题。

其中基于消息长度 + 消息内容的变长协议是项目开发中最常用的一种方法，需要我们重点掌握，例如开源中间件 Dubbo、RocketMQ 等都基于该方法自定义了自己的通信协议。