哪种文件访问最好：Webdav 还是 FTP？ [关闭]答案

【问题标题】：Which file access is the best : Webdav or FTP? [closed]哪种文件访问最好：Webdav 还是 FTP？ [关闭]
【发布时间】：2012-06-28 08:01:56
【问题描述】：

我必须开发一个 Java 应用程序，它必须读取网络上的一些文件，编辑它们并将它们放回去。

问题是我总是（通过网络）通过 FTP 协议进行文件操作。但是，我最近听说了基于 HTTP 的 Webdav。

有没有人注意到它们之间的差异（在速度方面）？哪一个是最好的？如果 FTP 有好处，他们为什么要“发明”Webdav？

【问题讨论】：

这个问题怎么还没结束？
我想知道这个问题是否可以改写为值得重新打开。乍一看，FTP 和 WebDav 的用途似乎完全相同，知道何时使用其中一个会很有帮助。
Related: Can questions that ask for a comparison be constructive? 据此，这个问题是无可救药的。另一方面，这个问题目前有近 30,000 个观点和许多赞成票，尽管有理由断言“这个问题的答案几乎完全基于观点，而不是事实、参考资料或特定专业知识”，这个问题的答案清楚地表明并非如此。

标签： ftp webdav

【解决方案1】：

Webdav 在轻松通过防火墙（没有单独的控制/数据套接字）方面优于 FTP。速度应该与两种协议通过原始 tcp 套接字传输文件的速度大致相同。

【讨论】：

你能解释一下吗？

【解决方案2】：

WebDAV 与 FTP 相比具有以下优点：

通过一个 TCP 连接工作，可以更轻松地将其配置为绕过防火墙、NAT 和代理。在 FTP 中，数据通道可能会导致正确的 NAT 设置出现问题。
同样由于一个 TCP 连接可以持久，因此 WebDAV 在传输许多小文件时会比 FTP 快一点 - 无需为每个文件建立数据连接。
GZIP 压缩是 HTTP 的标准，但不是 FTP 的标准（是的，MODE Z 在 FTP 中提供，但未在任何标准中定义）。
HTTP 有多种身份验证方法可供选择，这些方法未在 FTP 中定义。例如。 NTLM 和 Kerberos 身份验证在 HTTP 和 FTP 中很常见，除非您同时编写 FTP 的客户端和服务器端，否则很难获得对它们的适当支持。
WebDAV 支持部分传输，并且在 FTP 中部分上传是不可能的（即您不能覆盖文件中间的块）。

还有一件事需要考虑（取决于您是否控制服务器） - SFTP（SSH 文件传输协议，与 FTP 没有任何关系）。 SFTP 比 WebDAV 功能更丰富，SFTP 是一种访问远程文件系统的协议，而 WebDAV 在设计时考虑到了抽象（WebDAV 用于“文档”，而 SFTP 用于文件和目录）。 SFTP 具有上述 WebDAV 的所有优点，并且在管理员和开发人员中更受欢迎。

【讨论】：

这些标头专门用于获取，而不是上传资源。 httpbis 规范特别建议不要将范围与 PUT 请求结合使用，因为它可能导致不希望的结果。资料来源：我是一个主要的 webdav 服务器的作者，我每天都在浏览 rfc。
@Evert (1) “标头用于获取” - 您有规范性参考吗？ (2) 某些草案不鼓励某事的事实并不意味着这是被禁止的。我们还开发和销售 WebDAV 组件：-P
@Evert 只是服务器必须在收到范围请求时报告它不支持范围请求。只不过是服务器开发人员的一点关心;）。
很公平。请记住，添加该段落是因为现实世界的问题，而不是因为他们觉得他们想要更严格。
@elmarco 您似乎将文件访问（问题在于）与远程文档管理混淆了。我们在这里讨论 file 访问。至于“广泛的操作系统支持” - 这是无稽之谈，因为从 Unix 到 Windows 到 Java 到 Android 和 iOS 的所有现代平台都存在 SFTP 的客户端和服务器（是的，那里存在服务器）。

【解决方案3】：

回答问题 - Why did they "invent" Webdav

WebDAV 代表Web Distributed Authoring and Versioning。

互联网并不意味着通过 url (Uniform resource locator) 消耗资源

但事情就是这样。

因为 HTTP 具有用于获取资源 (GET) 和 (HEAD) 的强大语义。 (POST) 覆盖了语义操作的数量，而 (DELETE) 则被不信任所笼罩。 HTTP 缺乏其他一些特性，例如多资源操作。

