华 南，朱彦霞

(1.河南中广智媒科技有限公司，河南 郑州 450000；2.中国广电河南网络有限公司；3.河南省职工医院；4.河南省郑州工人疗养院)

0 引言

随着云计算、物联网和大数据技术的发展，海量数据的传输和存储成为了一个亟待解决的问题。对于小文件的传输，由于其“个体小、总量多”[1]的特点，给数据传输带来了很大的困难，同时也带来了存储空间浪费、经济损失[2]等问题。

目前，已经有多种小文件传输优化方案（如基于云计算[3-4]、并行计算[5-6]、多线程和UDP 协议[7-8]等)，但是仍然存在依赖云计算服务，依赖硬件和网络设备以及数据丢失或重复传输等问题；Windows 操作系统中基于NTFS 分区格式的小文件传输方案表现良好，但仍面临使用负担较大、效率低、跨网络海量小文件同步等问题；基于Windows 操作系统的小文件传输方案Robocopy、Fastcopy、TeraCopy、Synctoy 等，支持多线程传输、断点续传等功能，然而相比Linux 平台，存在学习使用负担较大的问题、跨网络海量小文件同步、传输效率低、高性能产品收费成本高等问题；Windows操作系统中活动目录技术支持DFS 文件服务并提供强大的数据同步功能，但其依赖许多服务和配置才能使用，在技术上缺乏灵活性。此外，通过RPC 映射目录的同步方法可以通过优化拷贝方式进行同步[9]，但由于底层协议的原因，当传输海量文件时，整体性能会下降，特别是当传输中断时，进行数据对比将耗费更多时间。

因此，海量小文件同步传输及性能优化问题是个技术难点，也是当今云计算技术研究的一个热点。为了解决这个问题，需要设计出更高效、可靠、安全的同步传输方案，并通过优化算法和技术手段来提高同步效率和速度，降低成本，从而更好地满足人们日益增长的数据传输需求。

1 算法设计

在标准的Windows 操作系统中，进行两个终端之间的文件传输（例如，从PC1 到PC2 传输1000 个文件）如图1所示。标准的Windows操作系统会对每个文件执行一次完整的磁盘和网络传输流程，无论文件大小如何，这导致在传输大量文件时速度非常慢。此外，网络传输时协议的握手次数并没有减少，也会导致传输速度下降。

在不考虑LOFS（Loss of Service Faults）的情况下，传输速率（R）与拥塞窗口和数据包往返时间之间存在一定的关系。具体来说，传输速率与拥塞窗口和数据包往返时间的乘积成正比，即：

R=y/RTT

其中，y 表示当前拥塞窗口的大小，即网络中可以发送的数据包数量，RTT 表示数据包往返时间，即从发送端发送一个数据包到接收端并收到确认的时间。上述关系式表明，当拥塞窗口y 增加或数据包往返时间RTT减小时，传输速率R也会相应增加，反之亦然。这是因为当拥塞窗口y 增加时，网络中可以发送的数据包数量也会增加，传输效率提高；而当数据包往返时间RTT 减小时，数据包能够更快地在发送端和接收端之间传输，从而也提高了传输效率。

在考虑LOSF 传输情况下，在慢启动阶段，拥塞窗口大小的计算公式为：

y=min(W,CWND)

其中，y 表示当前拥塞窗口的大小，W 表示拥塞窗口的上限，CWND 表示当前的拥塞窗口大小。在慢启动阶段，CWND 的初始值为1，每经过一个往返时间RTT，CWND 的值就会加倍，即CWND=CWND*2。因此，可以将拥塞窗口y的计算公式表示为：

y=min(W,2^n)

其中，n 表示当前慢启动阶段经过的往返时间RTT 的个数，W表示拥塞窗口的上限。

在考虑LOSF传输情况下，传输速率为：

R=(MFS/RTT)*sqrt(2/p)

其中，R 表示传输速率，MFS 表示文件集的平均大小，RTT 表示往返时间，p 表示丢包率。这个表达式中，sqrt(2/p)表示LOFS 因子，描述了网络中丢包率对传输速率的影响。在不考虑丢包的情况下，传输速率与文件大小呈现正相关性，即随着文件大小增加，传输速率会相应增加；如果传输文件数量过多，会产生多个RTT 浪费，文件过小，网络带宽不能充分利用，对吞吐量产生影响、效率低下。

