rsync原理
上一篇blog里面提到了rsync，这里稍微提一下原理。
按照rsync官网上的资料（http://rsync.samba.org/），rsync同步过程大致可以分为两步，一是建立连接，二是同步数据。
一、建立连接
有两种方式，一种是daemon，另一种是server。前者在server端开启守护进程等待client端主动发送连接请求；后者由client端在server端所在的服务器上开启服务进程（通过shell生成服务进程）。
二、同步数据
用edraw画了个图，感觉还算解释得比较清楚。
Receiver是数据同步的目标方，Sender是数据同步的发出方。Receiver和Sender的身份与client和server的身份没有关系。
block checksum使用了某种strong hash算法获得。rolling checksum使用了weak hash算法。
Tags: rsync
December 23rd, 2009 at 21:37
-c, –checksum
This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a “quick check” that (by default) checks if each file’s size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly.
The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender’s file: files with either a changed size or a changed checksum are selected for transfer.
Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer “Does this file need to be updated?” check.
For protocol 30 and beyond (first supported in 3.0.0), the checksum used is MD5. For older protocols, the checksum used is MD4.