简而言之，是读协议，不是写协议。

您可以通过 FTP 和许多机制上传您的资源 (URL) 以供获取。

WebDAV 应该提供互联网缺失的故事：支持通过相同机制 HTTP 创作资源。它扩展了语义，引入了新的 HTTP VERBS。

它还引入了机制，不仅可以读取、写入、修改和删除资源（uris），还可以查询和修改资源的元属性。不是你以前做不到，而是通过后门机制做的。

如您所见，它为 Internet 资源带来了一些您对桌面文件操作所期望的相同机制。

以下是一些类比：

MKCOL     ----- make collection ----- similar to make folder
PROPGET   ---- get properties (meta?) --- same as get info or extended attributes on mac
PROPPATCH --- modify properties
COPY      ---- cp
MOVE      ---- mv

我希望，我已经确立了 WebDAV 的一些崇高目标，作为 HTTP 的扩展，以支持互联网创作。不知道我们是否已经实现了。

关于您的问题

您的应用程序是一个客户端，并且必须使用可用的机制 - 另一端的 FTP 或 WebDAV。如果 WebDAV 可用，您可以使用它。但是需要一些时间来适应语义。 FTP 具有有限的语义并且擅长于简单性。如果您已经在使用它，请不要更改它。

哪个更快

这类似于回答，HTTP 或 FTP 哪个更快？

狡猾地指出，如果这是一个这样的问题，我们就不会通过 HTTP 下载/上传文件；）

【讨论】：

很有趣地概述了 Web 的哲学以及 WebDav 的关系。谢谢 pyfunc。

【解决方案4】：

取决于你想做什么。例如，FTP 上获取文件列表的开销是 7 个字节 (LIST -a)，而使用 Webdav (PROPFIND + 207 Multi Status) 是 370 个字节。

对于发送一些文件，FTP 的开销比 Webdav 低，等等。

如果您需要发送/获取大量小文件，FTP 会更快（使用多个连接进行正确的流水线操作，以及每个文件的 TCP 连接）。如果你发送/接收大文件，两种技术都是一样的，开销可以忽略不计。

请看： http://www.philippheckel.com/files/syncany-heckel-thesis.pdf

【讨论】：

不错的细节和数字
所以你说 FTP 在所有情况下都更好。
我的意思是，如果您打算（仅）发送和接收文件，那么 FTP 比 Webdav 更好。但是，Webdav 有许多其他 FTP 所没有的功能（例如锁定、共享）。如果处理大文件，那么与附加功能相比，webdav 的开销可以忽略不计。
WebDAV 可能使用更少的字节，但 ftp 需要更多的连接。如果延迟较低且数据包较小，则 ftp 可能会更快，但在大多数现代互联网带宽上相当可观，而延迟不一定很大 - 而在这里，（流水线）WebDAV 可能优于 FTP。
通过加密，在防火墙和 NAT 之后，WebDAV 运行的机会比 FTP(S) 高得多，因为 FTP 工作需要内容重写和嗅探......

【解决方案5】：

由于 DAV 在 HTTP 上工作，因此您可以获得 FTP 无法提供的 HTTP 的所有好处。

例如：

强身份验证、加密、代理支持和缓存。

您确实可以通过 SSH 获得其中的一部分，但 HTTP 基础架构 比 SSH 部署得更广泛。此外，SSH 不像 HTTP 那样拥有广泛的工具、开发库和应用程序。

DAV 传输（嗯，HTTP 传输）也比 FTP 更有效。您可以通过单个 TCP 连接进行多次传输，而 FTP 需要为每个传输的文件建立新连接（加上控制连接）。

Reference

【讨论】：

【解决方案6】：

文件修改时间：

ftp 和 webdav 处理文件修改时间的方式似乎有所不同。

似乎 ftp 中有一个“命令”来保留该时间（几个 ftp 客户端和服务器声称这样做），而 webdav，如果我没记错的话，可以获取文件修改日期，但不能在上传时设置它.

owncloud 客户端和一些专有的 webdav 客户端似乎有一种解决方法，但这只适用于他们的软件

根据使用情况，这是支持 ftp 的有力论据。我不希望我的文件有修改日期 == 上传日期。稍后下载后，我无法按日期判断我拥有的是哪个版本的文件。

【讨论】：