同一個 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 擁擠、伺服器負載高，都會算進總時間裏；這裏也沒有任何東西能令傳輸快過它所在的那條連線。
在特別差的連線上，你現在可能會看到傳輸直接停下，而不是慢慢爬。讓好幾塊資料同時在路上，需要鏈路撐得住；撐不住時，傳輸會以「伺服器沒有回應」結束，而不是磨上好幾分鐘。伺服器上的檔案保持原樣，換一條好一點的網絡重試就可以。我們寧願直接告訴你這次傳不成，也不想讓它假裝十分鐘。