當需要在機器之間傳輸400GB文件的時候，你就會非常在意傳輸的速度了。默認情況下(約125MB帶寬，網絡延遲17ms，Intel E5-2430，本文后續討論默認是指該環境)，scp的速度約為40MB，傳輸400GB則需要170分鍾，約3小時，如果可以加速，則可以大大節約工程師的時間，讓攻城師們有更多時間去看個電影，陪陪家人。
目錄
- 1. 結論
- 2. 測試數據：加密算法和壓縮的影響
- 3. 關於是否啟用壓縮
- 4. "壓縮級別"對傳輸速度影響不大
- 5. 測試數據：完整性校驗算法MACs選擇
- 6. 參考閱讀
1. 結論
聲明：這里給出的測試數據不具有一般性，僅供參考。測試與數據本身特性有很大關系，本文使用InnoDB的redo log作為測試數據。
* 改變ssh加密算法，可以讓速度更快；通常，越弱的加密算法，速度越快
* 通常壓縮會降低scp速度，但這與數據類型有很大關系，對壓縮率非常高的數據啟用壓縮，可以加速
* 壓縮級別對傳輸效率影響很小
* 用於完整性校驗的不同MAC( message authentication code)算法，對性能約有10%-20%的影響。
所以，簡單嘗試如下，讓你的SCP速度double一下：
scp -r -c aes192-cbc ...
scp -r -c arcfour128 -o "MACs umac-64@openssh.com" ...
注：啟用壓縮使用參數： -o "Compression yes"
2. 測試數據：加密算法和壓縮的影響
這里對比了12種ssh中實現的加密算法和是否使用壓縮的傳輸效率，測試文件使用的是InnoDB的1GB*4的日志文件(注意：不同類型的文件測試結果會很不同)，這里縱坐標單位為MB/s，數據分為壓縮傳輸和不壓縮傳輸兩組：
原始數據：scp_speed.txt
可以看到，不同加密算法傳輸速度相差很大；使用了壓縮之后，速度下降很多，也看到不同加密算法加密后區別並不大。
3. 關於是否啟用壓縮
* 壓縮只有在網絡傳輸速度非常慢，以致於壓縮后節省的傳輸時間大於壓縮本身的時間，這時才有效果，所以是否啟用壓縮，需要實際測試
* 壓縮比很低的數據，不要再啟用壓縮(例如已經壓縮過的數據、視頻等)
* 通常建議，傳輸前先壓縮，而不是使用ssh的壓縮；建議使用pigz/lbizp2等並行壓縮工具
* 數據中大量重復、空洞，這類適合壓縮的數據，可以嘗試壓縮選項，例如如下是一組，大量"空洞"數據的測試：
看到，壓縮大大提高了傳輸效率
4. "壓縮級別"對傳輸速度影響不大
最后一組對比是，將壓縮級別從1改到9，對比傳輸速度，縱坐標單位MB/s，對12種加密算法分別使用了測試9個壓縮級別，數據如下：
原始數據:
MB/s with-compression without-compressoin
3des-cbc 17.525 13.5
aes256-ctr 20.325 30.2
aes192-ctr 20.275 35.1
aes128-ctr 20.275 38.5
cast128-cbc 20.825 38.9
blowfish-cbc 20.8 43.1
arcfour 21.975 74.2
arcfour128 21.725 75
arcfour256 22.025 75.8
aes128-cbc 21.6 75.8
aes256-cbc 21.325 80.1
aes192-cbc 21.725 85.2
可以看到，壓縮級別對傳輸影響較小。ssh使用的默認壓縮級別是6。
5. 測試數據：完整性校驗算法MACs選擇
通過選項Macs可以設置對應的哈希算法，man ssh_config可以看到支持哪些哈希算法。這里對了比了12中加密算法下使用不用的完整性校驗算法的性能情況：
看到，絕大數情況下"umac-64@openssh.com"(關於此哈希)性能都更好，所以建議嘗試使用此哈希算法做驗證，看看你的場景下速度是否與提升。也可以看到，默認的hmac-md5哈希在默認的加密aes128-ctr下表現比較好；