交易系统在弱网环境下的重传与超时参数调优，核心思路是让TCP层重传更快响应丢包、应用层超时设置更宽一档，两层拉开梯度，避免一次网络抖动直接触发订单失败。
交易系统弱网优化方案：先分清两个层级的职责
弱网落到交易链路上，典型表现就两种：丢包和延迟抖动，很多人调参时把TCP重传和应用层超时混为一谈，结果调了半天，问题依旧，先搞清楚各自的位置,方案才不会跑偏。
重传是TCP的自动反应，超时是应用层的判断
TCP重传发生在操作系统内核协议栈里，应用层代码根本感知不到，你发一个订单消息，内核发现ACK没回来，自己就悄悄重发了，整个过程对交易系统是透明的，应用层只知道"这条消息怎么还没回应"。
应用层超时则是交易系统自己设定的等待上限，比如订单请求发出去后，系统说好等2秒，2秒内没收到交易所确认，就判定订单超时,接着走撤单或重发逻辑。
两个机制是串联关系：
- 消息发出 → TCP检查是否需要重传 → 等ACK
- 应用层同时倒计时 → 超时触发业务动作
弱网下最难受的地方在于：TCP还在老老实实重传，应用层却先失去耐心直接超时了，反过来，应用层给了足够耐心，TCP又因为重传参数过于保守，迟迟不重发丢掉的包,消息活活卡死。
两层参数为什么不能各自为政
行业共识认为，交易系统调优最忌讳的是只调一头，只调TCP不调应用层，内核层把丢包恢复了，但应用层超时早就触发，该走的流程已经走了，只调应用层不调TCP，超时放宽了，可是TCP重传太慢,消息送达时间照样不可控。
所以调优的第一步，是同时打开两侧的配置文件，一起看,一起改。
TCP重传超时参数怎么调：四个关键旋钮
Linux内核里跟TCP重传相关的参数不少，但交易系统真正需要动手的,主要是下面四个。
RTO初始值与最小RTO
RTO（Retransmission Timeout）决定"多久没收到ACK就触发重发"，Linux默认的RTO初始值在1秒左右，这个值对交易系统来说太漫长了，内核同时提供了一个下限参数，用来约束RTO的最小值,防止计算出来的等待时间过短导致频繁重发。
弱网调优时，可以把最小RTO调低，让重传更快介入,查询和设置方式：
sysctl net.ipv4.tcp_rto_min sysctl -w net.ipv4.tcp_rto_min=50
注意，RTO是动态计算的，内核会根据实时RTT（往返时间）自动调整，直接把最小RTO调到极低值，在延迟本来就稳定的链路上影响不大，但在抖动明显的链路上可能导致过度重传,反而加剧拥塞。
重传次数上限
Linux提供两个关键参数：
tcp_retries1：默认值对应大约3次重传，低于这个次数时，内核只重传，不做路由切换判断tcp_retries2：默认值对应大约15次重传，超过这个次数后，内核直接放弃连接
交易场景下，15次重传等于是给连接留了相当长的存活时间，弱网环境里，连接挂死比延迟更可怕，业内专家指出，把tcp_retries2收窄到对应5-8次重传的范围，能让内核更早放弃坏连接,应用层也好更快感知异常。
sysctl -w net.ipv4.tcp_retries2=8
快速重传与SACK
快速重传机制允许TCP在收到3个重复ACK时立即重发，不用傻等RTO超时，这个机制对交易系统价值很大,因为它把丢包恢复时间从秒级降到了毫秒级。
SACK（选择性确认）是快速重传的好搭档，它让接收方明确告诉发送方"哪些段丢了，哪些到了"，发送方只需要补发缺失部分，不用把后面所有数据都重传一遍，对于批量行情数据同步,这个机制能省下不少带宽。
确认当前内核是否开启：
sysctl net.ipv4.tcp_sack sysctl net.ipv4.tcp_fack
两个值都应该是1，如果不是，直接用sysctl -w开启，或者写入/etc/sysctl.conf持久化。
一个可落地的调整顺序
别一次性全改完，按下面的顺序来,每改一步观察一段时间：
- 先把
tcp_sack和tcp_fack确认开启，收益最大且几乎无副作用 - 再调低
tcp_rto_min，从默认值逐步降到100ms级别 - 然后收紧
tcp_retries2，从默认15次左右降到8次左右 - 最后调整
tcp_retries1，一般保持默认就好
应用层超时参数：订单、心跳、行情要分开设
应用层超时不是统一一个值走天下，交易系统里至少有三类超时,各自场景差异很大。
订单超时的梯度设计
订单超时是整个系统里最敏感的参数，设太短，弱网抖动时正常订单被误杀，产生大量废单，设太长，排队订单越积越多,后面请求全部延迟。
比较实用的做法是参考正常延迟的分位值来定，先统计正常行情下订单从发出到确认的延迟分布，取P99延迟，然后在这个基础上放宽50%到一倍作为超时阈值，如果专线环境下订单确认延迟P99是80ms，那超时设在150ms到200ms之间就相对合理，公网环境延迟高一些，P99可能在200ms上下,超时阈值就要相应放宽到500ms左右。
心跳与断线重连
FIX协议或者自定义长连接都有心跳机制，用来探测连接是否还活着，心跳超时设太短，网络抖动稍微大一点就误判对端离线，直接断开连接,这在弱网下是相当一部分连接闪断的根源。
心跳间隔和超时次数要配合着看，业内比较稳妥的做法是：心跳间隔保持默认（比如30秒），把超时次数放宽到3次以上，这样一次心跳丢失不会立刻断连,连续多次丢失才判定链路故障。
断线重连的重试次数和间隔同样值得调，重试间隔用递增策略，从1秒开始，每次翻倍，最多到10秒左右封顶，连续重试太频繁,反而加剧弱网链路的拥塞。
行情重传请求
行情这块容易被忽略，组播行情丢包后，接收端靠序列号间隙发现缺口，然后向重传服务器发起补包请求，这个请求如果超时设太短，缺口补不回来，行情快照就不完整，如果设太长,补包数据到达时已经失去了时效性。
行情重传请求的超时建议比订单超时更宽松，因为行情数据对实时性的要求是"越快越好"，但即使晚到300ms依然有拼接价值，实际项目中,行情重传请求超时设在500ms到1秒之间是主流做法。
弱网场景的验证方法：先模拟再上线
参数调完不能直接上生产，用网络模拟工具造一个可控的弱网环境,验证参数是否真的扛得住。
用tc命令制造弱网
在测试服务器上执行下面的命令,可以模拟固定延迟和丢包：
tc qdisc add dev eth0 root netem delay 100ms loss 5%
延迟和丢包率要根据目标场景来设定，移动端弱网建议模拟延迟200ms、丢包10%的组合，跨地域专线则模拟延迟50ms、丢包1%更贴近真实。
测试结束后记得清理：
tc qdisc del dev eth0 root
观察哪些指标
验证阶段重点看三个数据：
- 订单成功率：弱网模拟前后对比，成功率不掉点是底线
- 订单响应延迟：看P50和P99两个值，P99比P50更能反映尾部延迟
- TCP重传率：用
netstat -s查看重传统计，或者用ss -i看单连接的重传次数
如果重传率明显高于正常水平，说明RTO参数调整方向不对，重传太过激进，如果订单成功率下降,多半是应用层超时设得太紧。
专线与公网的区别对待
专线环境丢包率普遍很低，延迟波动也小，TCP参数保持相对保守即可，重点优化应用层超时的精度，公网环境延迟和丢包都不可控，TCP层要更积极,RTO下限和重传上限都得拉开空间。
移动端交易场景还有一层特殊性，用户拿着手机走过信号不好的区域，网络路径直接变化，TCP原有的连接状态全废了，这种情况下，与其指望TCP参数，不如在应用层把重连做得更快、更果断。
交易系统弱网优化常见问题
交易软件网络超时设置多少合适？
取决于链路类型和交易品种，专线下订单超时设在100ms到300ms之间是常见区间，公网上需要放宽到500ms以上，移动端弱网环境甚至要放到1秒以上，心跳超时建议是心跳间隔的3倍以上，别用固定的秒数一刀切，行情重传请求超时相对固定,500ms到1秒是比较均衡的区间。
弱网下优先调TCP重传还是应用层超时？
先确认瓶颈在哪，用ss -i查看连接的重传次数和RTT，如果丢包频繁但重传很快恢复，问题多半出在应用层超时太紧，如果重传拖了很久才恢复，队列里积压了大量消息，那就该回头调TCP参数，实际场景中，先把TCP重传的SACK和RTO下限调好，再回头放宽应用层超时,这个顺序踩坑最少。
期货交易系统弱网参数配置有没有通用模板？
没有放之四海皆准的模板，但可以参考一个基础起点，TCP层开SACK，tcp_rto_min设为50ms到100ms，tcp_retries2保持在8次左右，应用层订单超时取正常延迟的P99再放宽一倍，心跳超时给足3次容错，行情重传请求设500ms到1秒，这套配置在多数期货高频场景下能扛住轻度弱网，但务必用tc模拟验证后再上线，交易的试错成本禁不起"差不多"来买单。