Transportprotokolle: UDP vs. TCP für Streaming

Before media can flow, it crosses the network - and the transport protocol shapes latency and quality. The two choices are TCP and UDP.

TCP guarantees ordered, reliable delivery: a lost packet is resent before later data arrives. Great for files and pages, where correctness beats speed.

For live media, TCP's reliability backfires. One lost packet stalls everything behind it during the resend - head-of-line blocking - causing freezes.

UDP is connectionless and fire-and-forget: no guaranteed order, no retransmits. Packets arrive fast or not at all - ideal for time-sensitive media.

In a live call, a frame from two seconds ago is useless. Better to drop a lost frame and move on than wait for a resend - which is why streaming prefers UDP.

Three metrics define real-time quality: latency (delay), jitter (arrival-timing variation), and packet loss. Keep all three low for a smooth call.

Since UDP packets arrive unevenly, the receiver uses a small jitter buffer to briefly hold and reorder them before playback - smoothing timing at the cost of tiny delay.

WebRTC sends media over UDP by default, layering RTP for sequencing and timestamps plus SRTP for encryption. It falls back to TCP only when UDP is blocked.

Instead of TCP-style retransmits, WebRTC fights loss smartly: FEC sends redundant data, NACK re-requests only critical packets, and concealment hides gaps.

WebRTC constantly measures bandwidth. If the link degrades, congestion control lowers resolution or bitrate to keep the stream alive instead of stalling.

Pick the right tool: TCP when every byte must arrive in order (downloads, APIs), UDP when timeliness wins (live audio and video) - just as WebRTC does.

Recap: streaming favors UDP because TCP's reliability causes freezes. WebRTC runs RTP/SRTP over UDP with a jitter buffer, FEC, NACK, and congestion control.