28  Transport Comprehensive Review

In 60 Seconds

This comprehensive review consolidates transport layer knowledge for IoT, covering TCP vs UDP fundamentals, DTLS security for constrained devices, protocol overhead analysis, and optimization techniques. It serves as an index to focused sub-chapters on protocol selection, overhead calculations, DTLS architecture, and knowledge checks — estimated at 2 hours total study time.

Key Concepts
  • TCP/UDP Trade-off Summary: TCP: reliable, ordered, connection-oriented, 20-byte header, 3-RTT setup; UDP: unreliable, unordered, connectionless, 8-byte header, 0-RTT; IoT typically prefers UDP for constrained devices
  • Transport Protocol Selection Framework: Choose based on: data rate (UDP for high-rate streaming), reliability requirement (TCP for commands), latency (UDP for real-time), device constraints (UDP for CoAP on 8-bit MCU)
  • QUIC Protocol: HTTP/3 transport built on UDP; provides TLS 1.3 encryption, multiplexing, and congestion control; eliminates TCP’s head-of-line blocking; growing adoption in IoT gateways
  • WebSocket over TCP: Upgrade from HTTP connection to bidirectional stream; used for IoT dashboard push notifications and browser-based device control; not recommended for constrained IoT devices
  • End-to-End vs Hop-by-Hop Reliability: TCP provides end-to-end reliability; application-layer protocols (MQTT QoS, CoAP Confirmable) provide hop-by-hop; only both together guarantee delivery through intermediaries
  • Congestion Control Impact on IoT: TCP congestion control (CUBIC, BBR) reduces throughput during congestion; for real-time IoT data (audio, video), use UDP to avoid throughput collapse and implement application-layer rate adaptation
  • UDP Checksum: Mandatory in IPv6 (optional in IPv4); provides error detection for the UDP header + payload; 1-in-65,536 chance of undetected corruption; use application-layer CRC for critical data
  • Transport Security Integration: Use TLS for TCP-based protocols (MQTT, HTTP); use DTLS for UDP-based protocols (CoAP, MQTT-SN); never use cleartext transport for IoT data in production

28.1 Learning Objectives

By the end of this review, you will be able to:

  • Synthesize TCP vs UDP knowledge for IoT protocol selection across different deployment scenarios
  • Evaluate DTLS security trade-offs for constrained devices running CoAP over UDP
  • Calculate protocol overhead to compare bandwidth and battery impact of TCP, UDP, and DTLS
  • Apply transport optimization techniques for IoT-specific challenges like lossy links and sleep/wake cycles

The transport layer is the part of networking that ensures data gets from one application to another reliably (or quickly, depending on what you need). This review brings together all the transport concepts covered so far — TCP, UDP, DTLS, and more — into a comprehensive overview that helps you see how everything connects.

“This review brings together everything we have learned about the transport layer,” said Max the Microcontroller. “TCP vs UDP fundamentals, DTLS security, overhead analysis, and optimization techniques — all in one place.”

“The key insight is that protocol selection is always about trade-offs,” explained Sammy the Sensor. “TCP gives reliability but costs battery. UDP gives speed but risks data loss. DTLS gives security but adds overhead. There is no free lunch.”

“This review is organized into focused sub-chapters,” added Lila the LED. “Protocol selection reviews the decision framework. Overhead analysis does the math on bandwidth and battery. DTLS security covers encryption architecture. Each one takes about 20 to 30 minutes.”

“Use this as a study guide or a reference,” said Bella the Battery. “If you can answer the knowledge checks in each sub-chapter, you truly understand IoT transport. Two hours of study here is worth days of debugging transport issues in production.”

Deep Dives:

Comparisons:

Network Layer:

Learning:

28.2 Chapter Index

28.2.1 1. Protocol Selection and Trade-offs

Transport Review: Protocol Selection

  • Key takeaways for UDP, TCP, and DTLS
  • Selection criteria: reliability, latency, power, security
  • Trade-off analysis: TCP retransmission vs UDP application-layer retry
  • TCP vs UDP architecture comparison diagrams

