5  TCP vs UDP: How to Choose

Keywords

TCP UDP comparison, IoT transport selection, transport protocol comparison, TCP evidence review, UDP evidence review, application reliability over UDP, transport decision record

5.1 Start With the Failure Question

Do not choose TCP or UDP by reputation. Start by asking what failure would hurt this IoT flow: wasted battery, stale telemetry, a duplicated command, delayed control, or a missing audit record. The better transport choice is the one whose behavior and remaining responsibilities match that failure story.

5.2 Overview: TCP and UDP Answer Different Evidence Questions

TCP and UDP are not good or bad in isolation. They answer different transport questions. TCP gives the application an ordered byte stream with connection state, acknowledgements, retransmission, flow control, and close behavior. UDP sends independent datagrams and leaves acknowledgement, retry, duplicate handling, ordering, and acceptance behavior to the application or a higher protocol.

The right comparison starts with the message. A replaceable sensor reading, an irreversible actuator command, a configuration transfer, and a gateway upload can each need a different transport record even when they share the same device or network path.

For example, a greenhouse sensor that reports temperature every five seconds may tolerate a missed UDP datagram if the dashboard marks freshness and the next reading replaces the old one. The same gateway may use TCP for a configuration download because the file must arrive as an ordered stream and the application must know when the transfer is complete. Neither choice is proven by the protocol name alone: the review record needs the message consequence, the receiver rule, and the owner of any retry or rejection decision.

A useful comparison also avoids the common shortcut "TCP equals safe, UDP equals unsafe." TCP can still deliver bytes for a command that the application rejects, parses incorrectly, or applies twice after a retry above the stream. UDP can be acceptable when a higher protocol supplies acknowledgement, sequence, freshness, or duplicate evidence. The chapter's question is therefore not "which protocol is better?" but "which layer proves the behavior this message claims?"

If you only need the intuition, this layer is enough: choose TCP when stream behavior and connection evidence fit the flow; choose UDP only when datagram behavior fits and the record explains loss, duplicate, ordering, security, receiver behavior, and retest limits.

TCP and UDP answer different questions: TCP adds connections, ordering, and congestion control, while UDP stays a lightweight, connectionless datagram.

TCP Evidence

Connection state, ordered byte stream, retransmission behavior, flow control, close behavior, and application framing limits.

UDP Evidence

Datagram identity, acceptable loss or retry ownership, duplicate handling, ordering rules, and receiver acceptance behavior.

Security Boundary

TLS, DTLS, gateway termination, peer identity, replay handling, and where protection starts or ends.

Retest Trigger

The change in message criticality, endpoint role, retry policy, path, or security layer that reopens the decision.

Overview Knowledge Check

5.3 Practitioner: Build the Transport Decision Record

A reviewable TCP-versus-UDP decision is a compact record. It names the flow, the required behavior, the selected transport, the evidence, the open limit, the owner, and the trigger for retesting the choice.

The decision record keeps the selected transport tied to message behavior, evidence, limits, owner, and retest trigger.

Record field

Question

Evidence to keep

Failure it prevents

Message

What exact flow is being reviewed?

Telemetry, command, alert, configuration, batch upload, firmware transfer, or gateway handoff.

Reusing one protocol answer for unlike flows.

Required behavior

What must the receiver observe?

Stream order, datagram identity, freshness, duplicate handling, final acceptance, rejection, or retry.

Treating sender-side transmission as application success.

Selected transport

Which behavior fits the evidence?

TCP stream, UDP datagram, DTLS-protected datagram, application-confirmed UDP, or split gateway path.

Choosing from protocol preference instead of flow behavior.

Reliability owner

Where is retry or acceptance decided?

Transport stack, application protocol, gateway, receiver, operations rule, or explicit open issue.

Calling a path reliable without naming the layer that proves it.

Security boundary

Where is identity and protection checked?

TLS, DTLS, gateway termination, replay handling, peer identity, and protected segment scope.

Assuming a transport choice also proves authorization.

Retest trigger

What future change invalidates the record?

Message criticality, endpoint sleep behavior, gateway role, timeout policy, security layer, or receiver rule.

Letting a stale decision survive changed product behavior.

