FTP、FTPS、SFTP 和 SCP 在傳輸速率方面如何比較？
答案1
如果您有一個快速的廣域網，您會發現sftp和的scp速度大致相同，但速度很慢。它們都遭受底層 openssh 的效能問題。對於現代硬件，這不是由於加密開銷，而是由於 openssh 實現的問題 - 它實現了自己的內部視窗機制，該機制在快速連接上崩潰。
這些問題在長距離（更高延遲）連接上變得更加明顯，但即使在 LAN 上我也遇到緩慢的情況。
這些都有詳細記錄，並且可以使用補丁來解決問題。修補連接的任一端都會有所幫助；理想情況下，你應該修補兩端。有關更多資訊和補丁，請參閱高性能 SSH在匹茲堡超級電腦中心。
順便說一句，一旦視窗問題解決，加密開銷也可能成為一個問題。補丁也修復了這個問題。
同時，你會發現這ftp是非常不安全的；它以純文字形式發送密碼。
ftps我認為將 ftp 協定封裝在 SSL 中。它可能比未打補丁的 SFTP/SCP 更快。
最後一點：根據我的經驗，WinSCP 客戶端（至少有時）慢得令人痛苦。我不知道為什麼，但根據他們的常見問題解答，我不是唯一遇到此問題的人。因此，如果您從 Windows 進行 scp，而且速度似乎很慢，請嘗試其他用戶端。即使使用未打補丁的 openssh 伺服器，使用不同的客戶端也可以做得更好。不幸的是，我不確定哪些是好客戶，除了pscpPutty 的普通客戶之外。
答案2
一般來說，所有協定的執行效果大致相同。您更有可能受到網路或磁碟速度的限制，而不是協定的限制。
舊版的 OpenSSH (SFTP/SCP) 使用固定的視窗大小，這將限制高延遲網路（例如跨大西洋）的速度。有一個名為 HPN（高效能網路）的補丁集可以解決此問題，它包含在大多數現代 OpenSSH 安裝中。
如果您遇到諸如千兆位元或更快的 LAN 連結和較慢的 CPU 之類的情況，則 SFTP/SCP 可能會遇到瓶頸。您將能夠看出，因為 ssh/scp/sftp 進程將在發送或接收主機上使用 100% 的 cpu。如果您使用的是較新版本的 OpenSSH (6.4+)，您可以啟用 AES 密碼的線程版本，該密碼將能夠使用 1 個以上的核心來處理加密，並且不太可能受到 CPU 而不是磁碟的限製或網路頻寬。
如果您同時控制發送方和接收方，OpenSSH 6+ 還具有可選的「NONECIPHER」模式。這使用常規加密/密鑰等登錄到遠端計算機，但隨後會下降到未加密的連接以進行實際的文件複製。這將消除 CPU 開銷。 NONECIPHER 內建了一些保護措施，可防止您獲得未加密的 shell。
最後，協議不應該成為速度的限制，儘管舊版本的 ssh 確實存在高延遲連結的問題。
答案3
根據加密開銷，我認為普通 FTP 的效能可能比其他協定稍好，但可能可以忽略不計。我會先使用提供您需要的安全性的協議，然後再擔心吞吐量。
話雖這麼說，您必須設定測試才能找到真實的數字。以上一切只是我的意見。如果您在本機測試效能，請在網路上設定伺服器。如果最終使用將透過網際網路進行，請從外部主機進行測試。
答案4
一如既往，谷歌掌握著答案，
FTP 與 SFTP 與 FTPS
其中說 FTP > FTPS > SFTP
在別人的測試中，FTP 似乎也比 SCP 更快（http://www.lysesoft.com/support/forums/viewtopic.php?f=5&t=542）但我建議您親自嘗試一下。
因此，只需在網路上的任意裝置上設定 SCP 和 FTP，然後執行典型的檔案傳輸，看看兩者需要多長時間