735  Transport Protocol Fundamentals: TCP and UDP

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
  • Analyze trade-offs between reliability, overhead, and power consumption
  • Understand header structures and overhead implications

735.1 Prerequisites

Before diving into this chapter, you should be familiar with:

  • Layered Network Models: Understanding the OSI and TCP/IP protocol stack is essential since transport protocols (Layer 4) sit between application protocols and network routing, managing end-to-end communication
  • Networking Basics: Knowledge of fundamental networking concepts including packets, headers, ports, addressing, and basic data transmission provides the foundation for understanding transport protocol operation
  • IoT device constraints: Familiarity with power consumption, memory limitations, and bandwidth constraints of IoT sensors helps you appreciate why choosing between TCP and UDP significantly impacts battery life and network efficiency
NoteKey Takeaway

In one sentence: TCP guarantees delivery but adds latency and power cost; UDP is fast but unreliable - choose based on whether you can tolerate lost data.

Remember this: For battery-powered IoT sensors sending frequent readings, UDP (or UDP-based CoAP) often extends battery life by 10x or more compared to TCP, because you skip connection setup and acknowledgments.

735.2 Getting Started (For Beginners)

What are Transport Protocols? Transport protocols are the delivery systems that move data between applications running on different devices. The two main options are TCP (reliable but slower, like registered mail with tracking) and UDP (fast but unreliable, like dropping a postcard in the mailbox). For IoT, choosing the right transport protocol can mean the difference between a battery lasting 6 months versus 6 years.

Why does it matter? Every time your smart thermostat sends a temperature reading or your fitness tracker uploads step counts, it uses either TCP or UDP. TCP guarantees the data arrives correctly but uses more battery power and time due to acknowledgments and retransmissions. UDP sends data quickly with minimal overhead but doesn’t guarantee delivery. Understanding this trade-off helps you design efficient IoT systems - use UDP for frequent sensor readings where losing one data point doesn’t matter, and TCP for critical commands like unlocking a smart door.

Key terms to know: | Term | Simple Definition | |——|——————-| | TCP | Transmission Control Protocol - reliable delivery with acknowledgments, like certified mail | | UDP | User Datagram Protocol - fast, connectionless delivery with no guarantees, like postcards | | 3-way handshake | TCP’s connection setup process (SYN, SYN-ACK, ACK) required before sending data | | Retransmission | When TCP automatically resends lost packets, improving reliability but draining battery | | DTLS | Datagram Transport Layer Security - encrypted version of UDP for secure, lightweight communication |

Deep Dives: - Transport Protocols Overview - Index page for all transport topics - DTLS Security - Securing UDP communications - Protocol Selection - Choosing the right protocol - Decision Framework - Decision matrices and pitfalls

Comparisons: - CoAP Protocol - UDP-based application protocol for IoT - MQTT Protocol - TCP-based pub-sub messaging

Architecture: - Layered Models - Understanding protocol stack layers - Networking Basics - Foundation concepts

735.3 Introduction to Transport Layer Protocols

Time: ~10 min | Level: Foundational | Unit: P07.C33.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/CoAP/HTTP]
    end

    subgraph "Transport Layer"
        T1[TCP<br/>Reliable, Ordered]
        T2[UDP<br/>Fast, Lightweight]
        T3[DTLS<br/>Secure UDP]
    end

    subgraph "Network Layer"
        N1[IP<br/>Routing & Addressing]
    end

    subgraph "Link Layer"
        L1[Wi-Fi/Zigbee/LoRa]
    end

    A1 --> T1
    A1 --> T2
    A1 --> T3
    T1 --> N1
    T2 --> N1
    T3 --> N1
    N1 --> L1

    style T1 fill:#2C3E50,stroke:#16A085,color:#fff
    style T2 fill:#2C3E50,stroke:#16A085,color:#fff
    style T3 fill:#2C3E50,stroke:#16A085,color:#fff
    style A1 fill:#E67E22,stroke:#16A085,color:#fff
    style N1 fill:#16A085,stroke:#2C3E50,color:#fff
    style L1 fill:#95a5a6,stroke:#2C3E50,color:#fff

Figure 735.1: Transport layer protocols (TCP, UDP, DTLS) connecting application and network layers
Transport layer protocols sit between application and network layers, providing end-to-end communication services
WarningCommon Misconception: “TCP Always Uses More Power Than UDP”

The Misconception: Many developers assume TCP always consumes significantly more power than UDP for IoT devices, leading them to avoid TCP entirely.

