5 TCP vs UDP: How to Choose

5.1 Start With the Failure Question

Name the harmful failure. Test that case. Keep the receiver’s result visible. Recheck after either end changes.

Picture a greenhouse sensor sending a new temperature every five seconds. One missed reading may be harmless because the next one replaces it. Now picture a door command. Repeating that command may cause harm. These flows should not inherit the same delivery choice.

Transport is the part of a data path that moves information between applications. One style creates a managed stream. It keeps order and works to replace missing pieces. Another style sends separate messages. It leaves more decisions to the application. Neither style makes the whole product safe by itself.

Start with failure. Can an old value be replaced? Must every byte arrive in order? Is a repeat safe? How long may the receiver wait? Who notices a break? Write these answers before choosing the transport style.

Then inspect the ends. A managed stream can still carry a bad or repeated action. A separate message can be reliable when a higher layer adds identity, age, order, and reply rules. The receiver must prove the result that matters to the product.

This first view compares two clean styles. Real software adds security, retries, queues, and its own state. The Practitioner layer builds a decision record for each flow. Under the Hood examines connection state, duplicate action, receiver ownership, and the boundaries that simple labels can hide.

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?"

The TCP-versus-UDP choice becomes clearer when both candidates are judged against the same message need. Inspect Figure 5.1 to compare their evidence boundaries before selecting either protocol.

Read Figure 5.1 from the message purpose into failure meaning, then compare TCP’s stream state with UDP’s datagram boundary. Continue through receiver responsibility and the security boundary to the decision and retest trigger. The path connects protocol mechanics to application consequences instead of awarding a universal winner.

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.

Once the candidate behavior is understood, the decision needs a record that exposes what each side proved and left open. Figure 5.2 provides that side-by-side structure.

In Figure 5.2, start with the flow scope and required receiver outcome, then compare connection or datagram evidence, reliability ownership, and security treatment. Finish with the chosen behavior, limits, owner, and retest trigger. This order turns the comparison into an auditable product decision rather than a list of protocol features.

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.

Boundary and ownership changes can invalidate an earlier choice even when the protocol name stays the same. Inspect Figure 5.3 to see how the final review preserves those conditions.

Read Figure 5.3 from message purpose through failure consequence and required transport behavior. Next check gateway and security boundaries, receiver evidence, and operational limits before reaching the decision and retest trigger. The record closes the chapter by making selection conditional on the deployed path rather than on TCP or UDP in the abstract.

Retest Conditions

Reopen the transport decision when the message consequence or any evidence owner changes. Check purpose first, then endpoint and connection behavior, gateway translation, reliability rules, and the protection boundary. A change at any of those points can turn an acceptable stream or datagram path into a different application claim. The conditions below therefore belong to the decision record, not to a generic protocol maintenance list.

• 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 Decide Whether the Next Sample Replaces the Missing One

Suppose samples at elapsed times 0 s and 10 s arrive, but the 5 s sample is lost. Choose a freshness rule that exposes the resulting ten-second gap rather than letting the display’s current clock imply that the old temperature was just measured.

If the application needs only the latest state, choose independent datagrams with explicit sample identity, age checks and suitable protection when the tested loss behaviour is acceptable. That design still needs to reject a delayed old sample that arrives after the new one.

If a maintenance upload requires every byte in order, choose a managed stream when its connection and recovery costs fit the endpoint. A missing piece can then delay delivery of later stream bytes while transport works to restore order; the application still needs message framing.

For a concrete framing example, two application records contain 12 bytes each, giving 24 bytes in total. Choose a length or delimiter contract that can recover both records even if reads return the stream as 8 bytes followed by 16 bytes, because socket-read boundaries need not match record boundaries.

The door command needs another decision: choose a stable command identifier and repeat-safe handling wherever retries can re-submit an operation. If an unlock result is lost after execution, reconnecting a reliable stream does not tell the sender whether another attempt would repeat the action.

Read Figure 5.1 from message purpose through failure meaning and receiver responsibility, then choose using those boundaries rather than a speed reputation. The companion review record keeps the selected behaviour tied to the tested endpoints, security layer and remaining limits.

Predict whether a transport acknowledgement proves that the door physically unlocked. It proves only the acknowledgement’s defined transport result; choose a separate application outcome that distinguishes accepted, rejected, completed and unknown command states when the service needs those distinctions.

Finally, choose to re-test the flow when its meaning changes from routine telemetry to an alarm requiring complete event history. The same five-second source cadence can now need durable records and recovery rules that were unnecessary for a replaceable dashboard value, which is why this module evaluates complete flows rather than awarding one protocol a universal win.

5.6 Summary

TCP and UDP should now be compared as different evidence boundaries for a named flow. Start with message purpose and failure consequence, then assign stream or datagram behavior, receiver responsibility, protection, operational limits, and the retest trigger. The summary below closes the comparison without declaring a universal winner: the acceptable choice is the one whose observed behavior fits this receiver outcome.

Remember that mechanisms above transport can change the comparison. Application acknowledgements, sequence identifiers, freshness checks, and idempotency can make a UDP-based path reviewable, while poor stream framing or receiver-state handling can make a TCP-based path unsafe. The decision belongs to the complete bounded flow, not to a protocol reputation.

• 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.7 Key Takeaway

5.8 See Also