网络编程socket慎重断开连接

业务场景

• 我们公司是做智慧交通的，主要卖交通相关的硬件产品和软件平台
• 硬件主要是路口或路段上的前端硬件设备，包括信号机、雷达、雷视、边缘计算单元等，软件包括信控平台、智慧路口、管控平台等
• 信号机通信协议有国标推荐协议，定义了一些接口和数据字段，现在信号机厂商常用的有国标2007和国标2017，这也是信号机送检需要遵守的协议
• 一般经过检验、进入市场的信号机，至少都已经实现了国标2007协议，当然，由于要创造通信壁垒，防止自家的信号机被别的信控平台轻松接入，各家对协议的细节都有不同的实现
• 当然，这也是因为国标协议没有定义这些细节，因此统一信控很难实现，除非是不做信号机硬件只做平台的大厂商去推动
• 硬件也有配套的软件，硬件里一般使用的是嵌入式编程，使用精简的Linux系统，配套软件基本使用C语言编写
• 当我们的信号机配置工具或者信控平台，需要与信号机进行通信时，遵循约定好的通信协议，进行代码开发，使用socket进行通信接收和传输二进制数据
• 在做智慧路口的开发时，接收智慧路口的硬件边缘计算单元的数据，使用的也是socket通信协议，根据事先定义的协议，订阅和接收解析数据

心跳与连接

• 对于平台软件与硬件的socket通信，要特别注意网络的断开与重连，因为在现实网络环境中，即使是内网，网络波动也无法避免
• 维护好socket通信，处理好连接断开与重连，才能做好这个通信服务
• 可以通过心跳来保持连接，例如10秒发起一次心跳请求，连续3次没有心跳应答，就认为离线，进行离线情况的处理和尝试重连
• 但是不能只用心跳，数据通信也算，如果心跳没有应答，但是有数据过来了，这个时候应该也认定是连接正常的（可能是应答信息被海量信息淹没，黏包拆包没处理好，丢掉了）
• 对于主动断开socket连接，一定要慎重，不仅要有心跳次数校验，也要有数据通信对心跳监测的重置
• 有时候，糟糕的心跳检测主动断开操作，还不如没有检测

报错与捕获

• 我们的socket通信都是传输的都是二进制数据，而且都是把数据类型转换成数字，只传输数字类型数据
• 对于socket通信，最需要注意的就是黏包和拆包问题了，如果没有进行处理，通信并发比较高时，就好导致比较多的解析错误，只能丢掉数据
• 而且，如果你的报错没处理好，一报错直接就把连接断开了，那就更致命了。在公司联调测试都没问题（少量数据包），一旦部署到生成环境，直接频繁报错重连（大量数据黏包解析报错），直接爆炸
• 网络连接不稳，数据包丢失，数据不完整，也会解析报错，都有可能
• 数据不完整，解析会报错，所以一定要处理黏包，要捕获报错，不能一报错就断开连接了
• 处理黏包拆包的可以参考我这篇博客：关于Netty使用中黏包拆包带来报错问题及解决
• 如果不是Java语言，或者未使用netty，也可以参考使用里面的思路
• 简单陈述下思路：
  • 先检验数据报文头，如果不是，丢弃
  • 读到报文头后，插好标记点（报文头前），开始解析处理数据
  • 读取报文头里的数据长度值（一般报文头里都有一个字节表示数据体长度），再获取剩余数据报文体包字节长度，如果小于报文体长度值，重置游标到前面的标记点，结束等待下一个报文来临
  • 如果长度大于等于报文体长度值，按照协议继续解析长度内的报文体，解析完返回，剩下的字节（应该是报文头或者加上一部分数据体），下次再继续解析