Streaming performance is not only a video-player concern. Software artifacts, model weights, backups, audio libraries, and large API exports all depend on the same fundamentals: move bytes quickly, preserve the exact payload, respect backpressure, and stop cleanly when a client disconnects.
Webship treats those requirements as one transport problem across HTTP/1.1, HTTP/2, HTTP/3, direct file delivery, reverse proxying, and WebTransport. The fast path is useful only when it preserves framing, cancellation, trailers, security inspection, and bounded memory.
Measured 100 MB streaming capacity
The Webship 1.3.1 Debian capacity run measured median payload throughput with a fixed 100 MB fixture. Every accepted sample required the exact 99,943,778-byte response body and zero client, protocol, proxy, major-page-fault, and HTTP/3 packet-loss errors.
| Webship mode | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Direct file delivery | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | Reverse proxy with TLS termination | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Reverse proxy with TLS pass-through | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
In the recorded comparison, Webship produced the highest direct and TLS-terminated median for every measured protocol. The complete matrix includes Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, and Bun on the [benchmark page](/benchmarks).
These numbers measure capacity on the benchmark host. They are not a promise for an arbitrary internet path. Storage latency, network bandwidth, round-trip time, packet loss, TLS policy, concurrency, and origin behavior still determine real delivery speed.
One binary, three transport strategies
A large response does not benefit from the same policy as a small HTML document. Webship keeps the ordinary request path conservative and promotes only a proven bulk response.
HTTP/1.1: fewer transitions around the file
On Linux, Webship keeps the response head and file payload inside one best-effort TCP cork interval. Once a large TLS response qualifies for the bulk path, direct file delivery can move from Rustls records to audited one-way kernel TLS and use sendfile without copying the payload through an application buffer.
The connection still begins in userspace TLS. Small responses remain there. Webship requests the kTLS transition only after a response body of at least 1 MiB proves that the connection is carrying bulk data.
HTTP/2: batching without breaking flow control
HTTP/2 multiplexing makes uncontrolled buffering expensive. Webship batches writes while retaining stream and connection flow-control limits. For high-concurrency streaming, a 128 KiB TLS write buffer can hold two 64 KiB DATA frames, while the connection send budget remains explicit and bounded.
An already-ready upstream body frame can be prefetched without bypassing Hyper framing, trailers, cancellation, inspection, or backpressure. That reduces an avoidable scheduler round while keeping the protocol contract intact.
HTTP/3: QUIC pacing instead of kTLS
HTTP/3 never uses the TCP kTLS path. Webship applies transport-aware QUIC pacing, bounded datagram packetization, DPLPMTUD, and per-reactor timer-driven microbatching. Large HTTP/3 responses and accepted WebTransport sessions can select BBR without changing the CUBIC policy used by ordinary traffic.
The focused HTTP/3 stability qualification used seven accepted samples. TLS-terminated streaming delivered a 1,938.6 MiB/s median with 2.12% coefficient of variation. TLS pass-through delivered 1,748.5 MiB/s with 1.65% coefficient of variation. Both series had zero body-integrity, client, protocol, and packet-loss errors.
Direct delivery or reverse proxy?
Use direct delivery when Webship owns the deployed file tree. It removes the origin hop and enables the most efficient static-file path.
A minimal multi-protocol site looks like this:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Use reverse-proxy TLS termination when Webship must route by path, apply WAF or API Shield checks, enforce body limits, add forwarding headers, or observe HTTP fields:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Set tls_termination = false when the origin must retain the application plaintext and active session keys. Pass-through cannot inspect encrypted HTTP fields. TCP pass-through therefore routes by ClientHello SNI, while HTTP/3 pass-through requires one shared UDP origin.
Tune bulk streaming explicitly
For high-concurrency HTTP/2 TLS streaming, Webship documents these process-bound settings:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"The connection budget above provides 128 KiB of credit for 256 active streams. Treat it as a capacity decision, not a universal default. Measure memory, latency, and throughput with your expected concurrency before increasing it.
On Linux, load the kernel TLS and BBR modules and allow the Webship service account to select BBR. Webship fails before binding when its required kernel capability is unavailable, so a deployment cannot silently claim the optimized path while running without it. Other operating systems retain the portable Rustls and congestion-control paths documented for their platform.
WebTransport is a different streaming shape
WebTransport combines reliable streams and unreliable datagrams over a secure session. It does not use TCP kTLS. Webship's bounded diagnostic endpoint validates origins and enforces session, stream, capsule, datagram, byte, and idle-time limits.
In the 1.3.1 capacity run, direct WebTransport reached 1,018.1 MiB/s for reliable streams and 1,038.9 MiB/s for datagrams. TLS pass-through reached 548.6 MiB/s and 629.7 MiB/s respectively. Both modes passed all five samples with zero rejected samples, zero lost datagrams, and zero client major faults.
Prefer HTTP/3 for new WebTransport clients. The HTTP/2 path exists for compatibility with the older expired-draft settings.
What to verify before production traffic
- Test the exact media or artifact sizes you will serve, not only a tiny synthetic response.
- Verify the response length and content digest at the client.
- Exercise cancellation, range requests, slow readers, and origin half-close behavior.
- Measure sustained throughput together with CPU, memory, socket errors, retransmits, and tail latency.
- Validate direct, TLS-terminated, and pass-through modes separately; they have different security and routing boundaries.
- Keep instrumentation off for normal production traffic, then enable bounded diagnostics deliberately when investigating.
- Recheck the Linux kTLS and BBR preflight after kernel, container, or systemd sandbox changes.
Streaming is fast when the whole path cooperates. Webship's design keeps the bulk-data optimizations protocol-specific while preserving one operational model and one correctness bar.
Read the complete [Webship 1.3.1 documentation](/docs/1.3.1), inspect the [benchmark methodology and competitor matrix](/benchmarks), or download a signed build from [Downloads](/downloads).