凌晨 2:10，香港葵涌机房 11 楼，空调风声比平时大一点。IM 实时消息延迟告警又亮了，深圳、长沙、成都三地同时飙红。丢包 0.5%—1.8%，RTT 抖动 20–80ms。运维值守只有我一个人。我盯着 mtr 曲线和 p99 延迟，心里清楚：这不是带宽问题，是弱网络下小包实时流被 TCP 拖慢了。

这一次，我决定把“薄流优化”（TCP Thin Streams）彻底吃透，哪怕把内核参数翻个底朝天。

场景与目标

• 业务形态：长连接小包实时通信（IM 心跳 + 文本消息 + 在线状态），每条消息几十到几百字节，典型“薄流”（thin stream）。
• 网络路径：内地各地宽带 → 国际出口 → 香港机房（跨境路径，不稳定、拥塞点多、队列深）。
• 痛点：少量丢包 + 抖动导致指数级 RTO 回退、迟迟不快速重传，用户端“发已读却卡 2–5 秒才同步”。

目标：

在 CentOS 7（3.10 系内核） 上启用并验证 TCP Thin Streams 相关优化，使弱网络下的小包实时流更快重传、更少指数退避、更稳时延，并配合网卡与队列策略把尾延迟压下来。

1. 环境与硬件参数（真实机房口径）

基线网络画像（凌晨 1:30–2:00 实测）

备注：消息体小、拥塞信号稀疏，传统 TCP 快速重传触发不积极；一旦 RTO，指数退避把实时性拖垮。

2. TCP Thin Streams 是什么，为什么对小包实时流有效？

Thin Stream（薄流）：指在任意时刻在网内“飞行”的报文段很少（拥塞窗口小、报文小、节奏稀）。

问题：

• 快速重传通常需要 3 个重复 ACK，薄流很难凑齐。
• RTO 指数退避（1x→2x→4x…）对实时业务“过于保守”。

Linux 内核的两项“薄流”优化：

• tcp_thin_dupack：在薄流条件下，1 个重复 ACK 就触发快速重传（而不是等 3 个）。
• tcp_thin_linear_timeouts：在薄流条件下，RTO 线性回退（更温和），避免指数爆炸。
• CentOS 7 的 3.10 系内核已包含这两项开关（RHEL 回溯过多项 TCP 补丁）。我们的工作是确认、启用、压测、联动调优。

3. 变更方案总览（一步到位清单）

3.1 内核参数（/etc/sysctl.d/99-thin-streams.conf）

# 让薄流更积极地恢复丢包
net.ipv4.tcp_thin_dupack = 1
net.ipv4.tcp_thin_linear_timeouts = 1

# 小包实时流常用的辅助参数（按需启用、逐项验证）
net.ipv4.tcp_fastopen = 3            # TFO client+server（仅对新建连接有益）
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1         # 避免路径 MTU 异常导致黑洞
net.ipv4.tcp_autocorking = 0         # 减少自动合包延迟（需验证是否存在该回溯）
net.ipv4.tcp_tw_reuse = 1            # 高并发短连接环境更友好（长连接影响小）

# 缓冲与窗口（按真实带宽-时延积 BDP 设上限，不要盲目拉满）
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 26214400
net.ipv4.tcp_wmem = 4096 65536 26214400

# ECN 在跨境路径上未必友好，默认保持关闭（0）；若路径可用再评估开启（1/2）
net.ipv4.tcp_ecn = 0

加载与校验：

sysctl --system
sysctl -a | egrep 'tcp_thin|tcp_autocorking|tcp_(r|w)mem|tcp_fastopen'

提醒：tcp_autocorking 是否存在视 3.10 回溯情况而定；若不存在，忽略即可。

3.2 网卡与队列（抑制尾延迟）

开启 fq_codel（3.10 有）

tc qdisc replace dev eth0 root fq_codel
tc -s qdisc show dev eth0

中断合并（示例）——减少批量等待（以 X710 为例）：

# 先看当前
ethtool -C eth0
# 适度下调 RX 合并时间（微秒），避免小包排队过久
ethtool -C eth0 rx-usecs 20 rx-frames 1 tx-usecs 0
# 视丢包与 CPU 观察值微调（10–40us 之间找平衡）

Ring 缓冲：避免过大导致排队延迟，也不能太小丢包：

ethtool -g eth0
ethtool -G eth0 rx 1024 tx 1024

多队列与 RSS：确保中断/软中断有足够 CPU 并行度：

ethtool -l eth0
# 根据 CPU 核心与 NUMA 拓扑合理设置 combined/rx/tx 数（例如 8 或 16）

