监控数据“假死”之谜：以太网温湿度传感器 TCP 连接池耗尽问题复盘

监控数据“假死”之谜：以太网温湿度传感器 TCP 连接池耗尽问题复盘

在智慧档案馆与数据中心项目中，我们曾遭遇一个诡异现象：平台显示数百个以太网温湿度传感器“在线”（Link灯亮、Ping正常），但 Modbus TCP 读数全部停滞，界面曲线呈直线，重启平台采集服务后瞬间恢复，数小时后问题复现。

这不是传感器故障，也不是网络抖动，而是典型的 TCP 连接池耗尽（Connection Pool Exhaustion）​ 问题。本文完整复盘该问题的定位过程、根因分析与工程化解决方案。

一、现象回顾：诡异的“假死”

故障表象：

• 交换机端口灯常亮，Ping 时延正常（<1ms）。
• 平台设备列表显示“在线”，但温湿度数值长时间不更新（如超过 30 分钟）。
• 平台日志大量报错：Connection refused、Connection timeout、No buffer space available。
• 重启平台的 collector 服务，所有数据瞬间恢复，但 2~4 小时后故障重现。
• 单台传感器断电重启无效，必须重启平台端服务。

初步误判：

• 运维怀疑交换机 VLAN 配置问题。
• 开发怀疑传感器固件 Bug（假死）。
• 测试怀疑网络环路或 ARP 攻击。

二、定位过程：从表象到内核

1. 排查传感器（排除法）

• 使用 Modbus Poll 直连单台传感器，读取正常。
• 更换不同品牌传感器，问题依旧。
• 结论：传感器硬件正常，问题在平台侧或网络交互逻辑。

2. 排查网络（抓包分析）

• 在平台服务器上执行 tcpdump： tcpdump -i eth0 host <sensor_ip> -w cap.pcap
• 分析发现：平台向传感器发起 TCP 握手（SYN），传感器回复 SYN-ACK，但平台没有发送最后的 ACK，或者发送了 RST（复位）。
• 关键发现：服务器上存在大量处于 TIME_WAIT 状态的 TCP 连接。 netstat -an | grep :502 | wc -l # 结果：接近 65000（系统上限）

3. 锁定根因：连接池与短连接灾难

深入代码发现，采集服务采用了“每次读取都新建连接，读取完立即关闭”的短连接模式。

故障逻辑链：

1. 短连接风暴：1000 个节点，采集周期 10 秒。每分钟建立 6000 个 TCP 连接。
2. TIME_WAIT 堆积：TCP 协议规定，主动关闭连接的一方（平台）会进入 TIME_WAIT 状态，持续 60 秒（2MSL），确保远端收到确认。
3. 端口耗尽：系统可用临时端口（Ephemeral Ports）约 28k~65k 个。由于连接创建速度远超 TIME_WAIT 回收速度，端口资源被耗尽。
4. 假死现象：新连接无法建立（No buffer space），但旧连接已关闭，Ping（ICMP）不受影响，导致“Ping 通但读不出数”的假死假象。

💡 核心误区：认为 TCP/IP 是“连上网就能用”，忽略了操作系统对并发连接数和端口资源的硬性限制。

三、根因分析：为什么传感器“扛不住”短连接？

虽然问题爆发点在平台，但传感器端的实现方式加剧了这一问题。

1. MCU 资源限制

工业以太网温湿度传感器通常使用 STM32 + W5500（硬件协议栈）或 LWIP（软件协议栈）。

• W5500：通常只有 8 个 Socket，且内部缓冲区极小（如 2KB/ Socket）。
• LWIP：受限于 MCU RAM，TCP PCB（控制块）数量通常配置为 10~20 个。

2. 错误的平台端逻辑

• 错误：Connect -> Read -> Close，循环往复。
• 后果：传感器端频繁收到 TCP 握手与挥手，必须频繁分配和释放 PCB 资源。当平台连接频率过高时，传感器的 TCP 协议栈无法及时回收资源，导致内部队列满，直接拒绝新连接（RST）。

3. SNMP 的“背刺”

部分平台在 Modbus TCP 失败后，会频繁发送 SNMP GET 请求。虽然 SNMP 基于 UDP，但如果传感器同时开启了 TCP 服务，频繁的 TCP 连接失败日志会占用 MCU 处理时间，间接影响 UDP 响应。

四、解决方案：从“短连接”到“长连接池”

1. 架构改造：引入连接池（Connection Pool）

