SFTP 传文件（不过墙）上下行都只能跑到带宽十分之一，怎么排查哪里的问题？好几个月了，一点相关资料都找不到。FTP(S)要开多个端口。除了这 3 个似乎没有别的稍微主流一点的原生支持上传的断点续传的协议了

[edis0n0]

[1423]

http ，上传就是对面在下载，隧道打好，对面 aria2c 下载 http

[cnbatch]

还有一种可能性，运营商主动限制了单线程的速度。

已经有先例：
https://www.v2ex.com/t/906804
主题是 IPv6 的，而回帖当中有人提到部分地区、运营商连 IPv4 都有这种限速，所以还得考虑运营商是否限了速。

[cnbatch]

至于支持断点续传的主流协议，别忘了还有 BT 协议，双向断点续传毫无问题。
不想自己制作种子文件的话，用 Syncthing 即可。

[edis0n0]

@cnbatch #2 但我单线程 HTTP 上传也能跑满上行。为了防止 SSH 流量被 QoS ，我套国内 VPN 也测试了一遍，SSH 速度还是只有同样套 VPN 传的 HTTP 的 1/10 。

[ryd994]

filezilla 可以多线程

[edis0n0]

@ryd994 #5 都说了不是多线程的问题

[Vneix]

1.接收端 CPU 性能不足，接收数据时因为解密导致性能下降。（可能性较大）
2.使用非 22 端口试试。

[eason1874]

参数配置要调优吧。我同一台内网机器，用 SMB 大概 115MB/s ，用 SFTP 大概 25MB/s （服务器使用率很低，不知是哪个配置锁死了，我懒得管，不知道怎么调）

[shiji]

https://stackoverflow.com/questions/8849240/why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp

[davidyin]

SFTP 加密解密开销太大？

[jacy]

同问，同服务器 http/https 很快，ss 确超慢

[edis0n0]

@Vneix #7
@davidyin #10 非标端口，两边都是近 5 年主流配置独立服务器，CPU 占用小于<1%

[cnbatch]

那大概率就是加解密的原因了。

这里有一份 SSH 调优参考：
https://www.nsoftware.com/kb/articles/legacy/sbb/6-lowtransferspeedsftp.rst
它第一条就讲清楚了，SSH 一般情况下只有 1-1.5 Mb/s 的速度，想要让速度变快，首先要做的就是调整加密算法，最好换成 AES （因为大概率有硬件加速）。

所以可以尝试下让 SSH 优先使用 AES 。

[edis0n0]

@cnbatch 我的宽带是 100Mbps 下行 50Mbps 上行，HTTP 单线程两者都能跑满，SFTP 只有 10Mbps 下行和 3.5Mbps 还稳不住的上行，就算没有硬件加速也不可能这么慢的

[cnbatch]

SSH 还真的会这么慢，一点都不奇怪，我用 SCP 复制文件经常只有 1~2 MB/s 的速度，速度快的反倒极少遇到，换成 SFTP 才好点但也不保证万能。

那份 SSH 调优参考是这么说的：
DES and 3DES are very slow, RC4 is the fastest, and AES is relatively fast
DES 和 3DES 非常慢，RC4 最快，AES 相对较快

some clients started to use hardware support for processor instructions that make AES faster
某些客户端使用硬件指令集支持让 AES 更快

如果你的 SSH 恰好就用 DES 或者 3DES ，它还真的可以慢到气死人

[datocp]

stunnel 有关于各种算法的性能测试

Performance was tested on:

Intel® Core™ i5-3570K CPU @ 3.40GHz
Ubuntu 14.10, kernel 3.18.11-031811-generic x86_64
OpenSSL 1.0.2a (built from source with gcc-4.9)
stunnel 5.16 running on a single CPU core (taskset -c 0)
(1) 2048-bit RSA certificate
(2) Negotiated encryption: ECDHE-RSA-AES256-GCM-SHA384
(3) Negotiated encryption: PSK-AES256-CBC-SHA
(4) In order to handle N concurrent connections on a Unix platform, stunnel requires nfile (ulimit -n) to be higher than 2*N, and nproc (ulimit -u) to be higher than N

ECDHE-RSA-AES128-GCM-SHA256 688 MB/s 5.5 Gbit/s
ECDHE-RSA-AES256-GCM-SHA384 648 MB/s 5.2 Gbit/s
ECDHE-RSA-AES128-SHA256 244 MB/s 2.0 Gbit/s
ECDHE-RSA-AES256-SHA384 204 MB/s 1.6 Gbit/s
DES-CBC3-SHA 28 MB/s 0.22 Gbit/s