如何定位TcpClient与Azure容器内TcpListener连接被重置的原因

我有基于TcpListener和TcpClient实现的服务端与客户端，本地运行时二者可正常连接、交换数据，无任何异常。但当我将服务端部署在Azure容器服务的Docker容器中，再通过客户端连接时出现如下问题：

• 客户端成功连接服务端
• 客户端与服务端完成正常握手
• 数据传输正式启动
• 约20秒后（正常传输需数分钟）连接中断，服务端报错「connection reset by peer」，客户端报错「error reading past the end of the stream」

两端均认为是对端引发故障，本地运行正常说明问题出在链路中间。已确认不存在防火墙之类的连接建立层面问题，客户端也没有主动断开连接，仍在等待服务端返回数据，而「connection reset by peer」说明链路上某节点主动发送了RST包。请问有什么可行方法可以定位干扰数据传输的原因？

• 抓包确认RST包发送源
  服务端容器内执行tcpdump抓对应业务端口的TCP流量，过滤规则设置为tcp.flags.reset == 1，确认RST包的源IP归属：如果源IP属于客户端侧网络，排查客户端出口网关的流量规则；如果源IP属于Azure侧节点，进入下一步排查。
• 校验Azure链路组件的空闲超时配置
  Azure基础负载均衡、应用网关、NAT网关等链路组件默认会对空闲TCP连接进行回收，虽然官方默认超时时间为4分钟，但手动配置可能被调整为20秒甚至更短。这里的空闲判定标准为连接上无任何双向数据包传输，即使业务层处于运算等待状态暂时无数据收发，也会被判定为空闲。你可以直接查看容器服务绑定的上述链路组件配置，确认超时时间是否和断开时间吻合。
• 验证TCP保活机制是否生效
  本地运行时无中间链路的超时限制，因此无需保活即可正常运行，但云上链路普遍要求连接定期发送保活包避免被回收：
  • 检查应用层TcpListener、TcpClient绑定的socket是否开启TCP keepalive，保活间隔需设置为远小于20秒的阈值，比如10秒
  • 检查Docker容器的内核参数，默认容器继承宿主机的tcp_keepalive_time通常为7200秒，远高于链路超时阈值，要么调整容器内核参数，要么在业务层自行实现短间隔的心跳包机制。
• 排查容器资源限制引发的隐性断连
  检查Azure容器实例的CPU、内存、网络带宽监控，确认断连时间点是否出现资源打满的情况，容器运行时资源不足时会主动重置高负载的TCP连接。同时检查容器网络插件的配置，确认是否有流量控制、连接数限制的规则命中你的业务连接。
• 对比测试缩小故障范围
  在服务端所在的同一VPC内启动虚拟机部署客户端，测试同VPC内连接是否正常：如果同VPC内无断连问题，即可确定故障出在公网链路或VPC边界网关的配置上；如果同VPC内也出现相同故障，则排查范围可以缩小到容器本身或VPC内部的网络规则。
• 增加全链路收发日志排查丢包
  在服务端和客户端分别添加详细的收发日志，记录每个数据包的时间戳、大小、序列号，确认断连前是否存在数据包丢失、未应答的情况，排除应用层逻辑引发的异常断连。

内容的提问来源于stack exchange，提问作者Mason Wheeler