了解為什麼網路傳輸會出現這種差異？
概括：
我無法理解網路傳輸中的特殊差異。
- 為什麼在從一台機器同步到另一台機器時會出現如此差異，反之亦然？
還：
- 鑑於最大網路傳輸速度約為 110 M/秒，類似操作的本地磁碟速度約為 200 M/秒（因此，沒有瓶頸），為什麼兩台機器之間的 rsyncing 速度比理論100M/秒？
細節：
首先，伺服器是
# uname -a FreeBSD das 10.1-RELEASE-p8 FreeBSD 10.1-RELEASE-p8 #25 d0fb866(releng/10.1): Thu Nov 13 07:57:26 EST 2014 root@bellicose:/usr/obj/root/pcbsd-build-10-STABLE/git/freebsd/ sys/GENERIC amd64客戶是：
# uname -a Darwin compute.internal 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64兩台機器都有 16GB 的記憶體。
通過在伺服器上執行本地 rsync，至少在這種情況下，一種知道磁碟速度的期望值是多少。
使用二進製文件 test.bin，732M，FreeBSD 伺服器上的本地 rsync 顯示大約 200 M/秒：
# rsync --stats -h test.bin copy.bin [....] sent 732.54M bytes received 35 bytes 209.30M bytes/sec total size is 732.36M speedup is 1.00也就是大約 200 M/秒。
在 mac mini 客戶端上，我幾乎有 70M/秒：
# rsync --progress --stats -h test.bin copy.bin test.bin 732.36M 100% 70.06MB/s 0:00:09 (xfr#1, to-chk=0/1) [....] sent 732.54M bytes received 35 bytes 69.77M bytes/sec total size is 732.36M speedup is 1.00現在，使用以下命令進行網路速度測試
iperf：在伺服器（FreeBSD 伺服器）上：
# iperf -f M -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 0.06 MByte (default) ------------------------------------------------------------ [ 4] local 192.168.1.5 port 5001 connected with 192.168.1.226 port 50757 [ ID] Interval Transfer Bandwidth [ 4] 0.0-30.0 sec 3356 MBytes 112 MBytes/sec在客戶端（OS X mac mini）上：
# iperf -f M -M 9000 -c 192.168.1.5 -t 30 -w 80K WARNING: attempt to set TCP maxmimum segment size to 9000 failed. Setting the MSS may not be implemented on this OS. ------------------------------------------------------------ Client connecting to 192.168.1.5, TCP port 5001 TCP window size: 0.08 MByte (WARNING: requested 0.08 MByte) ------------------------------------------------------------ [ 4] local 192.168.1.226 port 50757 connected with 192.168.1.5 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-30.0 sec 3356 MBytes 112 MBytes/sec因此，我可以假設網路連接（兩個網卡之間的直 7 類電纜）約為 110 M/秒。
現在，這是一個令人費解的情況：
如果我從 FreeBSD 伺服器 rsync 到 mac mini，我會得到大約 50 M/sec 的傳輸速度：
# rsync --progress --stats -h test.bin -e "ssh -l gsl" '192.168.1.226:/tmp/' Password: test.bin 732.36M 100% 57.10MB/s 0:00:12 (xfr#1, to-chk=0/1) [....] sent 732.45M bytes received 46 bytes 50.51M bytes/sec total size is 732.36M speedup is 1.00但是相反方向的 rsync 提供了低得多的傳輸速率，20M/秒：
# rsync --progress --stats -h test.bin -e "ssh -l gsl" '192.168.1.6:/tmp/' test.bin 732.36M 100% 19.55MB/s 0:00:35 (xfr#1, to-chk=0/1) [....] sent 732.54M bytes received 35 bytes 20.07M bytes/sec total size is 732.36M speedup is 1.00我的兩個問題：
- 為什麼在從一台機器同步到另一台機器時會出現如此差異，反之亦然？
還：
- 鑑於最大網路傳輸速度約為 110 M/秒，類似操作的本地磁碟速度約為 200 M/秒（因此，沒有瓶頸），為什麼兩台機器之間的 rsyncing 速度比理論100M/秒？
有人可以幫助理解這一點，或許就如何提高傳輸速度提供一些建議？
更新：根據@dhag 的回答，我嘗試使用 複製文件
netcat，即不使用壓縮：在“伺服器”（推送）端：
time cat test.bin | nc -l 2020 nc -l 2020 0.25s user 6.29s system 77% cpu 8.462 total在接收端（FreeBSD）：
time nc 192.168.1.226 2020 > test.bin nc 192.168.1.226 2020 > test.bin 0.09s user 4.00s system 62% cpu 6.560 total如果我沒記錯的話，這應該意味著 732M/6.29s = 117M/sec，這超出了
iperf統計數據。也許是記憶體問題？更新 2：使用 rsync 完全不加密（只有在使用守護程序和 rsync:// 協議時才有可能）：
# rsync --progress --stats -h test.bin rsync://gsl@192.168.1.5/share ⏎ test.bin 732.36M 100% 112.23MB/s 0:00:06 (xfer#1, to-check=0/1) [....] sent 732.45M bytes received 38 bytes 112.69M bytes/sec total size is 732.36M speedup is 1.00這也證實了@dhag 的想法。
我只能提供一個猜測，即差異是通過兩台主機的不同計算、記憶體、記憶體或磁碟特性來解釋的：
如果我們假設 CPU 是一個瓶頸，那麼如果較慢的機器在發送時較慢（這假設加密比解密的計算量更大）是有道理的。這可以通過切換到計算量較小的密碼來測試（嘗試添加
-c arcfour到您的 SSH 命令行；在這種情況下，傳遞--rsh="ssh -c arcfour"給rsync）。如果我們假設文件是直接從磁碟讀/寫到磁碟的，那麼磁碟可能會成為瓶頸；更現代的電腦可以達到 100 MBps 的讀取速度，但較舊的電腦或在筆記型電腦級驅動器上執行的電腦（例如，我相信 Mac Mini）無法實現。
如果我們進一步假設作業系統使用文件系統記憶體，情況可能會更加複雜：
- 如果源文件包含在文件系統記憶體中，在 RAM 中，那麼它的讀取速度可以比 100 MBps 快得多；
- 如果目標系統應用了寫入記憶體並且能夠將文件的很大一部分放入 RAM（在您的情況下應該如此，因為 RAM 比您的測試文件大得多），那麼它可以聲稱寫入在它之前完成實際上已經到達磁碟（這可能意味著您測量的 200MBps 是）。
磁碟與記憶體未知可以通過在讀取之前刷新文件系統記憶體來測試（如何做到這一點取決於作業系統）：然後發送文件將至少與磁碟指示的一樣慢。相反，通過在發送之前完全讀取文件（可能使用
cat file.bin >/dev/null），可以影響作業系統記憶體它。為了進一步調查 CPU 是否是一個問題，在傳輸過程中執行是有意義
top的；如果rsyncorssh程序佔用了 100% 的核心，那麼這將是一個瓶頸。