069、连接事件长度协商失败后的重传堆积

一次深夜的现场调试几年前做一个工业数据采集项目主站和从站之间用有线连接跑一套实时协议。现场调试阶段一切正常数据每秒更新一次波形平滑。直到客户把设备拉到另一条产线上问题出现了从站偶尔会卡住十几秒不响应主站那边的重传计数器像疯了一样往上跳。最初怀疑是线缆质量问题。换了屏蔽双绞线问题依旧。又怀疑是电磁干扰加了磁环稍微好了一点但没有根除。最后抓了一段总线波形把通信过程逐帧拆开看才发现一个非常隐蔽的现象主站发出的连接请求里带着一个期望的通信周期参数从站回应的参数比主站期望的短了一截双方没有谈拢但协议栈并没有立刻断开重来而是把这次协商失败悄悄咽了下去继续用旧的参数发数据。主站那边等不到按新参数返回的应答就不断重传重传队列越堆越长最后把发送缓冲区撑爆整个链路假死。这个坑折腾了将近一周。后来复盘发现问题的根源不在物理层也不在协议本身而在于“连接事件长度协商”这个环节失败之后协议栈内部的重传管理没有做正确的降级处理。公开资料里讲协商流程的多讲协商失败之后怎么办的几乎没有。这篇就专门把这个盲区拆开讲。协商失败为什么会被“咽下去”先把这个场景用通用术语描述清楚。两个设备建立连接时发起方会提出一组通信参数其中包含一个“连接事件长度”或者叫“通信窗口长度”的字段。这个字段的含义是每次通信事件中双方约定用多长的时间窗口来交换数据。这个值可以是几百微秒到几毫秒不等。接收方如果资源够就接受这个值如果资源不够比如它的射频前端切换需要更长时间或者它的处理任务周期和这个窗口对不齐它就会回一个更短的值。正常流程下发起方收到这个更短的值应该更新自己的参数然后用新参数重新发起一次协商或者直接按新参数开始通信。问题出在很多协议栈实现里协商失败被设计成“软失败”——不报错不断连只是把参数更新到本地然后继续跑。设计者的初衷是好的避免因为一次协商不完美就断开连接提高鲁棒性。但这个“继续跑”埋了一个雷发送方的重传定时器仍然是基于旧参数设置的。举个例子。发起方原本期望的窗口是 2ms它把重传超时设为 3ms。接收方回了一个 1ms 的窗口。发起方内部把窗口参数改成了 1ms但重传超时忘了同步改还是 3ms。于是每次通信事件实际只用了 1ms 就结束了接收方在剩下的 2ms 里处于空闲状态。发起方等了 3ms 没收到应答触发重传。重传的数据用的是新窗口接收方可能已经进入休眠或者去处理别的任务了没接住。发起方再等 3ms再重传。重传次数一多发送队列就堵了。现场观察到的现象就是从站看起来“卡住”了主站的重传计数器飞涨但总线上的数据帧并没有明显减少只是有效数据比例极低大量是重复帧。重传堆积的几种典型形态协商失败后的重传堆积不是单一现象根据协议栈实现的不同会表现出几种不同的形态。了解这些形态有助于现场快速判断。第一种是“定时器不同步型”。上面例子就是这种。发送方的重传超时基于旧参数接收方的实际处理窗口基于新参数。每次重传都打在对端不准备好的时刻重传永远无法成功直到重传次数达到上限协议栈报错或者复位链路。这种形态的特点是重传间隔固定重传次数很快达到上限链路复位后可能恢复正常但下次协商失败又会重演。第二种是“缓冲区泄漏型”。协商失败后协议栈没有清理上一次协商过程中分配的发送缓冲区。旧缓冲区里的数据没有被释放新数据又不断往里塞最终缓冲区耗尽。这种形态的特点是重传计数器不一定涨得很快但发送接口会返回“资源不足”错误或者干脆阻塞。现场用调试器看内存会发现发送队列的长度只增不减。第三种是“应答窗口错位型”。协商失败后接收方按新窗口工作但发送方仍然按旧窗口的节奏去读应答。发送方在旧窗口的末尾去读接收方已经关闭了接收通道读回来的是空或者错误的状态字。发送方认为应答无效触发重传。这种形态的特点是重传不是每次都发生而是间歇性发生看起来像随机丢包但丢包率又出奇地高。这三种形态可能单独出现也可能组合出现。现场排查时先看重传计数器的增长曲线再看发送缓冲区的占用曲线基本就能定位到是哪一种。怎么在现场把问题钉死现场没有协议栈源码的情况下怎么确认是协商失败导致的重传堆积有一套可操作的判断流程。第一步抓取连接建立阶段的总线数据。重点看协商请求和协商应答这两个帧。如果应答帧里的窗口参数和请求帧里的不一致就说明协商没有达成一致。这一步用普通的逻辑分析仪或者带协议解码的示波器就能做。第二步观察协商完成之后的第一批数据帧。如果发送方在应答帧到达后仍然按照旧窗口的节奏发送数据或者重传超时明显大于实际窗口就可以确认是定时器没有同步更新。第三步统计重传帧的比例。在正常通信中重传帧占比应该低于百分之几。如果重传帧占比超过百分之三十而且重传帧的内容高度重复基本可以确定是重传堆积。第四步检查发送缓冲区的状态。如果协议栈提供了查询接口直接读发送队列的长度。如果队列长度在协商失败后持续增长且没有回落就是缓冲区泄漏型。这四步做完基本能把问题范围缩小到协商失败后的参数同步环节。接下来就是决定怎么改。三种处理策略的取舍确认问题之后处理策略有三种各有各的代价。策略一协商失败直接断连重来。这是最干净的做法。协商失败后发送方主动断开连接等待一个随机退避时间然后重新发起协商。如果对端还是回一个不一致的参数再断再重来。这个策略的代价是连接建立时间变长在需要快速重连的场景下可能不可接受。但它的好处是彻底避免了参数不一致的状态。适合对连接稳定性要求高、对重连时间不敏感的场景。策略二协商失败后强制使用对端参数并同步更新所有定时器。这个策略要求协议栈在收到协商应答后不管参数是否一致都把本地所有相关定时器、缓冲区大小、重传次数上限全部按对端返回的参数重新计算。这个策略的代价是实现复杂度高因为要改的地方很多容易漏掉某个角落。但它的好处是连接不会断通信能继续。适合对连接连续性要求高的场景。策略三协商失败后进入降级模式用最小的公共参数集通信。比如双方都支持一个最低速率的通信模式协商失败后就切到这个模式虽然性能下降但至少能通。这个策略的代价是通信效率降低可能影响实时性。适合对带宽要求不高的采集类场景。在实际项目中我通常选策略二但会把策略一作为兜底。也就是先尝试同步所有参数如果同步之后连续出现多次重传失败再触发断连重来。这样既保证了大多数情况下的连接连续性又避免了在极端情况下陷入死循环。代码层面的一个关键修改点如果能在协议栈代码里改关键修改点通常在一个叫“协商完成回调”或者“连接参数更新”的函数里。下面是一个通用化的伪代码示例展示正确的同步逻辑应该怎么做。/* 协商完成后的参数更新函数 */voidon_nego国外半导体厂商a国外半导体厂商on_complete(conn_params_t*local,conn_params_t*remote){/* 第一步更新窗口参数 */local-window_sizeremote-window_size;/* 第二步同步更新所有依赖窗口参数的定时器 */local-retransmit_国外半导体厂商meoutcalc_retransmit_国外半导体厂商meout(remote-window_size);/* 第三步同步更新重传次数上限 */local-max_retransmitcalc_max_retransmit(remote-window_size);/* 第四步同步更新发送缓冲区的水位线 */local-tx_buffer_high_watermarkcalc_high_watermark(remote-window_size);/* 第五步如果协商前后参数差异超过阈值主动清理旧缓冲区 */if(abs(local-old_window_size-remote-window_size)WINDOW_DIFF_THRESHOLD){flush_tx_buffer(local);reset_retransmit_counter(local);}/* 第六步记录协商结果用于后续诊断 */log_nego国外半导体厂商a国外半导体厂商on_result(local-old_window_size,remote-window_size);}这段代码的核心思想是窗口参数一变所有跟它相关的量都要跟着变。很多协议栈只改了第一步后面几步漏了就导致了定时器不同步和缓冲区泄漏。另外第五步的“主动清理”很关键。如果协商前后窗口差异很大比如从 2ms 变成 1ms旧缓冲区里可能积压了大量按旧窗口节奏排布的数据这些数据在新窗口下可能永远发不出去。不如直接清掉让上层重新生成。现场调试时的一个实用技巧如果现场无法修改协议栈代码有一个临时规避手段在应用层加一个“协商结果校验”逻辑。每次连接建立后主动去读一次对端的实际窗口参数如果和自己的不一致就主动断开重连直到双方一致为止。这个逻辑可以写在一个独立的监控任务里不碰协议栈本身。/* 应用层监控任务定期校验协商结果 */voidnego国外半导体厂商a国外半导体厂商on_watchdog_task(void){while(1){conn_params_tlocalget_local_params();conn_params_tremotequery_remote_params();if(local.window_size!remote.window_size){log_warning(window mismatch: local%d, remote%d,local.window_size,remote.window_size);force_disconnect();wait_random_backoff();reconnect();}sleep(WATCHDOG_INTERVAL);}}这个技巧的好处是不需要动协议栈风险低。坏处是如果协商失败频繁发生会导致连接反复断开重连影响通信稳定性。所以它只适合作为临时手段最终还是要在协议栈层面解决。从设计阶段就避开这个坑如果项目还在设计阶段有几条原则可以提前避开这个坑。第一协商参数不要只协商一个窗口长度要把所有相关联的参数打包成一个“连接配置集”一起协商。对端要么全接受要么全拒绝不允许部分接受。这样就不存在参数不一致的状态。第二如果必须支持部分接受那就要在协议栈里定义一个“参数依赖图”。窗口长度变了哪些定时器要变哪些缓冲区要变哪些计数器要变全部在依赖图里标清楚。参数更新时按依赖图遍历一个不漏。第三在连接建立阶段加一个“参数确认”握手。发送方收到协商应答后不要立刻开始发数据而是先发一个确认帧把最终生效的参数集告诉对端。对端确认后双方再进入数据通信阶段。这个确认帧可以带一个校验和确保双方对参数的理解完全一致。第四在协议栈里加一个“协商失败计数器”。每次协商失败就加一如果连续失败超过阈值就主动上报错误而不是默默继续。这样现场调试时能第一时间看到问题不用等到重传堆积到链路假死才发现。一个容易被忽略的角落双向协商上面讲的都是单向协商也就是发起方提参数接收方回参数。但在一些协议里协商是双向的双方都要提出自己的期望参数然后取一个交集。这种情况下协商失败的表现更隐蔽。比如 A 方期望窗口 2msB 方期望窗口 1.5ms交集可能是 1ms。但如果协议栈在计算交集时出了偏差比如把 1.5ms 向下取整成 1ms但 A 方以为交集是 1.5ms就会导致 A 方按 1.5ms 的重传超时去等而 B 方实际只给 1ms 的窗口。结果和单向协商失败一样只是原因变成了交集计算不一致。这种双向协商的场景下现场排查要同时抓双方的参数日志。如果双方日志里记录的最终窗口参数不一致就是交集计算出了问题。修改点通常在交集计算函数里要确保双方用完全相同的取整规则和比较逻辑。重传堆积的连锁反应重传堆积如果不及时处理会引发一系列连锁反应这些反应有时候比堆积本身更麻烦。第一个连锁反应是功耗上升。重传意味着射频前端反复发射如果设备是电池供电的续航会急剧下降。现场表现为设备发热明显电池掉电快。第二个连锁反应是信道拥塞。重传帧占用了宝贵的信道时间导致正常数据发不出去。如果同一个信道上有多个设备一个设备的重传堆积会拖慢整个网络的吞吐量。第三个连锁反应是上层业务超时。重传堆积导致有效数据延迟增大上层的超时定时器会触发业务层可能认为设备离线触发告警或者切换备用链路。但实际上链路是通的只是被重传堵住了。这种“假离线”现象在现场很难排查因为从业务层看就是设备没响应。第四个连锁反应是协议栈复位。如果重传次数达到上限协议栈可能会触发复位。复位后连接重建如果协商再次失败又会进入重传堆积。形成“复位-重连-协商失败-重传堆积-复位”的死循环。现场表现为设备反复重启但每次重启后只能正常工作几秒钟。理解这些连锁反应有助于在现场快速判断问题的严重程度。如果只是重传计数器涨但业务层还没超时那还有时间慢慢排查。如果业务层已经开始报离线那就得先想办法把重传压下去恢复通信再找根因。一个通用化的诊断清单最后给一份现场可用的诊断清单按顺序执行基本能覆盖大多数情况。第一确认协商阶段双方参数是否一致。抓包看请求帧和应答帧的窗口字段。第二确认协商完成后发送方的重传超时是否按新窗口更新。看协议栈日志或者用调试器读定时器寄存器。第三统计重传帧占比。如果超过百分之三十进入下一步。第四检查发送缓冲区水位。如果持续增长不回落确认是缓冲区泄漏。第五检查业务层是否有超时告警。如果有说明重传已经影响到上层。第六检查设备是否有异常复位。如果有说明重传堆积已经触发协议栈保护。第七根据以上结果选择策略一、二或三进行处理。如果现场无法改代码先用应用层看门狗临时规避。这份清单不依赖任何特定厂商的工具或协议全部基于通用的调试手段。核心思路就是先确认协商结果再确认参数同步再确认重传比例最后确认连锁影响。一步一步缩小范围最终钉到具体的代码修改点。