![快速的方法](https://linux22.com/image/25602/%E5%BF%AB%E9%80%9F%E7%9A%84%E6%96%B9%E6%B3%95.png)
我在使用 NFS 时遇到了一些问题,我想尝试使用普通的旧 TCP。
但我不知道从哪里开始。
在硬件方面,我使用以太网交叉电缆将两台上网本联网。
为了将它们联网,我输入
$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start
在第一台上网本上
$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1
在第二个
/mnt/network1
在 /etc/fstab 中指定为
192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0
以及/etc/exports
(使用该文件的语法),在第一台上网本上。
上面的方法工作正常,但是文件和目录很大。每个文件平均约为 0.5 GB,目录大小均在 15 到 50 GB 之间。
我用来rsync
传输它们,命令( on 192.168.1.2
)是
$ rsync -avxS /mnt/network1 ~/somedir
我不确定是否有办法调整我的 NFS 设置以更好地处理大文件,但我想看看rsync
通过普通旧 TCP 运行守护程序是否比rsync
通过 NFS 更好。
那么,重申一下,如何使用 TCP 建立类似的网络?
更新:
因此,经过几个小时的努力,我试图将自己从无知的泥潭中拉出来(或者,正如我喜欢这样想的,通过自己的努力让自己站起来),我得出了一些有用的事实。
但首先,导致我走上这条兔子之路而不是简单地接受当前最佳答案的是:这nc
是一个令人难以置信的酷程序,但它绝对不适合我。我已经尝试过netcat-openbsd
和netcat-traditional
软件包,但没有任何运气。
我在接收机器 ( ) 上收到的错误192.168.1.2
是:
me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
route
给出:
me@netbook:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default dir-615 0.0.0.0 UG 0 0 0 wlan0
link-local * 255.255.0.0 U 1000 0 0 eth0
192.168.0.0 * 255.255.255.0 U 2 0 0 wlan0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
但是,这里有一个好消息:在 中设置静态 IP 地址/etc/network/interfaces
(我在尝试开始nc
工作时开始这样做)解决了我所有的 NFS 问题并重新点燃了我对 NFS 的热爱。
我使用的确切配置(192.168.1.1
当然是第一台上网本)是:
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
通过这些设置,两台上网本将能够在启动后直接相互 ping 通,甚至不需要ifup
.
不管怎样,我仍然很想看到nc
实际情况,所以我希望有人帮助我调试这个过程。
答案1
快速的方法
这最快的通过 LAN 传输文件的方式很可能不是 rsync,除非有少量更改。 rsync 花费相当多的时间进行校验和、计算差异等。如果您知道无论如何都将传输大部分数据,只需执行类似的操作(注意:有多种实现netcat
;请查看手册特别是,您可能不想要-p
):
user@dest:/target$ nc -q 1 -l -p 1234 | tar xv
user@source:/source$ tar cv . | nc -q 1 dest-ip 1234
它使用 netcat ( nc
) 通过端口 1234 上的原始 TCP 连接发送 tar。没有加密、真实性检查等,因此速度非常快。如果您的交叉连接以千兆位或更低的速度运行,您将与网络挂钩;如果更多,您将挂钩磁盘(除非您有存储阵列或快速磁盘)。 tar 的标志v
使其在运行时打印文件名(详细模式)。对于大文件,这几乎没有开销。如果您正在处理大量小文件,则可以将其关闭。另外,您可以pv
在管道中插入类似的内容来获取进度指示器:
user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv
当然,您也可以插入其他内容,例如(并在接收端gzip -1
添加标志 -发送端的标志将使用比 1 更高的压缩级别,当然,除非您设置 GZIP 环境变量)。虽然 gzip 实际上可能会更慢,除非你的数据z
z
真的压缩。
如果你确实需要 rsync
如果您确实只传输一小部分已更改的数据,则 rsync 可能会更快。您可能还想查看-W
/--whole-file
选项,因为真正快速的网络(如交叉连接)可以更快。
运行 rsync 最简单的方法是通过 ssh。您需要尝试使用 ssh 密码来看看哪个最快,它可以是 AES、ChaCha20 或 Blowfish(尽管 Blowfish 的 64 位块大小存在一些安全问题),具体取决于您的芯片是否具有 Intel 的 AES -NI 指令(并且您的 OpenSSL 使用它们)。在一个足够新的 ssh 上,rsync-over-ssh 看起来像这样:
user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target
对于较旧的 ssh/sshd,请尝试使用aes128-ctr
或aes128-cbc
代替[email protected]
.
ChaCha20 是[email protected]
(还需要一个足够新的 ssh/sshd),Blowfish 是blowfish-cbc。 OpenSSH 不允许在没有密码的情况下运行。您当然可以使用您喜欢的任何 rsync 选项来代替-avP
.当然,您可以走另一个方向,从目标计算机(拉)而不是源计算机(推)运行 rsync。
使 rsync 更快
如果您运行 rsync 守护进程,则可以消除加密开销。首先,您将创建一个守护程序配置文件 ( /etc/rsyncd.conf
),例如在源计算机上(有关详细信息,请阅读 rsyncd.conf 联机帮助页):
[big-archive]
path = /source
read only = yes
uid = someuser
gid = somegroup
然后,在目标计算机上运行:
user@dest:~$ rsync -avP source-ip::big-archive/ /target
您也可以以相反的方式执行此操作(但当然您需要将只读设置为否)。有身份验证等选项,请查看联机帮助页了解详细信息。
答案2
如何?或 TL;DR
tar
我发现的最快方法是,mbuffer
和的组合ssh
。
例如:
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
使用它,我在 1Gb 链路上实现了超过 950 Mb/s 的持续本地网络传输。替换每个 tar 命令中的路径以适合您要传输的内容。
为什么?缓冲区!
到目前为止,通过网络传输大文件的最大瓶颈是磁盘 I/O。答案是mbuffer
或buffer
。它们大体相似,但也mbuffer
有一些优点。默认缓冲区大小为 2MB mbuffer
,默认缓冲区大小为 1MB buffer
。较大的缓冲区更有可能永远不会为空。选择目标文件系统和目标文件系统上本机块大小的最小公倍数的块大小将提供最佳性能。
缓冲是让全部区别!有的话就用吧!如果你没有,那就去获取吧!使用(m}?buffer
任何东西都比单独使用任何东西更好。它几乎可以说是解决缓慢网络文件传输的灵丹妙药。
如果您要传输多个文件,请使用tar
将它们“集中”到一个数据流中。如果是单个文件,您可以使用cat
I/O 重定向。tar
vs.的开销cat
在统计上是微不足道的,所以我总是使用tar
(或者zfs -send
在我可以的地方),除非它已经是压缩包。这些都不能保证为您提供元数据(尤其是cat
不会)。如果您需要元数据,我会将其作为练习留给您。
最后,用于ssh
传输机制既安全又开销很小。同样,ssh
与 的开销nc
在统计上是微不足道的。
编辑
好的,各位,这个答案是十岁了。时代变了。
- 这个问题具体是关于局域网s,而不是大陆之间。
- mbuffered ssh 与 mbuffered nc 在统计上并不显着。单独使用 ssh 与单独使用 nc 是另一回事。 tcp 与 udp 模式下的 NC 是另一回事。
- 在此更新(2022-01)时,高速文件传输的最佳一般答案仍然是(正如 @derobert 在评论中提到的)。
scp -c [email protected]
答案3
您甚至不需要使用 TCP。 AoE 是以太网上的 ATA 实现,作为第 2 层,它是一种开销较低的方法,无需了解 TCP/IP 堆栈。它将以最少的开销为您提供最快的传输速度。***
https://en.wikipedia.org/wiki/ATA_over_Ethernet
***如果网络是瓶颈,请确保您发送的是压缩数据。