这篇博文分享的是我们针对一个耗时20秒的请求，用Wireshark进行抓包分析的过程。
请求的流程是这样的：客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器。
下面是分析的过程：
1. 启动Wireshark，针对内网网卡进行抓包。
2. 在IIS日志中找出要分析的请求（借助Log Parser Studio）
通过c-ip(Client IP Address)可以获知SLB的内网IP，在分析Wireshar抓包时需要依据这个IP进行筛选。
通过sc-bytes(Bytes Sent)可以得知请求的响应内容的长度大于1MB，这可能是触发问题的一个条件。
3. 停止Wireshark抓包
4. 在Wireshark的Filter中输入ip.src==10.159.63.237 or ip.dst==10.159.63.237，筛选出针对10.159.63.237这个IP的包。
5. 根据IIS日志中的时间点找出Wireshark中对应的包（最终完成响应内容发送的包）：
6. 然后Follow TCP Steam，只列出这个TCP流上的包，这样就可以方便地找出发起请求的包：
看到这个包中的TCP Window size只有29，感觉有些小。我们又专门抓包测试了一下Mac OS X与Windows，Mac OS X的起始TCP Window size是8192，Windows是256。
看了一下之前的SYN/ACK包，才知道了怎么回事？
SLB->ECS，[SYN]，TCP Window size:14600
ECS->SLB, [SYN，ACK] TCP Window size:8192
SLB->ECS, [ACK] TCP Window size:29
SLB在SYN时设置的TCP Window size是14600，而ECS中的Windows Server 2012回SYN/ACK时给的TCP Window size是8192，由于SLB的Window size scaling factor是512，于是14600/512就是28了。这地方可以考虑在Windows中将TCP Window size改大一些。
关于TCP Window，推荐阅读园子里Vamei写的博文——协议森林10 魔鬼细节 (TCP滑窗管理)。
7. 由于响应内容大于1MB，远远超出了TCP的MSS(Maxitum Segment Size)，要进行TCP segment of a reassembled PDU，所以接下来出现了有一堆的TCP segment of a reassembled PDU包。
8. 在发送TCP segment of a reassembled PDU的过程中出现了重复的ACK包
这说明了当时网络环境出了某种问题。
9. 再接下来出现了[TCP Out-Of-Order]，服务端收到的TCP包的次序不对，出现的时间点是14:36:26.993176，至此已经耗时84ms。
这里也说明了当时网络环境出了某种问题。
10. 继续发送TCP segment of a reassembled PDU，结果在14:36:27.060223又出现[TCP Dup ACK ]：
11. 接着又出现了[TCP Out-Of-Order]。
12. 接下来SLB给ECS发了一个致命的ACK包，Window Size竟然只有2：
这时服务端估计郁闷极了，就如同跟着宝马开车，突然前面的宝马踩了个急刹车。
（注：SLB这么做，也有可能是客户端网络环境的原因）
13. 过了500多ms之后，SLB给ECS发了一个[TCP Window Update]包，将TCP window size改为了36。
14:36:27.779925000 10.159.63.237 10.161.241.208 TCP 66 [TCP Window Update] 14319 > http [ACK] Seq=313 Ack=922921 Win=18432 Len=0 TSval=173285669 TSecr=18155162
14. 交通恢复正常。。。
15. 突然宝马又踩了一次急刹车，TCP window又变成了2：
14:36:27.862061000 10.159.63.237 10.161.241.208 TCP 66 14319 > http [ACK] Seq=313 Ack=957673 Win=1024 Len=0 TSval=173285752 TSecr=18155225
16. 700多ms后的[TCP Window Update]又让交通恢复正常。
17. 就这样反复地踩刹车、加速。。。。
18. 直到了14:36:47，才完成了整个响应内容的发送，而时间已经过去近21秒。
从分析的情况看，SLB与客户端的网络环境都可能引起这个问题。但是从IIS日志来看，有些耗时长的请求竟然达到了140秒，什么样的客户端会傻到一直等2分多钟而不断开TCP连接或重发请求？