一个诡异的TCP连接正常但数据传输失败的问题定位以及解决思路

问题现象

• 本机通过ie向目标机器发送http请求后无法获得数据

定位思路

1. ping目标机器，通，排除物理性网络连接问题，怀疑端口或是防火墙问题

2. 通过telnet ip port 能够成功连接，排除网络策略

3. 联系目标机器的服务商测试，他们能够正常访问和获得请求，排除服务端不可用

4. 联系网络管理团队在本网段发送请求，能够成功获取数据，基本排除服务端网络问题，基本定位是本地网络，系统问题，应用问题，硬件问题。

5. 由于本地实际上是一个虚拟机所以不存在实际硬件问题，故排除之，

6. 本机安装chrome，依然无法获取数据，排除单一性IE浏览器问题

7. 本机安装postman，依然无法获取数据，排除浏览器问题，换衣是系统配置或是网络配置问题

8. 检查本地网络代理，发现没有配置代理，故排除

9. 至此，一般性问题都以排除，继续排查难度极大，考虑到是全新系统，建议系统管理员直接重装操作系统

10. 等待重装操作系统后测试，发现问题仍然存在，基本崩溃，向管理员询问系统配置情况，发现可能安装了一系列的新安全防护软件，但安全规定是这些软件不能动。。。。因此怀疑这这些软件对系统进行了某些配置的更改，为此祭出大招，安装wireshark

11. 启动wireshark后，开始抓包，截图如下方所示，发现TCP的典型三次握手是齐的，但实际的数据传输总是重传。但是原因没有思路

12. 于是找到有丰富网络分析经验的人来帮忙，发现了在连接的第一个包中多了一个ECN的参数怀疑跟这个有关

13. 个人去网上一通检索，发现真的是可能，由于中间网络设备不支持ECN所以就一直重传

14. 关闭ECN设置，直接OK

抓包结果如下图所示

ECN简介

Explicit Congestion Notification（显示拥塞通知）

基本原理：路由器在出现拥塞时通知TCP。

（1）TCP段传递时，路由器使用IP首部中的2位来记录拥塞；

（2）TCP段到达后，接收方知道报文段是否在某个位置经历过拥塞。

然而，需要了解拥塞发生情况的是发送方，而非接收方。

因此，接收方使用下一个ACK通知发送方有拥塞发生，然后，发送方做出响应，缩小自己的拥塞窗口。

解决方案

netsh interface tcp set global ecncapability=disabled

原因分析

由于近期安全要求升级导致加装额外的安全套件，但中间网络设备不兼容，导致新配置的机器都有这个问题。

回顾

真正难以解决的问题往往都是底层的问题，就这一个参数就决定了你与高手之间的差距，真的很像那个著名的画这条线2美元，知道在哪画这条线19998美元的故事。