粉丝反馈：某公司整体上网异常如何诊断？跟上节奏，TCP 流经典分析案例 ！
本期分享的案例是有线网络的相关问题。
某公司近期搬迁后，网络设备不变（某G路由+某W交换机组网）。员工目前普遍反馈网络慢，表现为网页加载不完全、加载时间长、网页转圈、部分网页打不开需要多次刷新.....
规模在两百人左右使用上网，网络拓扑如下：
三层网络架构，划分了多个VLAN供业务部门使用。
四条入户宽带均为动态公网IP，三条电信+一条移动
3. 基础分析针对这种整网卡顿的问题，一般能想到的原因可能有：DNS服务器异常或响应慢、带宽负载不均匀和宽带会话数限制等，所以IT在出口路由器上做了相关的优化策略如下：
尝试一：“多线策略”使用负载均衡，无明显改善尝试二：“多线策略”使用智能选线，无明显改善尝试三：LAN口DHCP DNS使用本DNS（电信DNS）无明显改善，之前是使用的公共DNS（百度,阿里，腾讯）尝试四：使用策略路由指定出口进行分流，无明显改善确认会话数：由于宽带用的都是公网IP的企宽，和运营商确认是无限制的那下来就进一步分析，看看问题原因到底是出现宽带线路上还是其它。
4. 深入分析(1) 远程确实发现网站存在卡顿异常，迟迟刷不出来内容或加载失败
(2) 直接来看PC抓取访问该Web的异常TCP流（抓包中的对应stream61），可以看到服务器响应的Seq明显出了问题：握手之后的服务器—>终端第一个包的seq为1，下来的报文应该seq=1+length=1+0=1，但却变成了3264449421：
我们再看下另外一条异常访问Web的TCP流：
服务器返回的TCP报文的Seq错误导致终端无法接收，可能有两种原因：
其一是服务器真返回错了，概率非常小，接下来进一步抓WAN口去证明即可其二是TCP报文被路由器篡改导致返回错误。(3) 抓取WAN口访问Web的异常TCP流，如下：
可以明确看到路由器WAN与网站服务器TCP交互的过程中，路由WAN响应的ACK值明显不对，给了一个非常大得错误值，而不是ack=seq+len。
(4) 来对比看看正常的TCP流交互就清楚了：
这条正常的TCP交互流中，服务器和路由器WAN口都遵循TCP握手中seq和ack的标准计算，所以双方都认，没啥问题。
5. 原因定位及解决方案(1) 根本原因：
显然是出口路由存在TCP流交互异常，对内返回的网站TCP报文Seq值异常，PC无法接收；对外要求网站响应的TCP报文ack值异常，网站服务器无法接收和正常交互。
(2) 解决方案：
应该属于产品BUG，但TCP流往往和硬件加速有关，可以尝试关闭路由器的硬件加速功能观察使用，但要注意，关闭此功能一般会导致吞吐量和转发性能的下降。
(3) 后续情况：
目前来看已解决，问题闭环。
