排查背景
这个问题发生在外联区域网络中，用户使用SFTP客户端通过专线去第三方服务器拉文件，文件较大，每次都是几个G的文件，线路带宽50Mbps，但传输速度只有50-60KBps，十分缓慢，而且还有随机的中断，所以这里存在两个问题：
- 为什么传输会中断？
- 为什么传输速度会这么慢？
排查过程
整个分析都是基于在SFTP客户端上的抓包，首先，传输中断从数据包中可以看到是由于SFTP服务器端发送的REST报文引起的，很明显是由服务器或中间4-7层设备发出的这个报文，那为什么会出现这个报文呢？在分析了整个报文的TCP窗口后发现，当窗口增加到了65535后，服务器就返回了REST，很有可能与此相关，但也并非每次都会REST。
然后我观察了数据包中的TCP Option，发现缺少TCP Window Scaling factor，这个Option的数值是通过TCP三次握手时协商出的，首先由SYN发起方提供Option字段，SYN+ACK回应方给出支持的Option，后面的传输就会用到支持的Option，而这个问题中的客户端SYN包有window scaling option，但SFTP服务器回应的SYN+ACK中并没有，这就表明窗口增加到65535后就不会再往上涨了，这在一定程度上就限制了数据包的传输速率，因为在窗口无法放开的前提下，服务器在单位时间内发送的数据包就会受限。Linux服务器可以通过以下命令检查是否开启，1代表开启，0代表关闭
cat /proc/sys/net/ipv4/tcp_window_scaling
在解决Window Scaling factor的问题后，发现传输速率有了提升，到了200KBps，但依然没有吃满线路带宽，继续抓包观察，通过在Wireshark中观察I/O图表的数据包传输，发现数据包传输忽高忽低，而正常的数据包传输应该是起来后几乎在一条水平线上，如下图所示：
然后我在IO图表上同时设置了显示 tcp.analysis.fast_retransmission ，发现数据包传输的大起大落都伴随着大量的快速重传，于是可以判断网络上出了什么问题
结论
最后对端检查自己的专线接口发现处于半双工状态，接口CRC错包很多，将其强制置为全双工后问题解决，SFTP传输速率可以吃满带宽，达到5MBps。
在对端发现接口错包后，我马上在本端路由器上做了快ping，发现了不少的丢包，其实这个问题一开始判断的时候就应该从基础排错做起，先做专线点对点的快Ping，可以节省不少时间。另外就是这个问题监控并未告警，所以对这种专线线路一是要提高监控灵敏度，点对点丢1个包都要引起关注，二是要用SNMP监控接口双工状态，只要改变就要告警。
这个问题还蛮常见的，一般运营商提供的设备都不能自适应，都要强制指双工状态和速率的。