加速scp传输速度

标签: 系统运维 | 发表时间:2013-11-07 07:28 | 作者:Orczhou
出处:http://www.blogread.cn/it/

标签:   scp

   当需要在机器之间传输400GB文件的时候,你就会非常在意传输的速度了。默认情况下(约125MB带宽,网络延迟17ms,Intel E5-2430,本文后续讨论默认是指该环境),scp的速度约为40MB,传输400GB则需要170分钟,约3小时,如果可以加速,则可以大大节约工程师的时间,让攻城师们有更多时间去 看个电影,陪陪 家人

1. 结论

    声明:这里给出的测试数据不具有一般性,仅供参考。测试与数据本身特性有很大关系,本文使用InnoDB的redo log作为测试数据。

   * 改变ssh加密算法,可以让速度更快; 通常,越弱的加密算法,速度越快

   * 通常压缩会降低scp速度,但这与数据类型有很大关系,对压缩率非常高的数据启用压缩,可以加速

   * 压缩级别对传输效率影响很小

   * 用于完整性校验的不同 MAC( message authentication code)算法,对性能约有10%-20%的影响。

   所以,简单尝试如下,让你的SCP速度double一下:

scp -r -c arcfour128 ...

   scp -r -c aes192-cbc ...

   scp -r -c arcfour128 -o "MACs [email protected]" ...

   注:启用压缩使用参数: -o "Compression yes"

2. 测试数据:加密算法和压缩的影响

   这里对比了12种ssh中实现的加密算法和是否使用压缩的传输效率,测试文件使用的是InnoDB的1GB*4的日志文件(注意:不同类型的文件测试结果会很不同),这里纵坐标单位为MB/s,数据分为压缩传输和不压缩传输两组:

    screen-scp-compare-cipher-compression

   原始数据: scp_speed.txt

   可以看到,不同加密算法传输速度相差很大;使用了压缩之后,速度下降很多,也看到不同加密算法加密后区别并不大。

3. 关于是否启用压缩

   * 压缩只有在网络传输速度非常慢,以致于压缩后节省的传输时间大于压缩本身的时间,这时才有效果,所以是否启用压缩,需要实际测试

   * 压缩比很低的数据,不要再启用压缩(例如已经压缩过的数据、视频等)

   * 通常建议,传输前先压缩,而不是使用ssh的压缩;建议使用pigz/lbizp2等并行压缩工具

   * 数据中大量重复、空洞,这类适合压缩的数据,可以尝试压缩选项,例如如下是一组,大量"空洞"数据的测试:

    chart_1

   看到,压缩大大提高了传输效率

4. "压缩级别"对传输速度影响不大

   最后一组对比是,将压缩级别从1改到9,对比传输速度,纵坐标单位MB/s,对12种加密算法分别使用了测试9个压缩级别,数据如下:

    screen-scp-compare-compression-level

    大图链接 原始数据: scp-compression-level.txt

   可以看到,压缩级别对传输影响较小。ssh使用的默认压缩级别是6。

5. 测试数据:完整性校验算法MACs选择

   通过选项Macs可以设置对应的哈希算法,man ssh_config可以看到支持哪些哈希算法。这里对了比了12中加密算法下使用不用的完整性校验算法的性能情况:

    screen-scp-compare-macs-all

    查看大图

   看到,绝大数情况下"[email protected]"( 关于此哈希)性能都更好,所以建议尝试使用此哈希算法做验证,看看你的场景下速度是否与提升。也可以看到,默认的hmac-md5哈希在默认的加密aes128-ctr下表现比较好;

6. 参考阅读

   * differenct between -ctr/cbc:介绍了ctr和cbc的区别

   *   The use of UMAC in the SSH Transport Layer Protocol介绍umac相关的哈希算法

   * 在 <<The Secure Shell: The Definitive Guide>> ISBN: 0-596-00011-1概述了各种加密算法的安全性和效率 参考

   * man scp/ssh/ssh_config

   * OpenSSH ciphers performance benchmark

   * 100% SCP/SSH Performance Gain by Selecting the Right Algorithm

   *   Ciphers and [email protected]

您可能还对下面的文章感兴趣:

  1. 使用scp在windows和Linux之间互传文件 [2010-12-15 22:08:42]
  2. 使用scp命令在两台linux上对拷文件或者文件夹 [2010-04-16 09:22:04]
  3. linux 建立两台机器的信任关系 [2009-12-07 16:11:39]

