1. 什么是粘包#

TCP 是一种面向字节流的传输协议。

发送端多次调用 send 时，TCP 只把这些数据看成一串连续的字节，并不记录应用程序每一次 send 的边界。接收端调用 recv 时，读取到的是当前接收缓冲区中能够取得的一段字节。

因此可能出现：

• 发送端连续发送的多个数据包，被接收端一次 recv 读出；
• 发送端一次发送的数据，被接收端分多次 recv 读出；
• 一次 recv 读到前一个数据包的结尾和后一个数据包的开头。

所谓“粘包”，本质上不是 TCP 把数据传错了，而是应用层没有办法从连续字节流中识别每一条消息的边界。

2. 为什么会出现粘包#

常见原因包括：

• TCP 只负责可靠地传输字节流，不保留消息边界；
• 发送端和接收端都存在缓冲区；
• send 与 recv 并不是一一对应的；
• 操作系统可能合并较小的数据后再发送；
• 网络状况和接收方读取速度会影响每次 recv 得到的数据量。

粘包的形成位置分成两类：

• 发送端粘包：多个较小数据在发送缓冲区中被合并后发送，Nagle 算法也可能促成这种合并；
• 接收端粘包：接收程序没有及时读取，或一次读取了缓冲区中的多条消息，导致多条应用层数据连在一起。

需要牢记：

1
一次 send ≠ 对方的一次 recv

TCP 能保证字节的顺序和可靠性，但应用程序必须自己设计“如何拆包”。

方法一：设置开始或结束标志#

在每条消息的开始或结束位置放置特殊标志。接收端不断读取数据，遇到该标志后，就认为一条完整消息结束。

例如：

1
你好\n吃饭了吗\n

其中 \n 可以作为结束标志。

优点：

• 实现思路简单；
• 消息长度可以变化。

缺点：

• 正文中也可能出现相同标志；
• 如果正文允许出现标志，需要设计转义规则；
• 接收端要在缓存中查找分隔符。

方法二：固定数据包大小#

规定每条消息都占固定数量的字节，例如每个包固定为 100 字节。接收端每收满 100 字节，就得到一条完整消息。

优点：

• 接收端容易判断消息边界；
• 拆包逻辑简单。

缺点：

• 数据不足固定长度时会浪费空间；
• 数据超过固定长度时仍要额外拆分；
• 不适合消息长度变化很大的场景。

方法三：先发送数据长度，再发送数据#

发送端先发送一个固定长度的“包头”，在包头中说明后续数据的大小；接收端先取得长度，再按该长度读取正文。

数据格式可以表示为：

1
┌──────────────┬────────────────────────┐
2
│ 数据长度     │ 数据内容               │
3
│ 固定大小     │ 长度由前面的字段决定   │
4
└──────────────┴────────────────────────┘

接收过程：

1
先接收长度字段
2
        ↓
3
根据长度申请空间
4
        ↓
5
再接收指定长度的数据
6
        ↓
7
还原并处理完整消息

优点：

• 适合可变长度消息；
• 接收端能够准确知道还需要读取多少字节；
• 是实际项目中常用的应用层封包方式。

缺点：

• 需要分别处理包头和包体；
• 必须校验长度，防止错误或恶意长度导致内存问题。

1
struct Node
2
{
3
    int a;
4
    char b[10];
5
    long c;
6
};

1
struct Node n1;
2
int nSize = sizeof(n1);
3

4
// 先发送数据包大小
5
send(sockClient, (char*)&nSize, sizeof(int), 0);
6

7
// 再发送数据包
8
send(sockClient, (char*)&n1, sizeof(n1), 0);

1
int nPackSize = 0;
2

3
// 先接收数据包大小
4
recv(sockClient, (char*)&nPackSize, sizeof(int), 0);
5

6
// 根据收到的大小申请空间
7
char* buf = new char[nPackSize];
8

9
// 再接收数据包
10
recv(sockClient, buf, nPackSize, 0);
11

12
delete[] buf;

1
struct Node* p = (struct Node*)buf;
2
cout << p->a << endl;

1
struct Node p1 = *(struct Node*)buf;
2
cout << p1.a << endl;

方法四：使用短连接#

每发送一条或一组数据就建立一次连接，发送结束后关闭连接。连接关闭可作为本次数据结束的标志。

优点：

• 消息边界容易确定。

缺点：

• 频繁进行三次握手和四次挥手；
• 连接建立与释放的开销较大；
• 不适合需要频繁通信的场景。

四种方法对比#

1. 为什么需要心跳#

TCP 长连接建立后，如果双方长时间没有业务数据，仅靠“当前没有收到消息”不能判断：

