tcp_fastopen在MongoDB副本集中基本无效，因其依赖短连接首次建连加速，而副本集使用长连接复用且驱动/服务端未启用TFO；真正提升吞吐需调优TCP缓冲区、窗口缩放、连接队列等内核参数，并协同WiredTiger缓存配置。
直接调用 tcp_fastopen 对 MongoDB 副本集的网络吞吐量提升非常有限，真正起效的是合理增大 TCP 缓冲区与调整连接队列——尤其在跨机房同步、高写入延迟场景下。
为什么 tcp_fastopen 在副本集里基本没用
MongoDB 副本集节点间通信（如 oplog 拉取、心跳、选举）使用长连接，且绝大多数连接在初始化后持续复用。而 tcp_fastopen 仅对「首次建连 + 立即发数据」的短连接有加速效果（绕过三次握手的一个 RTT），对已建立的持久连接完全不生效。
更关键的是：MongoDB 驱动和 mongod 进程本身并未启用 TFO 客户端支持（即使内核开了 net.ipv4.tcp_fastopen = 3），服务端也未在 socket 层调用 TCP_FASTOPEN 选项监听。实测开启前后，replication lag 和 network I/O wait 指标无统计学差异。
- 副本集流量本质是流式、连续、低频但高吞吐的 oplog 复制，不是大量短连接请求
-
tcp_fastopen的收益集中在 Web 类 HTTP 短连接场景，比如 nginx + upstream - 强行开启反而可能因中间设备（防火墙、负载均衡）不兼容导致连接失败
真正影响副本集网络吞吐的关键参数
瓶颈通常出现在内核 TCP 栈处理能力上：缓冲区太小导致频繁阻塞、接收队列溢出丢包、窗口缩放未启用限制最大带宽。这些才是跨机房同步慢、replSetGetStatus 显示 optimeDate 落后、secondary 同步卡顿的根源。
-
net.ipv4.tcp_rmem和net.ipv4.tcp_wmem：必须设为三元组，第三项（max）决定单连接理论最大接收/发送窗口。副本集建议设为"4096 65536 16777216"（即 16MB），避免因窗口小导致吞吐被限死 -
net.ipv4.tcp_window_scaling：必须为1，否则窗口无法突破 64KB，跨公网或高延迟链路（RTT > 50ms）时带宽利用率会暴跌 -
net.core.somaxconn和net.core.netdev_max_backlog：副本集心跳、选举、oplog fetch 请求并发高，需分别设为65535和5000，防止连接排队超时被丢弃 -
net.ipv4.tcp_slow_start_after_idle：设为0，避免长连接空闲后重置拥塞窗口，对持续复制流很关键
验证是否生效：别只看 sysctl 值
改完参数后，必须确认 mongod 进程实际使用的 socket 缓冲区大小，因为应用层可主动 setsockopt 覆盖内核默认值：
ss -i -t -n | grep :27017
输出中 rcv_space 和 snd_space 应接近你设的 tcp_rmem[2] 和 tcp_wmem[2]（如 16777216）。如果仍显示 212992 或 262144，说明 mongod 启动时未继承或被驱动覆盖，需检查启动参数或升级到 6.0+ 版本（WiredTiger 默认更积极使用大缓冲区）。
- 用
mongostat --host rs0/10.0.1.10:27017,10.0.1.11:27017观察netIn/netOut是否稳定增长，而非周期性毛刺 - 在 secondary 上执行
db.adminCommand({ "replSetGetStatus": 1 })，关注optimeDate与 primary 的差值是否收窄至秒级 - 用
iftop -P 27017确认流量是否持续打满链路带宽，而非断续抖动
复杂点在于：这些参数要逐节点调，且不同物理距离（同城 vs 跨省）需要的 tcp_rmem max 值不同；容易被忽略的是，wiredtiger_cache_size_gb 如果设得太小，会导致大量脏页刷盘挤占网络带宽——网络优化必须和存储层参数协同调整，单点调参意义不大。
