8  TCP and UDP Fundamentals

In 60 Seconds

Transport protocols (Layer 4) manage end-to-end communication between IoT devices. TCP guarantees reliable, ordered delivery with a 20-byte minimum header and 3-way handshake, while UDP provides minimal 8-byte header fire-and-forget transmission. For battery-powered IoT sensors sending frequent readings, UDP (or CoAP over UDP) can extend battery life by 10x compared to TCP by eliminating connection setup and acknowledgment overhead.

Key Concepts

• OSI Layer 4 Responsibilities: End-to-end data delivery between applications; port-based multiplexing; optional: error detection (both), error recovery (TCP), ordering (TCP), flow control (TCP), congestion control (TCP)
• TCP Segment: Unit of TCP transmission including: source port, dest port, sequence number, ACK number, header length, flags (SYN/ACK/FIN/RST/PSH/URG), window size, checksum, urgent pointer, options, payload
• UDP Datagram: Minimal transport unit: 8-byte header (source port, dest port, length, checksum) + payload; no connection state, no ordering, no reliability
• Internet Checksum: 16-bit ones-complement sum of UDP/TCP header + data (IPv4 optional for UDP, mandatory for IPv6); detects single-bit errors; NOT cryptographically strong
• TCP Slow Start: Congestion control phase starting from cwnd=1 MSS; doubles cwnd per RTT until ssthresh; transitions to Congestion Avoidance (linear increase) at ssthresh
• TCP Fast Retransmit: Retransmits lost segment immediately upon receiving 3 duplicate ACKs without waiting for retransmission timeout; faster recovery than RTO-based retransmission
• UDP Multicast Group: IPv4 224.0.0.0/4 or IPv6 ff00::/8 address ranges; UDP datagrams sent to multicast address are delivered to all group members; used for IoT device discovery (mDNS, SSDP)
• Port Scanning: Network reconnaissance technique sending connection attempts to all ports; TCP port scan: SYN → SYN-ACK (open) or RST (closed); IoT devices must use firewalls to block unauthorized port access

Learning Objectives

By the end of this section, you will be able to:

• Identify the role of transport layer protocols (Layer 4) within the IoT protocol stack
• Compare TCP and UDP characteristics and use cases across IoT deployment scenarios
• Explain why UDP is preferred for many IoT applications and justify when TCP is the better choice
• Evaluate trade-offs between reliability, overhead, and power consumption for a given IoT scenario
• Analyze header structures to calculate protocol overhead and its impact on battery life

8.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

Key Takeaway

The one question that decides everything: Can I tolerate losing this data point? If yes, use UDP. If no, use TCP.

Remember this: The overhead gap widens with transmission frequency. For hourly reports, TCP and UDP battery life differ by less than 5%. For per-second telemetry, UDP can last 3-6x longer because it skips connection setup and acknowledgments.

Sensor Squad: The Two Delivery Methods!

“Think of TCP and UDP as two very different delivery services,” said Max the Microcontroller. “TCP is like a courier who makes you sign for every package, calls if the delivery fails, and keeps trying until you get it. Reliable, but slow and expensive.”

“UDP is more like throwing a paper airplane across the room,” laughed Sammy the Sensor. “You launch it and hope it arrives! No confirmation, no retries. But it is incredibly fast and uses almost no energy – just an 8-byte header versus TCP’s 20-byte minimum.”

“For my temperature readings, UDP is perfect,” added Lila the LED. “I send a reading every minute. If one gets lost, another is coming soon. But if someone sends a firmware update to reprogram me, they better use TCP – losing part of the update could brick me!”

“The numbers tell the story,” said Bella the Battery. “For a 10-byte sensor payload, TCP adds 20 bytes of header plus the handshake overhead. That is 200 percent overhead! UDP adds just 8 bytes – only 80 percent overhead. Over thousands of transmissions, that difference means months of extra battery life.”

---

For Beginners: Transport Protocols

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 |

---

Related Chapters

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

8.2 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.

