kafkaProducer发送数据分析

在命令行执行：

使用console_producer连接kafka服务，发送数据，利用wireshark抓包查看具体的发送过程

 

 

 

头3条是tcp协议的三次握手。

握手成功后，第4条开始console_producer开始发送连接信息，在wireshark未设置该tcp协议具体的解码协议之前，在wireshark中只能看到tcp标志位位psh（推送）和ack（确认），第5条是kafka服务器对第四条的返回信息，同样也只能看到psh和ack。

查看第4条数据，发送在tcp协议中payload有30个byte,说明这条协议不同于普通的tcp协议

 

第6条和第7条的情况和4、6条类似。

在第7条中的info显式bind_reciever,协议显式为SMPP，右键该条信息，在右键菜单中选择decode as，在弹出的页面中，设置解码的协议为kafka：

 

 

设置完成后，可以看到wireshark中对应信息发生了变化：

 

可以看到从第4条到第7条都变成了kafka的解析内容，第4条是查看kafka服务的版本号请求，第5条是kafka对该请求的回应信息；第6条是请求获取kafka元数据信息，而第7条是对该请求的回应信息。

第8条信息是console_producer客户端在接收到metadata信息后向kafka服务器发送ack确认信息。

之后tcp保持长连接，等待console_producer客户端发送数据。

再分析一下由于负载均衡没有转发tcp协议的情况。

 

头3条还是3次握手，第4条console-producer客户端发送psh，ack请求，由于负载均衡服务器没有配置tcp协议的反向代理，负载均衡服务器会拒绝连接，具体过程：

1. 负载均衡服务器返回收到信息的ack信息，
2. 紧接着负载均衡服务器又发送断开连接的信息（FIN），
3. 然后客户端向服务器发送ack信息表示收到断开连接的信息，
4. 客户端向服务器发送被动断开连接信息
5. 服务器收到客户端断开连接信息，向客户端发送确认信息

查看第4条console-producer客户端发送psh，ack的请求，采用kafka方式解码后：

之后可以看到：

但是此时该条信息显式为kafka response，request missing ，这是有问题的。

回到上一步设置decode as，在弹出的页面中设置tcp port的端口号：

 

之后显示就正常了：