C/C++ Linux 应用开发面试：TCP 粘包拆包与协议帧解析

做 Linux 网络服务、嵌入式网关、采集 Agent 或设备通信程序时，面试官很容易从 socket 问到 TCP 粘包拆包、二进制协议、大小端、非阻塞 IO 和缓冲区设计。这个主题不考花哨框架，重点考你是否真正理解 TCP 是字节流，以及能不能用 C/C++ 写出稳定、可维护、低资源占用的协议解析代码。

岗位场景

Linux 设备侧或服务端程序
  -> 使用 TCP 长连接接收设备上报、控制命令或心跳
  -> 约定 magic/version/type/length/payload/crc 协议帧
  -> 处理半包、粘包、乱序业务消息、超时和连接断开
  -> 在嵌入式环境中控制内存、CPU、日志和异常恢复成本

这类题考的是 TCP 基础、C/C++ 内存模型、二进制编码、状态机、非阻塞 IO、边界检查和嵌入式资源意识。

高频面试题

1. TCP 为什么会出现粘包和拆包？

简洁答案：TCP 是可靠有序的字节流协议，不保留应用层消息边界。一次 send 写入的数据，接收端可能一次读到一部分、多条消息合并，或者任意组合。

关键知识点：

• TCP 只保证字节顺序和可靠到达，不保证应用层包的边界。
• Nagle、MSS、拥塞控制、内核缓冲区、接收端读取节奏都会影响分段。
• “粘包”不是 TCP 错误，而是应用层协议没有正确分帧。

C/C++ 落地思路：

• 不要假设一次 recv 就等于一个完整业务包。
• 接收缓冲区要支持累计数据、循环解析、保留半包。
• 协议必须明确消息边界，常见方式是固定长度、分隔符或长度字段。

// recv 只负责拿字节，parse_frames 才负责按协议切帧。
ssize_t n = ::recv(fd, buf, sizeof(buf), 0);
if (n > 0) {
    input.append(buf, static_cast<size_t>(n));
    parse_frames(input);
}

2. 二进制协议帧通常怎么设计？

简洁答案：常见做法是固定头部加可变 payload，头部包含 magic、version、type、length、sequence 和 checksum，接收端先解析头部，再按 length 等待完整 payload。

关键知识点：

字段	作用	面试追问点
magic	快速识别帧起点	如何从脏数据中重新同步
version	协议演进	老设备兼容策略
type	区分心跳、上报、命令	是否需要请求响应映射
length	标识 payload 长度	最大长度和越界保护
crc	检测传输或解析错误	CRC 覆盖哪些字段

C/C++ 落地思路：

• 协议头用明确宽度整数，例如 uint16_t、uint32_t。
• 不直接把网络字节流强转成 struct*，避免对齐、填充和大小端问题。
• 对 length 做上限校验，防止异常包导致内存暴涨。

constexpr uint16_t kMagic = 0xA55A;
constexpr uint32_t kMaxPayload = 64 * 1024;

struct FrameHeader {
    uint16_t magic;
    uint8_t version;
    uint8_t type;
    uint32_t length;
    uint32_t seq;
    uint16_t crc;
};

3. 为什么不能直接 reinterpret_cast<FrameHeader*> 解析网络包？

简洁答案：网络数据是连续字节，C/C++ 结构体可能有内存填充和对齐要求；不同 CPU 的大小端也可能不同，直接强转会带来可移植性和未定义行为风险。

关键知识点：

• struct 字段之间可能插入 padding。
• ARM 等平台对未对齐访问更敏感，嵌入式设备上尤其常见。
• 网络协议通常使用大端序，也就是 network byte order。

C/C++ 落地思路：

• 用显式读取函数从字节数组中取整数。
• 多字节字段统一走 ntohs、ntohl 或自定义解码函数。
• 如果为了落盘或网络传输使用 packed struct，也要谨慎隔离在序列化层。

uint32_t read_u32_be(const uint8_t* p) {
    return (static_cast<uint32_t>(p[0]) << 24) |
           (static_cast<uint32_t>(p[1]) << 16) |
           (static_cast<uint32_t>(p[2]) << 8) |
           static_cast<uint32_t>(p[3]);
}

4. 接收缓冲区如何处理半包和多包？

简洁答案：维护一个输入缓冲区，每次读取后循环解析：数据不足头部就等待，头部完整但 payload 不足也等待，完整帧解析成功后从缓冲区消费掉对应字节。

关键知识点：

• 半包：当前缓冲区不足以组成完整帧。
• 多包：当前缓冲区包含多个完整帧，需要循环处理。
• 脏数据：magic 不匹配时要丢弃或扫描到下一个可能帧起点。

C/C++ 落地思路：

• 小型程序可用 std::vector<uint8_t> 或 std::string 保存接收字节。
• 高频服务可用 ring buffer 降低移动内存成本。
• 解析函数要返回“需要更多数据、成功、协议错误”这类明确状态。

enum class ParseResult { NeedMore, Ok, BadFrame };

ParseResult try_parse_one(std::vector<uint8_t>& in) {
    constexpr size_t kHeaderLen = 14;
    if (in.size() < kHeaderLen) return ParseResult::NeedMore;

    uint16_t magic = static_cast<uint16_t>((in[0] << 8) | in[1]);
    if (magic != kMagic) return ParseResult::BadFrame;

    uint32_t len = read_u32_be(&in[4]);
    if (len > kMaxPayload) return ParseResult::BadFrame;
    if (in.size() < kHeaderLen + len) return ParseResult::NeedMore;

    // handle payload: in[kHeaderLen, kHeaderLen + len)
    in.erase(in.begin(), in.begin() + kHeaderLen + len);
    return ParseResult::Ok;
}

