标签：window alt syn image log inux net cat 应该
最近有用户反映有2个机房的服务器互传数据很慢，传输速度在2-3M/s ，正常情况下应该是50M/s 左右。这个2个机房是跨地区的，一个在广东，一个在江苏。
说明：这里为了表述，将用户在广东机房的服务器称为A服务器，江苏机房的服务器称为B服务器。
将我自己在广东机房的服务顺称为C服务器，江苏机房的服务器称为D服务器
用户询问是不是机房有限速，正常情况下，机房是不会做这种限速的。
我登录了自己的C、D服务器，互传测试数据，发现数据传输正常，数据传输速度在50M/S ，
从上面的基本验证了，机房是没有做限速。
分别登录用户的2台服务器：A、B，互传测试数据 ，速率是2-3M/s, 从B服务器往A服务器传数据也是2-3M/s。
从上面的结果基本判断，问题还是在A、B服务器本身上。
从B服务器向D服务器传输数据，数据传输正常，同机房传输速度在100M+/S
这表明同机房数据传输是正常的。
然后再从A服务器传输数据到D服务器，数据传输正常50M/s 左右。
从B服务器传输数据到C服务器，数据传输在2-3M/s
从上面的结果基本可以排除A服务器的问题，问题应该在B服务器
继续从A服务器传输数据到D服务器，从B服务器传输数据到C服务器，并使用tcpdump 在C、D服务器上抓包，将将抓包结果保存到文件中,命令如下：
C服务器抓包命令
tcpdump -i eth0 src host 192.168.1.1 -w aa.pcap
D服务器抓包
tcpdump -i eth0 src host 172.16.1.1 -w bb.pcap
从2个抓包结果来看，数据没有重传和乱序的情况，网络质量是没有问题。但有个地方有异常，传输慢的TCP窗口扩展因子没有启用，
没有启用TCP窗口扩展因子的情况:
或
启用TCP窗口扩展因子的情况：
检查发现B服务器的TCP窗口扩展因子没有打开，
#cat /proc/sys/net/ipv4/tcp_window_scaling
0
0为禁用，1为启用，使用以下命令启用
# echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
再传输数据，数据传输速度正常了，问题解决。
那么什么是TCP窗口扩展因子呢？
窗口扩大选项使TCP的窗口定义从16位增加为32位。这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大操作(scaling operation)来完成的。于是TCP在内部将实际的窗口大小维持为32位的值。
这个选项只能够出现在一个SYN报文段中，因此当连接建立起来后，在每个方向的扩大因子是固定的。为了使用窗口扩大，TCP通信的两端必须在它们的SYN报文段中发送这个选项。主动建立连接的一方（这里一般是客户端）在其SYN中发送这个选项，但是被动建立连接的一方（负载均衡器和服务节点）只能够在收到带有这个选项的SYN之后才可以发送这个选项。每个方向上的扩大因子可以不同。
TCP根据接收缓存的大小自动选择移位计数。也就是说，扩大因子的数值自动产生。当然也可以通过特定的接口由应用层进行修改。
客户端可以在发起SYN握手的时候向均衡器协商窗口扩大因子，数值可以是从0到16之间的任一值（用于表示扩大窗口的位移量，实际的窗口大小为：(16bit的windows大小)×2 （扩大因子））。当均衡器向服务节点发起SYN握手请求后，会将先前对应客户端的窗口扩大选项值传递到服务节点进行协商。如果服务节点支持该选项，将会使用该扩大因子与客户端进行splicing通信，尽管客户端仅仅是简单的把服务节点以0位移扩大因子看待。其实，作为典型的客户－服务通信模式，从服务端－>客户端的返回数据量往往比较大，在客户端使用较大的窗口扩大因子也便于客户端接收大量数据，提高通信的效率。
如果服务节点不支持窗口扩大因子选项，均衡器需要忽略所有客户端的窗口扩大因子选项，使之无效，这一点和其他的扩展TCP选项的处理模式相同，主要是为了兼容更旧的TCP/IP协议栈实现系统。在后续的通信中，客户端将自动调整扩大因子，仅使用16位窗口大小选项来与服务节点通信。
在Linux系统中TCP扩展因子通过 /proc/sys/net/ipv4/tcp_window_scaling设置，0为禁用，1为启用
要支持超过64KB的TCP窗口，必须启用该值（1表示启用），TCP窗口最大至1GB，TCP连接双方都启用时才生效。
TCP窗口扩展因子设置错误导致数据传输慢问题排查始末
标签：window alt syn image log inux net cat 应该
原文地址：http://www.cnblogs.com/simpledevops/p/7366755.html