The Reality: For infrequent transmissions (every 5+ minutes), TCP and UDP have nearly identical battery life. A real-world study of Nordic nRF52840 sensors sending 10-byte readings every 5 minutes showed:

  • UDP: 45.6 years battery life (2000 mAh)
  • TCP (full connection): 43.8 years battery life
  • Difference: Only 4% (~1.8 years over 45 years)

Why? At low transmission frequencies, sleep current (5 uA) dominates battery consumption (99.99% of time). TCP’s connection overhead (13 ms vs 1.3 ms) is only 0.00027% of each 5-minute cycle.

When TCP Overhead Matters: The power penalty appears at high transmission rates (every 10-30 seconds). The same study showed at 10-second intervals:

  • UDP: 45.5 years
  • TCP (full connection): 8.6 years
  • Difference: 81% reduction (36.9 years)

Quantified Insight: TCP overhead becomes significant when active radio time exceeds ~0.1% of the duty cycle. Below that threshold, sleep current dominates regardless of protocol choice.

Takeaway: Don’t blindly avoid TCP for battery devices. Calculate your specific duty cycle - for infrequent reporting (hourly/daily), TCP’s reliability benefits often outweigh negligible power costs.

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

735.4 User Datagram Protocol (UDP)

UDP is a connectionless protocol with very low overhead and fast transmission, but no guarantee for message delivery.

735.4.1 UDP Characteristics

%%{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
    S[Sender] -->|1. Create Datagram| D1[UDP Datagram<br/>Header + Data]
    D1 -->|2. Send| N[Network]
    N -->|3. Deliver| R[Receiver]

    N -.->|Packet may be lost| X[X]
    N -.->|May arrive out of order| O[Packet 3, 1, 2]

    R -.->|No ACK sent| S

    style S fill:#2C3E50,stroke:#16A085,color:#fff
    style D1 fill:#E67E22,stroke:#16A085,color:#fff
    style R fill:#2C3E50,stroke:#16A085,color:#fff
    style N fill:#16A085,stroke:#2C3E50,color:#fff
    style X fill:#e74c3c,stroke:#c0392b,color:#fff
    style O fill:#f39c12,stroke:#e67e22,color:#fff

Figure 735.2: UDP connectionless transmission showing packet loss and reordering without acknowledgments
UDP is connectionless: datagrams are sent without handshake, acknowledgment, or guaranteed delivery

This variant shows the same UDP communication but emphasizes the energy savings that make UDP attractive for battery-powered IoT sensors.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '11px'}}}%%
sequenceDiagram
    participant S as Sensor<br/>(Battery)
    participant G as Gateway

    Note over S: Wake from sleep<br/>1ms startup

    rect rgb(46, 204, 113)
        Note over S,G: UDP: Single packet, then sleep
        S->>G: Data (1 packet)
        Note over S: TX: 5ms @ 15mA
    end

    Note over S: Total active: 6ms<br/>Back to sleep @ 5uA

    rect rgb(231, 76, 60)
        Note over S,G: If TCP: 8 packets minimum
        Note over S: SYN (5ms)<br/>wait SYN-ACK (50ms)<br/>ACK (5ms)<br/>Data (5ms)<br/>wait ACK (50ms)<br/>FIN (5ms)<br/>wait FIN-ACK (50ms)
    end

    Note over S: TCP: ~170ms active<br/>UDP: ~6ms active<br/>28x energy difference!

Figure 735.3: UDP Energy Timeline - Shows why UDP’s “fire and forget” approach saves significant battery on constrained devices

Key Insight: The energy savings come from eliminating round-trip wait times. Each TCP handshake requires waiting 50-200ms for responses, keeping the radio active and draining battery.

735.4.2 UDP Properties

Connectionless: - No connection establishment (no handshake) - No connection state maintained - Each datagram independent

Unreliable: - No acknowledgments: Sender doesn’t know if received - No retransmission: Lost packets are not resent - No ordering: Packets may arrive out of order - No flow control: Can overwhelm receiver

Lightweight: - Small header: 8 bytes only - Minimal processing: No state, no retransmission logic - Low latency: Immediate transmission

Use Cases: - Sensor readings (temperature, humidity) - Real-time data (video streaming, voice) - DNS queries - IoT telemetry (CoAP, MQTT-SN)

735.4.3 UDP Header Structure

