atppp’s Blog

网络到底能有多快？废话少说，先从一些基本问题说起。

A. 速度单位和测速方法

文件传输速度一般用 MB/s 表示。这个缩写 MB 涉及到 Binary Prefix 的问题，按照最正统的约定，1 MB = 10⁶ = 1 000 000 bytes，而 1 MiB = 2²⁰ = 1 048 576 bytes，这两者只相差 5%，很多地方就常常混用。比方 dd 命令汇报的速度是正统的 MB/s，而 wget 和大部分浏览器显示的 MB/s 则实际上是 MiB/s。

网络连接速度则一般用 Mbps 表示，百兆以太网连接速度是 100 Mbps，也即 100 000 000 bits per second。一个 byte 是 8 个 bit，注意一般小写 b 表示 bit，大写 B 表示 byte。比方 USB 2.0 极限速度是 480 Mbps，实际上只不过是 60 MB/s，现代内置硬盘的速度都远高于此。

因此我们可以看到，百兆以太网 100 Mbps 数据传输的极限速度是 100 000 000 / 8 / 2²⁰ = 11.9 MiB/s。但是这些数据中大概至少有 2% 是网络包头之类的，其真正的有用数据吞吐率（throughput）极限是 11.6 MiB/s 左右。

有关测速方法，fishy 同学对此似乎很有研究。现成的可以测试和显示网络传输速度的命令有比如 dd, rsync --progress, wget, scp 等，windows 下面那就用 ftp 软件或者浏览器好了……

B. 影响速度的因素

我们平时架的家用局域网一般都是百兆以太网，通常情况下，传文件至少可以达到 11 MiB/s 的速度，但是也未必，有各种因素会减慢这个速度。

• 网络传输协议：通常在局域网里面使用的文件传输/共享协议有：afp, ftp, http, sftp, rsync, nfs, smb。大部分协议传大文件都可以不费力气的打满带宽，唯一要提一下的就是这个 smb 协议。smb 也就是平常在 windows 里面共享文件夹用的那个协议，很诡异的一点是这个协议传文件即使是两台 windows 之间也常常打不满带宽，而 Mac 下面性能尤其低，至于为什么会这样，我也不知道（请高人指点）。另外一点是如果传输大量小文件，有很多额外数据要浪费带宽，rsync 协议在这一点上稍强，但是比较通用的提速办法是在源机器把文件打包传输到目标机器再解包。
• 机器性能：通常来说，主频 500 MHz 以下的机器做路由器，或者主频 1 GHz 以下的机器用有加密/压缩的协议（比如 sftp）传文件，其本身都有可能成为性能瓶颈。即便是 Linksys，早期有些号称百兆以太网的路由器其实根本达不到 100 Mbps 交换数据，被骗的人不在少数。另外硬盘的写入性能如果达不到网络带宽，测试网络性能可以只传文件而不写磁盘，比如 wget 加 -O /dev/null，千兆以太网传文件的速度瓶颈就有可能在硬盘写入速度。
• 程序设置：通常来说程序的参数设置只要不太离谱都不会影响传文件的速度，但是也有例外。比如，Mac 下面的 dd 命令从 smb mount 的目录拖文件，如果使用默认 bs 大小速度非常之慢。另外，sftp 协议用不同的软件差别很大，但是我忘记我以前的测试结果了，所以等我有空再补上来……
• 网况：（这个词不知道谁发明的，貌似是从“路况”一次发展出来的）在局域网内一般网络结构比较容易控制，打满带宽并不是难事；但是到了大因特网上网络传输速度基本上就不由你控制了，这个问题就不在这里讨论了。

C. 关于无线网

无线网 Wi-Fi 技术日新月异，以下是三种常见的规格：

• 802.11b：频段 2.4 GHz，连接速度最高 11 Mbps，吞吐率极限大概在 0.5 MiB/s 左右。
• 802.11g：频段 2.4 GHz，连接速度最高 54 Mbps，吞吐率能达到 2.4 MiB/s。
• 802.11n：频段可选 2.4 GHz 或者 5 GHz，连接速度最快似乎可以到 300 Mbps，吞吐率极限据说高于 12 MiB/s。

不要被无线网的连接速度所迷惑，用目前最常见的 802.11g 传文件实际上只能到 2.4 MiB/s 的样子，而且现在市面上的低端 802.11g 无线路由器往往不能稳定保持这个速度。有一种 802.11g+ 技术可以把 802.11g 的性能翻倍，但是通用性不强，所以使用的地方并不多。

事实上，在 802.11b 之前还有过一个 802.11a，频段是 5 GHz，性能和 802.11g 差不多，可是因为频段选的不好，并没有流行起来。