Figure 8.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

Common 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.

Core 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

8.3 User Datagram Protocol (UDP)

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

8.3.1 UDP Characteristics

Figure 8.2: UDP connectionless transmission showing packet loss and reordering without acknowledgments

UDP is connectionless: datagrams are sent without handshake, acknowledgment, or guaranteed delivery

Alternative View: UDP Timeline with Energy Focus

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

Figure 8.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-200 ms for responses, keeping the radio active and draining battery.

8.3.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)

8.3.3 UDP Header Structure

Figure 8.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)

8.3.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)

8.3.5 UDP Analogy

UDP 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

Quick Check: UDP Properties

8.4 Transmission Control Protocol (TCP)

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

8.4.1 TCP Characteristics

Figure 8.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

8.4.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)

8.4.3 TCP Header Structure

Figure 8.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, NS, CWR, ECE
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)

8.4.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

8.4.5 TCP Analogy

TCP 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.

8.5 TCP vs UDP Comparison

Figure 8.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

8.5.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

Decision Guide: When to Choose TCP vs UDP

Choose TCP when:

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

Choose 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.

Alternative View: TCP vs UDP Packet Timeline Comparison

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.

Figure 8.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 requires ~6.6x more bytes transmitted than UDP (344 vs 52 bytes including IP headers). At 1 reading/minute, TCP can reduce battery life by 3x or more compared to UDP.

8.6 Worked Example: Choosing TCP vs UDP for a Smart Agriculture Gateway

Scenario: A farm deploys 200 soil moisture sensors across 50 hectares. Each sensor sends a 24-byte reading (moisture level, temperature, battery voltage) every 60 seconds to a LoRaWAN gateway, which relays data to a cloud dashboard. The gateway has a 4G cellular uplink (1 Mbps) with a $0.01/MB data plan. The same gateway also receives firmware update commands (average 50 KB each) from the cloud once per month.

Question: Should the gateway use TCP or UDP for (a) relaying sensor telemetry to the cloud and (b) receiving firmware commands?

Step 1: Calculate telemetry overhead with TCP vs UDP

Putting Numbers to It

The overhead difference between TCP and UDP directly impacts battery life. For a 24-byte sensor payload transmitted every 60 seconds:

UDP total bytes: \[\text{Total}_{\text{UDP}} = 8\text{ B (UDP)} + 20\text{ B (IP)} + 24\text{ B (payload)} = 52\text{ B}\]

TCP per-message (new connection each time): \[\begin{align} \text{Handshake} &= 3 \times 40\text{ B} = 120\text{ B} \\ \text{Data} &= 20\text{ B (TCP)} + 20\text{ B (IP)} + 24\text{ B} = 64\text{ B} \\ \text{Teardown} &= 4 \times 40\text{ B} = 160\text{ B} \\ \text{Total}_{\text{TCP}} &= 120 + 64 + 160 = 344\text{ B} \end{align}\]

Energy calculation at 250 kbps (31,250 bytes/sec), 50 mA TX current, 5 uA sleep current: \[\begin{align} T_{\text{UDP}} &= \frac{52}{31{,}250} = 1.66\text{ ms} \\ T_{\text{TCP}} &= \frac{344}{31{,}250} = 11.0\text{ ms} \\ E_{\text{UDP}} &= 50\text{ mA} \times \frac{1.66\text{ ms}}{3{,}600{,}000\text{ ms/h}} = 0.023\text{ \mu\text{Ah}} \\ E_{\text{TCP}} &= 50\text{ mA} \times \frac{11.0\text{ ms}}{3{,}600{,}000\text{ ms/h}} = 0.153\text{ \mu\text{Ah}} \end{align}\]

For 1,440 daily readings (every 60 seconds, matching the scenario) with a 2,000 mAh battery, including 5 uA sleep current (0.12 mAh/day):