• 对方仍然在线，只是暂时没有发送数据；
• 对方程序已经崩溃；
• 对方主机断电；
• 中间网络已经断开；
• 连接实际上已经失效。

因此，可以定期发送很小的固定消息，用来检查对端是否仍然存活，这就是心跳机制。

2. 基本工作过程#

1
客户端                         服务端
2
   │────── 心跳请求 ──────────>│
3
   │<───── 心跳响应 ───────────│
4
   │                           │
5
   │  等待一个固定时间间隔     │
6
   │────── 心跳请求 ──────────>│
7
   │<───── 心跳响应 ───────────│

如果在规定时间内连续多次没有得到响应，程序可以认为连接已经失效，并执行：

• 关闭当前连接；
• 清理连接资源；
• 通知上层业务；
• 必要时尝试重新连接。

3. 两种实现方式#

1
int keepAlive = 1;
2
setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE,
3
           (char*)&keepAlive, sizeof(keepAlive));

1. 作用#

如果应用程序频繁发送很小的数据包，大量 TCP/IP 首部会增加网络开销。

Nagle 算法的目标是：

尽量把多个小数据合并成较大的数据段再发送，减少“小包”数量，提高网络利用率。

Nagle 算法通常默认开启。

2. 发送条件#

满足下列条件之一时，数据可以被发送：

1. 数据长度达到 MSS；
2. 数据中包含 FIN；
3. 设置了 TCP_NODELAY，即关闭 Nagle 算法；
4. 未设置 TCP_CORK 选项，并且此连接上先前发送的小数据已经全部收到确认；
5. 前面条件都不满足，但等待达到超时时间，通常按约 200 ms 理解。

3. MSS#

MSS 是 Maximum Segment Size，即最大报文段数据长度。

它表示一个 TCP 报文段中能够承载的最大应用数据量，不包含 TCP 首部和 IP 首部。

4. Nagle 算法的优缺点#

优点：

• 减少小数据包的数量；
• 减少协议首部开销；
• 提高带宽利用率。

缺点：

• 为了等待更多数据，可能增加发送延迟；
• 对交互性强、要求低延迟的程序不一定合适。

例如终端输入、实时操作等场景，可能更关注响应速度，因此会考虑关闭 Nagle 算法。

5. 使用 TCP_NODELAY 关闭 Nagle 算法#

1
int value = 1;
2
setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY,
3
           (char*)&value, sizeof(int));

含义：

• TCP_NODELAY = 1：关闭 Nagle 算法，小数据可以更及时地发送；
• TCP_NODELAY = 0：允许使用 Nagle 算法。

关闭 Nagle 并不等于程序一定更快，它是在“更低延迟”和“更少网络开销”之间作选择。

TCP_CORK 会让发送端尽量先积累数据、再组成较大的报文段发送；它与 TCP_NODELAY 的关注点不同，而且主要见于 Linux。当前阶段先记住它会影响“小数据是否立即发送”即可。

1. 什么是网络拥塞#

网络中的路由器和交换机，其处理速度与缓存空间都是有限的。

当发送方送入网络的数据过多、过快时，可能出现：

• 中间设备排队加剧；
• 网络时延升高；
• 缓存被占满；
• 数据包丢失；
• 发送方超时后再次重传；
• 重传又进一步增加网络负担。

如果不进行控制，可能形成“越丢越重传，越重传越拥塞”的恶性循环。

拥塞控制的目标是根据网络状态调整发送速度，避免向网络中一次注入过多数据。

拥塞控制还可以让共享网络资源的连接获得相对更公平的使用机会。但不同连接的网络路径、RTT 和丢包情况并不相同，因此这种公平是相对的，不是理论上的绝对平均。

2. 流量控制与拥塞控制的区别#

发送方真正能够发送而未确认的数据量，通常受两者共同限制：

1
实际发送窗口 = min(rwnd, cwnd)

3. 两个重要变量#

4. 四种拥塞控制算法#

1
RTT 次数：  0    1    2    3    4
2
cwnd：      1    2    4    8   16  MSS

1
慢开始：    1 → 2 → 4 → 8 → 16
2
拥塞避免： 16 → 17 → 18 → 19 → 20

1
ssthresh = 当前 cwnd / 2
2
cwnd = 1 MSS
3
重新进入慢开始

1
收到 3 个重复 ACK
2
        ↓
3
立即重传丢失的报文段
4
        ↓
5
ssthresh = 当前 cwnd / 2
6
        ↓
7
cwnd = ssthresh + 3 MSS
8
        ↓
9
每多收到一个重复 ACK，cwnd 再增加 1 MSS
10
        ↓
