iptables开启导致kafka生产者消息发送失败

   近期部门有几个业务接连反馈producer消息发送时收到错误日志：The server disconnected before a response was received/WARN - Error in I/O with /XXXX(kafka主机)/java.io.IOException: Connection reset by peer，伴随有部分消息发送失败，影响终端用户体验，结合近期kafka从物理机迁移到虚拟机的大背景，怀疑和虚拟机有关，紧急将kafka服务端回迁到物理机，观察一段时间，业务反馈消息发送恢复正常，开始怀疑虚拟机内核参数配置问题，以下开始定位过程：

1、kafka服务端抓包分析，码流中出现FIN和RST关键字，疑似kafka主动断开连接；

2、仔细对比物理机与虚拟机内核参数，未发现明显与TCP连接相关的差异；

3、与同期迁移虚拟机的业务B的内核参数对比，发现业务B迁移到虚拟机之前对内核参数进行了调优，打开了iptables，关闭了timestamps和tcp_tw_recyle，咨询负责业务B的同事，是由于业务B涉及到外网访问，关闭tcp时间戳和连接回收是要避免中间NAT导致的时间戳错乱造成正常tcp连接被错误回收，开启iptables也是因为涉及外部访问安全考虑，但是producer发送消息到kafka是纯内网访问，咨询网络组同事，业务producer内网调用kafka是不会有任何NAT存在的，因此排除时间戳和tcp连接打开的影响；

4、排除了物理机与虚拟机内核参数的差异，进一步对kafka端的报文进行分析，发现每一次FIN报文出现和上前面一条报文的时间差都是精确的10分钟，这个十分钟内双方没有任何交互，而FIN报文之后的下一条请求到来时，kafka即返回RST给producer，重置连接，RST的时间点与业务日志报错时间吻合；

5、以10分钟为突破口，先分析操作系统的keepalive配置，发现2400000ms即40分钟的配置远大于10分钟，再排查kafka配置，发现配置项connection.max.idle.ms=60000，即空连接的超时时间，10分钟的空闲长连接会被kafka主动回收掉，时间吻合，现象吻合（主动发FIN包），但是，为何物理机没有这个问题，还需要进一步分析；

6、分别搭建kafka在虚拟机和物理机上的测试环境，部署两组同样的producer分别往物理机和虚拟机的kafka发送消息，同时在producer上抓包分析，发现10分钟的空闲周期之后，访问物理机的producer可以收到来自kafka的FIN包，正常4次挥手关闭连接，但是访问虚拟机kafka的producer却之后10分钟之后的某个时间点的消息发送请求和接着收到的来自kafka的RST响应，似乎是虚拟机kafka的FIN包被什么东西阻止了；

5、将目光再一次聚焦到虚拟机，抛出10分钟的疑惑点，求助虚拟机团队确认，虚拟机团队排查很快出了结果，kafka所在虚拟机的宿主机打开了iptables，tcp连接跟踪超时时间为10分钟（net.netfilter.nf_conntrack_tcp_timeout_established=600）,按照虚拟机团队专家的解读：连接跟踪模块回收的是连接跟踪记录表项，不是回收tcp空闲连接，tcp空闲连接是客户端和服务端才能回收的，正常的数据报文即使连接跟踪表项不存在也会触发新产生连接跟踪记录表项，所以kafka的FIN包作为非正常数据报文被宿主机拦截了，经过多次重发FIN包依然失败，此时kafka已经认为连接成功关闭，但对端的producer并未收到，认为连接一直是OK的，在10分钟后的某个时间点再一次使用该连接试图生产消息时，作为正常的数据报文，被kafka宿主机放通，但到了kafka之后，kafka发现该连接早已失效，随即返回RST。

  至此问题定位告一段落，看起来是kafka服务端配置与kafka虚拟机所在宿主机配置共同触发的问题，但其实发送失败也是因为producer没有配置消息发送失败重试机制，这样对于消息不可丢失的场景风险较大，后面业务接入kafka时我们也会增加这样一个评审点。

解决措施：

由于虚拟机团队安全要求开启宿主机iptables，且10分钟的tcp连接跟踪超时配置是经过大量实验多层评审保障主机性能利用达到最佳的设置，所以决定是业务做统一调整适配：

1、虚拟机上所有已上线的kafka修改connection.max.idle.ms=30000重启；

2、消息不容丢失的业务增加异常捕获重发机制；

其它可行解决方案参考：

1、合理设置主机tcp_keepalive时间，例如设置为5分钟；

2、调大tcp连接跟踪回收超时时间；