TCP, defined in RFC 9293 (August 2022, the consolidated revision), is the transport every browser-based streaming protocol depends on. It guarantees that the bytes the sender writes arrive at the receiver in the same order and without gaps, by sequencing every byte, acknowledging receipt, retransmitting lost packets and adapting its sending rate to the network. HTTP/1.1, HTTP/2 and the original RTMP all run on TCP, which is why an HLS or DASH player works through every router, firewall and corporate proxy on earth.
The cost of TCP's guarantees is head-of-line blocking. If one packet is lost, every later packet waits until the lost one is retransmitted, even if the later packets belong to an unrelated stream multiplexed on the same connection. For a 4K HLS stream this can be invisible. For a low-latency live stream behind a flaky cellular link it can be the difference between watching and rebuffering. That weakness is the reason QUIC was invented.
For streaming, the relevant TCP knobs are window size, initial congestion window (cwnd), the congestion-control algorithm (CUBIC by default, BBR for high-bandwidth links) and the kernel's send buffer size. Modern Linux defaults are generally fine for VOD over a CDN. Live and low-latency workflows usually want BBR enabled and large send buffers tuned via tcp_rmem and tcp_wmem.