11
收到新的 ACK 后退出快恢复，进入拥塞避免

1
连接开始
2
   ↓
3
慢开始（指数增长）
4
   ↓ 达到 ssthresh
5
拥塞避免（线性增长）
6
   ├─ 发生超时 → 大幅减小 cwnd → 慢开始
7
   └─ 3 个重复 ACK → 快重传 → 快恢复 → 拥塞避免

1. TCP 的三个核心特点#

TCP 是：

1. 面向连接的协议；
2. 可靠传输的协议；
3. 基于字节流的传输协议。

2. 面向连接#

通信前，客户端和服务端需要先建立连接。

• 建立连接：三次握手；
• 释放连接：四次挥手；
• 一条 TCP 连接的两个端点之间进行点对点通信。

3. 可靠传输#

TCP 通过多种机制实现可靠传输，例如：

• 序列号 seq；
• 确认号 ack；
• 确认机制；
• 超时重传；
• 快重传；
• 校验；
• 失序数据重排；
• 合理分段。

4. 字节流与粘包#

TCP 不保留应用层消息边界，因此应用程序必须自行制定消息格式。

四种拆包方法：

1. 先发送包大小，再发送数据；
2. 添加开始或结束标志；
3. 固定包大小；
4. 使用短连接。

5. TCP 的控制机制#

• 流量控制：通过滑动窗口避免接收方来不及处理；
• 拥塞控制：通过慢开始、拥塞避免、快重传、快恢复调节网络中的数据量；
• 心跳或保活：发现长连接是否已经失效；
• Nagle 算法：减少网络中的小数据包。

6. TCP 是否支持广播#

TCP 面向连接，一条连接的通信端点是确定的，因此不能像 UDP 那样直接进行广播或组播。

1. 一个应用不一定只使用一种传输协议#

协议的选择应该服从具体业务，而不是简单地认为“整个软件只能使用 TCP”或“整个软件只能使用 UDP”。

同一个功能较复杂的应用，可以在不同场景中组合使用 TCP 和 UDP。例如：

• 游戏中的实时状态更新更看重及时性，可以考虑 UDP；
• 游戏中的文字聊天、购买或赠送物品更看重可靠性，可以考虑 TCP；
• 即时通信中的文字、文件传输更看重完整可靠，可以考虑 TCP；
• 实时音视频更看重低延迟，可以考虑 UDP；
• 以文件存取为核心的应用，可能主要使用 TCP。

FTP 是应用层的文件传输协议，其底层使用 TCP 提供可靠传输。

结论：

不要脱离业务直接问“TCP 和 UDP 哪个更好”，而要先判断该功能更重视可靠性、实时性，还是可控性。

2. 在 UDP 之上增加可靠机制#

UDP 本身不提供 TCP 那样的可靠传输，但应用层可以选择性实现部分可靠机制：

1. 为每个应用数据包增加序号 SEQ；
2. 接收方收到数据后返回确认 ACK；
3. 发送方启动定时器；
4. 在超时时间内没有收到确认，就重新发送；
5. 使用发送队列保存尚未确认的数据；
6. 引入滑动窗口，一次发送多个包，提高传输效率。

示意：

1
应用层发送队列：1  2  3  4  5  6  ...
2
当前窗口：      [1  2  3]
3
                    │
4
                    └── 收到 ACK=4 后，窗口向后移动
5
下一窗口：               [4  5  6]

这些机制的思想与 TCP 中的 SEQ、ACK、滑动窗口和超时重传相似，但实现位置从传输层变成了应用层。

3. 为什么不一定直接使用 TCP#

应用层在 UDP 之上实现可靠性，会比原始 UDP 增加开销，但可以只选取业务真正需要的能力。例如：

• 保留 UDP 的报文边界，不产生 TCP 字节流的拆包问题；
• 自行决定确认、重传和窗口策略；
• 不必照搬 TCP 的所有控制机制；
• 可以针对实时业务在可靠性与延迟之间作更细的取舍。

相应地，应用程序也必须自行承担更多工作，例如：

• 超时与重传；
• 顺序和去重；
• 发送窗口；
• 心跳与连接状态管理；
• 异常数据处理。

4. QUIC#

QUIC 是一种基于 UDP 的新型网络传输协议，由 Google 发起，并由互联网工程任务组（IETF）标准化为 RFC 9000。

它的核心目标是比 TCP 更快、更安全，目前已成为 HTTP/3 的底层传输协议。

简单来说，它改善了传统网络在弱网环境下速度慢、切换网络易断连等问题，已被多种互联网服务采用。

说明：可以以 UDP 为基础，在其上层增加可靠传输等能力，形成更符合特定需求的新协议。