UDP 是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而 TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 并没有把这些数据块区分边界，仅仅是一连串没有结构的字节流；另外从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

1. 粘包和拆包

当应用层协议使用 TCP/IP 协议传输数据时，TCP/IP 协议簇可能会将应用层发送的数据分成多个包依次发送，而数据的接收方收到的数据可能是分段的或者拼接的，所以它需要对接收的数据进行拆分或者重组。

假设 Client 向 Server 连续发送了两个数据包，用 packet1 和 packet2 来表示，那么服务端收到的数据可以分为三种情况，现列举如下：

第一种情况，接收端正常收到两个数据包，即没有发生拆包和粘包的现象。

第二种情况，接收端只收到一个数据包，但是这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。

第三种情况，这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。

2. 为什么会发生 TCP 粘包、拆包

2.1. 最大传输单元

IP 协议是用于传输数据包的协议，作为网络层协议，它能提供数据的路由和寻址功能，让数据通过网络到达目的地。不同设备之间传输数据前，需要先确定一个 IP 数据包的大小上限，即最大传输单元（Maximum transmission unit，即 MTU），MTU 是 IP 数据包能够传输的数据上限。

MTU 的值不是越大越好，更大的 MTU 意味着更低的额外开销，更小的 MTU 意味着更低的网络延迟。每一个物理设备都有自己的 MTU，两个主机之间的 MTU 依赖于底层的网络能力，它由整个链路上 MTU 最小的物理设备决定，如下图所示，网络路径的 MTU 由 MTU 最小的红色物理设备决定，即 1000：

路径最大传输单元发现（Path MTU Discovery，PMTUD）是用来确定两个主机传输路径 MTU 的机制，它的工作原理如下

1. 向目的主机发送 IP 头中 DF 控制位为 1 的数据包，DF 是不分片（Don’t Fragment，DF）的缩写；
2. 路径上的网络设备根据数据包的大小和自己的 MTU 做出不同的决定：
   1. 如果数据包大于设备的 MTU，就会丢弃数据包并发回一个包含该设备 MTU 的 ICMP 消息；
   2. 如果数据包小于设备的 MTU，就会继续向目的主机传递数据包；
3. 源主机收到 ICMP 消息后，会不断使用新的 MTU 发送 IP 数据包，直到 IP 数据包达到目的主机；

以太网对数据帧的限制一般都是 1500 字节，在一般情况下，IP 主机的路径 MTU 都是 1500，去掉 IP 首部的 20 字节，如果待传输的数据大于 1480 节，那么该 IP 协议就会将数据包分片传输。

IP 协议数据分片对传输层协议是透明的，假设我们使用 UDP 协议传输 2000 字节的数据，加上 UDP 8 字节的协议头，IP 协议需要传输 2008 字节的数据。如下图所示，当 IP 协议发现待传输的数据大于 1480 字节，就会将数据分成下面的两个数据包：

1. 20 字节 IP 协议头 + 8 字节 UDP 协议头 + 1472 字节数据；
2. 20 字节 IP 协议头 + 528 字节数据；

数据的接收方在收到数据包时会对分片的数据进行重组，不过因为第二个数据包中不包含 UDP 协议的相关信息，一旦发生丢包，整个 UDP 数据报就无法重新拼装。如果 UDP 数据报需要传输的数据过多，那么 IP 协议就会大量分片，增加了不稳定性。

如果 IP 协议没有数据包大小的限制，那么上层可以以消息为单位传输数据，自然就不存在分片和组装的需求，不过因为物理设备的 MTU 限制，想要保证数据传输的可靠性和稳定性还需要传输层的配合。

2.2. 最大分段大小

TCP 协议是面向字节流的协议，应用层交给 TCP 协议的数据并不会以消息为单位向目的主机发送，应用层交给 TCP 协议发送的数据可能会被拆分到多个数据段中。

TCP 协议引入了最大分段大小（Maximum segment size，MSS）这一概念，它是 TCP 数据段能够携带的数据上限。在正常情况下，TCP 连接的 MSS 是 MTU - 40 字节，即 1460 字节；不过如果通信双方没有指定 MSS 的话，在默认情况下 MSS 的大小是 536 字节。

IP 协议的 MTU 是物理设备上的限制，它限制了路径能够发送数据包的上限，而 TCP 协议的 MSS 是操作系统内核层面的限制，通信双方会在三次握手时确定这次连接的 MSS。一旦确定了 MSS，TCP 协议就会对应用层交给 TCP 协议发送的数据进行拆分，构成多个数据段。

需要注意的是，IP 协议和 TCP 协议虽然都会对数据进行拆分，但是 IP 协议以数据包（Package）为单位组织数据，而 TCP 协议以数据段（Segment）为单位组织数据。

如下图所示，如果 TCP 连接的 MSS 是 1460 字节，应用层想要通过 TCP 协议传输 2000 字节的数据，那么 TCP 协议会根据 MSS 将 2000 字节的数据拆分到两个数据段中：

• 20 字节 IP 头 + 20 字节 TCP 头 + 1460 字节数据；
• 20 字节 IP 头 + 20 字节 TCP 头 + 540 字节数据；

从应用层的角度来看，两个数据段中 2000 字节的数据构成了发送方想要发送的消息，但是 TCP 协议是面向字节流的，向协议写入的数据会以流的形式传递到对端。

