一行代码解决scp在Internet传输慢的问题

悠悠 2022-09-12 10:55 270阅读 0赞

遇到一个迟来的case，用scp在长链路上传输文件竟然慢到无法忍受！100～200毫秒往返时延的链路，wget下载文件吞吐可达40MBps，scp却只有9MBps。

我开始以为这是加密带宽损耗所致，然而用HTTPS测试却正常。

为了避免pacing平滑掉边沿事件，设置CC为CUIBIC，抓包抓到如下trace波形：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZG9nMjUw_size_20_color_FFFFFF_t_70_g_se_x_16]  
这要么是一个rwnd limited的场景，要么是app limited的场景，肯定不是cwnd limited的场景，我并没有模拟任何丢包和限速。

strace确认是否有setsockopt来设置收发buffer：

$ sudo strace -f -F -e trace=setsockopt -p 1181607
    ...
    [pid 1181977] setsockopt(5, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = 0
    [pid 1181977] setsockopt(5, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0
    ...

用下面的代码bypass一下setsockopt排除影响：

#define _GNU_SOURCE
    #include <dlfcn.h>
    #include <stdio.h>
    #include <sys/socket.h>
    
    typedef int (*orig_setsockopt_f_type)(int sockfd, int level, int optname,
                          const void *optval, socklen_t optlen);
    
    int setsockopt(int sockfd, int level, int optname,
                          const void *optval, socklen_t optlen)
    { 
    	int size;
    	orig_setsockopt_f_type orig_setsockopt;
    	orig_setsockopt = (orig_setsockopt_f_type)dlsym(RTLD_NEXT,"setsockopt");
    	if (optname == SO_SNDBUFFORCE || optname == SO_RCVBUFFORCE ||
    	    optname == SO_SNDBUF || optname == SO_RCVBUF) { 
    		//size = *(int *)optval;
    		//size *= 10;
    		//*(int *)optval = size;
    		return 0;
    	}
    	return orig_setsockopt(sockfd, level, optname, optval, optlen);
    }
    
    // gcc -shared -fPIC -o bypass.so bypass.c -ldl
    // LD_PRELOAD=/root/bypass.so /usr/sbin/sshd -D
    // LD_PRELOAD=/root/bypass.so scp root@192.168.56.101:/var/www/html/big /dev/null

结果依旧。

我写这篇文章的目的不是为了描述如何优化这个case的过程，而是摆一个观点，涉及到网络传输的优化，若不懂协议，仅局限在主机协议栈和编程范畴，很容易陷入细节的深渊。

我并不精通SSH协议，要花点时间去看规范，这花了几乎一个晚上的时间，最终我get到了问题的核心：

*  SSH允许在一个TCP连接上复用多个channel，需要对每一个channel做流控以保证公平，所以每个channel必须自己做而不是使用TCP的流控，OpenSSH的实现有问题。

由于历史原因，不光SSH，很多协议在做端到端流控的时候，均未考虑网络本身的BDP，包括TCP协议。假设带宽无限大且无丢包，接收端处理速率一定，下一批数据到达之前，相对于比较近发送端，接收端需要等待远发送端更久的时间，若想让这段时间内接收端有数据可处理，远发送端必须发送更多的数据。

这里解释一下pacing发送和burst发送和接收窗口的关系：

*  pacing发送：需要保证pacing rate和接收端的处理速度一致。
 *  burst发送：需要保证两次burst间的平均速率和接收端的处理速度一致。

需要确认OpenSSH是如何维护channel接收窗口的，是否有考虑到BDP的影响。

简单猜测就是没有，因为在TCP层都很难精确采集到这些信息，就更别提在应用程序中了。

下载OpenSSH代码：

git clone git://anongit.mindrot.org/openssh.git

找到封装WINDOW\_ADJUST报文的函数channel\_check\_window，果然没有考虑BDP，相当于完全按照接收端channel单位时间处理能力来通告窗口。

打开debug，可以看到无论设置多少的时延，接收端的通告窗口都是随着处理能力而固定变化的：

debug2: channel 0: window 1982464 sent adjust 114688

这像极了《UNIX网络编程》里面的my\_read函数。

改了它便是，为通告窗口增加一个小余量，用来平滑网络传输中的等待时间：

// 修改数据接收端的该函数。
    static int
    channel_check_window(struct ssh *ssh, Channel *c)
    { 
            int r;
    
            if (c->type == SSH_CHANNEL_OPEN &&
                !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) &&
                ((c->local_window_max - c->local_window >
                c->local_maxpacket*3) ||
                c->local_window < c->local_window_max/2) &&
                c->local_consumed > 0) { 
                    if (!c->have_remote_id)
                            fatal_f("channel %d: no remote id", c->self);
                    if ((r = sshpkt_start(ssh,
                        SSH2_MSG_CHANNEL_WINDOW_ADJUST)) != 0 ||
                        (r = sshpkt_put_u32(ssh, c->remote_id)) != 0 ||
                        //(r = sshpkt_put_u32(ssh, c->local_consumed)) != 0 ||
                        // 增加2000试试效果！
                        (r = sshpkt_put_u32(ssh, c->local_consumed + 2000)) != 0 ||
                        (r = sshpkt_send(ssh)) != 0) { 
                            fatal_fr(r, "channel %i", c->self);
                    }
                    debug2("channel %d: window %d sent adjust %d", c->self,
                        c->local_window, c->local_consumed);
                    c->local_window += c->local_consumed;
                    c->local_consumed = 0;
            }
            return 1;
    }

就改了这一行代码，效果杠杠的，看下效果，左边是接收端速率，右边是发送端CPU利用率。先看没改之前的怂样子：  
![在这里插入图片描述][454c44342cdf49b791f5bff76cfe812d.png]  
改过那一行之后：  
![在这里插入图片描述][362a88fcae7e4540913e2ace3a2232ba.png]  
CPU被加解密跑满了，发包迅猛。

我试着将余量增加，企图更快到达极限，传输过程中得到了错误：

client_loop: send disconnect: Broken pipe
    lost connection

这是意料之中的，因为余量会逐渐积累，直到overflow。正确的做法应该在每次通告时减去已经使用的部分后再增加余量。

只改一行代码只能保证积累余量溢出之前传输完毕的正确性，若要修改这个问题也不难，多改几行代码便是：

static int
    channel_check_window(struct ssh *ssh, Channel *c)
    { 
            int r;
    +       int extra = 0;
            
            if (c->type == SSH_CHANNEL_OPEN &&
                !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) &&
                ((c->local_window_max - c->local_window >
                c->local_maxpacket*3) ||
                c->local_window < c->local_window_max/2) &&
                c->local_consumed > 0) { 
    +           	// 不能超过SO_RCVBUF设置的8388608那么大
    +               if (c->local_window_max < 8000000) {  
    +                       extra = 200000; 
    +                       c->local_window_max += extra;
    +               }
                    if (!c->have_remote_id)
                            fatal_f("channel %d: no remote id", c->self);
                    if ((r = sshpkt_start(ssh,
                        SSH2_MSG_CHANNEL_WINDOW_ADJUST)) != 0 ||
                        (r = sshpkt_put_u32(ssh, c->remote_id)) != 0 ||
    -                   (r = sshpkt_put_u32(ssh, c->local_consumed)) != 0 ||
    +                   (r = sshpkt_put_u32(ssh, c->local_consumed + extra)) != 0 ||
                        (r = sshpkt_send(ssh)) != 0) { 
                            fatal_fr(r, "channel %i", c->self);
                    }
                    debug2("channel %d: window %d sent adjust %d", c->self,
                        c->local_window, c->local_consumed);
                    c->local_window += c->local_consumed;
    +               // local_window 加上余量。
    +               c->local_window += extra;
                    c->local_consumed = 0;
            }
            return 1;
    }