3.3 应用层 Socket 选项（以 Go/Python 为例）

禁用 Nagle（TCP_NODELAY），配合小包实时：

// Go 示例（net.TCPConn）
conn, _ := net.DialTCP("tcp", nil, raddr)
conn.SetNoDelay(true)           // TCP_NODELAY
conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(30 * time.Second)

# Python 示例
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
# Linux keepalive 细化（秒）
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 10)
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)

TFO（TCP Fast Open）：仅对新建连接减少 1 RTT；长连接为主的场景收益有限，但可作为补充。记得服务端监听套接字同时开启（TCP_FASTOPEN 选项）。

3.4 可选：升级内核以用 BBR（非本次主角）

若你确实需要进一步压低排队延迟，可用 ELRepo 安装 kernel-ml（≥4.9 有 BBR，5.x 更稳），然后：

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

但本文核心在 3.10 下的 Thin Streams；BBR 作为后手方案。

4. 变更前的实验复刻（可在灰度机做）

使用 tc netem 复刻跨境弱网：

# 80±20ms 延迟，丢包 0.8%，1% 概率的乱序（幅度 50%）
tc qdisc replace dev eth0 root netem delay 80ms 20ms 25% loss 0.8% reorder 1% 50%

压测脚本（Go，小包突发 + 心跳）：

// 省略连接建立...
// 每 50ms 发一条 120bytes 小包，间或突发 10 条
payload := make([]byte, 120)
ticker := time.NewTicker(50 * time.Millisecond)
for {
    select {
    case <-ticker.C:
        conn.Write(payload)
        if rand.Intn(100) < 5 { // 5% 概率突发
            for i := 0; i < 10; i++ {
                conn.Write(payload)
            }
        }
    }
}

观测指标：

• 服务端：应用确认耗时（毫秒），ss -tin 中拥塞窗口、重传计数。
• 系统：sar -n TCP,DEV 1、netstat -s、tc -s qdisc。
• 端到端：消息发送→服务端 ACK 的 p50/p95/p99。

5. 实操步骤（我在机房那一夜的命令清单）

确认内核具备薄流开关

sysctl -a | egrep 'tcp_thin_dupack|tcp_thin_linear_timeouts'
# 两项都能查到即 OK；查不到再确认内核版本或回溯情况

落盘参数并加载

cat >/etc/sysctl.d/99-thin-streams.conf <<'EOF'
net.ipv4.tcp_thin_dupack = 1
net.ipv4.tcp_thin_linear_timeouts = 1
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_autocorking = 0
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 26214400
net.ipv4.tcp_wmem = 4096 65536 26214400
net.ipv4.tcp_ecn = 0
EOF

sysctl --system

队列策略与网卡

# 队列：fq_codel
tc qdisc replace dev eth0 root fq_codel

# 中断合并：先备份再调整
ethtool -C eth0 rx-usecs 20 rx-frames 1 tx-usecs 0
ethtool -G eth0 rx 1024 tx 1024

应用层确认

• 强制 TCP_NODELAY。
• 连接保活参数按上文设置。
• 服务端若用 Nginx/Tengine 反代 TCP（stream），注意 proxy_socket_keepalive on; 等细节。

灰度与回滚

• 先在 2 台接入上生效，流量镜像 5%，观察 30 分钟。
• 回滚很简单：sysctl -w net.ipv4.tcp_thin_dupack=0; sysctl -w net.ipv4.tcp_thin_linear_timeouts=0；队列策略回退 tc qdisc del dev eth0 root。

6. 实测数据（开启前后对比）

A/B 灰度 30 分钟，深圳 & 长沙 & 成都 三地采样

观察到 tcp_thin_dupack=1 是贡献最大的单项，其次是 fq_codel 对尾延迟的改善；autocorking=0 在我们这套代码路径下也有正向作用（减少内核自动延迟合包）。

7. 关键细节与坑位记录

tcp_autocorking 不一定存在
某些 3.10 变体未回溯该开关。若 sysctl -a 查不到，就不要强行设置；业务层可以用 TCP_NODELAY、MSG_MORE 来明确控制分包/合包。

tcp_fastopen 不是银弹
我们是长连接场景，TFO 对首包有益，但总体验证收益不大；若你是频繁短连接（HTTP/短 RPC），TFO 更划算。注意中间盒兼容性，必要时只开客户端侧。

ECN 在跨境路径上经常被中间设备“整活”
默认关；要开也请先做路径探测（tracebox/iperf）与灰度。