虽然有一些第三方免费和收费软件可在一定程度上提升大量小文件传输效率，例如从Linux 上移植的Rsync，但由于这些软件是基于Linux 开发的，对于中文和Windows 平台特殊的NTFS 存储技术兼容性较差。当同步的文件过大或文件数量过多时，也会出现兼容性问题。

对此，可以利用Windows 7 及其后续操作系统的特性，结合最新的设计思路来实现文件的高速同步。本文提出并构建了一种高效的Windows 文件同步算法fastNTsync，该算法基于以下三种技术优势：

⑴NTFS分区表快照技术

该技术能够在不中断文件系统的情况下对NTFS分区表完成快照，从而提高同步的效率。快照可用于记录分区表的状态，以便在同步期间快速检测和比较分区表的变化。

⑵NTFS $MFT分析技术

该技术可分析NTFS文件系统的主文件表（$MFT），以便快速获取文件信息。这有助于减少网络传输量和提高同步效率。

⑶文件打包分区组合拷贝技术

该技术可将文件按照一定的规则打包成一个包，并在传输过程中对包进行组合拷贝。这有助于减少网络传输次数和提高同步效率。

本文提出的fastNTsync 算法融合了以上三种技术，可显著提高文件同步的效率和速度，同时解决了NTFS特殊性和中文兼容性问题。

2 fastNTsync算法实现及性能验证

2.1 开发运行环境

fastNTsync 算法以Microsoft 的.NET Core 5 为主要开发平台，使用C#语言开发，并使用LiteDB 数据库作为嵌入式数据库。模拟物理环境使用Oracle VM VirtualBox 开源虚拟机来仿真多机环境，网络采用NAT方式。虚拟机分别模拟一部分Linux/Windows环境，实验环境网络实际为10000M 以太网卡传输（网络配置如图2所示）。

图2 网络配置信息图

2.2 fastNTsync算法实现思路及伪代码

fastNTsync 算法采用公共的RSA 库和改进过的128 位hash 算法来提高数据传输的安全性和效率，同时应用第三方开源ZIP 库实现文件块的打包提高文件传输效率,在实际应用过程中还应考虑文件冲突、同步队列管理和异常处理等细节问题。

2.2.1 fastNTsync算法具体实现思路

具体实现思路如下：

⑴同步服务器端启动后，使用开源库获取发起端的NTFS索引和文件映射表$MFT数据，并将其拷贝到内存流中形成快照，以支持文件同步。

⑵解析NTFS 索引和$MFT 数据，获取需要同步的目录和文件树结构，包括文件名、字节长度、修改时间等信息，并将这些数据写入LiteDB 数据库，以支持快速的同步任务处理。

⑶开启HTTP 服务，允许同步客户端通过验证码和同步任务ID 来获取LiteDB 的快照库，以支持远程同步操作。

⑷允许同步客户端扫描设定的同步存储目录和文件结构，包括文件名、目录结构、文件CRC、字节长度、修改时间和校验128 位hash，并将这些索引数据存储到本地LiteDB数据库中，以便进行同步数据对比。

⑸通过比较客户端和服务端LiteDB 数据库中的索引数据，对需要同步的新增、修改和删除操作进行识别，并将这些操作转化为HTTP 请求，以支持远程同步操作。

⑹同步客户端通过HTTP 请求获取需要同步的文件内容，然后通过文件流的方式，将文件写入本地存储，以实现同步文件的传输。

⑺同步过程中可以使用正则表达式来排除不需要同步的文件类型，同时可以配置同步速度限制，以避免网络带宽资源被占满。

2.2.2 编码实现

fastNTsync算法伪代码如下：

2.2.3 算法核心过程

⑴利用NTFS分区表的特性和Hash码提升文件同步效率

Windows NTFS分区表身携带文件的长度和修改时间信息，通过计算Hash 码进行快速比对，避免了对文件内容的重复读取和计算Hash 码的过程，提高了文件同步的效率。

⑵小文件打包优化网络传输效率

在文件同步过程中，使用无压缩打包的方式优化网络传输效率。因为Windows 在网络之间传输小于512KB 甚至更低容量的小文件的效率并不高，使用无压缩打包的方法可以提高网络传输效率，从而提高同步效率。