• UDP: \(0.023 \times 1{,}440 = 33\text{ \mu\text{Ah}/day}\) + sleep = 0.153 mAh/day \(\Rightarrow\) 35.8 years
• TCP: \(0.153 \times 1{,}440 = 220\text{ \mu\text{Ah}/day}\) + sleep = 0.340 mAh/day \(\Rightarrow\) 16.1 years

The 6.6x per-transmission energy difference (344 vs 52 bytes) is dampened by sleep current but still results in roughly 2x shorter battery life – significant over a multi-year deployment.

Per sensor reading (24-byte payload):

Protocol	Header	IP Header	Total per Message	Overhead %
UDP	8 bytes	20 bytes	52 bytes	117%
TCP	20 bytes	20 bytes	64 bytes	167%
TCP (new conn)	20 + handshake (3 x 40) + teardown (4 x 40)	20 bytes	344 bytes	1333%

Step 2: Calculate monthly data cost

200 sensors x 1 msg/min x 60 min x 24 hr x 30 days = 8,640,000 messages/month

Protocol	Bytes/Month	Monthly Cost
UDP	8.64M x 52 = 449 MB	$4.49
TCP (persistent)	8.64M x 64 = 553 MB	$5.53
TCP (per-message)	8.64M x 344 = 2,972 MB	$29.72

Step 3: Assess reliability needs

• Sensor telemetry: If one reading is lost, the next arrives in 60 seconds. 2% packet loss means missing ~172,800 readings/month out of 8.64 million – insignificant for trend analysis.
• Firmware commands: A corrupted or lost firmware update can brick a device. Reliability is mandatory.

Step 4: Decision

Data Type	Protocol	Reasoning
Sensor telemetry	UDP (with CoAP NON)	Replaceable data, saves $1-25/month, lower latency
Firmware updates	TCP (with TLS)	Must be complete and uncorrupted, 50 KB/month is negligible overhead

Key insight: The $25.23/month savings from using UDP instead of TCP-per-message may seem small, but across 100 gateways over 5 years, that is $151,380. For battery-powered gateways on solar, the energy savings from eliminating TCP handshakes would be even more significant than the data cost.

---

8.7 Interactive: TCP vs UDP Overhead Calculator

Use this calculator to compare TCP and UDP overhead for your own IoT scenario. Adjust the payload size, transmission interval, and battery capacity to see how protocol choice affects battery life and data costs.

viewof payload_size = Inputs.range([1, 500], {value: 24, step: 1, label: "Payload size (bytes)"})
viewof tx_interval = Inputs.range([1, 3600], {value: 60, step: 1, label: "TX interval (seconds)"})
viewof battery_mah = Inputs.range([100, 20000], {value: 2000, step: 100, label: "Battery (mAh)"})
viewof tx_current_ma = Inputs.range([5, 200], {value: 50, step: 1, label: "TX current (mA)"})
viewof data_rate_kbps = Inputs.range([10, 1000], {value: 250, step: 10, label: "Data rate (kbps)"})
viewof sleep_current_ua = Inputs.range([1, 50], {value: 5, step: 1, label: "Sleep current (uA)"})