Estimated Time: 30 minutes

28.2.2 2. Overhead and Battery Analysis

Transport Review: Overhead Analysis

  • Protocol overhead visualization for 10-byte payloads
  • Overhead comparison tables: UDP (24B), TCP (244B), DTLS (53B)
  • Battery life calculations for environmental sensors
  • Impact of transmission frequency on battery life

Estimated Time: 25 minutes

28.2.3 3. DTLS Security Architecture

Transport Review: DTLS Security

  • DTLS architecture for securing UDP-based IoT communication
  • DTLS handshake process and overhead
  • Cookie-based DoS protection for constrained devices
  • Session resumption for battery savings (68% reduction)

Estimated Time: 20 minutes

28.2.4 4. Knowledge Check

Transport Review: Knowledge Check

  • Understanding checks for battery life impact and protocol selection
  • Quiz questions on TCP vs UDP overhead
  • DTLS handshake and session resumption questions
  • Comprehensive review scenarios for protocol matching

Estimated Time: 45 minutes

Total Estimated Time: 2 hours across all four sub-chapters.

28.3 Quick Reference

Protocol Header Reliability Best For
UDP 8 bytes Best effort Real-time, telemetry
TCP 20–60 bytes Guaranteed Firmware, critical data
DTLS/UDP 8 + 13 bytes Secured UDP Secure CoAP

DTLS record overhead: 13-byte DTLS header + 8-byte UDP header + 20-byte IP header = 41 bytes total transport overhead (excluding cipher-specific IV/MAC which adds 16–32 bytes depending on cipher suite).

For a sensor sending 10-byte payloads every 60 seconds over a lossy cellular link (15% packet loss), compare UDP vs TCP energy consumption.

UDP transmission cost: \[ \text{Packet size} = 10 \text{ (payload)} + 8 \text{ (UDP)} + 20 \text{ (IP)} = 38 \text{ bytes} \]

With 15% loss and application-layer retries, expected transmissions per message: \[ \text{TX}_{\text{avg}} = \frac{1}{1 - 0.15} \approx 1.18 \text{ transmissions} \]

TCP transmission cost (full connection lifecycle): \[ \text{Handshake} = 3 \times 40 = 120 \text{ bytes (SYN, SYN-ACK, ACK; each = 20 IP + 20 TCP)} \] \[ \text{Data + ACK} = 50 + 40 = 90 \text{ bytes (data: 20+20+10; ACK: 20+20)} \] \[ \text{Teardown} = 3 \times 40 = 120 \text{ bytes (FIN, FIN-ACK, ACK — 3-way close)} \] \[ \text{Total} = 120 + 90 + 120 = 330 \text{ bytes per message} \]

Radio-on time per message (RF bit-time at 1 Mbps, 200 mA TX current):

\[ t_{\text{UDP}} = \frac{38 \times 1.18 \times 8}{10^6} = 0.359 \text{ ms (RF bit-time)} \] \[ t_{\text{TCP}} = \frac{330 \times 8}{10^6} = 2.64 \text{ ms (RF bit-time)} \]

For cellular links (NB-IoT / LTE-M), the total radio-on time includes channel acquisition and protocol setup, scaling the bit-time by a cellular overhead factor (~1000× for small payloads). Effective radio-on times are approximately 360 ms (UDP) and 2,640 ms (TCP). Converting to energy at 200 mA:

\[ E_{\text{UDP}} = 200 \text{ mA} \times \frac{0.360 \text{ s}}{3600 \text{ s/h}} \approx 0.0200 \text{ mAh/reading} \] \[ E_{\text{TCP}} = 200 \text{ mA} \times \frac{2.64 \text{ s}}{3600 \text{ s/h}} \approx 0.147 \text{ mAh/reading} \]

Daily energy (1,440 readings/day):

UDP: \(1{,}440 \times 0.0200 = 28.8 \text{ mAh/day}\)

TCP: \(1{,}440 \times 0.147 = 211.7 \text{ mAh/day}\)

Battery life with 2000 mAh:

