Content #
先在Putty上缓慢地输入3个字符“j”，每次按键的间隔在300毫秒以上，这时候
Wireshark抓到了前9个包。接着我快速敲击键盘，Wireshark又抓了后面的包，
Wireshark截屏如图所示。
前3个包的解说如下。客户端：“我想给你发个加密后的字符‘j’。”服务器：“我收到字符‘j’了，你可以把它显示出来。”客户端：“知道了。”接下来的4、5、6号包，以及7、8、9号包也是一样的情况我的客户端10.32.200.43放在上海，而服务器10.32.23.55位于悉尼，它们之间的往返时间大概是150毫秒。由于这些包是在客户端收集的，所以1号包和2号包相差150毫秒是正常现象。奇怪的是客户端收到2号包之后，竟然等待了大约200
毫秒才发出3号包。本来是1毫秒之内可以完成的事，为什么要等这么久呢？再看看5号和6号之间，以及8号和9号之间，也是大概相差200毫秒。
这其实就是TCP处理交互式场景的策略之一，称为延迟确认。该策略的原理是这样的：如果收到一个包之后暂时没什么数据要发给对方，那就延迟一段时间（在 Windows上默认为200毫秒）再确认。假如在这段时间里恰好有数据要发送，那确认信息和数据就可以在一个包里发出去了。第12号包就恰好符合这个策略，客户端收到11号包之后，等了41毫秒左右时我又输入一个字符。结果这个字符和对11 号包的确认信息就一起装在12号包里了。
延迟确认并没有直接提高性能，它只是减少了部分确认包，减轻了网络负担。有时候延迟确认反而会影响性能。微软的 KB 328890 提供了关闭延迟确认的步骤。我在另一台客户端10.32.200.131上实施这些步骤后，结果如图所示，果然不到1
毫秒就发确认了（参见6号包和7号包的时间差）。
From #
Wireshark网络分析就这么简单