相关 [加速 scp 传输] 推荐:

加速scp传输速度

- - IT技术博客大学习
   当需要在机器之间传输400GB文件的时候,你就会非常在意传输的速度了. 默认情况下(约125MB带宽,网络延迟17ms,Intel E5-2430,本文后续讨论默认是指该环境),scp的速度约为40MB,传输400GB则需要170分钟,约3小时,如果可以加速,则可以大大节约工程师的时间,让攻城师们有更多时间去 看个电影,陪陪 家人.

表空间传输

- - 数据库 - ITeye博客
Oracle 的可传输表空间特性通过将 元数据和数据文件 简单地从一个数据库移动到另一个数据库,提供 在数据库之间有效移动大数据的一种简易方法. 代替重新创建对象,可移植表空间可以让 毫不费力地移动大对象,而所花费的时间是你手动创建这些对象的时间. 可移植表空间包括将属于源数据库的所有数据文件拷贝到目标数据库,并将关于表空间 数据目录信息从源数据库拷贝到目标数据库.

加速膨胀

- ndv - 博客李淼
宇宙学从上世纪六十年代成了现代科学的一部分,既有理论,也有实验(观测). 大爆炸宇宙学说先有理论,后有观测支持,这和很多物理学发现有所不同. 物理学家们最初不仅预言了一些轻元素的丰度(氢、氦、氘、锂等),还预言了微波背景辐射. 后者是无所不在的温度大约为2.7K的黑体辐射,在六十年代为威尔逊和彭齐亚斯所发现.

加速MapReduce2

- - CSDN博客云计算推荐文章
       原文链接: Getting MapReduce 2 Up to Speed        因为文章中采用的改善措施,CDH 5 让MapReduce2中作业的速度和MapReduce1的速度一样(甚至更快).        一旦你知道问题所在,性能改进的地方会很微小、简单,甚至乏味.

Windows 8改进文件传输体验

- Homer - Solidot
多年来,Windows资源管理器对话框一直在兢兢业业的计算完成一个大文件复制或删除操作需要花多长时间. 然而,剩余时间对话框经常会让人摸不着头脑,它会从几小时跳到几分钟再跳到几秒钟,仿佛虚无般的缥缈. 现在,在Windows 8中,你将不会有类似体验了,因为微软取消了剩余时间估计. Windows项目经理Alex Simmons在Building Windows 8博客上介绍新一代操作系统在文件管理上的改进:所有复制任务都展示在同一对话框内;用完成传输的比率取代剩余时间估计,但用户可以点击“更多细节”了解完成任务的剩余时间、传输速率和剩余传输大小.

c_socket.io_server笔记之htmlfile块传输

- - BlogJava-首页技术区
关于htmlfile chunked传输. Google天才工程师们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题,具体是封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象,支持 IE、Mozilla Firefox 浏览器,但需要服务器端配合使用.

window.name实现的跨域数据传输

- - Web前端 - ITeye博客
a.com/app.html:应用页面. a.com/proxy.html:代理文件,一般是一个没有任何内容的html文件,需要和应用页面在同一域下. b.com/data.html:应用页面需要获取数据的页面,可称为数据页面. 在应用页面(a.com/app.html)中创建一个iframe,把其src指向数据页面(b.com/data.html).

手机数据传输安全分析

- - FreeBuf.COM | 关注黑客与极客
如今手机已经成了我们离不开的伙伴和知己,它了解我们的日常生活. 然而每一天在路上的时候,它都会收集我们的私密信息. 平时我们会用它拍照,在社交网络中分享我们的心情;我们也用它发送邮件、短信以及拨打电话. 所以,这些信息则让我们的智能手机成为黑客眼热的宝库. 最重要的是,我们中大多数人相信手机中的数据是绝对安全的.

优雅地实现 TCP 压缩传输

- - 鸟窝
集群式、负载均衡的RPC框架 rpcx支持多种的序列化库,可以有效的减少消息体的大小,但是对于字符串或者图片的字节slice,明显还可以进一步的压缩,正如fasthttp作者valyala在他的新的开源项目 httpteleport中描述的: 通过1G的带宽传输10G的数据 (夸张). 为了在RPC的传输中减少传输的数据大小,我在不影响rpcx整体框架的基础上,参考了httpteleport的实现,对 net.TCPConn进行了封装,实现了压缩/解压缩功能的 net.Conn,可以有效的减少带宽,节省公司在带宽上的花费, 以下就是具体的实现.