OK，问题解决。

虽然最终改了不止一行，但也不多，大概不到10行吧。但这终究只是一个POC，问题是余量如何随着不同的环境而自适应，其实倒也不难，只要可以计算当前的内核TCP缓冲余量即可，以此作为余量就行，而TCP缓冲区可以通过getsockopt获取。

说到底还是要看协议而不是代码，靠手艺而不是靠工具。

如果不懂SSH协议多channel复用TCP，就不知道channel流控，这是scp程序app limited的根源。不懂这个就很难找到要改哪一行，代码工具玩得再溜，再精通语言混社区，不懂协议则寸步难行。

为了让事情规范化，工程化，我感觉无能为力，也不知上述修改的隐患。我承认我无力折腾场面宏大的事情。

通过查阅各种资源，幸运的是，2004年就有人意识到这个问题并且做了伟大的事情，这就是HPN-SSH：  
[https://www.psc.edu/hpn-ssh-home/][https_www.psc.edu_hpn-ssh-home]

同时我找到了一个HPN-SSH的作者对该问题的解释：  
[https://stackoverflow.com/questions/8849240/why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp][https_stackoverflow.com_questions_8849240_why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp]

下面是一个关于SSH性能问题的总览：  
[http://www.allanjude.com/bsd/AsiaBSDCon2017\_-\_SSH\_Performance.pdf][http_www.allanjude.com_bsd_AsiaBSDCon2017_-_SSH_Performance.pdf]

期待Chris Rapier的HPN-SSH可以早日合入OpenSSH主线，完美期待！

好了，这就是本周我要讲的故事。

--------------------

浙江温州皮鞋湿，下雨进水不会胖。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZG9nMjUw_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/84c17cba6c084080a5106685f8b8e883.png
[454c44342cdf49b791f5bff76cfe812d.png]: /images/20220828/9e8ce3bc0f8e4b978c31683720d9ff55.png
[362a88fcae7e4540913e2ace3a2232ba.png]: /images/20220828/3cb70c0b5af94f5b80b95d9194eaf664.png
[https_www.psc.edu_hpn-ssh-home]: https://www.psc.edu/hpn-ssh-home/
[https_stackoverflow.com_questions_8849240_why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp]: https://stackoverflow.com/questions/8849240/why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp
[http_www.allanjude.com_bsd_AsiaBSDCon2017_-_SSH_Performance.pdf]: http://www.allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf