作者：刘开洋
爱可生交付服务团队北京 DBA，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
1、问题
前几天跟客户聊天，埋怨服务器之前的数据传输工具不好用，问我哪种传输工具效率高？还真被问住了，毕竟没通过实际嘛，明天就测试下。
有点粗率得搜寻了下，不过工具还不少。
数据传输工具: ftp sftp scp rsync tftp
2、筹备工作
刨除网络带宽等其余因素，咱们就 Linux 服务器之间传输文件做个比照，看看到底什么工具才是最快、最适宜我的场景的。
咱们就下面这些传输工具在文件理论大小和文件数量多少的档次上别离做个比照速度和简便性比照：
首先筹备环境，配置两个机器 ssh 互信，创立两个文件夹，以不同的形式创立一个 50G 左右的大文件和 51200 个 1M 的小文件：
# 制作 50G 大文件
[root@yang-01 big]# fallocate -l 50G 50g_file
[root@yang-01 big]# ll
total 52428856
-rw-r--r-- 1 root root 53687091200 Apr 10 17:55 50g_file
[root@yang-01 big]# du -sh *
51G 50g_file
# 制作 51200 个 1M 文件
[root@yang-01 many]# seq 51200 | xargs -i dd if=/dev/zero of=1m_file{} bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00468854 s, 224 MB/s
······
[root@yang-01 many]# ls | wc -l
51200
[root@yang-01 test]# du -sh many
51G many小提示：这里采纳了两种形式制作大文件，大家能够参考应用，生成文件的确是 50G，字节数与之对应，至于为什么 du 工具计算出来是 51G，这里并不是计算机 1024 与 1000 的数值换算的起因，而是因为 du 命令计算的是该文件累计应用到文件系统的总块数，可能呈现应用的局部块空间占用并不残缺的状况，导致数值偏大。
#### 2.1、测试 SCP
第一个测试的是 scp，这是作者应用频率最多的一个近程传输工具，通常 Linux 零碎会装置有该工具。
####### 1 * 50G 文件测试
[root@yang-02 big]# scp /opt/test/big/50g_file root@yang-01:/opt/test/re/
50g_file 100% 50GB 135.5MB/s 06:17
####### 51200 * 1M 文件测试
[root@yang-02 many]# time scp /opt/test/many/1m_file* root@yang-01:/opt/test/re/
1m_file1 100% 1024KB 22.5MB/s 00:00
1m_file10 100% 1024KB 35.8MB/s 00:00
1m_file100 100% 1024KB 14.8MB/s 00:00
1m_file1000 100% 1024KB 32.9MB/s 00:00
1m_file10000 100% 1024KB 35.7MB/s 00:00
······
1m_file9998 100% 1024KB 113.4MB/s 00:00
1m_file9999 100% 1024KB 96.5MB/s 00:00
real 20m43.875s
user 4m2.448s
sys 2m52.604s
[root@yang-01 re]# ls | wc -l
51200阐明：
- 相似于 cp 命令，因为跨机器文件加密传输导致其速度稍慢于 copy 操作；
- 如果存在生产环境中无奈应用 ssh 协定的状况，能够采纳 nc 文件传输；
- 长处：该工具对于机器的系统资源占用少、影响较小，使用方便；
2.2、测试 FTP
上面测一下 ftp，看看成果如何。
####### 1 * 50G 文件测试
[root@yang-01 re]# ftp yang-02
Connected to yang-02 (192.168.88.72).
220 (vsFTPd 3.0.2)
Name (yang-02:root): root
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get /opt/test/big/50g_file /opt/test/re/50g_file
local: /opt/test/re/50g_file remote: /opt/test/big/50g_file
227 Entering Passive Mode (192,168,88,72,38,232).
150 Opening BINARY mode data connection for /opt/test/big/50g_file (53687091200 bytes).
226 Transfer complete.
53687091200 bytes received in 150 secs (359091.49 Kbytes/sec)
ftp> quit
221 Goodbye.
####### 51200 * 1M 文件测试
[root@yang-01 re]# time ftp yang-02
Connected to yang-02 (192.168.88.72).
220 (vsFTPd 3.0.2)
Name (yang-02:root):
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> prompt off
Interactive mode off.
ftp> cd /opt/test/many
250 Directory successfully changed.
ftp> mget * .*
local: 1m_file1 remote: 1m_file1
227 Entering Passive Mode (192,168,88,72,156,228).
150 Opening BINARY mode data connection for 1m_file1 (1048576 bytes).
226 Transfer complete.
······
1048576 bytes received in 0.00337 secs (311057.86 Kbytes/sec)
local: . remote: .
227 Entering Passive Mode (192,168,88,72,213,4).
550 Failed to open file.
Warning: embedded .. in .. (changing to !!)
local: !! remote: !!
227 Entering Passive Mode (192,168,88,72,223,91).
550 Failed to open file.
ftp> quit
221 Goodbye.
real 14m32.032s
user 0m12.857s
sys 3m21.131s
[root@yang-01 re]# ls | wc -l
51200阐明：
- 基于 TCP 传输协定，ftp 客户端收回命令到服务端进行文件下载、上传或者变更目录；
- 实用于内网的文件归集以及公共文件的调阅。
- 偶发性的文件传输，为了保障各主机之间的安全性，个别不会应用这种形式进行数据传输。
2.3、测试 SFTP
sftp 就是在 ftp 的根底上补充了 加密 / 解密 的技术，咱们也一起看下和 ftp 的传输速度差别：
####### 1 * 50G 文件测试
[root@yang-01 re]# sftp root@yang-02
Connected to yang-02.
sftp> get ./big/50g_file /opt/test/re/50g_file
Fetching /./big/50g_file to /opt/test/re/50g_file
/./big/50g_file 100% 50GB 128.7MB/s 06:37
sftp> quit
####### 51200 * 1M 文件测试
[root@yang-01 re]# time sftp root@yang-02
Connected to yang-02.
sftp> get ./many/1m_file* /opt/test/re/
Fetching /./many/1m_file1 to /opt/test/re/1m_file1
/./many/1m_file1 100% 1024KB 77.3MB/s 00:00
······
Fetching /./many/1m_file9999 to /opt/test/re/1m_file9999
/./many/1m_file9999 100% 1024KB 118.0MB/s 00:00
sftp>
sftp> quit
real 19m43.154s
user 4m52.309s
sys 4m47.476s
[root@yang-01 re]# ls | wc -l
51200阐明：
- 相较于 ftp 工具，在晋升安全等级的根底上对 ssh 传输进行加密，sftp 的传输速率升高了 70% 左右；
- 应用 sftp 和 ftp 的应用须要搭建服务，应用麻烦，且 sftp 的传输速率相似于 scp。
2.4、测试 RSYNC
再看看 rsync 工具的测试：
####### 1 * 50G 文件测试
[root@yang-02 big]# time rsync -av ./50g_file root@yang-01:/opt/test/re/50g_file
sending incremental file list
50g_file
sent 53,700,198,488 bytes received 35 bytes 107,940,097.53 bytes/sec
total size is 53,687,091,200 speedup is 1.00
real 8m17.039s
user 5m36.160s
sys 2m41.196s
####### 51200 * 1M 文件测试
[root@yang-02 many]# time rsync -av ./1m_file* root@yang-01:/opt/test/re/
sending incremental file list
1m_file1
1m_file10
1m_file100
······
1m_file9998
1m_file9999
sent 53,702,886,375 bytes received 972,872 bytes 58,278,740.37 bytes/sec
total size is 53,687,091,200 speedup is 1.00
real 15m21.548s
user 5m46.497s
sys 2m38.581s阐明：
- rsync 从比 scp 略微快一点，Centos 中默认装置；
- 占用带宽少，因为 rsync 在两端服务器之间传输数据块时会进行解压缩解决。
- 劣势：rsync 只会同步发生变化的文件，如果没有变更，rsync 不会进行笼罩解决，即 rsync 适宜增量同步（因为场景起因，这里没有过多演示）；
- 如果传输文件数量多的时候，rsync 工具可能会导致磁盘的 I/O 偏高，如果文件系统中存在数据库会产生肯定影响。
2.5、测试 TFTP
相似于 sftp，测一下 tftp 的速度怎么样：
####### 1 * 50G 文件测试
[root@yang-01 re]# time tftp yang-02
tftp> get ./big/50g_file
real 10m30.114s
user 0m6.029s
sys 1m16.888s
[root@yang-01 re]# ll
total 1805832
-rw-r--r-- 1 root root 1849168384 Apr 11 17:54 50g_file
[root@yang-01 re]# du -sh *
1.8G 50g_file
####### 1 * 1G 文件测试
[root@yang-01 re]# time tftp yang-02
tftp> get ./many/1g_file1
tftp> quit
real 5m54.090s
user 0m29.190s
sys 2m58.866s
[root@yang-01 re]# ll
total 1048576
-rw-r--r-- 1 root root 1073741824 Apr 11 18:09 1g_file1阐明：
- tftp 工具是基于 UDP 协定进行数据传输，同样须要配置相干服务，应用过于麻烦；
- 测试 50G 大文件传输仅仅 1.8G，产生超时中断，fail，且工夫较长；
- 测试 1 个 1G 文件传输工夫为 354s，揣测 50 倍工夫较长，放弃该工具的测试。
2.6、补充 NC
小编补充 nc 工具必定是遇到了上述工具无奈实现数据传输的场景，咱们测下速度：
####### 1 * 50G 文件测试
[root@yang-02 big]# nc 192.168.88.71 10086 < /opt/test/big/50g_file
[root@yang-01 re]# time nc -l 10086 > 50G_file
real 2m30.663s
user 0m9.232s
sys 2m16.370s
####### 51200 * 1M 文件测试
[root@yang-01 many]# tar cfz - *|nc 192.168.88.71 10086
[root@yang-01 re]# time nc -l 10086|tar xfvz -
1m_file1
1m_file10
1m_file100
···
1m_file9997
1m_file9998
1m_file9999
real 11m38.400s
user 3m47.051s
sys 2m33.923s阐明：
- 这个工具的性能很是弱小，能够实现任意 TCP/UDP 端口的监听与扫描；
- 劣势：速度相比于 scp 快很多，简直没有网络协议的开销；
- 跨机器传输文件只是它的性能之一，其余性能期待大家摸索，据说能够网络测速哦。
2.7、补充 python 工具
如果还有 nc 无奈解决的场景，咱们再试下应用 python 的 SimpleHTTPServer 模块吧：
####### 1 * 50G 文件测试
[root@yang-02 big]# python -m SimpleHTTPServer 10086
Serving HTTP on 0.0.0.0 port 10086 ...
192.168.88.71 - - [13/Apr/2022 16:02:15] "GET /50g_file HTTP/1.1" 200 -
[root@yang-01 re]# wget http://192.168.88.72:10086/50g_file
--2022-04-13 16:02:15-- http://192.168.88.72:10086/50g_file
Connecting to 192.168.88.72:10086... connected.
HTTP request sent, awaiting response... 200 OK
Length: 53687091200 (50G) [application/octet-stream]
Saving to:‘50g_file’100%[==================================================================================>] 53,687,091,200 358MB/s in 2m 35s
2022-04-13 16:04:50 (330 MB/s) -‘50g_file’saved [53687091200/53687091200]
####### 51200 * 1M 文件测试
[root@yang-02 many]# python -m SimpleHTTPServer 10086
Serving HTTP on 0.0.0.0 port 10086 ...
192.168.88.71 - - [13/Apr/2022 19:46:02] "GET /1m_file1 HTTP/1.1" 200 -
192.168.88.71 - - [13/Apr/2022 19:46:02] "GET /1m_file2 HTTP/1.1" 200 -
······
192.168.88.71 - - [13/Apr/2022 19:55:21] "GET /1m_file51200 HTTP/1.1" 200 -
[root@yang-01 re]# cat liu.sh
#!/bin/bash
for ((i=1;i<=51200;i++))
do
echo "http://192.168.88.72:10086/1m_file$i"
done
[root@yang-01 re]# bash liu.sh > liu.list
[root@yang-01 re]# cat liu.list | wc -l
51200
[root@yang-01 re]# wget -i liu.list
--2022-04-13 19:46:02-- http://192.168.88.72:10086/1m_file1
Connecting to 192.168.88.72:10086... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576 (1.0M) [application/octet-stream]
Saving to:‘1m_file1’100%[=====================================================================================>] 1,048,576 --.-K/s in 0.05s
2022-04-13 19:46:02 (19.9 MB/s) -‘1m_file1’saved [1048576/1048576]
·······
100%[=====================================================================================>] 1,048,576 --.-K/s in 0.08s
2022-04-13 19:55:21 (11.9 MB/s) -‘1m_file51200’saved [1048576/1048576]
FINISHED --2022-04-13 19:55:21--
Total wall clock time: 9m 19s
Downloaded: 51200 files, 50G in 8m 11s (104 MB/s)阐明：
- 应用 python 的 SimpleHTTPServer 模块或者 python3 的 http.server 模块实现了一个轻量级的 HTTP 协定的 Web 服务器；
- Linux 发行版本简直都内置有 python，所以该工具应用也较为不便。
- 失常状况下，多文件传输有些麻烦，文件名可能无规律，须要单文件挨个解决。
3、总结
- 大文件传输速率：FTP > NC > python 工具 > SCP > SFTP > RSYNC。
- 小文件传输速率：python 工具 > NC > FTP > RSYNC > SFTP > SCP。
- 不同工具具备不同的利用场景，RSYNC 在增量同步或定期归档的状况下速度很快；FTP 工具搭建部署麻烦，实用于内网的文件归集以及公共文件的调阅，安全性低。
- 如果因为生产平安限度，敞开了 SSH 连贯或 22 端口的应用，能够应用基于其余协定的连贯拜访，举荐 nc 工具。
- 比照每个工具对于同容量的文件数量测试，小文件会导致 CPU 屡次读取匹配信息，减少 CPU 累赘，IO 的次数也会增多，存在肯定的 IO 瓶颈，同容量的大文件和多个小文件传输比照会有肯定的速度劣势。
- 如果是大量文件传输，可依据文件名特点分批次设置多个传输过程，从而达到源端服务器并发传输的成果，更好的利用网络带宽。
4、备注
- 因为操作限度，以上测试工具均疏忽交互式登录的工夫。
- 测试为虚拟机环境，无奈保障变量相对可控 (网络带宽、吞吐、磁盘性能等影响因素)，因而文中给出的工夫节点仅供参考。
- 对于各个工具的应用阐明及拓展，这里并没有给出，网上材料很多，各位老板随便爬取。
彩蛋：小编测试时发现各个工具 50 1G 的传输速度要快于 1 50G 文件，所以在同一环境下，会不会存在一种状况的 50G 容量（单文件容量和数量的穿插匹配）传输速度达到最快？有趣味的小伙伴能够持续钻研下。