TCP vs UDP

Let's say two systems A and B have to communicate with each other over a network. Most simply, if both of them are aware of how to route data to each other, you can just send a packet of data from A to B and get it over with. However, this ignores a critical aspect of communication - no network is perfect. Data can be lost, duplicated, or corrupted.

So then what if once we get this data packet at B we could just let A know that we received the data and that A can continue? Probably a better idea, but then A has to wait until B lets it know that it has received the data. But again - networks are not perfect. What if B does receive the data but the acknowledgement of the data receipt to A gets lost? Also, this method takes more time because there's way more data transfer involved.

In summary, both of these methods have their own advantages and drawbacks. The simplest way described in the thought experiment above is known as the User Datagram Protocol (UDP) and the more sophisticated protocol is known as the Transmission Control Protocol (TCP). If you have any programming experience, you have likely heard of these terms somewhere because they are frequently used in anything to do with networking.

Let's define these two a bit more accurately.

TCP: Reliable but Slower

TCP is a connection-oriented protocol designed for reliable data transmission. It establishes a connection between devices before data transfer begins, ensuring that all packets are delivered in order and without loss. The receiver sends acknowledgments to the sender once the packets are received. If a packet is lost or corrupted, TCP retransmits it.

This reliability comes with higher latency and overhead (since a connection needs to be established and there is more data transmission involved), making TCP ideal for applications like file transfers, emails, and web browsing, where accuracy is more important than speed.

How TCP Works:

1. Three-way handshake to establish connection (SYN, SYN-ACK, ACK)
2. Sequence numbers to track packet order
3. Acknowledgments for received packets
4. Retransmission of lost packets
5. Flow control to prevent overwhelming the receiver
6. Congestion control to avoid network saturation

UDP: Fast but Less Reliable

UDP is a connectionless protocol focused on low-latency communication, transmitting data without establishing a formal connection. It does not guarantee packet delivery, order, or error correction, making it faster but less reliable than TCP.

UDP is widely used in real-time applications like online gaming, video streaming, and VoIP, where speed and timely delivery are more critical than perfect accuracy. WebRTC also uses UDP by default but importantly might also use TCP as a backup.

How UDP Works:

1. No connection establishment - just send data
2. No acknowledgments of received packets
3. No retransmission of lost packets
4. No sequencing to enforce packet order
5. Minimal header overhead (8 bytes vs TCP's 20+ bytes)
6. No flow or congestion control

Choosing Between TCP and UDP

Why WebRTC Uses Both

WebRTC primarily uses UDP for media transmission because:

1. Real-time requirements: A few dropped frames in video are better than delayed frames
2. Consistent latency: Better to have consistent timing than perfect delivery
3. Built-in mechanisms: WebRTC implements its own reliability mechanisms on top of UDP when needed

However, WebRTC is smart enough to fall back to TCP when:

1. Firewalls block UDP: Some corporate networks block UDP traffic
2. Data channels need reliability: For chat messages or file transfers within WebRTC
3. TURN servers: Sometimes relay servers use TCP for more reliable connections

Understanding these protocols helps developers optimize their WebRTC applications for different network conditions and use cases.