Streaming and the send window: throughput without an infinite buffer

Four sizes must not be confused:

Without overlapping work, the sender can wait for a reply after every chunk. On long round trips the line then sits idle at times. The native window is negotiated on both sides: over TLS through the ALPN profile, over the relay (server route) in the handshake.

The window limits what is in flight, not what the receiver must hold. Four chunks are a credit limit. The receiver does not have to hold four complete files at once. The shared decryption pipeline overlaps loading, two verification and decryption workers and ordered output with at most three chunk slots. Pipeline occupancy and transport window are different limits. All relevant hashes, GCM tags and the whole-file hash are still checked; ordered output stays necessary.

Why low bandwidth works

A window says how much may be in flight without further release, not how fast that data has to arrive. Small bounded I/O steps and stall deadlines distinguish a slow but progressing transfer from a stuck connection. Profile deadlines still apply; a stalled transfer ends and can be resumed as the same job.

A rule of thumb: the bandwidth-latency product

Data needed in flight ≈ bandwidth × round-trip time

Pure arithmetic at a 20 ms round trip: 1 Gbit/s corresponds to 2.5 MB, 10 Gbit/s to 25 MB and 100 Gbit/s to 250 MB. These are decimal MB and no pipeit measurements. A bounded application window, the TCP window, packet loss, hashing, TLS, disks and memory bandwidth can each limit more tightly. A bigger window alone does not make a client 100-Gbit-capable.

Preparing, data transfer and safe completion have to be measured separately. A fast ciphertext micro-benchmark is no proof of the same payload rate including file scans, receive verification and disk commit.