⑶多线程传输提升文件同步效率

采用多线程传输技术提升网络并发效率。至少使用两个线程，同时处理多个文件的传输，从而减少传输时间，提高文件同步效率。

⑷利用NTFS索引及文件映射表特点提升文件同步效率

通过获取发起端NTFS的索引和文件映射表$MFT数据，以获取文件列表，减少I/O 请求，避免对文件系统的重复读取和计算，效率远远超过传统的文件递归检索效率。这样可加快文件同步速度，提高同步效率。

2.3 fastNTsync算法性能验证

算法性能验证过程如图3所示。

图3 算法验证过程

具体验证过程描述如下：

⑴ 通过fastNTsync 程序的函数-init_test 1，在PC1 的F 盘的目录f:svn estA 中创建6,546 个随机大小的.txt 的测试文件，硬盘使用传统的机械硬盘，总共约14GB 左右，最小的文件约1KB，最大的约300MB；其中，小于512KB 的文件有873 个。同时，在PC2 的E 盘中建立testA的空目录。

⑵在两台PC上配置fastNTsync.exe的配置信息，配置如下：

别名PC1IP:192.168.31.25

端口为7000，设定同步目录为：f: estB

别名PC2 IP:192.168.31.24

端口为7000，设定同步目录为：e: estB

⑶通过标准的Windows 命令，从PC1 电脑发起f:svn estA 到192.168.31.24e$（192.168.31.24 是PC2 的IP）进行文件拷贝，大文件与小文件在传输速率上差异性较为明显（如图4、图5 所示），系统估算平均用时为5分13秒。

图4 Windows自带Copy命令实现大文件传输速率示例图

图5 Windows自带Copy命令实现大量小文件传输速率示例图

由于小文件较多，网络传输实际速度大致在20Mbps～993Mbps左右徘徊。

⑷复制PC1 的testA 目录一份为testB，执行命令fastNTsync.exe -s PC1 -t PC2，开始同步；大文件与小文件传输速率基本无差异（如图6 所示），系统估算用时约1分17秒。

图6 fastNTsync.exe在覆盖模式下的速率

图7 Windows文件资源管理器传输在覆盖模式下的速率

通过对比可以看出，在相同环境及传输任务下，本文所提出的fastNTsync算法较传统Windows命令的执行效率优势更为突出。

第二次测试过程：PC1 的testA 文件并再次执行fastNTsync 程序的函数-init_test2，生成测试数据文件增加为7329 个，并且随机重写了PC1 的testA 目录下一些文件内容，最终test 目录大小为16.4 GB 左右。目前PC1和PC2大约有1000个以上的差异文件。

⑸进行第二次同步时，分别使用标准的Windows命令复制PC1 到PC2 的文件（直接覆盖）和改进后的fastNTsync.exe 程序进行同步。实验结果显示，使用Windows 命令复制文件的同步过程耗时6 分40 秒，而使用fastNTsync程序的同步过程仅耗时约58秒。

经过综合评测，fastNTsync算法采用NTFS快照技术高效地检索和比对两台待同步计算机的文件列表信息，从而仅同步需要更新的文件。此外，该算法对于小文件进行了打包和解包处理，减少了网络协议握手次数，提高了文件传输效率。

3 总结

随着数据量不断增加，海量小文件同步问题已成为一个重要问题。本文提出了一种基于fastNTsync算法的海量小文件同步优化算法，该算法充分融合了NTFS 分区表快照、NTFS $MFT 分析和文件打包分区组合拷贝等技术优势。通过优化同步过程中的数据传输、数据存储和数据管理等方面，该算法有效地提高了同步速度和效率，并实现了较高的同步质量。

实验结果表明，本文提出的fastNTsync 算法在处理大量小文件时具有显著的优势。相比现有同步算法，该算法可以更快地完成同步任务，同时也能够更加高效地利用存储空间。该算法的性能优势为海量小文件同步问题的解决提供了一种有效的解决方案，同时也为相关领域的研究和应用提供了有价值的参考。

虽然本文的fastNTsync算法能够有效解决海量小文件同步问题，但在实际应用中，仍需考虑不同环境下的应用效果、系统的稳定性和安全性等问题。未来的研究可以探究更加先进的同步算法，同时结合机器学习和人工智能等技术，进一步提高同步效率和准确性。