Compare setup cost, header bytes, acknowledgments, packet loss, and IoT transport choices
Watch setup, headers, ACKs, loss, and application reliability for the same IoT payload over TCP and UDP. The useful choice depends on behavior, not only the 20-byte versus 8-byte header.
Visual comparison
Use Step to inspect setup, data transfer, feedback, and loss handling one stage at a time.
Connection setup happens before the first application data byte.
UDP can send the first datagram immediately, but delivery policy belongs above UDP.
--
--
--
TCP creates connection state, numbers bytes, acknowledges received data, retransmits missing data, and delivers the stream to the application in order.
UDP adds ports, length, and checksum around each datagram. It does not create a connection, remember order, or resend a lost datagram by itself.
A tiny sensor report may benefit from UDP, while a configuration write may need TCP or an application protocol that adds confirmation and retry behavior.
Quick reference
Use this table to interpret the workbench output and avoid common TCP/UDP shortcuts.
| Question | TCP answer | UDP answer | IoT caveat |
|---|---|---|---|
| Can the first application message be sent immediately? | No. Normal TCP needs a three-way handshake first. | Yes. UDP can send a datagram without a transport handshake. | Security, DNS, radio attach, NAT traversal, or application login can add delay above either transport. |
| What is the minimum transport header per packet? | 20 bytes for a TCP header with no options. | 8 bytes for a UDP header. | Link-layer, IPv6, 6LoWPAN compression, security tags, and tunneling change the real on-air size. |
| What happens when one packet is lost? | TCP retransmits and keeps ordered delivery, at a latency cost. | UDP does not retransmit unless the application protocol chooses to. | For commands or firmware chunks, UDP usually needs confirmation and retry logic. |
| Does it preserve message boundaries? | No. TCP presents a byte stream, so applications frame their own messages. | Yes. One UDP send maps to one datagram, unless fragmentation occurs below. | Large UDP datagrams can fragment; constrained networks often keep payloads small. |
Guided practice
Load a task, press Step, and explain whether the extra bytes buy behavior the application needs.
Set the tiny payload preset. Notice that transport headers can outweigh the sensor value itself.
Load the command preset. Compare TCP against UDP with application ACK and retry enabled.
Load the lossy LPWAN preset. Watch how retries cost both bytes and time, even when hidden by TCP.
Deeper notes
The workbench intentionally uses a small set of visible assumptions. Expand the notes when validating a real design.
The total byte estimate includes the selected IP header, transport header, application payload, TCP connection setup packets, TCP ACK packets, and teaching retransmission packets. It excludes Ethernet, 802.15.4, cellular, security, tunneling, compression, and preamble overhead.
The 20-byte TCP minimum header is only the per-segment transport header. Short IoT exchanges can also pay for setup, ACKs, retransmissions, and options such as timestamps, SACK permitted, MSS, or window scaling. Long-lived connections amortize setup across many messages.
UDP does not define reliability, ordering, flow control, or congestion control. Applications that need those properties must add them carefully. Internet-facing UDP applications should follow UDP usage guidance and avoid sending uncontrolled traffic into congestion.
MQTT commonly runs over TCP. CoAP commonly runs over UDP and can use confirmable messages. QUIC runs over UDP but implements connection setup, reliability, congestion control, and streams above UDP. So the transport header is only one part of the design.
Sources
These links anchor the header sizes, TCP behavior, UDP guidance, and IoT protocol examples.