802.11n 是目前最新的 Wi-Fi 技术，协议还没有最终定稿，但是市面上用协议草案制作的 802.11n 路由器已经不少了。也正因为协议没有最终定稿，不同公司生产的无线基站和无线网卡配合工作往往达不到最高性能。从目前的情况看，802.11n 网络连接至少可以到 130 Mbps 的连接速度，传文件可以达到 5 MiB/s 以上，所以即便是最差情况，802.11n 也已经可以超过 802.11g 的性能。（比如，苹果的 Airport Extreme 如果要兼容 802.11g 就必须工作在 2.4 GHz 频段，这样即使和自家苹果电脑的 802.11n 网卡互联，也只能达到 130 Mbps 的速度；而如果换用 5 GHz 频段，连接速度就是 300 Mbps，传文件可以保持 10 MiB/s 以上。）

无线网的性能会受到很多东西的影响，比方，信号穿的墙厚不厚、什么材料的，周围有没有同频率的干扰信号。2.4 GHz 这个频段很热门（主要是因为这个频段在大多数国家不需要许可证就可以发射），无绳电话、卫星信号、蓝牙、甚至微波炉都是这个频段，所以一般的建议是无线基站要尽量远离别的电子设备。

D. 关于 DSL 等

一般家用安装的 DSL 或者什么宽带专线的带宽数字都是虚的，只有问同类用户才能估计实际的性能。米国最近出了一个规定，至少 768 kbps 才能号称 broadband。记得以前一个小旅馆几十间房共用一个 128 kbps 的出口也好意思对外号称他们有 high speed internet access。

E. 结语

我真唐僧。

换夏令时啦！丢了一个小时。每年都要调两次时间，每次调时间，都会出点事。

（标题引自 chen3feng 留言）最早认识到夏令时的邪恶是多年前改夏令时那天我刚好赶早班飞机，人还在外地完全没想起来要调时间，幸好我临睡前突然想起来，需要再提早一个小时出发，后来到机场的时候只剩 20 分钟就起飞了，真是后怕……

早期不知道是 samba 还是 windows 有问题，总之调时间以后两边看共享目录的时间会差一小时。有一次我几 TB 的数据被自动重新同步了一次，真衰。

有人在 crontab 里放了两点半执行的命令，结果调夏令时那天事务流程完全乱掉…… crontab man page 专门在 BUGS 一节指出：

If you are in one of the 70-odd countries that observe Daylight Savings Time, jobs scheduled during the rollback or advance will be affected. In general, it is not a good idea to schedule jobs during this period.

因为有了一些教训，有同事写程序开始用 UTC 时间，这样就不会受到本地时间调整的影响。去年不知道哪个土鳖提出来把调夏令时的日子提前一个月，各类操作系统都需要更新过才能正确调整夏令时。有位同学没更新操作系统，看时间不对就直接把电脑时钟拨快了一个小时，结果反而那些先进的用 UTC 时间的程序出错了（因为没有调整时区，所以电脑的 UTC 时间就错了）……

sigh，到底是用本地时间，还是 UTC 时间写程序？

为什么要执行夏令时？？不是说夏令时不省能源反而费吗？？？

某人 Windows 下一个硬 Raid5 不太稳定，怀疑芯片快挂了，于是打算把数据全部转移到另一个硬盘上。这个 Raid5 上有几百 G 数据，几万个小目录，几千万个文件，由于这个机器常常挂掉，直接复制是行不通的，于是他用了一些同步软件。同步文件不是一件复杂的事情，软件也多如牛毛，据说该哥们试用了 Karen’s Replicator、SyncToy、Allway Sync，还让老板买了一些别的软件，可是居然没有一个软件完成任务。不是容错能力差受不了硬盘文件错误，就是由于文件数量太大索性直接挂掉。于是一遍一遍重试，搞了四天连一半文件都没搞定，实在受不了了，问我怎么办……

于是我出了我以前出过的一个大法，把 src 和 dst 目录都 smbmount 到一个 linux 机器上，在 linux 机器上 rsync src dst。奇迹发生了，rsync 了一个晚上数据就全过去了。这个问题自然不一定要用这么诡异的方法解决，我只是很奇怪为啥这么多 Windows 下的软件都会不及一个外来妹 rsync……

今天某人一个 avi 死活放不了，我后来建议她试一试 VLC，居然就能放。 晕啊，难道我们进入共产主义了，要钱的软件做不过免费/开源的软件了……

rsyncrypto is basically rsync plus encryption. It’s not feature-complete I guess, but it works for me. Ubuntu source has binary package but compiling isn’t hard at all. Alright, so obviously man page has most of what you need, here I’ll write simple outlines.

Suppose your data source folder is ~/src, sync destination is ~/dst (this could be a mounted nfs or smb share), and rsyncrypto working directory is ~/rr.

A. Encryption

First of all, create backup keys:

