描述： A B两台服务器公网传输文件 A B 服务器带宽都超过100M
问题：不管传输多大的文件，服务器出口带宽怎么调大 传输速度永远定在 1-2M （wget rsync scp 都试过，并行的话每个子进程都是1-2M）
测试截图
iperf 测试正常
使用git命令下载测速工具
git clone https://github.com/sivel/speedtest-cli.git
开源测试网络工具正常
但是就是传输到B 服务器的时候 wegt 下载卡在1-2M
各种方法试过找问题，最后找到
检查发现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连接双方都启用时才生效。
暂无评论
写评论