Python后端与LabView测量单元TCP/IP双向通信设计方案咨询

问题解答 #

1. 单条TCP长连接双向通信的安全性与稳定性 #

TCP本身是全双工可靠传输协议，单条长连接双向通信是工业数据采集场景非常成熟的落地方案，只要做好以下几点就足够安全稳定：

• 定义清晰的应用层报文协议，解决TCP粘包/拆包问题：比如每个报文固定加2字节的 payload 长度头，或者约定特殊的报文结束分隔符，从协议层面避免单条消息出错影响整条连接的字节流解析，完全可以解决前同事担心的错误扩散问题
• 增加心跳保活机制：空闲时两端定时发送心跳包，超过阈值未收到响应就主动断开重连，避免死连接占用资源
• 做好异常容错处理：单条报文解析失败、校验不通过时，仅丢弃当前错误报文、重置解析状态即可，不需要断开整条连接，不会影响后续消息传输
• 增加断连自动重试逻辑：连接异常断开后，测量单元可以自动向后端发起重连，不影响业务连续性

高频通信场景下，长连接可以避免短连接每次三次握手、四次挥手的性能开销，整体效率远高于短连接方案。

2. 短连接方案下后端主动发请求的前提 #

如果坚持沿用当前短连接架构，必须让测量单元开启监听Socket作为服务端。
TCP连接的建立必须有一端作为监听方、一端作为主动发起方，当前架构里仅后端做监听，只有测量单元主动发起连接才能传输数据，后端没有可用链路主动向测量单元发消息。如果要实现后端主动查询，要么后端转为主动发起连接的角色，要求测量单元开放监听端口，要么在测量单元每次主动建立的短连接里预留等待后端请求的窗口，但后者会大幅增加短连接的占用时间，完全失去短连接原有的设计意义，还会带来更高的资源开销。
同时短连接反向调用还需要额外处理测量单元的网络防火墙、IP变动等问题，落地复杂度很高。

3. 适配测量单元简化逻辑需求的方案选择 #

采用长连接双向通信是更合理的选择，优势非常明显：

• 测量单元不需要额外开发服务端监听逻辑，仅需要作为客户端维护一条和后端的长连接即可：启动时主动连接后端固定监听端口，有测量数据时上报，收到后端的查询请求后返回对应结果即可，逻辑非常轻量，完全满足测量单元尽量简化的需求
• 不需要两端都同时实现服务端、客户端两套逻辑，整体开发量、后期维护成本都远低于双端监听方案
• 双向通信的实时性更高，不需要等待短连接建立就可以随时发起查询请求，更适配高频通信场景

后端侧的改动也非常小，仅需要在accept到测量单元的连接后，将socket实例存入缓存不主动关闭，单独开辟读写协程/线程处理该连接的上报数据接收、查询请求发送即可。

内容的提问来源于stack exchange，提问作者Jan Janáček