UDP: \(2000 / 28.8 = 69.4 \text{ days}\), TCP: \(2000 / 211.7 = 9.4 \text{ days}\)

TCP uses ~7.4× more energy due to connection overhead dominating for small, infrequent payloads.

Try It: Protocol Energy Comparison Calculator

Adjust the parameters to see how protocol choice and link conditions affect battery life.

The Reality: TCP can actually be less reliable than UDP for battery-powered IoT devices. TCP’s extra energy cost causes sensors to die early, making them 100% unreliable (no data at all).

Real-World Example: Copenhagen parking sensors switched from TCP to UDP, improving battery life from 8.3 months to 41 months (5× improvement) and reducing battery replacement costs by 82%.

Key Insight: For battery-powered IoT, operational reliability (device stays alive) matters more than packet reliability (every packet arrives).

See Protocol Selection for the full analysis.

Use this decision matrix to systematically select the right transport protocol for your IoT application by evaluating four key factors.

Step 1: Data Loss Tolerance

Question Answer Protocol Direction
Can you tolerate occasional missing readings? YES → Consider UDP
Must every byte arrive correctly? NO → Require TCP

Examples:

  • Temperature reading every 5 minutes: YES (next reading replaces old) → UDP candidate
  • Firmware update: NO (one bad byte bricks device) → TCP required
  • Credit card transaction: NO (financial accuracy critical) → TCP required
  • Video stream frame: YES (one dropped frame barely noticeable) → UDP candidate

Step 2: Latency Requirements (if UDP is candidate)

Question Answer Protocol Direction
Is real-time response critical (<100ms)? YES → Strong UDP
Is latency tolerance >1 second? YES → Consider TCP

Examples:

  • Industrial valve control: YES (immediate response needed) → Strong UDP
  • Environmental monitoring: NO (5-minute intervals acceptable) → Either protocol viable
  • Smart door lock: YES (<200ms response expected) → UDP with app-layer ACK

Step 3: Battery Constraints (if either protocol viable)

Question Answer Protocol Direction
Battery-powered with multi-year target? YES → UDP strongly preferred
Mains-powered or frequent charging? YES → TCP acceptable

Examples:

  • Parking sensor (5-year battery target): YES → UDP (TCP drains battery 4-8× faster)
  • Smart thermostat (mains-powered): NO → TCP acceptable
  • Wearable (daily charging): NO → TCP acceptable

Step 4: Security Requirements

Question Answer Protocol Impact
Requires encryption? YES + UDP → Add DTLS (+37–45 bytes record overhead: 13 header + 8–16 IV + 16 MAC)
Requires encryption? YES + TCP → Add TLS (+29–45 bytes record overhead: 5 header + 8–16 IV + 16 MAC)
No security needs? YES → Use base protocol

Decision Matrix Summary:

Scenario Loss Tolerance Latency Battery Security Protocol
Sensor telemetry High (periodic) >1s Years Optional UDP or UDP+DTLS
Firmware update Zero >10s N/A Required TCP+TLS
Smart lock command Zero <200ms Years Required UDP+DTLS+CoAP
Video surveillance High (frames) <100ms N/A Required UDP+DTLS
Financial transaction Zero >1s N/A Required TCP+TLS
Voice call Medium (packets) <150ms N/A Required UDP+DTLS
Configuration change Zero >5s N/A Required TCP+TLS

Special Cases:

Case 1: Periodic Telemetry with Occasional Critical Alerts

  • Solution: Use UDP for routine readings (99% of traffic), UDP+CoAP Confirmable for critical alerts (1% of traffic)
  • Benefit: 8× battery savings vs. using TCP for everything, while ensuring critical messages are acknowledged

Case 2: Large File Transfer on Battery Device

  • Solution: Use TCP despite battery cost — firmware integrity matters more than battery life
  • Mitigation: Transfer only during charging periods, or compress data to minimize radio-on time

Case 3: Real-Time Control with Zero Loss Tolerance

  • Solution: Use UDP+CoAP Confirmable with aggressive retries (timeout 100ms, max 3 retries)
  • Benefit: <500ms total latency including retries, while guaranteeing delivery