Worked Record: Replaceable Reading

A sensor sends periodic status readings, and the collector displays the latest accepted value. UDP can be reviewable if the record shows datagram identity, acceptable loss or replacement behavior, duplicate and stale-message handling, and the protection boundary when the path carries protected data.

The same UDP record should not be copied to an actuator command. The command has a different consequence, so it needs final receiver-state evidence and a separate retry or acknowledgement decision.

Practitioner Knowledge Check

5.4 Under the Hood: Boundaries, Ownership, and Retest Conditions

TCP and UDP sit below the application claim. TCP can retransmit bytes inside a connection, but it does not know whether the application message was authorized, framed correctly, applied, rejected, or rolled back. UDP preserves datagram boundaries, but it does not supply delivery confirmation, ordering, duplicate suppression, or flow control.

The under-the-hood review names the boundary where transport evidence stops and another layer must take over. That boundary is especially important when gateways translate between transports, when UDP carries a confirmable application protocol, or when DTLS protects a datagram path but does not define application acceptance.

At packet level, the evidence differs in kind. A TCP segment is part of a connection with sequence and acknowledgement state, congestion and flow-control behavior, and a byte stream that the application must frame into messages. A UDP datagram carries one message unit with a smaller fixed header, but any replay window, sequence number, acknowledgement timeout, retry cap, freshness rule, or duplicate cache must be supplied by the application protocol, gateway, or receiver. That distinction matters more than a simple header-byte comparison.

Connection lifetime changes the review as well. A persistent TCP connection can make setup cost less important, while a sleepy endpoint that opens a fresh connection for each short exchange may spend more radio time on handshake, acknowledgement, teardown, and retransmission behavior. A UDP path may save setup work, but only if the missing reliability evidence is either unnecessary for that message or explicitly provided elsewhere. Retest the decision when the product changes any of those hidden assumptions.

Stream Boundary

TCP proves byte-stream behavior within a connection, not message semantics or final receiver action.

Datagram Boundary

UDP preserves message units, but loss, duplicate, stale, and retry behavior must be visible elsewhere.

Gateway Boundary

A gateway can acknowledge one segment before another segment or the device has accepted the message.

Security Boundary

TLS or DTLS evidence protects a segment; it does not prove sensor truth, command safety, or parser correctness.

Transport selection remains reviewable when message consequence, selected behavior, reliability owner, security boundary, receiver evidence, open limit, owner, and retest trigger stay together.

Retest Conditions

• Retest if a status message becomes an alarm, command, audit record, or billing record.
• Retest if endpoint sleep behavior, memory, buffering, or connection lifetime changes.
• Retest if a gateway starts terminating or translating the selected transport behavior.
• Retest if retry, timeout, duplicate, stale-message, or receiver acceptance rules change.
• Retest if TLS, DTLS, replay handling, identity checks, or security ownership changes.

Under-the-Hood Knowledge Check

5.5 Summary

• TCP and UDP should be compared from message evidence, not from protocol preference.
• TCP provides ordered byte-stream behavior within a connection, but application correctness still needs separate proof.
• UDP provides independent datagrams, while acknowledgement, retry, duplicate handling, ordering, and receiver acceptance must be handled elsewhere when required.
• Security boundaries such as TLS and DTLS should be named separately from transport behavior.
• Gateways can split one end-to-end claim into multiple segment records.
• Retest when message criticality, endpoint behavior, gateway ownership, retry policy, receiver rules, or security boundaries change.

5.6 Key Takeaway

Compare TCP and UDP as evidence boundaries: name the message, assign reliability ownership, prove receiver behavior, separate security claims, and record the trigger that reopens the choice.

5.7 See Also

Transport Layer Overview

Review the flow, endpoint, port, reliability, and security vocabulary behind transport decisions.

User Datagram Protocol (UDP)

Use this for datagram-specific evidence, loss handling, duplicate behavior, and application responsibility.

Transmission Control Protocol (TCP)

Use this for stream-specific evidence, connection state, acknowledgements, flow control, and close behavior.

Transport Selection and Scenarios

Apply the comparison record across telemetry, commands, uploads, transfers, and gateway handoffs.