问题来源

最近在公司参与开发充电柜通信协议和迭代车辆通信协议。发现了以下几个问题

  1. 明文传输,没有任何加密机制
  2. 没有认证机制,任何人都可以接入,而且后台是通过每一条指令的imei来识别哪一条设备。这样造成的后果就是每次处理上报指令都会在集合中寻找是否有该设备的连接对象,存在则对其进行替换。而在这个过程中,会对集合加锁。
  3. 且因为每种指令都有自增长的序号,在处理和应答上报指令的序号的过程中,又得再次从集合中取出对应得连接对象,这个过程又得加锁。再加上服务调用设备发送指令还是要加锁,而集合是一个全局变量,这样就导致了所有用户的所有指令争抢的都是同一把锁,严重影响系统的吞吐量。
解决方案

基于这些问题,我在不影响协议的情况下做了这些优化

  1. 在获得连接对象后,将连接对象地址传入指令处理的方法,这样的好处就是在处理和应答上报指令的序号的过程中,不用对其加锁。很大程度上的解决了锁冲突的概率。
  2. 将读写通道设置为缓冲通道,这样可以在接收指令时不会因为业务处理而导致堵塞验证。
  3. 对通信中的一些粘包问题进行了处理,因为网络上的处理方式是用两个字节来表示接下来的内容数据长度。而前端硬件是无法修改的,所以后台只能通过$符来识别一条指令。
  4. 为了减少tcp处理指令事件调用导致的堵塞,将该事件直接发送到消息队列中,在另一个服务中对其事件处理。这样极大的减轻了tcp服务的负担,通信延迟明显降低。
灵感

最后由此引发了一个灵感,写一个tcp通信认证且加密传输的一个开源项目,以此作为模板来减少以后的重复造轮子的工作:

Tcp认证流程如下:

 

后言

其他不多言,过程逻辑很简单,望各位大神指出不足。

且目前只使用golang完成了服务端和客户端,后期打算使用java来实现。由于最近要面试java,这几个月都是使用golang开发,所以要复习java了,且这个项目要先缓一缓。等我好消息,告辞!

我是程序小白,每天进步一点点。