TCP 协议为了保证可靠性，会通过 IP 协议的 MTU 计算出 MSS 并根据 MSS 分段避免 IP 协议对数据包进行分片。因为 IP 协议对数据包的分片对上层是透明的，如果协议不根据 MTU 做一些限制，那么 IP 协议的分片会导致部分数据包失去传输层协议头，一旦数据包发生丢失就只能丢弃全部数据。

我们可以通过一个例子分析 MSS 存在的必要性。如下图所示，假设 TCP 协议中不存在 MSS 的概念，因为每个数据段的大小没有上限，当 TCP 协议交给 IP 层发送两个 1600 字节（包括 IP 和 TCP 协议头）的数据包时，由于物理设备的限制，IP 协议的路径 MTU 为 1500 字节，所以 IP 协议会对数据包分片：

四个数据包中只有两个会包含 TCP 协议头，即控制位、序列号等信息，剩下的两个数据包中不包含任何信息。因为网络无法保证数据包的送达顺序，所以当上述四个数据包乱序到达目的主机时，因为数据包中 TCP 协议头的缺失，所以接收方没有办法对数据包进行重组，自然也就无法保证可靠性和顺序了。

2.3. 滑动窗口

滑动窗口是 TCP 传输层用于流量控制的一种有效措施，也被称为通告窗口。滑动窗口是数据接收方设置的窗口大小，随后接收方会把窗口大小告诉发送方，以此限制发送方每次发送数据的大小，从而达到流量控制的目的。这样数据发送方不需要每发送一组数据就阻塞等待接收方确认，允许发送方同时发送多个数据分组，每次发送的数据都会被限制在窗口大小内。由此可见，滑动窗口可以大幅度提升网络吞吐量。

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

2.4. 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 操作系统的默认行为是相反的。

2.5. 总结

数据拆分的根本原因说到底还是物理设备的限制，不过每一层协议都受限于下一层协议做出的决定，并依赖下层协议重新决定设计和实现的方法。虽然 TCP/IP 协议在传输数据时都需要对数据进行拆分，但是它们做出拆分数据的设计基于不同的上下文，也有着不同的目的，我们在这里总结一下两个网络协议做出类似决定的原因：

• IP 协议拆分数据是因为物理设备的限制，一次能够传输的数据由路径上 MTU 最小的设备决定，一旦 IP 协议传输的数据包超过 MTU 的限制就会发生丢包，所以我们需要通过路径 MTU 发现获取传输路径上的 MTU 限制；
• TCP 协议拆分数据是为了保证传输的可靠性和顺序，作为可靠的传输协议，为了保证数据的传输顺序，它需要为每一个数据段增加包含序列号的 TCP 协议头，如果数据段大小超过了 IP 协议的 MTU 限制，接收方就无法按顺序对数据包进行重组，TCP 协议也就无法提供可靠性和顺序的保证；

3. 拆包/粘包的解决方案

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

• 服务端恰巧读到了两个完整的数据包 A 和 B，没有出现拆包/粘包问题；

• 服务端接收到 A 和 B 粘在一起的数据包，服务端需要解析出 A 和 B；

• 服务端收到完整的 A 和 B 的一部分数据包 B-1，服务端需要解析出完整的 A，并等待读取完整的 B 数据包；

• 服务端接收到 A 的一部分数据包 A-1，此时需要等待接收到完整的 A 数据包；

• 数据包 A 较大，服务端需要多次才可以接收完数据包 A。

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

3.1. 消息长度固定

每个数据报文都需要一个固定的长度。当接收方累计读取到固定长度的报文后，就认为已经获得一个完整的消息。当发送方的数据小于固定长度时，则需要空位补齐。

+----+------+------+---+----+

| AB | CDEF | GHIJ | K | LM |

+----+------+------+---+----+

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

+------+------+------+------+

| ABCD | EFGH | IJKL | M000 |

+------+------+------+------+

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

3.2. 特定分隔符

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

+-------------------------+

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

+-------------------------+

由于在发送报文时尾部需要添加特定分隔符，所以对于分隔符的选择一定要避免和消息体中字符相同，以免冲突。否则可能出现错误的消息拆分。比较推荐的做法是将消息进行编码，例如 base64 编码，然后可以选择 64 个编码字符之外的字符作为特定分隔符。特定分隔符法在消息协议足够简单的场景下比较高效，例如 Redis 在通信过程中采用的就是换行分隔符

3.3. 消息长度 + 消息内容

消息头     消息体

+--------+----------+

| Length |  Content |

+--------+----------+

消息长度 + 消息内容是项目开发中最常用的一种协议，如上展示了该协议的基本格式。消息头中存放消息的总长度，例如使用 4 字节的 int 值记录消息的长度，消息体实际的二进制的字节数据。接收方在解析数据时，首先读取消息头的长度字段 Len，然后紧接着读取长度为 Len 的字节数据，该数据即判定为一个完整的数据报文。依然以上述提到的原始字节数据为例，使用该协议进行编码后的结果如下所示：

+-----+-------+-------+----+-----+

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

+-----+-------+-------+----+-----+

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

4. 参考资料

https://mp.weixin.qq.com/s/reLnjLGuZFRVTIQDDRHC0Q

《Netty 核心原理剖析与 RPC 实践》