openssl req -nodes -newkey rsa:1536 -x509 \
  -keyout ~/rr/backup.key -out ~/rr/backup.crt

Then the actual sync command is:

rsyncrypto --ne-nesting=2 --trim=3 -n ~/rr/map \
  -cvr ~/src/ ~/dst/ ~/rr/keys ~/rr/backup.crt

This command will encrypt filename and folder structure. So obviously folder modification time will not be preserved, and empty folder will be lost. Parameter --trim depends on your folder location. --ne-nesting depends on the number of files you will have in the future. In general, you may want less than 1024 files per folder, so you need 1024*16^n > total number of files, --ne-nesting=2 is enough for 200,000 files. After this encrypted sync, and suppose you lose everything except files in the ~/dst/, then you’ll need backup.key to cold decrypt all files. So be sure to keep backup.key at another place, preferably at another physical location. You can put the above command into crontab if -v is removed. Also, syncing files without ownership might result in errors, and it may be hard to debug because rsyncrypto does not have very friendly error messages - in which case you may try to fix the file permission problem, or you may run the command by root.

If you want a parameter similar to --delete in rsync, the corresponding parameter in rsyncrypto is --delete-keys. The parameter --delete alone in rsyncrypto does not remove filename mapping in ~/rr/map.

B. Decryption

Suppose you want to cold decrypt to folder ~/rec/. First you need to decrypt filename mapping:

rsyncrypto -d ~/dst/filemap ~/rec/filemap \
  ~/rec/filemap-keys ~/rr/backup.key

The above command generates ~/rec/filemap, so then you can decrypt all files:

rsyncrypto --trim=3 -n ~/rec/filemap \
  -vrd ~/dst ~/rec/files ~/rec/keys ~/rr/backup.key

C. Windows sharing time precision

When you sync to or from windows sharing, you need a parameter similar to --modify-window=2 in rsync, but unfortunately rsyncrypto doesn’t have it. You can change source code in file.cpp, search for st_mtime, and change

dststat.st_mtime!=status.st_mtime

to

abs(dststat.st_mtime-status.st_mtime)>2

There’s another similar line you need to change in the same file.

Google 年初出了一篇论文，Failure Trends in a Large Disk Drive Population，讲了硬盘故障的趋势和各类因素对之的影响。相信大家或多或少都听说过周围的人硬盘破掉哭天哭地的事情，甚至可能发生在自己身上。我前几天算了一下，我自己在过去的七年里用过大概 20 个硬盘，其中挂掉了三个硬盘。不知道是个人感觉还是确有其事，硬盘的平均寿命可能确实已经不如二十世纪了。

硬盘挂掉到底是个什么样的概率呢？按照现在一般厂家宣传的来看，我们就假设硬盘的平均寿命是 3 年。这个硬盘挂掉就跟重原子衰变一个规律，是指数规律，也就是说，时间 t 之后硬盘还没有挂掉的概率是 exp(-t/T)，这里 T = 3 年。我们常常听人说，做事情要万无一失，这个意思是说出错的概率要小于 0.01%，现在我们宽容一点，硬盘数据也不是人命关天的事情，我们就说出错的概率小于 1% 就够满足了，那么这样的情况 t 是多少呢？t = -T * ln(0.99) = 11 天。也就是说，硬盘用了超过 11 天，就有大于 1% 的概率挂掉了。从这个计算我们可以看到，用硬盘指望硬盘不挂掉其实是很拼人品的。

有人说，既然硬盘会挂掉，那么我就建一个 raid 硬盘阵列就可以了，备份还是没什么必要的。raid1 可能是最常用的，高级一点可以用 raid5。自然，这是最基本的一个做法，即使一个硬盘挂掉也可以很快恢复数据。不过在硬盘物理层上还有文件系统，文件系统挂掉并不少见，而这种情况下 raid 的冗余数据是完全帮不上忙的。土人我亲眼见过 raid1 上 ntfs 文件系统崩溃，也见过 raid5 上 ext3 文件系统崩溃，从此大彻大悟再也不相信有了 raid 冗余模式就可以高枕无忧的屁话。

另外，在没有版本管理系统的情况下，有的时候写东西写错或者误操作往往会希望看看昨天这个文件是什么样子，这又是需要备份了。好了废话这么多，总之备份是放之四海而皆准的解决方案。如何备份？很多人不备份的原因就是太麻烦，首先，人最在乎的数据往往是每天都在变化的；其次，备份往往需要人去参与，比如刻盘；还有，如果没有好的软件，备份大量文件必然要耗费大量的机器时间。如果每天备份都要这么大张旗鼓，自然没人愿意备份了，所以实用的日常备份必定是自动进行的，而且需要程序快速准确判断出原始数据和备份的差异，只复制有差异的部分。