overhead_calc = {
  const udp_header = 8;
  const tcp_header = 20;
  const ip_header = 20;
  const handshake_bytes = 3 * (tcp_header + ip_header);
  const teardown_bytes = 4 * (tcp_header + ip_header);

  const udp_total = udp_header + ip_header + payload_size;
  const tcp_persistent = tcp_header + ip_header + payload_size;
  const tcp_new_conn = handshake_bytes + tcp_persistent + teardown_bytes;

  const data_rate_bytes_sec = data_rate_kbps * 1000 / 8;

  const t_udp_ms = (udp_total / data_rate_bytes_sec) * 1000;
  const t_tcp_pers_ms = (tcp_persistent / data_rate_bytes_sec) * 1000;
  const t_tcp_new_ms = (tcp_new_conn / data_rate_bytes_sec) * 1000;

  const e_udp_uah = tx_current_ma * t_udp_ms / 3600000;
  const e_tcp_pers_uah = tx_current_ma * t_tcp_pers_ms / 3600000;
  const e_tcp_new_uah = tx_current_ma * t_tcp_new_ms / 3600000;

  const daily_tx = Math.floor(86400 / tx_interval);
  const sleep_mah_day = sleep_current_ua * 24 / 1000;

  const udp_mah_day = (e_udp_uah * daily_tx / 1000) + sleep_mah_day;
  const tcp_pers_mah_day = (e_tcp_pers_uah * daily_tx / 1000) + sleep_mah_day;
  const tcp_new_mah_day = (e_tcp_new_uah * daily_tx / 1000) + sleep_mah_day;

  const udp_years = battery_mah / udp_mah_day / 365.25;
  const tcp_pers_years = battery_mah / tcp_pers_mah_day / 365.25;
  const tcp_new_years = battery_mah / tcp_new_mah_day / 365.25;

  const udp_overhead_pct = ((udp_total - payload_size) / payload_size * 100).toFixed(0);
  const tcp_pers_overhead_pct = ((tcp_persistent - payload_size) / payload_size * 100).toFixed(0);
  const tcp_new_overhead_pct = ((tcp_new_conn - payload_size) / payload_size * 100).toFixed(0);

  return html`
  <div style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 12px; margin: 16px 0;">
    <div style="background: #16A085; color: white; padding: 16px; border-radius: 8px; text-align: center;">
      <div style="font-size: 0.85em; opacity: 0.9;">UDP</div>
      <div style="font-size: 1.6em; font-weight: bold;">${udp_total} B</div>
      <div style="font-size: 0.8em;">${udp_overhead_pct}% overhead</div>
      <div style="font-size: 1.1em; margin-top: 8px; font-weight: bold;">${udp_years.toFixed(1)} years</div>
      <div style="font-size: 0.75em;">battery life</div>
    </div>
    <div style="background: #3498DB; color: white; padding: 16px; border-radius: 8px; text-align: center;">
      <div style="font-size: 0.85em; opacity: 0.9;">TCP (persistent)</div>
      <div style="font-size: 1.6em; font-weight: bold;">${tcp_persistent} B</div>
      <div style="font-size: 0.8em;">${tcp_pers_overhead_pct}% overhead</div>
      <div style="font-size: 1.1em; margin-top: 8px; font-weight: bold;">${tcp_pers_years.toFixed(1)} years</div>
      <div style="font-size: 0.75em;">battery life</div>
    </div>
    <div style="background: #E67E22; color: white; padding: 16px; border-radius: 8px; text-align: center;">
      <div style="font-size: 0.85em; opacity: 0.9;">TCP (new conn)</div>
      <div style="font-size: 1.6em; font-weight: bold;">${tcp_new_conn} B</div>
      <div style="font-size: 0.8em;">${tcp_new_overhead_pct}% overhead</div>
      <div style="font-size: 1.1em; margin-top: 8px; font-weight: bold;">${tcp_new_years.toFixed(1)} years</div>
      <div style="font-size: 0.75em;">battery life</div>
    </div>
  </div>
  <div style="background: #f8f9fa; padding: 12px; border-radius: 6px; font-size: 0.85em; border-left: 4px solid #2C3E50;">
    <strong>Daily transmissions:</strong> ${daily_tx.toLocaleString()} |
    <strong>Sleep drain:</strong> ${sleep_mah_day.toFixed(2)} mAh/day |
    <strong>TCP/UDP energy ratio:</strong> ${(tcp_new_conn / udp_total).toFixed(1)}x per message
  </div>`;
}

8.8 Interactive: Monthly Data Cost Calculator

Estimate your monthly cellular data costs for TCP vs UDP across a fleet of IoT devices.

viewof num_sensors = Inputs.range([1, 10000], {value: 200, step: 1, label: "Number of sensors"})
viewof cost_payload = Inputs.range([1, 500], {value: 24, step: 1, label: "Payload size (bytes)"})
viewof msg_interval_sec = Inputs.range([1, 3600], {value: 60, step: 1, label: "Message interval (seconds)"})
viewof cost_per_mb = Inputs.range([0.001, 0.10], {value: 0.01, step: 0.001, label: "Cost per MB ($)"})

