前年冬天，一个做边缘采集的团队找我帮忙看一个拖了他们快两周的现场问题。设备部署在户外，网络靠无线链路回传，链路质量时好时坏。现象很怪：同一批出厂的设备，跑同一版固件，断网重连之后，一部分设备能自动恢复业务，另一部分死活连不上，必须人工断电重启。他们一开始怀疑是无线模块批次差异，换了好几批模块，问题依旧。后来怀疑是服务器侧连接数限制，抓包看了半天也没看出名堂。我过去之后，先让他们把能恢复和不能恢复的设备各挑两台，把绑定相关的配置全部导出来对比。一看就发现，两组设备虽然业务配置一样，但有一处绑定信息的存储位置不同——一部分存在掉电不丢的区域，另一部分只存在运行内存里。这个差异平时完全看不出来，因为设备只要不断电，行为一模一样。可一旦断网，重连逻辑读绑定信息的路径不同，结果就分道扬镳了。
这篇就围绕“绑定信息到底存在哪”这件事，把重连差异的来龙去脉讲透。这不是教科书上会单独列一节的内容，但在一线待过的人都知道，这类问题极其隐蔽，排查起来非常耗时间。
先看现象：重连时到底发生了什么
设备断网重连，表面上是网络层的事，实际上业务层往往要重新走一遍“我是谁、我该连谁、我该传什么”的流程。绑定信息一般包含对端标识、会话令牌、通道号、心跳周期、加密参数这些东西。重连时，重连模块需要拿到这些信息才能把链路重新拉起来。
关键点在于：重连模块从哪里拿绑定信息。
如果绑定信息存在掉电不丢的存储区，重连模块直接读就行，读到什么用什么。如果绑定信息只存在运行内存里，断网本身不一定导致内存丢失，但很多设备的重连流程会伴随一次轻量级重启，或者网络子系统的复位会连带把业务侧的内存结构清掉。这时候重连模块去读，读到的是空，于是要么用默认值去连，要么直接放弃。
现场观察到的差异