有了自动备份，那么多长时间备份一次？这个完全看具体情况。比如与盈利挂钩的办公环境，每天备份数据的要求并不过分。另外，备几份？有人说要多备几份，每次备份删除一份最早的；也有人备三份不同频率的，分别是每天、每周、每月备份。我这里只是把看到的罗列一下供参考。一般的数据备一份足够。

然后一点是，往哪里备份？一般来说往另一个硬盘备份就可以了，可以是自己这个机器，也可以是另一个机器通过网络备份。不过会不会备份和原始数据同时挂掉呢？有可能的，比方，火灾，或者雷电袭击了输电系统。如果有这种顾虑，一般推荐是进行异地备份，通过网络或者别的手段把数据同步到另一个物理位置的机器上。很多年前 Stanford 发生过一起火灾，把 Career Development Center 一个楼全烧没了，所有的学生求职数据库连同备份都烧没了。很认真地说一句，如果有特别重要的数据，应该考虑异地备份，最简单的方法可以是，每年刻一些盘放到别的地方去，也花不了多少时间。

废话了很多，貌似没有涉及备份的具体技术问题，留着且听下回分解吧。

ps，其实硬盘挂掉不是按指数规律来的，Google 那篇论文也提到这点，前面那个计算其实是忽悠人的…… 不过 11 天这个结果的数量级还是正确的。

English Translation: A quick summary

• to get root privilege: compile acp_commander.java and run

  java -jar acp_commander.jar -o -t TeraStation_ip

  You may need to temporarily disable firewall on the machine that executes this command. You can then telnet in with empty root password, and set a password. Start sshd to have secure connection. Because it’s so easy to hack TeraStation, I think it can only be used in trustworthy local network.

• Every time you restart TeraStation, you have to use acp_commander to start sshd, but root password is preserved.
• To have special characters in the windows sharing password, just run passwd and smbpasswd under shell.
• TeraStation supports rsync but rsync is only intended to be used between TeraStations. You could change /etc/rsyncd.conf to configure rsyncd server. Also, you can setup crontab job to rsync from TeraStation main disk to a USB disk plugged into TeraStation. This is obviously the best local backup method.

小日本作了一堆 TeraStation 文件服务器（民间 wiki，民间论坛），卖得还不错。这玩意没什么特别的高科技成分，嵌入式 linux，加一堆软 raid。唯一比较赞的是机箱工艺比较好，体积也比较小。对于一般的应用，默认启动起来的 TeraStation 已经足够能用，但是没有 root 权限总是一件很不愉快的事情。下面简略记一下我对我们买的 TeraStation Pro II 的一些 hack。

默认的 TeraStation 对外只开了 web 管理界面和 smb 文件共享。但是它留了一个洞，可能是为了升级 firmware 方便。有人琢磨出来利用这个洞获得 root 权限，google acp_commander 就可以找到详细说明。acp_commander.java 源代码在 这里 备份一下。acp_commander 可以给 TeraStation 发送命令。执行

java -jar acp_commander.jar -o -t TeraStation_ip

清空 root 密码并启动 telnetd，然后 telnet 进去使用空密码登录 root 并设置密码。然后启动 sshd 就可以登录 ssh shell 了。一个要注意的问题是 acp_commander 需要接收 UDP 包，所以执行命令的这台机器需要临时关掉防火墙。

TeraStation 每次重启动会 reset 一些设置，所以需要重新用 acp_commander 来启动 sshd。注意 root 密码是不会被 reset 的，所以以后每次只要启动 sshd 即可，不需要清空 root 密码，也不需要再启动 telnetd 了。当然最彻底的方法是换掉 TeraStation 的 firmware，人民群众也已经创造了稳定的内核。不过我比较懒，所以还是用老的 firmware，反正我需要的功能都已经有了。另外，因为这个默认的 TeraStation fireware 这么容易被黑掉，所以建议只在可信赖的内网使用小日本的这个玩意儿。

TeraStation 的 web 界面相当的土鳖，不支持含有特殊字符的密码。大概看了一下貌似是因为 cgi 程序懒得处理这些特殊字符所以干脆禁止掉。当然，有了 shell 之后只要在 shell 下执行 passwd 和 smbpasswd 修改即可。ps 发现脚本到处都有日文注释，看来小日本写程序和有些中国人一样，也喜欢用母语注释。

TeraStation 本身支持 rsync 协议但是只是为了 TeraStation 之间备份用。有了 shell 之后可以修改 /etc/rsyncd.conf 来配置 rsync 服务器。当然也可以用 rsync over ssh，但是 TeraStation 的处理器不够强劲，高速解码 ssl 还是会影响一些性能。另外，从 raid 主盘往接在 TeraStation 上的 USB 盘备份可以在 crontab 设置 rsync，这应该是本地备份 TeraStation 最高效的方法。