How TCP and UDP work

Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)is a transportation protocol that is one of the core protocols of the Internet protocol suite. Both TCP and UDP work at transport layer TCP/IP model and both have very different usage.

Lets imagine, that we need to transfer certain amount of data. You may transfer only certain amount at the time (you have limitation on the packet size, which is below TCP/UDP).

In case of TCP, first you should establish connection (you may read about "3-Way handshake"). During this you agree on the "TCP Window Size" (explained  below). Then you start actual data transfer...

You transfer a packet, and then you wait for a confirmation, that the packet received. If you didn't receive confirmation within certain amount of time, you transmit the same packet again (Retransmission occured). If you agreed on certain "TCP Window Size", you may transmit multiple packets without waiting for a confirmation, and then you receive one confirmation for all these packets (not many, usually a few, just "more than one"). If you sent 3 packets, but only two confirmed, you will send that missing packet, if no confirmation was received at all, then you send all 3 packets again. But the bottom line is - each and every packet should be confirmed.

TCP has tweaked for performance over the years. ACKs are often piggy-backed with replies to messages so there is no extra packet or waiting. It can also dynamically adjust to changing network performance with features like slow start and congestion avoidance. TCP optimizes the amount of data sent per packet to avoid IP fragmentation. With UDP, if you send a message greater than 1472 bytes (for 'normal' Ethernet) the IP layer will fragment it into multiple datagrams and it will buffered and re-assembled in the receiving stack.


In case of UDP, you just blindly split your data into packets, and transfer them without any care, if they were received or not. You may do it "at the wire speed". And if you need some kind of control over the data, this should be taken care on higher layers of OSI model (for example, you should implement transfer verification at the Application Layer).

So, in theory, TCP actual performance is at least twice slower (for example, your one-way-trip time is 100ms, you sent a packet, and wait for a response), plus depends on receiver (how long it takes to prepare and send a confirmation), while UDP may send packets "as a stream" without any delay.

That said, there are many case where UDP may be a better choice. there isn't much use for retransmissions with applications like VOIP. For a simple exchange where you don't need the overhead of establishing and tearing down a connection UDP is likely the way to go, DNS being a perfect example. Note that even DNS will switch to TCP when the server sees that the reply will be lengthy due to multiple addresses and/or MX records.

If you are creating a VoIP application, there is no need constantly to check if the other end is on-line, so you can use UDP to transfer the main payload (voice) and a second TCP connection to handle connection/disconnection at a lower speed (once a second is ok).

If you are transmitting a public radio station over IP, you need only to enable your players to join one multicast channel. In the latest case, UDP is far more effective and is causing less overhead, since all the network balancing is handled by the multicast enabled routers.

In areas of video streaming and VoIP the overhead of TCP would be intolerable, so they use UDP and they work pretty well- mainly because the network infrastructure and the protocols have "matured" to the extent where reliability is largely taken for granted.

Clear as mud?