729 TCP vs UDP: Comparison and Selection
729.1 Engineering Tradeoffs
Option A: TCP - Guaranteed delivery via acknowledgments and retransmission, ordered packet delivery, flow/congestion control. Cost: 20-60 byte header, 3-way handshake overhead, 8x more battery drain for small payloads
Option B: UDP - Minimal 8-byte header, no connection state, immediate transmission, 78% less overhead for small payloads. Cost: No delivery guarantees, no ordering, application must handle reliability if needed
Decision factors: Use TCP when data loss is catastrophic (firmware updates, financial transactions, configuration). Use UDP when data is replaceable (periodic sensor readings where next value arrives soon), real-time delivery matters more than completeness (video streaming), or battery life is critical. Consider CoAP over UDP for selective reliability without full TCP overhead.
Option A: Persistent TCP Connections - Keep-alive maintains connection state, reduces handshake latency for subsequent messages, enables bidirectional push notifications. Cost: Memory for connection state (4KB per connection), keep-alive battery drain (2-10% overhead), gateway scalability limits
Option B: Connectionless UDP Messages - No state maintained between transmissions, each message independent, scales to unlimited devices. Cost: No push notifications without polling, must re-establish context per message, no automatic retry
Decision factors: Use persistent connections for devices requiring bidirectional communication (thermostats receiving commands) or high-frequency data streams. Use connectionless for battery-powered sensors sending periodic telemetry, especially at intervals >1 minute where connection overhead exceeds data overhead. Gateway with 10,000 persistent TCP connections needs 40MB+ RAM just for state.
Option A: Transport-Layer Reliability (TCP) - Automatic retransmission of all lost packets, in-order delivery guaranteed, transparent to application. Cost: Head-of-line blocking delays fresh data behind lost packets, blind retry of stale data, overkill for replaceable telemetry
Option B: Application-Layer Reliability (CoAP CON over UDP) - Selective reliability per message, exponential backoff retries, application decides what matters. Cost: Must implement retry logic, message IDs for deduplication, more complex application code
Decision factors: TCP works best for bulk transfers (firmware) where every byte matters equally. Application-layer reliability (CoAP Confirmable) works best for IoT telemetry where some messages are critical (alarms) and others expendable (routine readings). In lossy networks (10%+ packet loss), application-layer selective retry often achieves better practical reliability than TCP’s head-of-line blocking.
Scenario: A soil moisture sensor in a smart agriculture deployment sends 50-byte readings every 15 minutes. The sensor runs on a 2000 mAh battery at 3.3V. Calculate how protocol choice affects battery life.
Given: - Payload size: 50 bytes - Transmission interval: 15 minutes (96 times/day) - Battery capacity: 2000 mAh at 3.3V - Radio TX current: 120 mA (typical for Wi-Fi module) - Radio RX current: 80 mA - Sleep current: 10 uA - Transmission rate: 1 Mbps
Step 1: Calculate UDP overhead per transmission
UDP packet structure:
- IP header: 20 bytes
- UDP header: 8 bytes
- Payload: 50 bytes
- Total: 78 bytes = 624 bits
Transmission time: 624 bits / 1 Mbps = 0.624 ms
Energy per TX: 120 mA × 0.624 ms = 0.075 mAs
Daily energy (UDP):
- 96 transmissions × 0.075 mAs = 7.2 mAs/dayStep 2: Calculate TCP overhead per transmission
TCP per-message exchange:
1. SYN: 40 bytes (IP + TCP header)
2. SYN-ACK: 40 bytes (receive)
3. ACK: 40 bytes (send)
4. DATA: 70 bytes (IP + TCP header + payload)
5. DATA-ACK: 40 bytes (receive)
6. FIN: 40 bytes (send)
7. FIN-ACK: 40 bytes (receive)
Total TX: 40 + 40 + 70 + 40 = 190 bytes = 1520 bits
Total RX: 40 + 40 + 40 = 120 bytes = 960 bits
TX time: 1520 bits / 1 Mbps = 1.52 ms
RX time: 960 bits / 1 Mbps = 0.96 ms
Energy per exchange:
- TX: 120 mA × 1.52 ms = 0.182 mAs
- RX: 80 mA × 0.96 ms = 0.077 mAs
- Total: 0.259 mAs per transmission
Daily energy (TCP):
- 96 transmissions × 0.259 mAs = 24.9 mAs/dayStep 3: Calculate battery life comparison
Sleep energy (both protocols):
- 23.9 hours/day in sleep (accounting for TX time)
- 10 uA × 23.9 hours = 0.239 mAh/day = 239 mAs/day
UDP total daily consumption:
- TX energy: 7.2 mAs = 0.002 mAh
- Sleep: 239 mAs = 0.066 mAh
- Total: 0.068 mAh/day
- Battery life: 2000 mAh / 0.068 mAh/day = 29,412 days = 80.6 years
TCP total daily consumption:
- TX/RX energy: 24.9 mAs = 0.007 mAh
- Sleep: 239 mAs = 0.066 mAh
- Total: 0.073 mAh/day
- Battery life: 2000 mAh / 0.073 mAh/day = 27,397 days = 75.1 yearsStep 4: Factor in real-world overhead (retransmissions, keep-alives)
With 5% packet loss requiring retransmission:
- UDP + CoAP CON: 1.05x overhead = 0.071 mAh/day -> 77.2 years
- TCP: 1.15x overhead (head-of-line blocking) = 0.084 mAh/day -> 65.3 years
With TCP keep-alive every 30 minutes (if connection persisted):
- 48 keep-alives/day × 40 bytes = additional 0.003 mAh/day
- New TCP total: 0.087 mAh/day -> 63.0 yearsResult:
| Protocol | Daily Energy | Battery Life | Difference |
|---|---|---|---|
| UDP (ideal) | 0.068 mAh | 80.6 years | Baseline |
| TCP (ideal) | 0.073 mAh | 75.1 years | -7% |
| UDP + CoAP (5% loss) | 0.071 mAh | 77.2 years | -4% |
| TCP (5% loss + keepalive) | 0.087 mAh | 63.0 years | -22% |
Key Insight: While theoretical differences seem small, real-world conditions amplify the gap. TCP’s handshake overhead, retransmission behavior, and keep-alive requirements combine to reduce battery life by 22% compared to UDP with application-layer reliability. For deployments with thousands of sensors, this difference translates to significant maintenance cost savings. The calculation also reveals that sleep current dominates consumption - optimizing wake time is more impactful than protocol choice for very low duty-cycle sensors.
729.2 Common Pitfalls
The Mistake: Developers deploy MQTT or HTTP connections with default TCP keep-alive settings (typically 2 hours on Linux, 7200 seconds), assuming the OS handles connection maintenance appropriately for IoT devices.
Why It Happens: TCP keep-alive is often configured at the OS level, not the application level. Developers focus on application logic and assume “keep-alive” means the connection stays alive automatically. They don’t realize the default 2-hour interval is designed for desktop computers, not battery-powered sensors or NAT-traversing IoT devices.
The Fix: Configure keep-alive intervals based on your deployment constraints:
- NAT timeout avoidance: Set keep-alive to 30-60 seconds (most consumer NATs timeout idle connections at 60-300 seconds)
- Battery-powered devices: Set keep-alive to 5-15 minutes and accept occasional reconnections, or use UDP-based protocols instead
- Cellular IoT: Set keep-alive to 25-28 seconds (many carrier NATs timeout at 30 seconds)
// Linux: Set TCP keep-alive to 60 seconds
int keepalive = 1;
int keepidle = 60; // Start probes after 60s idle (not 7200s)
int keepintvl = 10; // Probe every 10s (not 75s)
int keepcnt = 3; // 3 failed probes = dead (not 9)
setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive));
setsockopt(sock, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle));
setsockopt(sock, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl));
setsockopt(sock, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));Impact: With default 2-hour keep-alive, NAT-traversing IoT connections silently die within minutes. Users report “random disconnections” that are actually predictable NAT timeout failures. Proper configuration (60s keep-alive) adds only ~1,440 small packets/day but maintains reliable connectivity.
The Mistake: Developers send large UDP datagrams (500-1500 bytes) without considering the path MTU, causing IP fragmentation that dramatically increases packet loss rates on lossy wireless networks.
Why It Happens: On wired Ethernet, the 1500-byte MTU rarely causes problems. Developers test on Wi-Fi (also 1500 MTU at IP layer) and assume it works everywhere. They don’t realize that 6LoWPAN has 127-byte frames, LoRaWAN has 51-222 byte limits, and LTE-M/NB-IoT have varying MTUs. When a packet exceeds the path MTU, IP fragmentation occurs silently.
The Fix: Design payloads to fit within the smallest expected MTU on your network path:
| Network Type | IP MTU | Safe Payload (UDP) | Safe Payload (TCP) |
|---|---|---|---|
| Ethernet/Wi-Fi | 1500 bytes | 1472 bytes | 1460 bytes |
| 6LoWPAN (uncompressed) | 1280 bytes | 1252 bytes | 1240 bytes |
| 6LoWPAN (compressed) | ~100-200 bytes | ~80-180 bytes | ~60-160 bytes |
| LoRaWAN SF7 | 222 bytes | 214 bytes | 202 bytes |
| LoRaWAN SF12 | 51 bytes | 43 bytes | 31 bytes |
| NB-IoT | ~1358 bytes | 1330 bytes | 1318 bytes |
Fragmentation math: A single 1000-byte UDP packet over 6LoWPAN (127-byte frames) requires 8+ fragments. With 5% per-frame loss rate, delivery probability drops to (0.95)^8 = 66%. The same data sent as 8 independent 125-byte packets with application-level ACKs achieves 95%+ delivery because each packet can be individually retransmitted.
Best practice: For constrained networks, keep UDP payloads under 100 bytes when possible. Use CoAP block-wise transfer for larger data, which handles fragmentation at the application layer with proper retransmission per block.
729.3 Summary
- Transport layer protocols provide end-to-end communication between IoT applications - primarily using UDP, TCP, and DTLS
- UDP advantages include 8-byte minimal header, connectionless operation, low power consumption, and support for multicast - ideal for periodic sensor telemetry
- TCP advantages include guaranteed delivery, ordered transmission, flow control, and congestion control - essential for firmware updates and critical data
- Protocol selection depends on reliability needs, latency requirements, power constraints, and whether data loss is acceptable
- UDP checksum is mandatory in IPv6 and critical for detecting bit errors from radio interference in unreliable wireless IoT networks
- TCP overhead includes 20-60 byte headers, connection state management, and 3-way handshake - significant energy cost for battery-powered devices
- Application-layer reliability can be added to UDP through protocols like CoAP Confirmable messages, providing efficiency with selective reliability
729.3.1 Protocol Selection Quick Reference
| Scenario | Protocol | Reasoning | Battery Impact |
|---|---|---|---|
| Temperature sensor (every 5 min) | UDP | Next reading arrives soon, loss tolerable | 45+ years |
| Firmware update (500 KB) | TCP+TLS | Must be 100% reliable and secure | Acceptable (infrequent) |
| Smart lock (command) | UDP+DTLS+CoAP CON | Security critical, low latency | 20+ years |
| Video stream (1080p) | UDP+RTP | Real-time matters more than perfection | N/A (mains) |
| Health alert (critical) | TCP+TLS | Cannot lose alarm data | Acceptable (rare) |
Decision Framework:
1. Is data loss catastrophic? → YES: TCP
2. Is transmission frequent (>1/min)? → YES: UDP
3. Is security required? → YES: Add DTLS/TLS
4. Is latency critical (<100ms)? → YES: UDP
5. Is device battery-powered? → YES: Prefer UDPKey Metrics (10-byte payload, every 10 seconds): - UDP: 24 bytes, 1.3ms radio, 45-year battery - TCP: 244 bytes, 13.3ms radio, 8-year battery - DTLS: 53 bytes, 2.8ms radio, 22-year battery
Transport Deep Dives: - Transport Protocols - TCP/UDP details - Transport Review - Complete reference - DTLS Security - Secure transport
Application Protocols: - MQTT - Over TCP - CoAP - Over UDP
Fundamentals: - Packet Structure - Frame formats - Layered Models - Protocol layers
Learning Hubs: - Quiz Navigator - Transport quizzes
729.4 Key Takeaways
Core Concepts: - Transport protocols provide end-to-end communication between applications: UDP (connectionless, 8-byte header) vs TCP (connection-oriented, 20-60 byte header) - UDP offers minimal overhead and low power consumption but provides no delivery guarantees, ordering, or flow control - TCP ensures reliable, ordered delivery through acknowledgments and retransmissions but requires 3-way handshake and connection state - DTLS (Datagram TLS) adds security to UDP while maintaining its low-overhead characteristics for IoT applications
Practical Applications: - Use UDP for periodic sensor telemetry where fresh data replaces old (temperature readings every 60 seconds, video streaming) - Use TCP for critical operations requiring reliability (firmware updates, configuration changes, smart lock commands) - CoAP adds application-layer reliability to UDP through Confirmable messages without TCP’s connection overhead - Hybrid approach: UDP for routine telemetry, TCP for critical operations in the same IoT system
Design Considerations: - UDP checksum is mandatory in IPv6 and critical for detecting bit errors from radio interference in wireless IoT networks - TCP persistent connections drain batteries through keep-alive packets (2-10% battery overhead) and connection state maintenance - For small payloads, UDP’s 8-byte header vs TCP’s 20-byte represents 40% overhead savings on 20-byte sensor readings - Application-level reliability on UDP (CoAP CON messages) balances efficiency with selective reliability better than full TCP
Common Pitfalls: - Choosing TCP for periodic telemetry with acceptable loss (wastes energy on connection overhead for replaceable data) - Assuming UDP always means unreliable (CoAP Confirmable messages add reliability with exponential backoff retransmission) - Maintaining persistent TCP connections for thousands of IoT devices (gateway memory exhaustion, keep-alive battery drain) - Using TCP for real-time applications where retransmission delays cause head-of-line blocking (video, voice)