730  Transport Protocols: Fundamentals

730.1 Transport Layer Protocols for IoT

NoteLearning Objectives

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)

TipWhat are Transport Protocols? (Simple Explanation)

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)

TipMinimum Viable Understanding: TCP vs UDP Selection

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):

Graph diagram

Graph diagram
Figure 730.1: TCP connection lifecycle showing 3-way handshake (SYN, SYN-ACK, ACK), bidirectional data exchange with acknowledgments, and 2-way graceful connection termination (FIN, FIN-ACK).

This variant shows TCP connection states and transitions, helping you understand why TCP has more overhead:

%%{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)

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

Figure 730.2: UDP connectionless communication showing client sending three datagrams to server without handshake, acknowledgments, or connection state - fire-and-forget transmission.

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

Figure 730.3: Power consumption comparison for battery-powered temperature sensor sending readings every 5 minutes: UDP requires 1 packet per reading while TCP requires 8 packets (3-way handshake, data with ACK, and 4-way termination), resulting in 8× higher battery drain.

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:

  1. What’s the main difference between TCP and UDP? → TCP guarantees delivery; UDP doesn’t
  2. Why does TCP use more battery? → It requires multiple back-and-forth messages
  3. When is losing data acceptable? → When fresh data comes frequently (sensor readings, video frames)
  4. What does “connectionless” mean? → UDP doesn’t establish a connection first; it just sends

NoteCross-Hub Connections

Enhance your understanding of transport protocols with these resources:

  • Quiz Navigator: Test your knowledge of TCP vs UDP trade-offs, header structures, and protocol selection decisions through interactive quizzes
  • Simulations Hub: Explore transport protocol behavior with network simulators showing packet loss, retransmission, and congestion control in action
  • Knowledge Gaps Hub: Review common misconceptions about transport reliability, connection overhead, and when to use TCP vs UDP
  • Videos Hub: Watch visual explanations of 3-way handshakes, acknowledgment mechanisms, and real-world IoT protocol implementations
WarningCommon Misconception: “TCP is Always More Reliable Than UDP”

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

⏱️ ~10 min | ⭐ Foundational | 📋 P07.C31.U01

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

Figure 730.4: IoT protocol stack showing transport layer (Layer 4) bridging application protocols (MQTT, CoAP, HTTP) to network layer (IP): MQTT and HTTP use reliable TCP, CoAP uses lightweight UDP or secure DTLS for constrained devices.

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

NoteTransport Fundamentals (Part 1)
Transport Fundamentals (Part 1)
Lesson 4 — UDP/TCP concepts that underpin CoAP and MQTT behavior.
NoteTransport Fundamentals (Part 2)
Transport Fundamentals (Part 2)
Lesson 4 — reliability, congestion, and power trade-offs for IoT.
ImportantCore Transport Protocols for IoT

IoT applications primarily use three transport layer protocols:

  1. UDP (User Datagram Protocol): Connectionless, lightweight, no guarantees
  2. TCP (Transmission Control Protocol): Connection-oriented, reliable, higher overhead
  3. DTLS (Datagram Transport Layer Security): Secure UDP communication