%%{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 "UDP Datagram"
        subgraph "UDP Header (8 bytes)"
            H1[Source Port<br/>16 bits]
            H2[Destination Port<br/>16 bits]
            H3[Length<br/>16 bits]
            H4[Checksum<br/>16 bits]
        end
        subgraph "Payload"
            P1[Application Data<br/>0-65,507 bytes]
        end
    end

    H1 -.->|Optional| H1
    H3 -.->|Header + Data| H3
    H4 -.->|IPv6: Mandatory<br/>IPv4: Optional| H4

    style H1 fill:#2C3E50,stroke:#16A085,color:#fff
    style H2 fill:#2C3E50,stroke:#16A085,color:#fff
    style H3 fill:#2C3E50,stroke:#16A085,color:#fff
    style H4 fill:#E67E22,stroke:#16A085,color:#fff
    style P1 fill:#16A085,stroke:#2C3E50,color:#fff

Figure 735.4: UDP datagram header structure showing 8-byte header with ports, length, and checksum fields
UDP header is minimal at only 8 bytes, providing lightweight transport with low overhead

UDP Header Fields:

Field Size Purpose
Source Port 16 bits Sending application’s port (optional, can be 0)
Destination Port 16 bits Receiving application’s port
Length 16 bits Total length (header + data) in bytes
Checksum 16 bits Error detection (optional in IPv4, mandatory in IPv6)

Total Header: 8 bytes (minimal overhead)

Maximum Payload: 65,507 bytes (65,535 - 20 IP header - 8 UDP header)

735.4.4 Why UDP for IoT?

Advantages:

  1. Low Overhead: 8-byte header vs 20-byte TCP header
  2. Low Power: No connection state = less memory, less processing
  3. Simplicity: Easy to implement on constrained devices
  4. Multicast/Broadcast: UDP supports one-to-many communication
  5. Real-Time: No retransmission delays

Disadvantages:

  1. Unreliable: Packets may be lost
  2. Unordered: Packets may arrive out of sequence
  3. No Congestion Control: Can overwhelm network

IoT Applications Using UDP: - CoAP (Constrained Application Protocol): RESTful for IoT - MQTT-SN (MQTT for Sensor Networks): Pub/sub for sensors - DNS: Domain name resolution - NTP: Network time synchronization - SNMP: Network management - Streaming: Real-time audio/video (when latency > reliability)

735.4.5 UDP Analogy

TipUDP is Like Traditional Mail

UDP is often compared to traditional mail delivery:

  • You write a letter (create datagram)
  • Drop it in mailbox (send datagram)
  • No acknowledgment that it was received
  • Don’t know if it was lost, delivered, or delayed
  • Can’t guarantee letters arrive in order you sent them

Example: - You mail 3 letters: Monday, Tuesday, Wednesday - They might arrive: Wednesday, Monday (Tuesday lost) - You won’t know Tuesday letter was lost unless recipient tells you

735.5 Transmission Control Protocol (TCP)

TCP is a connection-oriented protocol that guarantees establishment of connection before data transmission and ensures reliable, ordered delivery.

735.5.1 TCP Characteristics

%%{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 C as Client
    participant S as Server

    Note over C,S: Connection Establishment (3-way handshake)
    C->>S: SYN (seq=100)
    S->>C: SYN-ACK (seq=200, ack=101)
    C->>S: ACK (ack=201)
    Note over C,S: Connection ESTABLISHED

    Note over C,S: Data Transfer
    C->>S: Data (seq=101, 50 bytes)
    S->>C: ACK (ack=151)
    S->>C: Data (seq=201, 100 bytes)
    C->>S: ACK (ack=301)

    Note over C,S: Connection Termination (4-way)
    C->>S: FIN (seq=151)
    S->>C: ACK (ack=152)
    S->>C: FIN (seq=301)
    C->>S: ACK (ack=302)
    Note over C,S: Connection CLOSED

Figure 735.5: TCP connection lifecycle with 3-way handshake, data transfer with ACKs, and 4-way termination
TCP provides connection-oriented communication with 3-way handshake, acknowledgments, and graceful termination

735.5.2 TCP Properties

Connection-Oriented: - 3-way handshake: SYN, SYN-ACK, ACK before data transfer - Connection state: Both endpoints maintain connection information - 4-way termination: Graceful connection closure

Reliable: - Acknowledgments: Receiver confirms receipt of each segment - Retransmission: Lost packets automatically resent - Ordering: Sequence numbers ensure correct order - Error Detection: Checksum for data integrity

Flow Control: - Sliding window: Prevents sender from overwhelming receiver - Window size: Receiver advertises how much data it can accept

Congestion Control: - Slow start: Gradually increases transmission rate - Congestion avoidance: Backs off when network congested - Fast retransmit/recovery: Quickly recovers from packet loss

Use Cases: - Firmware updates (must be reliable) - Configuration data - File transfers - HTTP (web browsing) - MQTT (reliable pub/sub messaging)

735.5.3 TCP Header Structure

%%{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 "TCP Segment"
        subgraph "TCP Header (20-60 bytes)"
            H1[Source Port<br/>16 bits]
            H2[Destination Port<br/>16 bits]
            H3[Sequence Number<br/>32 bits]
            H4[Acknowledgment Number<br/>32 bits]
            H5[Header Length<br/>4 bits]
            H6[Flags<br/>SYN/ACK/FIN/RST<br/>9 bits]
            H7[Window Size<br/>16 bits]
            H8[Checksum<br/>16 bits]
            H9[Urgent Pointer<br/>16 bits]
            H10[Options<br/>0-40 bytes]
        end
        subgraph "Payload"
            P1[Application Data]
        end
    end

    H3 -.->|Ordering| H3
    H4 -.->|Reliability| H4
    H6 -.->|Control| H6
    H7 -.->|Flow Control| H7

    style H1 fill:#2C3E50,stroke:#16A085,color:#fff
    style H2 fill:#2C3E50,stroke:#16A085,color:#fff
    style H3 fill:#E67E22,stroke:#16A085,color:#fff
    style H4 fill:#E67E22,stroke:#16A085,color:#fff
    style H5 fill:#2C3E50,stroke:#16A085,color:#fff
    style H6 fill:#E67E22,stroke:#16A085,color:#fff
    style H7 fill:#16A085,stroke:#2C3E50,color:#fff
    style H8 fill:#2C3E50,stroke:#16A085,color:#fff
    style H9 fill:#2C3E50,stroke:#16A085,color:#fff
    style H10 fill:#2C3E50,stroke:#16A085,color:#fff
    style P1 fill:#16A085,stroke:#2C3E50,color:#fff

Figure 735.6: TCP segment header structure with 20-60 byte header including sequence numbers, flags, and window size
TCP header ranges from 20-60 bytes, containing fields for reliability, ordering, flow control, and connection management

TCP Header Fields (simplified):

Field Size Purpose
Source/Dest Port 16 bits each Application endpoints
Sequence Number 32 bits Byte stream position
Acknowledgment Number 32 bits Next expected byte
Flags 9 bits SYN, ACK, FIN, RST, PSH, URG
Window Size 16 bits Flow control (receiver buffer)
Checksum 16 bits Error detection
Options 0-40 bytes MSS, timestamps, window scaling

Total Header: 20-60 bytes (vs 8 bytes for UDP)

735.5.4 Why TCP for IoT?

Advantages:

  1. Reliability: Guaranteed delivery (critical for firmware updates)
  2. Ordering: Data arrives in correct sequence
  3. Error Recovery: Automatic retransmission
  4. Flow Control: Prevents buffer overflow
  5. Congestion Control: Network-friendly

Disadvantages:

  1. High Overhead: 20-60 byte header + connection state
  2. Higher Latency: 3-way handshake before data, retransmission delays
  3. Power Consumption: Connection state, acknowledgments, retransmissions
  4. Memory: Connection state requires RAM
  5. Not Real-Time: Retransmissions cause variable latency

IoT Applications Using TCP: - MQTT (Message Queue Telemetry Transport): Pub/sub messaging - HTTP/HTTPS: Web APIs, RESTful services - Firmware Updates: OTA (Over-The-Air) updates - Configuration: Device configuration and management - File Transfer: Log files, images

735.5.5 TCP Analogy

TipTCP is Like a Telephone Call

TCP is similar to a telephone system:

  • Dial number (SYN - request connection)
  • Other person answers (SYN-ACK - acknowledge request)
  • You say hello (ACK - confirm connection)
  • Connection established - can now talk
  • Conversation - back-and-forth communication
  • “Did you hear me?” - acknowledgments
  • Repeat if needed - retransmission
  • “Goodbye” (FIN - close connection)
  • “Goodbye back” (FIN-ACK - confirm closure)

Both ends must be connected before communication can begin.

735.6 TCP vs UDP Comparison

%%{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 "TCP - Reliable & Ordered"
        T1[Connection-Oriented]
        T2[3-Way Handshake]
        T3[Acknowledgments]
        T4[Retransmission]
        T5[Ordered Delivery]
        T6[Flow Control]
        T7[20-60 byte header]
        T8[High Power]
    end

    subgraph "UDP - Fast & Lightweight"
        U1[Connectionless]
        U2[No Handshake]
        U3[No ACKs]
        U4[No Retransmission]
        U5[Unordered]
        U6[No Flow Control]
        U7[8 byte header]
        U8[Low Power]
    end

    subgraph "IoT Use Cases"
        TC[TCP: Firmware Updates<br/>Configuration<br/>MQTT]
        UC[UDP: Sensor Telemetry<br/>CoAP<br/>Real-time Streaming]
    end

    T1 & T2 & T3 & T4 & T5 & T6 & T7 & T8 --> TC
    U1 & U2 & U3 & U4 & U5 & U6 & U7 & U8 --> UC

    style T1 fill:#2C3E50,stroke:#16A085,color:#fff
    style T2 fill:#2C3E50,stroke:#16A085,color:#fff
    style T3 fill:#2C3E50,stroke:#16A085,color:#fff
    style T4 fill:#2C3E50,stroke:#16A085,color:#fff
    style T5 fill:#2C3E50,stroke:#16A085,color:#fff
    style T6 fill:#2C3E50,stroke:#16A085,color:#fff
    style T7 fill:#2C3E50,stroke:#16A085,color:#fff
    style T8 fill:#e74c3c,stroke:#c0392b,color:#fff
    style U1 fill:#16A085,stroke:#2C3E50,color:#fff
    style U2 fill:#16A085,stroke:#2C3E50,color:#fff
    style U3 fill:#16A085,stroke:#2C3E50,color:#fff
    style U4 fill:#16A085,stroke:#2C3E50,color:#fff
    style U5 fill:#16A085,stroke:#2C3E50,color:#fff
    style U6 fill:#16A085,stroke:#2C3E50,color:#fff
    style U7 fill:#16A085,stroke:#2C3E50,color:#fff
    style U8 fill:#27ae60,stroke:#16a085,color:#fff
    style TC fill:#E67E22,stroke:#16A085,color:#fff
    style UC fill:#E67E22,stroke:#16A085,color:#fff

Figure 735.7: TCP vs UDP comparison showing reliability features versus lightweight characteristics with IoT use cases
TCP and UDP represent fundamental trade-offs between reliability and efficiency in IoT transport layer design

735.6.1 Detailed Comparison Table

Feature TCP UDP
Connection Connection-oriented (handshake) Connectionless
Reliability Reliable (ACKs, retransmission) Best-effort (no guarantees)
Ordering Ordered delivery Unordered (may arrive out of sequence)
Header Size 20-60 bytes 8 bytes
Overhead High (ACKs, state, retrans) Low (fire and forget)
Speed Slower (handshake, ACKs) Faster (immediate transmission)
Latency Higher (variable due to retrans) Lower (predictable)
Flow Control Yes (sliding window) No
Congestion Control Yes (slow start, etc.) No
Error Recovery Automatic retransmission None (app must handle)
Broadcast/Multicast No (point-to-point only) Yes
Power Consumption Higher (state, ACKs) Lower (minimal processing)
Memory Usage Higher (connection state) Lower (stateless)
Best For Reliability critical Low latency, real-time
IoT Use Cases Firmware, config, MQTT CoAP, telemetry, streaming
TipTradeoff: Reliable vs Best-Effort Delivery

Decision context: When choosing transport protocols for IoT, you must balance guaranteed delivery (TCP) against lightweight efficiency (UDP with optional application-layer reliability).

Factor Reliable (TCP) Best-Effort (UDP)
Power consumption High (handshakes, ACKs) Low (fire-and-forget)
Latency Variable (retransmissions) Predictable (no waiting)
Complexity Lower (handled by OS) Higher (app handles loss)
Cost Higher bandwidth overhead Lower overhead (8-byte header)
Header size 20-60 bytes 8 bytes
Connection state Required (memory usage) None (stateless)

Choose Reliable (TCP) when: - Data loss is unacceptable (firmware updates, commands) - Ordering matters (log files, sequential processing) - Infrequent transmissions (< 1/minute) where overhead is negligible - Using protocols requiring TCP (MQTT, HTTP, TLS)

Choose Best-Effort (UDP) when: - Occasional packet loss is acceptable (periodic telemetry) - Low latency is critical (real-time control, streaming) - Battery life is paramount (frequent transmissions) - Using lightweight protocols (CoAP, DNS, mDNS)

Default recommendation: UDP with CoAP Confirmable messages for critical alerts, Non-Confirmable for routine telemetry. Use TCP only for firmware updates, configuration changes, and when MQTT’s features justify the overhead.

This variant shows the same data transfer using TCP vs UDP side-by-side, highlighting the time and packet overhead difference - especially critical for understanding IoT battery impact.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '10px'}}}%%
sequenceDiagram
    box rgb(231, 76, 60) TCP (8 packets, ~180ms)
    participant TC as Sensor
    participant TS as Server
    end

    box rgb(46, 204, 113) UDP (1 packet, ~5ms)
    participant UC as Sensor
    participant US as Server
    end

    Note over TC,TS: TCP: Connection Setup
    TC->>TS: SYN
    TS->>TC: SYN-ACK
    TC->>TS: ACK

    Note over TC,TS: TCP: Data Transfer
    TC->>TS: Data (20 bytes)
    TS->>TC: ACK

    Note over TC,TS: TCP: Connection Close
    TC->>TS: FIN
    TS->>TC: FIN-ACK
    TC->>TS: ACK

    Note over UC,US: UDP: Fire and Forget
    UC->>US: Data (20 bytes)

    Note over TC,TS: Total: 8 packets<br/>Radio active: ~180ms<br/>Header overhead: 160+ bytes
    Note over UC,US: Total: 1 packet<br/>Radio active: ~5ms<br/>Header overhead: 8 bytes

Figure 735.8: TCP vs UDP Packet Timeline - Same 20-byte sensor reading requires 8 TCP packets vs 1 UDP packet

Key Insight: For a single sensor reading, TCP uses 36x more radio-on time than UDP. At 1 reading/minute, TCP could reduce battery life from 5 years to 2 months.

735.7 Knowledge Check

Question: A temperature sensor sends 20-byte readings every 30 seconds over a network with 2% packet loss. Should you use UDP or TCP?

Explanation: UDP is ideal for periodic telemetry where fresh data replaces old:

Why UDP: - Data is replaceable: If reading at T=0 is lost, reading at T=30 provides current status - Low overhead: UDP 8-byte header vs TCP 20+ bytes (40% less overhead for small payloads) - No connection setup: No 3-way handshake, saves energy and latency - 2% loss is acceptable: 98% reliability sufficient for monitoring (not control)

Overhead comparison: - UDP: 20 bytes data + 8 header = 28 bytes total - TCP: 20 bytes data + 20 header = 40 bytes (+43% overhead) - TCP first transmission: +3-way handshake (3x round trips)

Real-world: CoAP uses UDP for this exact reason - periodic sensor data where timeliness > completeness.

Question: A smart home gateway maintains persistent MQTT connections (over TCP) to 50 sensors. Each sensor sends data every 5 minutes. What is the main downside?

Explanation: TCP persistent connections are expensive for battery-powered IoT:

TCP connection overhead: - Keep-alive packets: TCP sends periodic packets (default 2 hours) to detect dead connections - Connection state: Buffers, sequence numbers, timers consume RAM - Energy cost: Wake from sleep every 2 hours to send keep-alive (~5-10% battery drain)

Gateway perspective (50 sensors): - TCP: 50 simultaneous connections x 4 KB state = 200 KB RAM minimum - Memory: Must handle all connections simultaneously - Scaling: Limited by TCP connection limits (typically 1000-10000)

Better approach: Use MQTT-SN over UDP for battery sensors, or use short-lived TCP connections (connect, send, disconnect) trading latency for battery life.

735.8 Summary

TipKey Takeaways

UDP (User Datagram Protocol): - Connectionless, unreliable, lightweight - 8-byte header, minimal overhead - Best for: Real-time, periodic data, power-constrained - IoT uses: CoAP, MQTT-SN, telemetry, streaming

TCP (Transmission Control Protocol): - Connection-oriented, reliable, ordered delivery - 20-60 byte header, connection overhead - Best for: Critical data, firmware updates, ordered delivery - IoT uses: MQTT, HTTP, configuration, file transfer

Quick Selection Guide: 1. Can I tolerate loss? YES = UDP, NO = TCP 2. Battery-powered? YES = prefer UDP, NO = either OK 3. Frequent transmission? YES = UDP critical, NO = TCP acceptable

735.9 What’s Next?

Continue to DTLS Security for UDP to learn how to secure UDP communications for IoT applications without the overhead of TCP+TLS.