在命令行执行：
使用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协议的反向代理，负载均衡服务器会拒绝连接，具体过程：
- 负载均衡服务器返回收到信息的ack信息，
- 紧接着负载均衡服务器又发送断开连接的信息（FIN），
- 然后客户端向服务器发送ack信息表示收到断开连接的信息，
- 客户端向服务器发送被动断开连接信息
- 服务器收到客户端断开连接信息，向客户端发送确认信息
查看第4条console-producer客户端发送psh，ack的请求，采用kafka方式解码后：
之后可以看到：
但是此时该条信息显式为kafka response，request missing ，这是有问题的。
回到上一步设置decode as，在弹出的页面中设置tcp port的端口号：
之后显示就正常了：
标签：数据分析,producer,ack,信息,kafka,发送,tcp,kafkaProducer,客户端 From： https://www.cnblogs.com/bayu/p/17104741.html