Telnet performance analysis on Windows XP

不过提个问题，你觉得windows作为telnet client，速度怎么样？和linux比较呢？
看看数据吧。Python实现的测试结果。

Windows XP is:

 

get units:       2.23399996758 s

write and read until:   10.0 s

write and read until prompt: 10.25 s

on Ubuntu:

get units:       2.92633891106 s

write and read until:   2.07120800018 s

write and read until prompt: 2.84075593948 s

解释下，分别做三种操作，每种操作，client端的data都是分两次发送。get units操作，设备返回的字符串最长。
write and read until返回的字符串长度次之。
write and read until prompt，其实client只是敲回车，设备返回的字符串最短。

很容易可以看出来，linux看起来性能比XP好太多了。
等等，难道没注意到一些反常的情况吗？同样在XP上面，按理get units返回的字符串很长
（而且这个函数还做了更多其他的事情，比如字符串解析等），为啥调用的时间反倒短呢？
而且，get units的操作，linux和xp的差别不大。反倒是那些返回字符串短的，差别很大。

抓包分析，又 GOOGLE了半天。发现在短包长的时候，xp的tcp ack延时比较大，很稳定的200ms延时。
<http://support.microsoft.com/kb/214397 >
<http://smallvoid.com/article/winnt-nagle-algorithm.html>
<http://support.microsoft.com/kb/328890/ >

TCP中有nagle和ack delayed两种算法作congestion control控制。
“The Nagle algorithm (by John Nagle) is a method for congestion control (RFC 896 ), so the sender won't flood the receiver with data. When the sender sends a packet to the receiver, then the sender will wait for an ACK from the receiver before sending the following packets.”
“The delayed ACK algorithm is also a method for congestion control (RFC 2581 ), so the receiver won't flood the network with ACK packets. When the receiver has to sent an ACK in response to a packet, then it waits a little (200 ms or until it has 2 outstanding ACKs) to see if more packets should arrive that it can acknowledge with that single ACK.”

对于微软的实现：
When a Microsoft TCP stack receives a data packet, a 200-ms delay timer goes off. When an ACK is eventually sent, the delay timer is reset and will initiate another 200-ms delay when the next data packet is received. To increase the efficiency in both Internet and the intranet applications, Microsoft TCP stack uses the following criteria to decide when to send one ACK on received data packets
 To avoid having small data packets congest the network, Microsoft TCP stack enables the Nagle algorithm by default, which coalesces a small data buffer from multiple send calls and delays sending it until an ACK for the previous data packet sent is received from the remote host. The following are two exceptions to the Nagle algorithm

SOCKET的 TCP_NODELAY可以控制disable Nagle算法。但是对于前面的问题没有帮助（这个需要server端也disable，才能间接的产生作用。）。Linux提供 TCP_QUICKACK，但微软不支持。微软需要在注册表中来控制ack delayed。

[HKEY_LOCAL_MACHINE /SYSTEM /CurrentControlSet /Services /Tcpip /Parameters /Interfaces /{Adapter-id}]
TcpAckFrequency = 2 (Default=2, 1=Disables delayed ACK , 2-n = If n outstanding ACKs before timed interval, sent ACK)

 

Subkey: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/<Interface GUID>
Entry: TcpAckFrequency
Value Type: REG_DWORD, number
Valid Range: 0-255
Default: 2
修改过后，测试结果一下变得很好了。

get units:       1.98600006104

write and read until:   0.25

write and read until prompt: 0.171999931335

但是这个选项被disable会影响所有的TCP应用。不推荐。
后来看<tcpip illustrated>，红宝书早有描述啊。只是看，和实际碰到后去解决，还是完全不一样的。
"Host Requirements RFC声明T C P需要实现一个经受时延的A C K，但时延必须小于
500 ms。"
"插口API用户可以使用T C P N O D E L A Y选项来关闭Nagle算法。
Host Requirements RFC声明T C P必须实现N a g l e算法，但必须为应用提供一种方法
来关闭该算法在某个连接上执行。"

在这个问题中，通过client和server都关闭nagle算法，也许能间接的解决这个问题，这样比修改注册表要好。