5. recv 和 send 在非阻塞模式下要注意什么？

简洁答案：非阻塞 IO 里 recv 和 send 可能只读写一部分数据，也可能返回 EAGAIN 或被信号打断返回 EINTR。业务层必须维护输入和输出缓冲区。

关键知识点：

• recv 返回 0 表示对端有序关闭连接。
• EINTR 可以重试，EAGAIN/EWOULDBLOCK 表示当前没有数据或无法继续写。
• send 成功返回的字节数可能小于待发送长度。

C/C++ 落地思路：

• socket 设置 O_NONBLOCK 后配合 epoll。
• 写侧维护 pending buffer，只在 fd 可写时继续发送剩余数据。
• 不在事件循环里无限重试，避免单连接占满 CPU。

ssize_t n = ::send(fd, out.data() + sent, out.size() - sent, MSG_NOSIGNAL);
if (n > 0) {
    sent += static_cast<size_t>(n);
} else if (errno == EINTR) {
    // retry later in the same state
} else if (errno == EAGAIN || errno == EWOULDBLOCK) {
    // wait for EPOLLOUT
} else {
    close_connection(fd);
}

6. epoll 的 LT 和 ET 模式有什么区别？

简洁答案：LT 是水平触发，只要 fd 仍可读或可写就会继续通知；ET 是边缘触发，只在状态变化时通知，通常要求非阻塞 fd，并一次读到 EAGAIN。

关键知识点：

• LT 更容易写对，适合多数业务服务。
• ET 事件更少，但读写循环没有 drain 到 EAGAIN 时容易丢事件。
• 嵌入式网关连接数有限时，KISS 原则下优先选择更简单可靠的 LT。

C/C++ 落地思路：

• 所有 epoll fd 都设置非阻塞。
• ET 模式下读循环必须持续 recv，直到返回 EAGAIN/EWOULDBLOCK。
• 对每个连接保存独立状态，避免把协议状态放在临时栈变量里。

for (;;) {
    ssize_t n = ::recv(fd, buf, sizeof(buf), 0);
    if (n > 0) append_and_parse(fd, buf, n);
    else if (n == 0) { close_connection(fd); break; }
    else if (errno == EINTR) continue;
    else if (errno == EAGAIN || errno == EWOULDBLOCK) break;
    else { close_connection(fd); break; }
}

7. 嵌入式场景下协议解析最容易踩哪些坑？

简洁答案：最常见的是没有长度上限、日志过量、缓冲区拷贝太多、异常包导致状态机卡死、连接断线后资源没有释放。

关键知识点：

• 嵌入式设备内存小，不能按客户端输入随意扩容。
• 网络抖动常见，心跳、超时和重连策略必须明确。
• 串口、CAN、TCP 网关类协议都需要处理半包和重同步。

C/C++ 落地思路：

• 对 payload、连接数、发送队列、日志频率都设置上限。
• 用状态机表达解析阶段，不用散落的布尔变量拼逻辑。
• 对异常包计数，超过阈值断开连接，避免一直扫描脏流量。

WAIT_HEADER
  -> header complete and length valid -> WAIT_PAYLOAD
  -> bad magic -> RESYNC
WAIT_PAYLOAD
  -> payload complete and crc ok -> DISPATCH
  -> timeout or crc bad -> DROP_OR_CLOSE

8. CRC、校验和和超时应该放在什么位置？

简洁答案：CRC 用来确认帧内容没有损坏或错位，超时用来避免半包长期占用连接状态。一般在完整帧到齐后校验 CRC，通过后再交给业务层处理。

关键知识点：

• TCP 已有传输层校验，但应用层 CRC 可以发现协议错位、串口桥接错误或设备固件缺陷。
• CRC 覆盖范围要写进协议文档，常见是 header 部分字段加 payload。
• 半包超时和心跳超时是两个概念，不要混在一起。

C/C++ 落地思路：

• 连接状态记录 last_read_at、frame_start_at、last_heartbeat_at。
• 半包超过阈值可以丢弃当前帧或断开连接。
• CRC 失败要输出 frame metadata，不要直接打印完整 payload，避免日志泄露和刷爆磁盘。

C/C++ 落地设计小结

socket read
  -> input buffer
  -> frame parser
       -> magic/version/length check
       -> payload completeness check
       -> crc check
  -> message dispatcher
  -> business handler
  -> output buffer
  -> socket write

最小可用设计：

• 协议层只负责字节到消息，不掺业务逻辑。
• 业务层只处理完整消息，不直接操作半包缓冲区。
• IO 层只处理 fd 读写、错误码和连接生命周期。
• 日志只记录关键元数据和错误原因，避免在嵌入式设备上输出大 payload。

学习要点

• TCP 是字节流，应用层必须自己分帧。
• 二进制协议要处理长度、大小端、对齐、版本和校验。
• C/C++ 网络程序必须严肃处理 partial read/write、EINTR、EAGAIN。
• epoll ET 模式需要 drain 到 EAGAIN，否则容易出现偶现卡死。
• 嵌入式程序要优先考虑内存上限、异常恢复、日志控制和状态机可读性。

小练习/复盘题

1. 设计一个 magic + version + type + length + payload + crc 协议帧，并写出每个字段的字节数。
2. 写一个 read_u16_be 和 read_u32_be，说明为什么不用结构体强转。
3. 给出一个输入缓冲区循环解析流程，覆盖半包、多包和坏 magic。
4. 解释 recv 返回 0、EINTR、EAGAIN 分别应该怎么处理。
5. 说明 epoll ET 模式下为什么必须把 socket 读到 EAGAIN。
6. 如果设备内存只有 64MB，你会给 payload、连接数和发送队列设置哪些上限？