共计 1149 个字符，预计需要花费 3 分钟才能阅读完成。
写在后面：因为这次问题以出其不意的形式自行隐没了，这篇文章可能仅仅为你提供一份排查思路。
问题
最近在我的项目中遇到了一个问题：TCP 建设连贯后，只能传输固定无限 N 条 (常量) 报文。
发送服务的代码曾经久经应用，可以信赖。然而建设连贯，发送 N 条数据后，发现收不到对方的响应。
排查
- 在重启发送服务的过程中发现，每次服务 整体重启 ，或是 TCP 连贯超时 断开重连，新发送的前 N 条 TCP 报文都有响应。
- 之后，调整了发送报文的频率，发现高频率下发送报文的数量 N 不变，看起来像是短时间内把报文发送的额度“用尽”了。反过来说，在 TCP 连贯建设后，先期待一段时间内不发送数据，之后也能发送 N 条有响应的报文。
- 最初应用 tcpdump 工具抓包，观测到：在发送报文前的 TCP 三次握手失常，前 N 条报文失常，第 N + 1 条报文 会以毫秒级疾速多次重发，且首次重发工夫极短，大概在首次发送报文的几十毫秒内就会开始重发。
- 此外，在非内网环境下，对方平台失常响应。
初步论断
①每次从新建设 TCP 连贯，可发送数据量重置。
②工夫窗口不是影响发送数据量的次要因素，数据量才是。
③并非对方不发送响应，而是我方的数据发送不过来，很可能与网络环境无关。
持续排查
接下来为了管制网络环境这一变量，抉择将服务部署在新服务器上测试。但因为服务器群部署在内网上，申请权限耽误了几天。
测试后果出其不意：不仅新服务器上的服务能够失常应用，原服务器上的服务也恢复正常了。而且，长期写的 TCP 报文发送器也体现得一切正常。
懵了呀。
问题出在哪儿？
事实上，对于这种像是小精灵一样隐没的问题，当初也没方法确定问题到底出在哪儿。只能靠目前的信息，做出揣测：
依据后面屡次控制变量的后果，很有可能是 防火墙协定权限 带来的问题。
公司内网的防火墙须要权限申请能力通过，而在申请时，须要抉择 TCP、UDP、HTTP 协定中的一项。假如开明人员搞错了协定内容，那么依据 DPI (Deep Packet Inspection) 深度包检测技术，防火墙可能对非 HTTP 协定的流量进行拦挡。
这解释了为什么第 N + 1 条报文会以毫秒级疾速多次重发——因为它在本地防火墙就被拦挡，这个失败速度是十分快的。
另外，为什么有 N 条报文能够发送？一个可能的解释是：HTTP 连贯须要 TCP 进行三次握手，而防火墙为三次握手设计了一些容忍度，这些容忍度体现为能够发送进来的 N 条报文。
那为什么隔了几天当前两台服务器都恢复正常了？这个问题大略是没法失去一个确切答案了，只能做一个揣测：防火墙管理人员在看到第二张权限申请单后，意识到第一张开错了协定，偷偷改过了……
预先总结
- 在排查中，控制变量法是无力的工具，能够从最有可能的中央开始控制变量，进步排查效率。
- 适合的重启能够抓到问题的“刷新点”，帮忙定位问题。
- 如果失败工夫较短，思考本地限度因素
- 大胆狐疑，小心求证。
