Why WebRTC Chooses UDP Over TCP and How RTP/RTCP Keep Streams Smooth

1. Transport Layer Protocols: TCP vs UDP

We all know HTTP runs on TCP, but many developers are less familiar with other transport protocols. TCP provides reliable, connection‑oriented byte‑stream transmission, while UDP offers connection‑less, packet‑oriented, unreliable delivery.

1.1 TCP and UDP Comparison

TCP is connection‑oriented; UDP is connection‑less.

TCP is a byte‑stream protocol; UDP is message‑oriented.

TCP guarantees reliable, ordered delivery; UDP does not.

1.1.1 UDP is connection‑less, TCP is connection‑oriented

UDP sends data without establishing a connection, while TCP requires a three‑way handshake and a four‑way termination.

1.1.2 UDP is message‑oriented, TCP is byte‑stream

UDP passes whole datagrams to the application with minimal processing; TCP treats data as an unstructured byte stream, storing it in buffers and handling flow and congestion control.

1.1.3 UDP is unreliable, TCP is reliable

UDP does not retransmit lost packets, whereas TCP detects loss and performs timeout‑based retransmission to ensure reliable delivery.

1.2 Why Choose UDP for Real‑time Audio/Video

Real‑time media is latency‑sensitive; TCP’s retransmission and congestion control introduce unacceptable delays, while UDP’s low‑overhead, connection‑less nature provides faster delivery despite occasional packet loss.

WebRTC uses reliable TCP for signaling but relies on UDP for media transport.

2. Application‑Layer Protocols: RTP and RTCP

UDP alone is insufficient for media; RTP adds sequencing, timestamps, and payload‑type information to support real‑time audio/video.

2.1 RTP Protocol

RTP provides end‑to‑end delivery, packet numbering, timestamps, and payload‑type identification.

Real‑time end‑to‑end transport.

Sequence numbers for loss detection and reordering.

Timestamps for synchronization and jitter calculation.

Payload type to indicate codec.

RTP header fields include version, padding, extension, CSRC count, marker, payload type, sequence number, timestamp, SSRC, and CSRC identifiers.

2.2 RTCP Protocol

RTCP supplies quality‑of‑service feedback such as Sender Report (SR) and Receiver Report (RR), occupying only about 5 % of bandwidth.

RTP defines two sub‑protocols: RTP and RTCP.

RTCP reports include packet counts, loss statistics, and other metrics to help adjust transmission strategies.

2.3 RTP Session Flow Summary

An RTP session uses a pair of UDP ports: an even port for RTP packets and the next odd port for RTCP packets.

Application sends media to RTP, which encapsulates it into RTP packets.

RTCP packages control information.

RTP packets are sent to the even UDP port; RTCP packets to the odd port.

2.4 Quick Start with Wireshark to Capture RTP/RTCP

Install Wireshark, capture traffic, filter for UDP, decode UDP as RTP, and inspect RTP headers (payload type, timestamp, SSRC) and RTCP reports.

3. Conclusion

Understanding the underlying transport protocols deepens one’s ability to leverage WebRTC’s full potential; merely using the API without this knowledge limits performance optimization.

4. References

RTP specification: https://tools.ietf.org/html/rfc3550