在 LAN 上以最大速度传输文件答案

【问题标题】：File Transfer with Maximum Speed on LAN在 LAN 上以最大速度传输文件
【发布时间】：2012-04-27 19:09:01
【问题描述】：

几乎所有的文件传输软件，如 [NetSupport, Radmin, PcAnyWhere..] 以及我在应用程序中使用的不同代码，当您发送大量小文件时，它会降低传输速度 就像 游戏文件夹 有很多文件。

例如在 LAN（以太网 CAT5 电缆）上，我发送一个文件，比如说视频，传输速率在 2MB 和 9MB 之间
但是当我发送一个包含大量文件的游戏文件夹时，传输速率约为 300kb-800kb

我猜这是因为发送文件的方式：

发送文件信息 [file_path,file_Size]。

发送文件字节[循环到文件末尾]。

结束传输[确保已完全接收]。

但是当您在网络上的共享文件夹上使用常规窗口[复制粘贴]时，发送文件夹的传输速度总是像发送单个文件一样快。
所以我尝试使用 [WCF service c# 4.0] 开发一个文件传输应用程序，该应用程序将使用 LAN 上可用的最大速度，我正在考虑这种方式：

Get all files from the folder.
if(FileSize<1 MB)
{
    Create additional thread to send;
    SendFile(FilePath);
}
else
{
    Wait for the large file to be sent. // fileSize>1MB
}

void SendFile(string path)  // a regular single file send.
{
    SendFileInfo;
    Open Socket and wait for server application to connect;
    SendFileBytes;
    Dispose;
}

但我对使用多个套接字进行文件传输感到困惑，因为这将使用更多端口和更多时间（侦听和接受延迟）。

那么这样做是个好主意吗？
需要一个关于是否可以做的解释，如何做，一个比 tcp 更好的协议，这意味着。
提前致谢。

【问题讨论】：

您是否考虑过将超出触发器大小的多个文件压缩到一个存档中，然后将其流式传输到另一端解压缩？
Andras 是对的，这将是迄今为止最快、最简单的方法。
@AndrasZoltan 我不认为 Windows 使用这种方式通过网络复制文件，最好将它们作为单个存档发送（仅用于小文件），但这需要更多处理和计算的时间以及服务器和客户端上更多的 CPU。
非常小的文件在网络上一个一个地移动时会产生巨大的开销：更多的文件意味着更多的传输，这反过来又意味着开销，最终意味着速度较慢。据我所知，最好的选择是将它们打包成一个字节数组，流式传输，然后在线路的另一端分解它。
@MurHafSoz 不，你是对的 - Windows 不使用这种技术 - 它使用的方法比你所处的级别更靠堆栈；事实上，我认为它甚至可能由文件系统本身处理，你将无法与之竞争。你必须作弊。

标签： c# sockets file-transfer

【解决方案1】：

也许，一个简单的解决方案是将所有文件收集到一个大流中（例如压缩它们，但只需附加以使其快速）并发送这个流。这将提供更快的速度，但会占用两个设备上的一些 cpu 以及如何分离流中的所有文件的好主意。

但据我所知，使用更多端口只会是一个缺点，因为会有更多不同的流发生冲突，因此速度会下降。

【讨论】：

ummm 像下载加速器和 Internet 下载管理器这样的软件呢，Send GetFile 最多 (16) 个单个文件以使下载更快，我认为这也使用多个连接。
那是另一回事，问题不是你的带宽，而是提供商限制了每个连接。因此，使用多个连接，每个连接可以说有 50kb，大约 1600kb。举个例子，这就像一次将 5 个文件复制到硬盘驱动器，首先，驱动器写入文件 1 的一部分，然后必须跳转到文件 2 的位置并写入其中的一部分，依此类推。由于 Enternet 是单流，即使您在 cpu 上使用多个线程，
它实际上是一根电缆，一次只能发送一位。因此，在宣布新文件或宣布不同线程发送上浪费的每一点都在浪费带宽。
我确切地知道它是什么并且我知道它是不同的，我的观点是它们之间的共同点是它使用更多的 a 连接。我想这意味着更多的端口。
发送小文件时，发送速度非常快，而且我反复需要在文件字节之前发送文件信息，所以在发送实际文件字节之前有一个浪费的延迟，这个延迟不使用LAN带宽，我可以将它用于在另一个端口上发送的另一个文件，这就是重点，但是像你说的那样使用更多端口仍然不好，所以我认为最后我必须使用你们所说的方式完成它。

【解决方案2】：

应该注意的是，您永远不会达到 100% 的 LAN 速度使用率 - 我希望您不希望这样 - 那里有太多因素。

同样回复您的评论，您无法达到操作系统用于传输文件的相同级别，因为您距离裸机比 Windows 更远。我相信 Windows 中的文件复制仅比驱动程序本身高一两层（甚至可能在文件系统驱动程序中在中）——在 WCF 服务中，你离得更远了！

您最简单的做法是将多个文件打包成档案并以这种方式传输，然后在接收端将完整的包解压到目标文件夹中。当然，其中一些文件可能已经被压缩，因此不会受益 - 但总的来说，您应该会看到很大的改进。对于可以保留目录结构的坚如磐石的压缩，我会考虑使用SharpZipLib

智能地使用压缩的系统（可能是中等级别、低 CPU 使用率，但可以很好地处理“可压缩”文件）可能匹配或可能优于操作系统复制。 Windows 不使用这种方法，因为它对容错毫无希望。在操作系统中，文件传输中途停止的传输仍会保留任何成功的文件。如果传输本身被压缩和中断，一切都会丢失，必须重新开始。

除此之外，您还可以考虑以下几点：

在尝试任何增强功能之前，首先使用默认压缩使其工作。在某些情况下（取决于文件的大小/数量），您可以简单地压缩整个文件夹，然后一次性传输。但是，超过一定尺寸，这可能需要很长时间，因此您需要创建一系列较小的拉链。

在接收压缩文件时将其写入磁盘上的临时位置，不要在内存中缓冲整个文件。将文件解压到目标文件夹后删除。

考虑添加将某些文件类型标记为可以“裸”发送的功能 - 即未压缩。这样您就可以从压缩过程中排除 .zips、avis 等文件。也就是说，一个包含一百万个 1kb zip 文件的文件夹显然会从打包到一个存档中受益 - 所以也许让自己能够设置一个最小大小，超过该文件仍将被打包到一个压缩文件夹（或者可能是一个文件文件夹本身的磁盘比率计数/大小 - 包括子文件夹）。

除此建议外，您还需要尝试获得最佳结果。

【讨论】：