立即确认模式
TCP 默认使用延迟确认：收到数据后并不马上回 ACK，而是等待一小段时间以合并确认、减少包量。对请求响应型的小交互，这段等待会让每次往返多出毫秒级延迟。TCP_QUICKACK 用来让内核对本连接立即发送确认。它不是一个持久开关：部分内核会在后续收包后把状态重置，需要按交互节奏重新设置。
基本信息
| 适用平台 | Linux（同名选项来源为 Linux 扩展） |
|---|---|
| 取值 | 1 使用立即确认，0 恢复默认延迟确认 |
| 默认状态 | 延迟确认，等待时间受本端确认超时定时器影响 |
| 持久性 | 非持久，内核可能重置，需重复设置 |
| 搭配 | 与 Nagle 关闭策略一起评估 |
典型使用场景
- 小请求响应型服务出现固定量级的延迟尖刺，怀疑与延迟确认叠加有关。
- 数据库或缓存客户端在单连接上与固定延迟叠加相关的问题定位。
- 压测中需要验证瓶颈到底在确认等待还是在应用处理。
- 长连接上偶发的慢请求归因，排除是否由确认定时器造成。
- 确认 Nagle 关闭后延迟是否仍然存在，以判断还要不要处理确认侧。
C 用例
C 用例
int one = 1;
if (setsockopt(fd, IPPROTO_TCP, TCP_QUICKACK, &one, sizeof(one)) < 0) {
perror("setsockopt TCP_QUICKACK");
}
/* 该状态可能被内核重置，关键交互之后需要重新设置 */确认瓶颈位置
确认瓶颈位置
ss -ti 'sport = :3306' | head # 观察 rtt 与确认超时相关字段
ss -tin state established 'sport = :3306' # 不解析服务名，便于脚本化
tcpdump -ni eth0 -ttt 'tcp port 3306' -c 20 # 看连续报文之间的时间间隔是否成固定量级
strace -c -p 12345 -f # 看应用读写次数，排除应用侧逐次小写现象与处置
| 观察到的现象 | 可能原因 | 处置方向 |
|---|---|---|
| 延迟成固定量级且很有规律 | 延迟确认与 Nagle 叠加 | 先合并写，再评估立即确认 |
| 包量上升、延迟略降 | 立即确认的代价显现 | 评估是否只对关键连接开启 |
| 延迟无规律、波动大 | 多半不是确认侧问题 | 转向锁、IO 与调度方向排查 |
延迟确认与 Nagle 要一起评估：先抓包确认瓶颈是确认等待还是发送侧攒包，再决定改哪一侧。
在吞吐型连接上强制立即确认会增加包量与处理开销，通常得不偿失；改动前用压测对比整体指标，而不是只看单次请求延迟。