核心思想：复用 TCP 连接，避免频繁三次握手和四次挥手。

改造前：

while True:
    sock = socket.create_connection((ip, 502))
    send_modbus_request(sock)
    recv_modbus_response(sock)
    sock.close()  # 触发 TIME_WAIT
    sleep(10)

改造后（连接池模式）：

class ModbusPool:
    def __init__(self, ip, min_conn=2, max_conn=5):
        self.pool = queue.Queue(max_conn)
        for _ in range(min_conn):
            self.pool.put(self._new_conn())

    def _new_conn(self):
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((ip, 502))
        return sock

    def get_conn(self):
        try:
            return self.pool.get(timeout=2)
        except queue.Empty:
            return self._new_conn() # 按需扩容

    def release_conn(self, sock):
        self.pool.put(sock)

# 使用
pool = ModbusPool(ip)
while True:
    conn = pool.get_conn()
    try:
        send_modbus_request(conn)
        recv_modbus_response(conn)
    except Exception:
        conn.close() # 异常时关闭
        conn = None
    finally:
        if conn:
            pool.release_conn(conn)
    sleep(10)

2. 操作系统参数调优（Linux）

调整内核参数，加速 TIME_WAIT 回收，扩大端口范围。

编辑 /etc/sysctl.conf：

# 开启 TIME_WAIT 复用
net.ipv4.tcp_tw_reuse = 1
# 开启快速回收（NAT环境慎用，建议仅内部网络开启）
net.ipv4.tcp_tw_recycle = 1 # 注意：Linux 4.12+ 已移除该参数，需依赖 tcp_fin_timeout
# 缩短 FIN_WAIT_2 时间
net.ipv4.tcp_fin_timeout = 30
# 扩大本地端口范围
net.ipv4.ip_local_port_range = 10000 65000
# 增加最大文件句柄数（影响Socket数量）
fs.file-max = 1000000

执行 sysctl -p 生效。

3. 传感器端优化建议

• 固件升级：确保传感器固件支持 TCP Keep-Alive。
• 配置调整：如果传感器支持，增加 TCP 超时时间（如从 2 秒调整为 10 秒），容忍平台短暂卡顿。
• 资源监控：通过 SNMP 或私有寄存器暴露 TCP 连接数、Socket 错误计数，便于预警。

4. 采集策略优化

• 批量读取：一次请求读取多个寄存器（如温度+湿度+状态），减少交互次数。
• 分级采集：关键节点 10 秒，普通节点 30~60 秒。
• 异常隔离：单节点连续失败 N 次后，将其移入“隔离区”，降低采集频率（如 5 分钟一次），避免拖累全局。

五、验证与效果

压测方案：

• 模拟 2000 个节点，采集周期 5 秒。
• 监控指标：netstat -an | grep :502 | wc -l 和 CPU 负载。

优化前：

• 连接数：线性增长至 65000+，随后平台假死。
• CPU：软中断（si）占用高。

优化后：

• 连接数：稳定在 2000 左右（每个节点 1 个长连接）。
• CPU：负载下降 40%，无 TIME_WAIT 堆积。
• 数据：连续运行 7 天无中断。

六、避坑指南（Checklist）

1. 严禁轮询短连接：Modbus TCP 必须长连接或连接池化。
2. 监控端口状态：定期巡检服务器的 TIME_WAIT 数量。
3. 压测先行：上线前模拟 2 倍峰值节点数进行压力测试。
4. 传感器选型：询问厂商“最大并发 TCP 连接数”和“Socket 数量”。
5. 日志规范：平台日志需区分“连接失败”、“读超时”、“数据异常”，避免混淆。
6. 优雅关闭：平台重启时，先发送 TCP FIN 包，而非直接 Kill 进程。

七、小结

这次“假死”复盘揭示了一个深刻的工程真理：网络编程的复杂性不在于“连通”，而在于“持续稳定地连通”。

对于以太网温湿度传感器这类资源受限的工业终端，平台端的连接管理策略往往比传感器本身的性能更关键。通过引入连接池、优化内核参数和调整采集策略，我们不仅解决了“假死”问题，更将系统的承载能力提升了数倍。

💡 核心心法：把传感器当成“珍贵资源”来对待，用连接池去“养护”它，而不是用短连接去“轰炸”它。

物联网 #边缘计算 #动环监控 #Modbus #工业以太网 #TCP连接池 #性能优化 #以太网温湿度传感器