%% fig-alt: UDP packet structure diagram showing IP Header (20 bytes), UDP Header (8 bytes), and Sensor Data (100 bytes) totaling 128 bytes
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
block-beta
columns 1
block:header:1
A["UDP Packet Structure"]
end
block:components:1
B["IP Header: 20 bytes"]
C["UDP Header: 8 bytes"]
D["Sensor Data: 100 bytes"]
end
block:total:1
E["TOTAL: 128 bytes"]
end
style A fill:#2C3E50,color:#fff
style B fill:#16A085,color:#fff
style C fill:#16A085,color:#fff
style D fill:#E67E22,color:#fff
style E fill:#2C3E50,color:#fff
739 Transport Protocols: Plain English Guide
739.1 Learning Objectives
By the end of this chapter, you will be able to:
- Explain TCP and UDP using everyday analogies that non-technical stakeholders can understand
- Calculate overhead differences between TCP and UDP for IoT sensor scenarios
- Analyze battery impact of transport protocol choices on constrained devices
- Determine when to use TCP vs UDP based on data characteristics and reliability requirements
739.2 In Plain English: Transport Protocols Explained
Think of transport protocols as different ways to send packages, but for data instead of physical items.
739.2.1 TCP: The Registered Mail Service
TCP is like sending a package via FedEx with signature confirmation:
- Before sending: You call the recipient - they answer - you confirm they’re ready (3-way handshake)
- During delivery: FedEx tracks every step, sends you updates, requires signature
- If something goes wrong: They try again, and again, until it arrives or you cancel
- After delivery: You get confirmation it was received and signed for
- Cost: Expensive (lots of steps, tracking, confirmation)
- Time: Takes longer (all the verification slows it down)
- Guarantee: You KNOW it arrived, in the right order, intact
Real-world TCP example: You’re updating your smart doorbell’s firmware. The file is 2 MB and contains critical code. If even one bit is wrong, your doorbell becomes a brick. TCP ensures every single byte arrives correctly, in order, with verification at every step.
739.2.2 UDP: The Paper Airplane Method
UDP is like throwing paper airplanes over a fence:
- No setup: Just throw it and hope it lands
- No tracking: You have no idea if it made it over the fence
- No order: If you throw 3 airplanes, they might land 2nd, 1st, 3rd
- No retries: If the wind blows one away, it’s gone forever
- Cost: Free (just the effort to throw)
- Time: Instant (no waiting for confirmation)
- Guarantee: None - but maybe you don’t care
Real-world UDP example: Your temperature sensor sends “72 degrees F” every 10 seconds. If one message gets lost, who cares? Another one is coming in 10 seconds anyway. No point wasting energy confirming the old temperature when fresh data is about to arrive.
739.2.3 The Perfect Analogy: Text Message vs Phone Call
| TCP (Phone Call) | UDP (Text Message) |
|---|---|
| Must establish connection first | Just send it |
| Know they picked up | Don’t know if they read it |
| Conversation flows both ways | One-way communication |
| Immediate feedback if disconnected | No feedback at all |
| “Can you hear me now?” | “Hope you got this!” |
| Takes more effort to setup | Fire and forget |
739.2.4 Why IoT Uses UDP So Much
Imagine you’re a battery-powered sensor in a field, miles from anywhere:
Scenario: Send temperature reading every hour
With TCP: 1. Wake up from sleep (uses battery) 2. Call the server: “Hey, are you there?” (uses battery) 3. Wait for response: “Yes, I’m here!” (uses battery while waiting) 4. Confirm: “OK, I’m sending data” (uses battery) 5. Send: “Temperature is 72 degrees F” (uses battery) 6. Wait for: “Got it, thanks!” (uses battery while waiting) 7. Say goodbye: “OK, hanging up” (uses battery) 8. Wait for: “Goodbye!” (uses battery while waiting) 9. Go back to sleep
With UDP: 1. Wake up from sleep (uses battery) 2. Shout: “TEMPERATURE IS 72 degrees F!” (uses battery) 3. Go back to sleep immediately
Result: UDP uses 1/8th the battery life for the same data!
739.2.5 When You MUST Use TCP (No Exceptions)
- Firmware updates: If even 1 byte is wrong, device is bricked
- Security keys: Encryption keys must be perfect or security fails
- Financial data: Can’t lose payment information
- Configuration commands: “Unlock door” message cannot be lost
- Medical alarms: Critical health alerts require guaranteed delivery
739.2.6 When UDP Is The Smart Choice
- Streaming video: Lost frame? Next one’s coming in 1/30th of a second
- Temperature readings: Fresh data replaces old automatically
- GPS location updates: Position changes constantly anyway
- Voice calls: Brief audio dropout better than delayed audio
- Gaming: Old player position irrelevant when new one arrives
The Golden Rule: If the next message makes the previous one irrelevant, use UDP. If every message matters forever, use TCP.
739.3 Real-World Example: The 100-Byte Sensor Reading
Let’s analyze a real IoT scenario with actual numbers to understand the overhead difference between TCP and UDP.
739.3.1 Scenario Setup
Device: Battery-powered soil moisture sensor Location: Agricultural field, Wi-Fi connection Data: Sends 100-byte sensor reading Frequency: Every 5 minutes Battery: 2000 mAh battery Transmission cost: 50 mA for 100 ms per packet
739.3.2 UDP Transmission Breakdown
Transmission Summary:
- Packets sent: 1
- Total bytes: 128 bytes
- Transmission time: 100 ms
- Battery consumed: 5 mAh (100 ms x 50 mA)
739.3.3 TCP Transmission Breakdown
%% fig-alt: TCP full connection diagram showing 8 packets including 3-way handshake (SYN, SYN-ACK, ACK), data transfer, and 4-way teardown (FIN, FIN-ACK, ACK), totaling 460 bytes
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
participant C as Client
participant S as Server
Note over C,S: TCP Full Connection (460 bytes total)
rect rgb(44, 62, 80)
Note over C,S: 3-Way Handshake
C->>S: Packet 1 - SYN (60 bytes)
Note right of C: IP: 20B + TCP: 40B
S->>C: Packet 2 - SYN-ACK (60 bytes)
Note right of S: IP: 20B + TCP: 40B
C->>S: Packet 3 - ACK (40 bytes)
Note right of C: IP: 20B + TCP: 20B
end
rect rgb(22, 160, 133)
Note over C,S: Data Transfer
C->>S: Packet 4 - DATA (140 bytes)
Note right of C: IP: 20B + TCP: 20B + Data: 100B
S->>C: Packet 5 - ACK (40 bytes)
Note right of S: IP: 20B + TCP: 20B
end
rect rgb(230, 126, 34)
Note over C,S: 4-Way Teardown
C->>S: Packet 6 - FIN (40 bytes)
Note right of C: IP: 20B + TCP: 20B
S->>C: Packet 7 - FIN-ACK (40 bytes)
Note right of S: IP: 20B + TCP: 20B
C->>S: Packet 8 - ACK (40 bytes)
Note right of C: IP: 20B + TCP: 20B
end
Transmission Summary:
- Packets sent: 8
- Total bytes: 460 bytes
- Transmission time: 800 ms (8 x 100ms)
- Battery consumed: 40 mAh (800 ms x 50 mA)
739.3.4 Side-by-Side Comparison
| Metric | UDP | TCP | Difference |
|---|---|---|---|
| Packets | 1 | 8 | 8x more |
| Total bytes | 128 | 460 | 3.6x more |
| Overhead bytes | 28 (22%) | 360 (78%) | 12.9x more |
| Data bytes | 100 (78%) | 100 (22%) | Same payload |
| Transmission time | 100 ms | 800 ms | 8x longer |
| Battery per message | 5 mAh | 40 mAh | 8x more |
739.3.5 Annual Battery Impact
Readings per year: 365 days x 24 hours x 12 per hour = 105,120 readings
| Protocol | Battery Usage | Battery Life | Lifespan |
|---|---|---|---|
| UDP | 105,120 x 5 mAh = 525,600 mAh | 2000 mAh battery | ~70 days |
| TCP | 105,120 x 40 mAh = 4,204,800 mAh | 2000 mAh battery | ~9 days |
Result: TCP drains the battery 7.8x faster than UDP for the same data!
739.3.6 Cost Analysis (1000 Sensors)
Assumptions: - Battery replacement cost: $5 per sensor (technician visit to field) - UDP battery life: 70 days (5.2 replacements/year) - TCP battery life: 9 days (40.6 replacements/year)
| Protocol | Replacements/Year | Labor Cost |
|---|---|---|
| UDP | 5,200 | $26,000 |
| TCP | 40,600 | $203,000 |
| Difference | 35,400 extra | $177,000 extra |
739.3.7 When TCP Overhead Is Worth It
Firmware update scenario: 500 KB file
| Protocol | Success Rate | Retransmission Cost | Total Cost |
|---|---|---|---|
| UDP | ~70% (2% loss x 500 KB) | Manual retry entire file | Fails often |
| TCP | ~99.9% | Automatic retry per packet | Succeeds reliably |
Verdict: For a 500 KB firmware update, TCP’s 460-byte overhead is trivial (0.09%) and the reliability is essential.
739.3.8 The Bottom Line
- For 100-byte periodic readings: UDP saves 78% battery, extends life 7.8x
- For 500 KB firmware updates: TCP overhead is 0.09%, reliability is priceless
- Hybrid approach: UDP for telemetry + TCP for firmware = best of both worlds
739.4 Summary
This chapter provided intuitive explanations of transport protocols through everyday analogies:
- TCP as registered mail: Reliable but expensive in terms of overhead and battery
- UDP as paper airplanes: Fast and lightweight but with no delivery guarantees
- Overhead analysis: TCP uses 8x more packets and 3.6x more bytes for the same payload
- Battery impact: TCP drains batteries 7.8x faster than UDP for periodic sensor readings
- Cost implications: A 1000-sensor deployment could save $177,000/year by using UDP for telemetry
- The golden rule: Use UDP when fresh data replaces old; use TCP when every byte matters
739.5 What’s Next
Continue learning about transport protocol selection:
- Real-World Scenarios and Common Mistakes: Learn from disaster scenarios and avoid the 7 most common transport protocol pitfalls
- Hands-On Transport Lab: Build a reliable message transport system on ESP32 with Wokwi simulation
- Transport Selection and Scenarios: Decision frameworks for IoT protocol selection