cost_calc = {
  const udp_h = 8;
  const tcp_h = 20;
  const ip_h = 20;
  const handshake = 3 * (tcp_h + ip_h);
  const teardown = 4 * (tcp_h + ip_h);

  const udp_per_msg = udp_h + ip_h + cost_payload;
  const tcp_pers_per_msg = tcp_h + ip_h + cost_payload;
  const tcp_new_per_msg = handshake + tcp_pers_per_msg + teardown;

  const msgs_per_month = num_sensors * (86400 / msg_interval_sec) * 30;

  const udp_mb = (msgs_per_month * udp_per_msg) / (1024 * 1024);
  const tcp_pers_mb = (msgs_per_month * tcp_pers_per_msg) / (1024 * 1024);
  const tcp_new_mb = (msgs_per_month * tcp_new_per_msg) / (1024 * 1024);

  const udp_cost = udp_mb * cost_per_mb;
  const tcp_pers_cost = tcp_pers_mb * cost_per_mb;
  const tcp_new_cost = tcp_new_mb * cost_per_mb;

  const savings = tcp_new_cost - udp_cost;
  const annual_savings = savings * 12;

  return html`
  <table style="width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 0.9em;">
    <thead>
      <tr style="background: #2C3E50; color: white;">
        <th style="padding: 10px; text-align: left;">Protocol</th>
        <th style="padding: 10px; text-align: right;">MB/Month</th>
        <th style="padding: 10px; text-align: right;">Monthly Cost</th>
        <th style="padding: 10px; text-align: right;">Annual Cost</th>
      </tr>
    </thead>
    <tbody>
      <tr style="background: #e8f8f5;">
        <td style="padding: 8px; font-weight: bold; color: #16A085;">UDP</td>
        <td style="padding: 8px; text-align: right;">${udp_mb.toFixed(0)}</td>
        <td style="padding: 8px; text-align: right;">$${udp_cost.toFixed(2)}</td>
        <td style="padding: 8px; text-align: right;">$${(udp_cost * 12).toFixed(2)}</td>
      </tr>
      <tr style="background: #ebf5fb;">
        <td style="padding: 8px; font-weight: bold; color: #3498DB;">TCP (persistent)</td>
        <td style="padding: 8px; text-align: right;">${tcp_pers_mb.toFixed(0)}</td>
        <td style="padding: 8px; text-align: right;">$${tcp_pers_cost.toFixed(2)}</td>
        <td style="padding: 8px; text-align: right;">$${(tcp_pers_cost * 12).toFixed(2)}</td>
      </tr>
      <tr style="background: #fdf2e9;">
        <td style="padding: 8px; font-weight: bold; color: #E67E22;">TCP (per-message)</td>
        <td style="padding: 8px; text-align: right;">${tcp_new_mb.toFixed(0)}</td>
        <td style="padding: 8px; text-align: right;">$${tcp_new_cost.toFixed(2)}</td>
        <td style="padding: 8px; text-align: right;">$${(tcp_new_cost * 12).toFixed(2)}</td>
      </tr>
    </tbody>
  </table>
  <div style="background: #f8f9fa; padding: 12px; border-radius: 6px; font-size: 0.85em; border-left: 4px solid #16A085;">
    <strong>Messages/month:</strong> ${msgs_per_month.toLocaleString()} |
    <strong>UDP vs TCP-new savings:</strong> $${savings.toFixed(2)}/month ($${annual_savings.toFixed(2)}/year)
  </div>`;
}

---

8.9 Knowledge Check

Quiz: TCP vs UDP Basics

Quiz: Match Protocol Features

🏷️ Label the Diagram

💻 Code Challenge

📝 Order the Steps

8.10 Summary

Key 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

Concept Relationships

Depends on:

