當談到Rsync時候，我們將使用一些術語來指代rsync工具在完成其任務的不同階段 下的各個角色或者進程。下面為一些后文將會用到的術語：
client/客戶端 role/角色
客戶端對同步過程進行初始化。
server/服務器端
role/角色 服務器是指遠端的rsync進程或者客戶端通過遠端shell、socket所連接到的系統。
服務器(server)是一個通用的術語，注意不要將其與Deamon混為一談。
一旦從Client到Server的鏈接建立起來，Client（客戶 端）/Server（服務 器）的這兩個角色的差別，就被Sender（發送者）/Receiver（接收者）所 取代了。
daemon/守護進程
同時也是進程 Daemon是一個rsync進程，該進程用於等待接收從Client發起的連接。在一 些平台上，Daemon也被叫做服務（Service）
remoteshell/遠端shell 角色
同時也是一系列的進程 一個或多個進程，用於向client和遠端的server之間提供連通性。
sender/發送者 role and process 可以存取待同步的文件資源的rsync進程。
receiver/接收者 role and process 作為角色：指同步過程中的目標系統；作為進程：指目標系統中，用於接收數據並接數據寫入磁盤的進程。
generator/生產者 process/進程
生產者進程用於識別文件的變化，並維持文件級別的邏輯。
當Rsync通過一個遠端SHELL和一個沒有啟動守護程序的服務器通訊的時候,
Rsync所使用的啟動方法是在遠端系統上派生一個遠端SHELL,然后使用這個遠端SHELL啟動一個Rsync進程.
Rsync的客戶機和服務器通過遠端SHELL的管道進行通訊.在這種模式下, Rsync服務器選項被傳送給命令行,
用於啟動遠端SHELL.
當Rsync和一個守護程序通訊的時候, 它直接和網絡插口通訊. 這是唯一一種可以被稱為涉及網絡的的Rsync通訊. 在這種模式下, Rsync的選項必須發送到網絡插口上. 下面是具體的描述.
開始通信：
客戶機和服務器最開始通訊的時候, 他們各自發送自己所支持的最高的協議版本號給對方. 兩邊會使用其中的小的版本作為用來傳輸的協議版本.
如果是一個守護模式連接,Rsync的參數會被從客戶機發送給服務器. 然后, 排出列表會被傳送. 然后,客戶機服務器的關系就只和錯誤和日志發送有關了.
本地的Rsync任務(原地址和目標地址都是本地掛載的文件系統)就像一個推送.客戶機：作為發送端, 派生一個服務器進程去行使服務器的功能. 客戶機/發送端和服務器/接收端通過管道相互通訊.
文件列表：
文件列表不僅包括路徑名,也包括所有者,模式, 讀寫權限, 大小和修改時間. 如果設置了--checksum選項, 文件列表還要包括文件的校驗值.
Rsync啟動完成后的第一件事, 發送端會建立文件列表. 在建立過程中, 每個條目都會通過一種優化的網絡傳送方式發送給接收方.
傳輸結束后, 兩側會以目錄對基礎目錄的相關性來編排順序. (具體的算法會和每次傳輸實用的協議版本有關). 一旦排序開始, 所以關於文件的指向都是使用他們在文件列表中的目錄順序.
如果必要, 發送者遵從文件列表中用戶和組的id->name對應表 接收者會使用它來為文件列表中的每個文件作id->name->id翻譯.
接收端收到完全的文件列表, 會派生出一個生成器, 和接收端一起建立一個完整的管道.
管道 Rsync嚴重依賴於管道. 這意味着一組進程間的的單向通訊. 一旦文件列表被共享, 管道就表現為如下的形式, 生成器->發送端->接收端
生成器的輸出是發送端的輸入, 發送端的輸出是接收端的輸入. 每個進程獨立的運行, 只有在管道延遲,或者等待硬盤讀寫或CPU資源的時候才會有延遲.
生成器 生成器比較文件列表和本地目錄樹. 如果設置了--delete參數, 在開始它的主要工作前, 它首先會甄別在本地存在而在發送端上不存在的文件, 然后在接收端刪除它們.
接下來生成器會開始遍歷文件列表. 每個文件都被檢查, 以確定是否需要同步. 大多數情況下如果修改時間和大小不同, 文件需要同步. 如果設置了--checksum, 文件校驗會被計算並比較. 目錄, 設備文件和鏈結不會被跳過. 缺失的目錄會被創建.
如果一個文件需要同步, 在接收端的任何版本的該文件都會被作為一個傳輸的"基礎文件"."基礎文件"作為一個數據源,兩側比較下來一致的數據就不需要被傳輸了. 為了更有效的在遠端匹配數據, 基礎文件的塊校驗被計算, 並和文件的目錄號一起送給發送端.如果設置了--whole-file, 空的塊校驗值用於新文件.塊大小, 以及在后期的版本中塊校驗的大小, 是基於每個文件的大小計算的.發送端
發送端進程一次從生成器讀一組文件號和相關聯的塊校驗.
對每一個生成器發送的文件號, 發送端會存儲塊校驗, 並建立一個哈希索引以快速檢索.接着本地文件會被讀取, 生成一個從文件的第一個字節開始的塊作的校驗. 這個校驗會和生成器發過來的校驗比較, 如果不相符, "不匹配"的字節會被加入到不匹配的數據中, 接着比較下一個字節的塊. 這被稱為"循環校驗"
如果一個塊的校驗匹配就會被認為是一個匹配的塊, 已經積累的不匹配塊會被發送給接收端, 一起發送的還有塊的偏移量和在接受端文件中的匹配塊的長度. 塊校驗生成器會提前去檢查匹配字節后面的一個字節.
即使塊的順序或者偏移量不同,以這種方法匹配的塊也能夠被確認. 這個程序是Rsync最核心的算法.通過這種方式, 發送者告訴接收端如何重組源文件成為一個目標文件. 這些指令包括所有的可以從基礎文件拷貝的數據(如果存在的話), 和任何本地沒有的新的數據, 的細節. 在處理末尾, 一個全文件的校驗會被發送, 然后發送端去處理下一個文件.
生成循環校驗以及在校驗中找到匹配的數據, 對CPU的能力有很大的需求. 在所有的Rsync進程中,發送端是最消耗CPU資源的.
接收端 接收端會從發送端的數據中讀取由文件索引號確認的文件. 然后打開本地文件(被稱為基礎文件), 建立一個臨時文件.
接收端會讀取非匹配數據和匹配數據, 並按順序重組他們成為最終文件. 當非匹配數據被讀取, 它會被寫入到臨時文件. 當收到一個塊匹配記錄, 接收端會尋找這個塊在基礎文件中的偏移量, 將這個塊拷貝到臨時文件. 通過這種方式, 臨時文件被從頭到尾建立起來.
建立臨時文件的時候生成了文件的校驗. 重建文件結束后, 這個校驗和來自發送端的校驗比較. 如果校驗不符, 臨時文件會被刪除. 如果失敗一次, 文件會再被處理一次. 如果失敗第二次, 一個錯誤會被報告.
臨時文件建立后, 所有者, 權限和修改時間會被設置. 然后它會被重命名已替代基礎文件.
從基礎文件拷貝數據到臨時文件,使接收端成為所有進程中對硬盤要求最高的一個. 小文件還有可能在緩存中, 可以減輕對硬盤的壓力; 但是對於大文件,在生成器去處理下一個文件的時候,或者還有由發送端造成的時延, 緩存中已經無法容納更多的數據,只能清除掉舊的. 另外,數據是隨機的從一個文件中讀取, 並被寫入另外一個, 如果讀寫的數據超過了硬盤緩存空間, 一個所謂的"尋找風暴"有可能發生,會進一步的損害性能.
守護程序 守護程序, 向所有的其他守護進程一樣, 為每一個連接派生子進程. 啟動的時候, 它解釋rsyncd.conf, 以確認存在的模塊, 並設置一些全局變量.
當接收到一個對已經定義的模塊的連接時, 守護進程派生一個子進程去處理這個連接. 這個子進程然后去讀取rsyncd.conf,
為被請求的模塊設置變量, 這個工作有可能改變模塊的root路徑, 或者拋棄已設定的用戶號和組號. 然后, 它就像其他的Rsync服務進程一樣,
或者作為發送端, 或者作為接收端.
Rsync協議 一個良好定義的通訊協議有以下幾個特性,-所有的數據都在良好定義的包中發送, 包括包頭, 可選的包體, 或者數據凈荷.
-每個包頭中, 明確的指定數據類型或者命令.
-每個包都有一個確定的長度.
除了這些特性以外, 協議還應支持不同等級的狀態, 包與包間的獨立性, 人類可讀性, 和重建一個斷掉連接的能力.
Rsyncs協議不具備任何以上一點優秀特性. 數據作為不間斷的字節流被傳輸.不匹配的文件數據是一個特例,沒有包長度, 沒有計數器. 每個字節的意義都是根據協議等級決定的, 都是獨立的.
例如, 發送端要發送一個文件列表, 它就是簡單的發送文件列表中的每一條, 發送結束就是一個NULL字節. 在文件列表的每一條中,有一個比特表示數據的結構, 這些變長的字符串只是被NULL字節簡單的終結. 發送端發送文件索引號和塊校驗對的時候, 工作方式是一樣的.
在可靠的連接上, 這種方法工作的很好, 它比正式的協議擁有較少的開銷. 但是很不幸, 它造成協議很難被文檔化, 調試, 或者擴展. 每個版本的協議在線路上表現的都不同, 除非知道確切的版本號才可以參與。
后記
文檔還在繼續被整理. 作者知道一定有一些明顯的疏忽, 對於有些讀者來說, 它更容易造成混亂, 而不是清晰. 希望它可以進化成一個有用的參考.歡迎提意見, 甚至重寫的建議.
Sync Algorithm: RSync vs. RDC
Note:
本文前半部分翻譯，原文可從rsync官方網站上得到，但是因為 時間原因，沒有翻譯完成，已翻譯的部分也存在詞不達意的現象，等以后有時間再修改吧。后半部分是轉載的網友的文章，原文地址為 這里
引用的文章:
http://bbs.chinaunix.NET/thread-2112273-1-1.html
http://andylin02.iteye.com/blog/1041752