该用TCP_CORK而非TCP_NODELAY时：需批量发送小数据且明确后续还有内容，以提升吞吐；而TCP_NODELAY适用于低延迟敏感的独立请求（如RPC、心跳）。两者互斥，混用易致行为异常。
什么时候该用 TCP_CORK 而不是 TCP_NODELAY
TCP_CORK 和 TCP_NODELAY 是互斥策略：前者攒包，后者禁 Nagle 立即发。如果你在批量写入（比如连续 write() 多段小数据，且明确知道后续还有内容），用 TCP_CORK 更合适；若你发的是独立、低延迟敏感的请求（如 RPC 响应、心跳），则选 TCP_NODELAY。混用会导致行为不可控——TCP_CORK 会覆盖 Nagle，但设了 TCP_NODELAY 后再设 TCP_CORK，内核实际按 TCP_NODELAY 行为执行。
setsockopt 设置 TCP_CORK 的正确姿势
必须确保 socket 已连接（connect() 或 accept() 成功后），且在写入前启用、写完后及时关闭。常见错误是忘记关 cork，导致最后一批数据卡住长达 200ms 才发出。
- 启用：
int cork = 1; setsockopt(sockfd, IPPROTO_TCP, TCP_CORK, &cork, sizeof(cork)); - 写入多段数据：
write(sockfd, buf1, len1); write(sockfd, buf2, len2); ... - 关闭：
cork = 0; setsockopt(sockfd, IPPROTO_TCP, TCP_CORK, &cork, sizeof(cork)); - 不要在非阻塞 socket 上依赖 cork 的“自动超时”——它仍会等满 200ms，期间
write()可能返回EAGAIN，需自行处理重试逻辑
TCP_CORK 在文件传输中容易被忽略的陷阱
直接对大文件循环 read()+write() 并开启 TCP_CORK，效果往往不如预期。原因在于：每次 read() 返回的数据量受文件系统页缓存、磁盘 I/O 调度影响，不一定凑成 MTU（通常 1448~1500 字节）；而 TCP_CORK 只在内核发送队列有未确认小包时才努力拼接，若上层写入节奏慢（>200ms 间隔），它就直接发出去了。
- 真正起效的前提是：应用层能控制写入节奏，比如把多个逻辑消息预打包进一个缓冲区，再一次性
write() - 配合
sendfile()时，TCP_CORK无效——sendfile()绕过用户态，内核直接从文件页缓存推数据到 socket 发送队列，不经过 cork 判断路径 - 虚拟机环境下（如 Ubuntu VM），还需检查
net.ipv4.tcp_low_latency是否为 0；设为 1 会削弱 cork 效果
为什么有时候开了 TCP_CORK 反而更慢
核心问题在于「延迟 vs 吞吐」的权衡被误用。CORK 不是万能加速器，它只在满足「高频小写 + 明确结尾」时提升吞吐；否则会引入确定性延迟。
立即学习“C++免费学习笔记（深入）”；
- 单次写入就关闭 cork（即只写一段数据就
cork=0），相当于白开——没攒到包，还多一次系统调用 - 在高丢包网络中，cork 会加剧 ACK 延迟感知，导致拥塞窗口增长变慢，反而降低整体吞吐
- 与
SO_SNDBUF过小叠加时，cork 数据可能填不满发送缓冲区，内核提前触发发送（即使没到 MTU），失去优化意义
最稳妥的做法是：先用 wireshark 抓包观察实际报文大小和间隔，确认是否真存在大量 TCP_CORK 并严格配对启停逻辑。
