%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22'}}}%%
stateDiagram-v2
[*] --> CLOSED
CLOSED --> SYN_SENT: send SYN
SYN_SENT --> ESTABLISHED: recv SYN-ACK,<br/>send ACK
ESTABLISHED --> FIN_WAIT_1: send FIN
FIN_WAIT_1 --> FIN_WAIT_2: recv ACK
FIN_WAIT_2 --> TIME_WAIT: recv FIN,<br/>send ACK
TIME_WAIT --> CLOSED: timeout
note right of ESTABLISHED: Data transfer<br/>occurs here
note right of TIME_WAIT: Wait 2×MSL<br/>(60-120 sec)
730 Transport Protocols: Fundamentals
730.1 Transport Layer Protocols for IoT
By the end of this section, you will be able to:
- Understand the role of transport layer protocols in IoT
- Compare TCP and UDP characteristics and use cases
- Explain why UDP is preferred for many IoT applications
- Understand DTLS (Datagram Transport Layer Security) for securing UDP
- Analyze trade-offs between reliability, overhead, and power consumption
- Select appropriate transport protocol for different IoT scenarios
- Understand TCP optimization techniques for constrained networks
730.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- Layered Network Models: Understanding the OSI and TCP/IP models is crucial since transport protocols operate at Layer 4, bridging application-layer protocols with network-layer routing
- Networking Basics: Knowledge of packets, headers, ports, and basic network communication provides the foundation for understanding how TCP and UDP manage end-to-end data delivery
- Basic IoT constraints: Familiarity with power consumption, bandwidth limitations, and reliability requirements of battery-powered sensors helps you appreciate why protocol selection matters for IoT deployments
730.3 🌱 Getting Started (For Beginners)
Analogy: Transport protocols are like different shipping services for your packages. Just as you choose between FedEx (fast, tracked, guaranteed delivery) or regular mail (cheaper, no tracking, might get lost), you choose between TCP and UDP based on your needs.
The two main options: - TCP = FedEx with signature required (reliable but slower, more overhead) - UDP = Dropping a postcard in the mail (fast but no guarantee it arrives)
Core Concept: TCP guarantees ordered, reliable delivery through connection setup, acknowledgments, and retransmissions (20-byte header overhead), while UDP provides best-effort delivery with no guarantees but minimal overhead (8-byte header) and no connection state. Why It Matters: A battery-powered sensor sending temperature every 5 minutes wastes 8x more energy with TCP (SYN, SYN-ACK, ACK, DATA, ACK, FIN, FIN-ACK) versus UDP (single packet). Missing one reading is acceptable; draining the battery in weeks instead of years is not. Key Takeaway: Use UDP for periodic sensor telemetry, real-time video/audio, and any scenario where occasional packet loss is acceptable. Use TCP only when you need guaranteed delivery (firmware updates, commands, financial transactions) and can afford the power and latency cost.
730.3.1 TCP vs UDP: The Fundamental Choice
TCP (Transmission Control Protocol):
This variant shows TCP connection states and transitions, helping you understand why TCP has more overhead:
Each state requires memory and CPU cycles to maintain, which is why constrained IoT devices often prefer stateless UDP.
UDP (User Datagram Protocol):
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
graph LR
C2[Client] -->|Send Datagram| S2[Server]
C2 -->|Send Datagram| S2
C2 -->|Send Datagram| S2
S2 -.->|No ACK| C2
style C2 fill:#16A085,stroke:#2C3E50,color:#fff
style S2 fill:#16A085,stroke:#2C3E50,color:#fff
730.3.2 Real-World Analogy: Phone Call vs Text Message
| TCP (Like a Phone Call) | UDP (Like Text Messages) |
|---|---|
| Connection must be established first | Just send it! |
| You know they’re listening | Hope they check their phone |
| Back-and-forth conversation | Fire and forget |
| Know immediately if disconnected | No idea if received |
| Best for: Banking, file transfers | Best for: Video streaming, games |
730.3.3 Why IoT Often Prefers UDP
IoT Sensor Scenario: Temperature Sensor (Battery Powered)
Sends reading every 5 minutes
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
sequenceDiagram
participant S as Sensor
participant G as Gateway
Note over S,G: UDP Approach (Low Power)
S->>G: Temp: 22°C
Note over S: 1 packet sent<br/>Sleep 5 min
S->>G: Temp: 22°C
Note over S: 1 packet sent<br/>Sleep 5 min
Note over S,G: TCP Approach (High Power)
S->>G: SYN
G->>S: SYN-ACK
S->>G: ACK
Note over S: 3 packets for setup
S->>G: Temp: 22°C
G->>S: ACK
S->>G: FIN
G->>S: FIN-ACK
Note over S: 8 packets total!<br/>8× power consumption
For small, frequent sensor readings: “If one reading is lost, the next one comes in 5 minutes anyway!”
730.3.4 Which Protocol for Which IoT Application?
| Application | Best Choice | Why |
|---|---|---|
| Temperature sensor readings | UDP | Small data, frequent updates, loss is acceptable |
| Firmware updates | TCP | Must arrive complete and correct |
| Video doorbell stream | UDP | Real-time matters more than perfection |
| Smart lock commands | TCP | Security-critical, must be reliable |
| Health monitor alerts | TCP | Critical data, cannot be lost |
730.3.5 🧪 Quick Self-Check
Before continuing, make sure you understand:
- What’s the main difference between TCP and UDP? → TCP guarantees delivery; UDP doesn’t
- Why does TCP use more battery? → It requires multiple back-and-forth messages
- When is losing data acceptable? → When fresh data comes frequently (sensor readings, video frames)
- What does “connectionless” mean? → UDP doesn’t establish a connection first; it just sends
The Myth: Many developers believe TCP’s reliability mechanisms make it universally superior to UDP for any IoT application requiring data delivery.
The Reality: While TCP guarantees transport-level delivery, it can actually reduce end-to-end reliability in high-loss networks through head-of-line blocking. Consider this quantified real-world scenario:
Smart Agriculture Sensor Network (10% packet loss):
UDP with Application-Level Retry (CoAP Confirmable):
- Send reading at T=0s
- Lost? Retry at T=2s, T=4s, T=8s (exponential backoff)
- 90% succeed on first try (0s latency)
- 9% succeed on second try (2s latency)
- 0.9% succeed on third try (4s latency)
- Average latency: 0.29s
- Data freshness: EXCELLENT
TCP with Automatic Retry:
- Send reading at T=0s (after 3-way handshake overhead)
- Packet 1 lost → retransmit after 200ms timeout
- Packet 2 lost → retransmit after 400ms timeout
- Packet 3 arrives but blocked behind Packet 1
- Packet 4 arrives but blocked behind Packet 1
- Average latency: 2-5s (head-of-line blocking)
- Data freshness: POOR (4 readings waiting behind 1 lost packet)
Measured Impact on 500-Sensor Deployment:
- UDP + CoAP: 98.7% delivery rate, 0.3s average latency, fresh data
- TCP: 99.2% delivery rate, 3.8s average latency, stale data bursts
- Result: TCP’s 0.5% reliability advantage is negated by 12× higher latency making data less actionable
The Lesson: For periodic IoT telemetry, application-level selective retry (CoAP Confirmable) provides better practical reliability than TCP’s blind retry-everything approach. TCP’s reliability is only superior when every byte matters (firmware updates, configuration) and latency doesn’t (bulk transfers).
Transport protocols are like choosing between sending a careful letter or tossing a paper airplane - both can deliver messages, but in very different ways!
730.3.6 The Sensor Squad Adventure: The Two Messenger Services
Sammy the Sensor had exciting news to share with the Cloud Computer across town: “Today’s temperature is 72 degrees!” But there were two ways to send the message.
“I’ll use TCP Turtle Express!” said Sammy. TCP Turtle was VERY careful. First, he knocked on the Cloud’s door: “Hello? Are you ready to receive?” The Cloud answered, “Yes, I’m ready!” Then TCP Turtle delivered the message, waited for the Cloud to say “Got it!”, and only THEN walked home. If the Cloud DIDN’T say “Got it,” TCP Turtle would try again and again until it worked.
Bella the Battery groaned. “That took SO long and used SO much of my energy with all that back-and-forth!”
Max the Microcontroller suggested another way: “Let’s try UDP Unicorn Express!” UDP Unicorn was SUPER fast. She grabbed Sammy’s message, galloped across town, tossed it toward the Cloud, and zoomed back home - all in seconds! She didn’t wait to see if the Cloud caught it.
“But what if the Cloud missed it?” worried Lila the LED.
“Then Sammy sends another temperature reading in five minutes anyway!” explained Max. “For simple sensor updates, it doesn’t matter if ONE message gets lost. UDP Unicorn saves so much energy that Bella can last for YEARS!”
The team decided: Important messages (like “UNLOCK THE DOOR!”) go with careful TCP Turtle. Regular updates (like temperature) go with speedy UDP Unicorn. Everyone wins!
730.3.7 Key Words for Kids
| Word | What It Means |
|---|---|
| TCP | Careful delivery that checks if your message arrived safely (slower but reliable) |
| UDP | Fast delivery that sends quickly but doesn’t check if it arrived (faster but might miss) |
| Acknowledgment | A “Got it!” reply that confirms a message was received |
| Packet | A small bundle of data sent over the network (like a digital envelope) |
| Retransmit | Sending the same message again because the first one got lost |
| Overhead | Extra work and energy needed beyond just sending the message |
730.3.8 Try This at Home!
The Two Delivery Services Game:
Set up two ways to send messages across your room:
TCP Style (Careful Delivery): 1. Sender says: “Ready to receive?” and waits for “Yes!” 2. Sender reads the message aloud 3. Receiver says: “Got it!” (or “Say again?” if they missed it) 4. Sender only sits down after hearing “Got it!”
UDP Style (Fast Delivery): 1. Sender simply reads the message once - fast! 2. Receiver tries to catch it (no replies allowed!) 3. Sender sits down immediately
Compare: - Which method is FASTER? (UDP!) - Which method makes SURE the message arrives? (TCP!) - If you send 10 messages per minute, does missing ONE matter much? (Not really - like a sensor!)
What you learned: - TCP is like a phone call (back-and-forth conversation) - UDP is like shouting across a playground (fast but maybe missed) - For sensors sending frequent updates, speed often beats perfect reliability!
730.4 Introduction to Transport Layer Protocols
The transport layer (Layer 4 in OSI model) provides end-to-end communication between applications. While not IoT-specific, transport protocols are crucial for IoT applications.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
graph TB
subgraph "Application Layer"
A1[MQTT]
A2[CoAP]
A3[HTTP]
end
subgraph "Transport Layer (Layer 4)"
T1[TCP<br/>Connection-Oriented<br/>Reliable]
T2[UDP<br/>Connectionless<br/>Best-Effort]
T3[DTLS<br/>Secure UDP]
end
subgraph "Network Layer"
N1[IP<br/>Routing]
end
A1 --> T1
A2 --> T2
A3 --> T1
A2 -.-> T3
T1 --> N1
T2 --> N1
T3 --> N1
style A1 fill:#E67E22,stroke:#16A085,color:#fff
style A2 fill:#E67E22,stroke:#16A085,color:#fff
style A3 fill:#E67E22,stroke:#16A085,color:#fff
style T1 fill:#2C3E50,stroke:#16A085,color:#fff
style T2 fill:#16A085,stroke:#2C3E50,color:#fff
style T3 fill:#16A085,stroke:#2C3E50,color:#fff
style N1 fill:#95a5a6,stroke:#2C3E50,color:#fff
This variant shows when to choose each transport protocol based on IoT application requirements:
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TD
START["IoT Application<br/>Requirements"] --> Q1{"Data must<br/>arrive?"}
Q1 -->|"Loss OK"| UDP_PATH["UDP Path"]
Q1 -->|"Must deliver"| Q2{"Security<br/>needed?"}
Q2 -->|"No"| TCP["TCP<br/>Reliable"]
Q2 -->|"Yes"| Q3{"Constrained<br/>device?"}
Q3 -->|"No"| TLS["TCP + TLS<br/>Standard secure"]
Q3 -->|"Yes"| DTLS["UDP + DTLS<br/>Lightweight secure"]
UDP_PATH --> Q4{"Security?"}
Q4 -->|"No"| UDP["Plain UDP<br/>Fastest"]
Q4 -->|"Yes"| DTLS
style START fill:#2C3E50,stroke:#16A085,color:#fff
style Q1 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q2 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q3 fill:#E67E22,stroke:#2C3E50,color:#fff
style Q4 fill:#E67E22,stroke:#2C3E50,color:#fff
style UDP fill:#16A085,stroke:#2C3E50,color:#fff
style TCP fill:#16A085,stroke:#2C3E50,color:#fff
style TLS fill:#16A085,stroke:#2C3E50,color:#fff
style DTLS fill:#16A085,stroke:#2C3E50,color:#fff
This decision tree helps you select the right transport protocol combination for your IoT deployment.
730.5 Videos
IoT applications primarily use three transport layer protocols:
- UDP (User Datagram Protocol): Connectionless, lightweight, no guarantees
- TCP (Transmission Control Protocol): Connection-oriented, reliable, higher overhead
- DTLS (Datagram Transport Layer Security): Secure UDP communication