目录：

对山东某充电桩服务的逆向分析(一) 对山东某充电桩服务的逆向分析(二)

文（一）补充

上文中「猜测1」对「充电桩同时使用TCP和MQTT」描述不是很详细，现说明如下： 服务端中运行test.proc.CmdRecvBusiProcessor、test.server.ServerHandler、test.service.KafkaProducer等至少3个服务。

• test.server.ServerHandler 处理接收设备信息；
• test.proc.CmdRecvBusiProcessor 返回接收信息；
• test.service.KafkaProducer 向设备发送订阅消息

抛开复杂的系统架构，上述流程大体如下：

也就是说，充电桩网关或设备需要建立两个TCP连接：一个连接服务端，上报各种数据消息；一个连接Kafka的Broker服务，订阅从服务器下发的消息。

猜测2：只使用TCP

设备与服务器通讯只使用TCP，Kafka为了防止服务器消息堵塞，仅做消息队列。服务端订阅Kafka的消息，并分区处理。

从log来看，不是使用的这种方式。

猜测3：使用TCP和MQTT混合使用

这个猜测是「猜测1」的补充，Kafka不仅作为服务器向设备下发指令用，还用来防止通讯堵塞，作为消息队列使用。大体流程图如下：

• 设备订阅Kafka消息。当用户操作需要充电、断电操作时，服务端向Kafka对应的topic发布消息；
• 业务处理服务端也订阅Kafka消息。test.server.ServerHandler接收到的业务量较大的消息发布到Kafka，业务处理服务端收到消息后进行处理，分担服务端的压力。

最后猜测，数据库用的Oracle，负载均衡没用Nginx。

结束

Over.