Part of migrating applications from on-premises hosting to cloud hosting (AWS, Azure, etc) involves re-evaluating how users access their data. A recent migration involved users running Windows 10 accessing a Windows file share using the SMB protocol. Since SMB isn’t safe to run directly over the Internet (it’s usually not encrypted and it has a long history of security vulnerabilities), potential options included tunneling SMB within a VPN or changing away from the SMB protocol. One such alternative is WebDAV.
Web Distributed Authoring and Versioning (WebDAV) provides the same basic functionality as NFS, SMB, or FTP over the familiar, widely deployed well supported HTTP protocol. It was literally designed for this use case.
Testing Methodology
I evaluated 7 approaches for clients to access a WebDAV share, testing the performance of each and noting pros and cons.
Testing was performed in March 2019. The same client, same server, and same connection was used for each test.
The client is a Dell Latitude 7490 running Fedora 29. Windows 10 (version 1809 build 17763.348) was run as a VM in KVM using user mode networking to connect to the Internet. For the smb+davfs2 testing, smb+davfs2 ran in Docker running in Linux and the Windows 10 VM connected to it.
The WebDAV server is running Apache 2.4.38 and Linux kernel 5.0.0-rc8. The WebDAV site is served over HTTPS.
Ping time between them is 18ms average, httping to the WebDAV server URL is 140ms average.
Windows 10’s Redirector over HTTP/1.1
WebDAV Redirector is the name of the built in WebDAV client in Windows. It’s accessed from Windows Explorer by using the “Map network drive…” option and selecting “Connect to a web site that you can use to store your documents and pictures”
Recent versions of Windows 10 support HTTP/2, so for this test, the “h2” protocol was disabled on the Apache server.
Windows 10’s Redirector over HTTP/2
This test is the same as the previous one except the “h2” protocol is enabled on the Apache server.
WebDrive
WebDrive (version 2019 build 5305) was used with “Basic Cache Settings” set to “Multi-User.” All other settings were left at their defaults.
WebDrive does not currently support TLS 1.3 or HTTP/2; I suspect these would improve performance.
davfs2 on Linux
davfs2 is a Linux file system driver which allows mounting WebDAV shares just like any other file system.
For this testing, the client is Linux, not Windows 10. Therefore, this test isn’t a real solution (the clients do need to run Windows 10). This test is for comparison and testing on component of a possible solution (Samba + davfs).
davfs2 does not support HTTP/2.
davfs2 offer a number of configuration options; here’s what was used for this testing:
/home/candrews/.davfs2/davfs2.conf[/home/candrews/webdavpoc]
use_locks 1
delay_upload 0 # disable write cache so users know that when the UI tells them the upload is done it’s actually done
And the mount command:
sudo mount -t davfs https://www.integralblue.com/cacdav /home/candrews/webdavpoc/ -ouid=1000,gid=1000,conf=/home/candrews/.davfs2/davfs2.conf
The davfs2 version is 1.5.4.
davfs2 with locks disabled (using a Linux client)
This test is the same as the previous one but this WebDAV locks disabled by setting “use_locks 1” in davfs2.conf.
Samba + davfs2
This test uses Samba to expose the davfs2 mount from the davfs2 test and uses Windows 10 to access the result SMB share.
The davfs2 mount exposed using SMB with the dperson/samba docker image using:
name smb -e USERID=1000 -e GROUPID=1000 --security-opt label:disable -v /home/candrews/webdavpoc:/webdavpoc:Z --rm -it -p 139:139 -p 445:445 -d dperson/samba -s "webdavpoc;/webdavpoc;yes;no;no;testuser" -u "testuser;testpass" -g "vfs objects ="
The biggest challenge with this approach, which I didn’t address, is with regards to security. The davfs2 mount that Samba exposes uses fixed credentials – so all Windows 10 users using the smb+davfs proxy will appear to the WebDAV server to be the same user. There is no way to pass through the credentials from the Windows 10 client through Samba through davfs2 to the WebDAV server. I imagine this limitation may disqualify this solution.
samba + davfs2 with locks disabled
This test is the same as the previous one but WebDAV locks are disabled in davfs2.
Results
Conclusion
Key takeaways from the results:
- The built in Windows Redirector (which is free and the easiest solution) is by far the slowest.
- WebDAV benefits greatly from HTTP/2. HTTP/2 was designed to improve the performance of multiple concurrent small requests (as is the case of HTML with references to CSS, Javascript, and images), and that’s exactly how WebDAV works. Each download is a PROPFIND and a GET, and each upload is a PROPFIND, PROPPUT, PUT, and, if locking is enabled, LOCK and UNLOCK.
- Disabling WebDAV locks improves performance. By eliminating the LOCK/UNLOCK requests for every file, upload performance doubled. Unfortunately, disabling WebDAV locks for the built in Windows Redirector requires a registry change, a non-starter for many organizations. WebDrive has locks disabled by default. davfs2 only uses locks when editing files (when a program actually has the file open for writing), not when uploading a new file.
- Surprisingly, the overall fastest (by far) approach involves a middle box running Linux using smb+davfs2. Adding a hop and another protocol usually slows things down, but not in this case.
- davfs2 is fast because it opens more HTTP connections allowing it to do more requests in parallel. WebDrive supports adjusting the concurrency too; in “Connection Settings” there are settings for “Active Connections Limit” (defaults to 4) and “Active Upload Limit” (defaults to 2). Adjusting these settings would impact performance.
- The client/server connection was high bandwidth (~100mpbs) and low latency (~18ms). Lower bandwidth and high latency would result in even greater benefits from using HTTP/2 and disabling locking.
Considerations for future research / testing include:
- AWS Storage Gateway may be a solution. Concerns for this approach include:
- Incompatible with MITM HTTPS-decrypting security devices
- Uses a local, on premises cache (called an “upload buffer” in the documentation) so changes are not immediately available globally
- Integrates with Active Directory for authentication/authorization, but setting up for a large number of users is onerous.
- Requires the use of S3 for file storage, which may not be compatible with the servers in AWS
- Various other WebDAV clients for Windows, such as DokanCloudFS, NetDrive, DirectNet Drive, ExpanDrive, and Cyberduck / Mountain Duck.
- Further tweaks to configuration options, such as the concurrency settings in WebDrive and davfs2
Performance Testing WebDAV Clients by Craig Andrews is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
This was really interesting, thanks!
I’m trying to figure out a few questions with your approach: first, while you (the point of your post) tried a number of different _clients_, you had clearly already decided on one server (Apache httpd). Had you considered other servers (I’ve been trying to identify them, since the WebDAV project list is 15+ years old)? And, I’m also curious about what seems the fatal flaw in using Apache, which is the lack of access control based on credentials, given on the server host all files are owned by the httpd process.
I’m wondering what I might have missed, here. Especially with the second question, I’ve been wondering whether a httpd daemon started as the end-user uid is the right approach.
Again, really good post – thanks you again.
I hadn’t really considered other servers. I went with Apache as I have experience with it and its WebDAV support seems to be well-maintained. A quick look at Wikipedia shows that there are some others that are worth a look. I suspect (based on the testing of clients I did in this post) that changing out the server doesn’t have much chance for a performance benefit, but it would be interesting to know for sure.
Apache does offer access control based on credentials. For example, one could use a .htaccess file to limit access by path, HTTP verb (so a user could read using GET, but not write using PUT, for example), or some other criteria. You’re correct, though, that all file system operations are done by the httpd process user so per-user SMB permissions aren’t used for access control, and that is a limitation. There’s seemingly no way to have Apache do something as the authenticated user making the request.
To have the user making the HTTP request also be the user making the SMB request, I think there are only 2 options:
Both of those seem like interesting paths to explore.
Thank you for the comment!