DEV Community

疏影
疏影

Posted on

WebDAV performance tuning on Windows

#networking #performance #tutorial

Your WebDAV mount feels slow. Here's what actually moves the needle: TCP buffers, TLS handshake amortization, and HTTP keep-alive.

TL;DR

Three knobs that matter, in order of impact:

  1. TLS session resumption — saves the second+ connection ~120 ms each
  2. HTTP keep-alive — saves the TCP+TLS handshake on every chunk
  3. TCP send/receive buffer size — for >100 MB sequential reads, the default is too small

Everything else (chunk size, threading, cache) is roundoff.

Test setup

Synology DS220+ on LAN, WebDAV over HTTPS port 5006, client = Windows 11 24H2, 1 Gbps wired.

Baseline: cold connection, single 4 GB file read = 89 MB/s. Default Windows TCP buffer = 64 KB.

1. TLS session resumption (the biggest win)

Without resumption, every TCP connection does a full TLS handshake = 1 RTT for TCP + 2 RTT for TLS = ~3 RTT before any data. On LAN that's ~3 ms, but if your server is across the internet, that becomes 50-300 ms.

Server-side (Synology DSM):

  1. DSM Control Panel → External Access → Certificate. Make sure you have a real cert (Let's Encrypt) — not self-signed.
  2. Enable HTTP/2 in Web Station / nginx reverse proxy. HTTP/2 multiplexes multiple requests over one TLS connection, which is what you actually want.

Client-side: Modern clients (RaiDrive, ScsDriver, macOS Finder) all resume TLS sessions automatically. Verify with Wireshark: you should see "NewSessionTicket" TLS extension in the handshake.

Before / after (4 GB single file read, RTT = 80 ms simulated):

Setup Throughput
No resumption, fresh TLS each 27 MB/s
TLS resumption 89 MB/s
TLS resumption + HTTP/2 92 MB/s

2. HTTP keep-alive

By default, HTTP/1.1 has Connection: keep-alive but servers often close after a few seconds of idle. With WebDAV's many small PROPFIND requests, you want the server to keep the connection open for at least 60 seconds.

nginx config (if you proxy WebDAV through nginx):

upstream webdav {
    server 127.0.0.1:5006;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    location / {
        proxy_pass http://webdav;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_read_timeout 300s;
    }
}
Enter fullscreen mode Exit fullscreen mode

The keepalive 32 directive tells nginx to keep up to 32 idle connections to the upstream — no TCP+TLS handshake per request.

Apache config:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 60
Enter fullscreen mode Exit fullscreen mode

Default Apache is fine, just make sure KeepAlive On is not commented out.

3. TCP send/receive buffer size

Windows default is 64 KB. For LAN file transfers that's the bottleneck.

Check current:

netsh int tcp show global
Enter fullscreen mode Exit fullscreen mode

Look for "Receive Window Auto-Tuning Level" — should be normal (default).

Set explicit buffers (PowerShell, admin):

netsh int tcp set global autotuninglevel=normal
netsh int tcp set global rss=enabled
Enter fullscreen mode Exit fullscreen mode

For per-adapter tuning (replace <iface> with Get-NetAdapter | Select Name):

netsh int tcp set supplemental template=internet custom congestionprovider=ctcp
Enter fullscreen mode Exit fullscreen mode

Linux server-side (if your NAS runs Linux):

sysctl -w net.ipv4.tcp_wmem="4096 16384 4194304"
sysctl -w net.ipv4.tcp_rmem="4096 87380 4194304"
Enter fullscreen mode Exit fullscreen mode

The max value (4 MB) lets the kernel buffer large reads without going back to the application for each chunk.

4. Chunk size in WebDAV clients

Most clients let you set a chunk size for large file transfers. Smaller chunks = more requests, more overhead. Larger chunks = better throughput but worse recovery if a chunk fails.

Reasonable values:

Use case Chunk size
LAN, fast server 8 MB
Internet, slow link 256 KB - 1 MB
Unreliable network 64 KB - 256 KB

In RaiDrive: Settings → Performance → Chunk size.
In ScsDriver: default is adaptive, but you can pin to 4 MB if your network is fast.

5. What doesn't help much

  • HTTP/3 (QUIC): helps on flaky networks (packet loss), not on clean LAN. Synology doesn't ship HTTP/3 yet.
  • Compression: WebDAV already handles this server-side for text files. Don't try to add gzip on top.
  • DNS caching: your server hostname isn't changing every request; OS-level cache is fine.

6. Diagnostic checklist

If your mount is still slow after the above:

  • [ ] Test from the server itself with curl -w "%{time_total} " -o /dev/null https://localhost:5006/file.bin — this is your floor
  • [ ] ping -t to your server — if >5 ms LAN, you've got network issues, not WebDAV issues
  • [ ] Wireshark on the connection — look for retransmissions, TLS alerts, small window sizes
  • [ ] Check server CPU during transfer — if it's pegged at 100%, the WebDAV daemon is the bottleneck, not the network
  • [ ] iostat -x 1 (Linux) — if disk await > 10 ms, the NAS drives are the bottleneck

For most people, items 1-3 above get them from 30 MB/s to 90+ MB/s. After that, you're fighting physics.

Top comments (0)