• Layered Network Models - Transport layer (Layer 4) sits between Application and Network layers
• Networking Basics - Understanding packets, headers, ports before transport protocols

Enables:

• TCP Fundamentals and UDP Fundamentals - Deep dives into each protocol
• Application Protocols - MQTT, CoAP, HTTP build on transport layer foundations
• Protocol Selection - Understanding options before choosing

Related concepts:

• Transport layer provides end-to-end communication while network layer handles hop-by-hop routing
• Port numbers enable multiplexing multiple applications over one IP address
• Reliability can be implemented at transport layer (TCP) or application layer (CoAP over UDP)

See Also

Fundamentals:

• OSI and TCP/IP Models - OSI seven layers and TCP/IP four-layer model explained
• Layered Models Fundamentals - Protocol stack layer concepts

External resources:

• RFC 793 - TCP - Transmission Control Protocol
• RFC 768 - UDP - User Datagram Protocol
• Computer Networking: A Top-Down Approach - Kurose & Ross textbook

Common Pitfalls

1. Confusing TCP with UDP Error Detection Capabilities

TCP does not provide stronger error detection than UDP — both use the same 16-bit Internet checksum. TCP’s advantage is error recovery (retransmission on detected error), not better error detection. For a 1,000-byte message, both TCP and UDP have the same ~1-in-65,536 probability of undetected bit errors. Applications requiring high data integrity (firmware images, cryptographic keys) must add their own CRC-32 or SHA-256 verification at the application layer, regardless of transport protocol.

2. Assuming TCP Prevents All Packet Loss

TCP guarantees that bytes are delivered or an error is reported — it does NOT guarantee that bytes are delivered quickly or with bounded latency. During severe network congestion, TCP can reduce throughput to near zero and still report successful delivery (bytes sit in retransmission queues). For real-time IoT applications where data freshness matters more than completeness (live sensor feeds, streaming), “reliable delivery but potentially stale” from TCP is worse than “fresh but occasionally missing” from UDP.

3. Not Understanding TCP Header Options Impact on MTU

A TCP SYN with MSS option, SACK option, window scale option, and timestamp option adds 20–40 bytes of options, reducing the SYN segment’s available payload to 0 (pure handshake). After handshake, TCP options in data segments (timestamps: 10 bytes, SACK: 8–40 bytes) reduce the available payload per segment. A calculated 1460 bytes/segment payload may actually be 1430–1450 bytes with options. Use tcp_info to read the actual MSS in use rather than calculating from MTU alone.

4. Using TCP Urgent Data for IoT Priority Signaling

TCP Urgent (URG) flag and urgent pointer are deprecated and widely ignored by modern network stacks and firewalls. Many middle boxes strip or drop TCP segments with the URG flag set. IoT applications requiring priority data delivery must implement priority at the application layer: separate high-priority MQTT topic, priority queue in the application server, or separate TCP connections for priority vs background data. Never rely on TCP URG for any production IoT priority signaling.

8.11 What’s Next?

You have compared TCP and UDP fundamentals and can now evaluate the right transport protocol for an IoT scenario. Continue your learning with the topics below:

Topic	Link	Why Read It
DTLS Security for UDP	transport-protocols-dtls.html	Secure UDP without TCP+TLS overhead — essential for constrained IoT devices
Protocol Selection Framework	transport-protocols-selection.html	Apply decision matrices to select the best protocol for your deployment
Decision Framework and Pitfalls	transport-protocols-decision-framework.html	Avoid common mistakes when combining transport and application protocols
CoAP — RESTful Protocol for IoT	../app-protocols/coap-fundamentals.html	Implement CoAP over UDP with Confirmable and Non-Confirmable messages
MQTT — TCP-Based Pub/Sub	../app-protocols/mqtt-fundamentals.html	Design publish/subscribe IoT systems using MQTT over TCP
Layered Network Models	../networking-core/layered-network-models.html	Review how Layer 4 fits into the full OSI and TCP/IP stack