网卡中断合并不要一刀切
X710 在 10–40µs 都能跑；如果 CPU 紧张、丢包增加，稍微加大 rx-usecs，并结合 irqbalance 与 RPS/RFS 做 CPU 亲和优化。

fq_codel 很好用，但别忘了观测
tc -s qdisc 观察 ecn_mark/drops，若丢弃升高且 RTT 并未改善，说明上游更拥塞，需要路径侧合作（边缘网关、上游运营商）。

应用层最好做“弱网感知”
我们增加了单连接滑动窗口测量，若 RTT 抖动/丢包超过阈值，业务层临时增大发送冗余或切换临近 POP。

8. 监控与告警（上线后我加了这些）

Kernel：netstat -s 的 segments retransmited、TCPTimeouts、TCPLossProbes（若回溯）。

Socket：ss -tin 抽样抓 rto, cwnd, retrans.

队列：tc -s qdisc show dev eth0，关注 backlog, drops.

应用：端到端确认时延 p50/p95/p99；丢失重发占比；异常事件（重连、踢线）。

业务 KPI：消息“已读”延迟投诉率、超时重试比、异常断开数。

9. 变更清单（最终可执行脚本）

脚本：enable-thin-streams.sh

#!/usr/bin/env bash
set -euo pipefail

CONF=/etc/sysctl.d/99-thin-streams.conf

cp -a ${CONF}{,.bak.$(date +%F-%H%M)} 2>/dev/null || true
cat > $CONF <<'EOF'
net.ipv4.tcp_thin_dupack = 1
net.ipv4.tcp_thin_linear_timeouts = 1
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
# 存在则生效，不存在忽略
net.ipv4.tcp_autocorking = 0

net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 26214400
net.ipv4.tcp_wmem = 4096 65536 26214400

net.ipv4.tcp_ecn = 0
EOF

sysctl --system

# 队列策略
tc qdisc replace dev eth0 root fq_codel

# 网卡示例调优（按需微调）
ethtool -C eth0 rx-usecs 20 rx-frames 1 tx-usecs 0 || true
ethtool -G eth0 rx 1024 tx 1024 || true

echo "[OK] Thin Streams baseline applied."

回滚：disable-thin-streams.sh

#!/usr/bin/env bash
set -euo pipefail
sysctl -w net.ipv4.tcp_thin_dupack=0
sysctl -w net.ipv4.tcp_thin_linear_timeouts=0
tc qdisc del dev eth0 root || true
echo "[OK] Thin Streams disabled."

10. FAQ：几个常见追问

启用后会不会更容易误判重传，放大抖动？
在薄流条件下早触发只针对“小在途量”的连接；我们在线观察，重传量增加有限，但早恢复带来的时延收益明显。若你的链路特性相反（乱序极多），请配合 reorder 场景再评估。

和 BBR 冲突吗？
不冲突。BBR 是拥塞控制算法，Thin Streams 是丢包与超时恢复策略的补刀。升级内核用 BBR 后，薄流开关依然有意义（但收益相对小些）。

UDP 会更好吗？
某些实时场景（语音、视频）确实更适合 UDP + FEC。但IM/状态同步常要可靠有序，TCP 仍主流。Thin Streams 让 TCP 在“少量丢包+抖动”条件下没有那么保守。

11. 收尾：那一夜之后

“凌晨 3:05，三地 p99 逐步回落到 400ms 左右，工单曲线明显下来了。
我靠在机柜门上喘口气，耳边是风冷和交换机的白噪。
事情并不神奇——只是让 TCP 在‘薄流’这类少见但真实的场景里更像人一点：别太怂，丢了赶紧补；别一丢就退避到天荒地老。
第二天早会，我把这套实践拍成变更模板。大家都笑，说这像是‘给 TCP 喝了半杯红牛’。
我说，不是红牛，是尊重现场。”

12. Checklist（给后来者）

•  sysctl -a 能看到 tcp_thin_*
•  /etc/sysctl.d/99-thin-streams.conf 已落盘
•  tc qdisc replace dev eth0 root fq_codel 已生效
•  网卡中断合并与 ring 已按 CPU/负载校准
•  应用层 TCP_NODELAY、Keepalive 就位
•  灰度验证 30–60 分钟，观察 p95/p99/重传/退避
•  回滚脚本可用，执行过演练

如果你也在香港机房、也在被跨境弱网络折磨，不妨按上面步骤做一轮。先灰度、再放量、持续观测。薄流优化并不神秘，但它特别“懂”小包实时流的焦虑——也许这就是我们要的那点“温度”