一行代碼解決scp在Internet傳輸慢的問題

遇到一個遲來的case，用scp在長鏈路上傳輸檔案竟然慢到無法忍受！100～200毫秒往返時延的鏈路，wget下載檔案吞吐可達40MBps，scp卻只有9MBps，

我開始以為這是加密帶寬損耗所致，然而用HTTPS測驗卻正常，

為了避免pacing平滑掉邊沿事件，設定CC為CUIBIC，抓包抓到如下trace波形：

這要么是一個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利用率，先看沒改之前的慫樣子：

改過那一行之后：

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/

同時我找到了一個HPN-SSH的作者對該問題的解釋：
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

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

好了，這就是本周我要講的故事，

浙江溫州皮鞋濕，下雨進水不會胖，