同一个 8 MB 文件、同一条连接、同一台手机：原本 54 秒的上传，现在 4 秒。没有开关要打开。
需要 Term v26.1.7 或更高版本。
撰写于
SFTP 浏览器里的上传快了好几倍，大文件的下载也一样。服务器越远，差距越明显——而那正是传文件最难受的场景。没有设置项要找：文件就是变快了。
其余一切照旧。传输依然显示进度、依然可以中途取消，也依然只在真正传完之后才覆盖对端的文件——上传失败的话，服务器上原本的东西保持原样。
一个 8 MB 文件，传给一台真实的 OpenSSH 服务器，链路往返延迟 200 ms——大致相当于连一台在另一个大洲的服务器。计时由应用自己完成，同一台手机，前后相隔几分钟。
省掉的正是「等」，所以服务器越远、能省的越多。就算是近处那台本来就不慢的服务器，也快了约十五倍。
| 服务器 | 上传（之前） | 上传（之后） |
|---|---|---|
| 近处（20 ms） | 1.06 MB/s | 16.1 MB/s |
| 另一个大洲（200 ms） | 0.15 MB/s | 2.10 MB/s |
两行都是同一个文件、同样加在同一台服务器前面的延迟。200 ms 那一行就是上面图里的手机；20 ms 那一行是在电脑上跑的——这么快的链路在电脑上容易安排，在 Wi-Fi 上不好凑。
小于 4 MB 的文件下载有意保持不变：单条流本来就已经接近能达到的上限，而让大文件变快的那套办法用在小文件上，开销比省下来的还多。
「更快」通常意味着「更用力」。这里正好相反。
传同一个 8 MB 文件，要加密的字节一个都没少。但这次上传占用的处理器时间从 2.2 秒降到了 0.33 秒——因为原来那 54 秒里，应用大部分时间是醒着在等服务器回话，而不是在干活。传得越短，就越省。
下载之前用掉 0.35 秒处理器时间，之后是 0.36 秒，而速度是原来的三点五倍。要干的活没变，变的是等待。
原来的传输一次只送出文件的一小块，等服务器确认之后才送下一块，而且每送一块都要求服务器顺手落盘。在每次往返都要花掉五分之一秒的链路上，时间几乎全花在这个等待里——连接大部分时候是空着的。现在同时有好几块在路上，大文件的下载还会拆成四条并行的流、边到边拼回原样。协议没变、服务器没变，对端也不需要做任何改动。
这些是单次运行、单台设备的结果。一台手机、一个 8 MB 文件，延迟是加在同一台机器上的服务器前面的，为的是让数字可以复现。你的链路不是实验室：上行慢、Wi-Fi 拥挤、服务器负载高，都会算进总时间里；这里也没有任何东西能让传输快过它所在的那条连接。
在特别差的连接上，你现在可能会看到传输直接停下，而不是慢慢挪。让好几块数据同时在路上，需要链路撑得住；撑不住时，传输会以「服务器没有响应」结束，而不是磨上好几分钟。服务器上的文件保持原样，换一条好一点的网络重试即可。我们宁愿直接告诉你这次传不成，也不想让它假装十分钟。