QUIC

HTTP/3, RFC 9114, is HTTP on QUIC. For file transfer it is the channel under a browser upload or download, not a new copy command. GET and PUT mean what they mean in HTTP. The packets underneath changed.

The practical differences are setup and loss. A new TCP plus TLS connection costs handshakes before the first file byte. QUIC can send application data in the first round trip on a resumed session. Streams do not block each other the way TCP bytes do: a lost packet stalls the stream it belonged to, not every download on the connection. That matters when one page fetches many objects. It matters less for a single 20 GB PUT, which is still bound by bandwidth and by the application's resume logic.

A recipient downloads a 3 GB master in Chrome. The scheme is still `https`. The browser negotiates HTTP/3, the socket is UDP on 443, and a mid-download loss stalls that stream for a moment instead of resetting a separate TCP connection. If the network blocks UDP, the browser falls back to HTTP/2 on TCP. The file still arrives. An operator who only allows TCP 443 will see successful transfers and wonder why the HTTP/3 flag never sticks. A firewall that allows UDP 443 and drops it halfway produces a fallback delay, not a corrupt file.

QUIC does not replace multipart upload, expiring links, or access control. It does not speak FTP. A partner who says "we support QUIC" means their HTTPS edge can do HTTP/3. The object store, the signature on the URL, and the checksum are unchanged. Measure throughput on the transfer. Do not assume UDP is faster on a path that rate-limits it.