Verification Checklist:

Before finalizing your protocol choice, verify: - [ ] Measured actual packet loss rate in deployment environment - [ ] Calculated battery impact with real transmission frequency - [ ] Confirmed NAT/firewall traversal for chosen protocol - [ ] Tested protocol behavior under network congestion - [ ] Validated end-to-end latency under worst-case conditions

Common Anti-Patterns to Avoid:

  • Using TCP because “it’s more reliable” without measuring battery impact
  • Using UDP for firmware updates to “save overhead”
  • Keeping persistent TCP connections to battery devices
  • Setting keep-alive intervals longer than NAT timeouts
  • Disabling UDP checksums to “save 2 bytes”
Try It: Protocol Selector

Answer four questions about your IoT application to get a protocol recommendation.

28.4 Knowledge Check

28.5 Concept Relationships

Prerequisites:

Consolidates Knowledge From:

Deep Dives:

Enables:

Related Concepts:

  • Quality of Service (QoS) builds on transport reliability
  • Network topology affects protocol choice (star vs mesh)
  • Security requirements influence DTLS vs TLS selection
  • Power Management: Battery life optimization techniques

Common Pitfalls

Choosing “TCP because it’s reliable” or “UDP because it’s fast” without systematic analysis leads to architectural debt. A CoAP-over-UDP system retrofit with TCP when reliability requirements emerge requires redesigning the entire message flow. Analyze transport requirements at design time: measure expected data volume, characterize reliability needs (which messages can be lost?), determine acceptable latency, and evaluate device constraints before selecting transport. Document the decision rationale for future architects.

TCP provides backpressure via window size (receiver can stop sender by setting window to 0); UDP has no backpressure. IoT pipelines using UDP without application-level rate limiting will overflow server receive buffers during bursts. Implement application-level flow control for UDP-based protocols: use MQTT broker QoS + inflight window limits, CoAP block-wise transfer for large data, or implement a token bucket rate limiter at the device to cap transmission rate.

Adding TCP (reliable) + MQTT QoS 1 (at-least-once) creates double reliability overhead: messages are retransmitted at both the TCP and MQTT layers, creating duplicate delivery risk. If MQTT broker loses TCP connection after receiving PUBLISH but before sending PUBACK, the client will retransmit — but the broker already has the message. Use QoS 0 over TCP (let TCP handle reliability), or use QoS 1 over TCP with broker deduplication by message ID, but avoid layering multiple reliability mechanisms unnecessarily.

TCP delivers bytes in order, but application-level messages may still arrive in an unexpected order when: multiple parallel TCP connections are used, messages are generated by different threads with different submission times, or a message pipeline reorders messages for load balancing. Application logic that requires strict ordering must implement its own message sequence numbers, independent of TCP’s byte-stream ordering.

28.6 What’s Next

After completing this review, apply your transport knowledge in these related areas:

Next Chapter Topic Why It Follows
Network Topologies Star, mesh, and tree network structures Transport protocol choice interacts with topology: mesh networks amplify UDP multicast advantages; star topologies suit persistent TCP connections
MQTT Protocol Publish-subscribe messaging over TCP MQTT runs on TCP and uses QoS 0/1/2 to layer reliability above the transport; understanding TCP trade-offs explains why MQTT QoS 2 is expensive
CoAP Protocol RESTful communication over UDP CoAP is UDP’s primary IoT application protocol; Confirmable vs Non-confirmable messages map directly to the reliability trade-offs covered here
DTLS Handshake DTLS session establishment in detail Deep-dive into the cookie exchange, certificate validation, and session resumption steps summarised in this review
Transport Optimizations IoT-specific TCP and UDP tuning Apply the overhead principles from this review: TCP keepalive tuning, UDP application-layer retry design, and NB-IoT cellular optimizations
Application Protocol Selection Choosing MQTT vs CoAP vs HTTP Transport choice cascades into application protocol selection; the framework here extends the decision matrix to the full protocol stack