When TCP is required for IoT, three optimization strategies reduce its overhead: connection keep-alive avoids repeated handshakes, TCP Fast Open sends data in the SYN packet, and lightweight stacks (uIP, lwIP) fit in kilobytes of RAM. QUIC, built on UDP, combines TCP’s reliability with UDP’s low latency by eliminating head-of-line blocking – potentially offering the best of both worlds for capable IoT devices.
By the end of this section, you will be able to:
Standard TCP was designed for powerful computers on reliable networks, but IoT devices are small and their connections can be flaky. This chapter covers ways to tune TCP for IoT and introduces QUIC, a modern protocol that combines the reliability of TCP with the speed of UDP. Think of it as upgrading from a bicycle to an electric bike.
“Sometimes we HAVE to use TCP, even for IoT,” said Max the Microcontroller. “When that happens, we use optimization tricks to reduce the overhead. TCP Fast Open sends data in the very first SYN packet – no waiting for the handshake to complete!”
“Connection keep-alive is another trick,” explained Sammy the Sensor. “Instead of tearing down and rebuilding the connection every time I send data, I keep it alive with tiny heartbeat packets. That saves the three-way handshake overhead for repeated transmissions.”
“Lightweight TCP stacks like uIP and lwIP are built for tiny devices,” added Lila the LED. “Standard TCP implementations need megabytes of RAM. These embedded stacks fit in a few kilobytes by only implementing the essential features.”
“And then there is QUIC – the next generation,” said Bella the Battery. “It is built on UDP but provides TCP’s reliability. The big win is zero round-trip connection setup and no head-of-line blocking. If one stream loses a packet, other streams keep flowing. For capable IoT devices, QUIC could be the best of both worlds!”
Before diving into this chapter, you should be familiar with:
Prerequisites:
Deep Dives:
While UDP is often preferred for IoT, sometimes TCP is necessary. Several optimizations exist to reduce overhead.
Problem: TCP handshake overhead for every message
Solution: Keep connection open for multiple transmissions
Trade-off: Memory for connection state vs power for repeated handshakes
Best for: Devices transmitting frequently (e.g., every minute)
Without Keep-Alive (connect per message):
Message 1: Handshake (120 bytes) + Data + Teardown (120 bytes)
Message 2: Handshake (120 bytes) + Data + Teardown (120 bytes)
...
Overhead per message: 240+ bytes
With Keep-Alive:
Initial: Handshake (120 bytes)
Message 1: Data + ACK (64 bytes)
Message 2: Data + ACK (64 bytes)
...
Periodic keep-alive: ~54 bytes every 60-120 seconds
Overhead per message: 64+ bytes (73% reduction)RFC 7413: Allows data in SYN packet (reduces handshake to 1-RTT)
Standard TCP:
Client -> Server: SYN
Server -> Client: SYN-ACK
Client -> Server: ACK + Data (first data after 1.5 RTT)TCP Fast Open:
Client -> Server: SYN + Cookie + Data (data in first packet!)
Server -> Client: SYN-ACK + Data
Total: 1 RTT for first dataBenefits:
Limitations:
| Implementation | Code Size | Features | Best For |
|---|---|---|---|
| uIP | 4-10 KB | Minimal TCP/IP | 8-bit MCUs, extremely constrained |
| lwIP | 40-100 KB | Full-featured, configurable | 32-bit MCUs, more RAM |
| PicoTCP | 50-150 KB | Modular, POSIX-like | Linux-like environments |
| Linux TCP | ~500 KB | Full featured | Gateways, edge devices |
uIP (Micro IP): - Single packet at a time (no send/receive windows) - No support for urgent data - Simple retransmission (fixed timeout) - Fits in 4 KB code, 1-2 KB RAM
lwIP (Lightweight IP): - Configurable features (enable/disable as needed) - Supports multiple connections - Full TCP with windows, selective ACK - Common in ESP32, STM32 projects
MQTT Keep-Alive: Maintain TCP connection with periodic pings - Keep-alive interval: 60-120 seconds typical - Prevents NAT timeout - Detects dead connections
HTTP Persistent Connections: HTTP/1.1 connection reuse - Single TCP connection for multiple requests - Eliminates handshake per request
CoAP over TCP: RFC 8323, combines CoAP efficiency with TCP reliability - For networks where UDP is problematic (firewalls, NAT) - Maintains CoAP’s lightweight message format
QUIC (Quick UDP Internet Connections) is a modern transport protocol originally developed by Google and now standardized as RFC 9000. While TCP and UDP dominate IoT today, QUIC offers compelling advantages for next-generation IoT applications.
QUIC is a UDP-based transport protocol that combines TCP’s reliability with UDP’s low latency, while integrating TLS 1.3 encryption:
Traditional Stack: QUIC Stack:
+------------------+ +------------------+
| Application | | Application |
+------------------+ +------------------+
| TLS | | |
+------------------+ | QUIC |
| TCP | | (includes TLS) |
+------------------+ +------------------+
| IP | | UDP |
+------------------+ +------------------+
| IP |
+------------------+1. 0-RTT Connection Resumption
For repeated connections (common in IoT telemetry), QUIC can send application data immediately:
First Connection: Subsequent Connections:
Client Server Client Server
| | | |
|--- ClientHello --> |--- 0-RTT Data ---> |
|<-- ServerHello ---| |<-- Response -------|
|--- Finished -----> | |
|<-- Finished ------| Total: 0 RTT
|--- Data --------->
Total: 1 RTT (vs TCP+TLS: 3 RTT)IoT Impact: Battery-powered sensors can save 2 round trips (100-500ms) per connection, reducing radio-on time by 30-60%.
2. Multiplexed Streams Without Head-of-Line Blocking
QUIC allows multiple independent streams. Unlike TCP, packet loss on one stream doesn’t block others:
TCP with HTTP/2: QUIC:
Stream 1: [Pkt1][Pkt2][----] Stream 1: [Pkt1][Pkt2][----] <- Waiting
Stream 2: [Pkt3][Pkt4][ BLOCKED ] Stream 2: [Pkt3][Pkt4][Pkt5] <- Continues!
Stream 3: [Pkt5][ BLOCKED ] Stream 3: [Pkt6][Pkt7] <- Continues!
Lost Pkt2 blocks ALL streams Lost Pkt2 only affects Stream 1IoT Impact: A gateway multiplexing data from 10 sensors can continue sending data for 9 sensors even if one sensor’s packet is lost.
3. Connection Migration
QUIC connections are identified by Connection ID, not IP:port. Connections survive address changes:
Before Network Switch: After:
192.168.1.50:54321 -> Server 10.0.0.75:42000 -> Server
Connection ID: 0xABCD Connection ID: 0xABCD (same!)
Connection continues without reset!IoT Impact: Mobile sensors (vehicles, wearables) can switch between Wi-Fi and cellular without losing connection.
4. Built-in Encryption (Always On)
QUIC mandates TLS 1.3 encryption with no fallback to plaintext:
QUIC Packet Structure:
+------------------+------------------+------------------+
| Header (clear) | Payload (encrypted) |
| Conn ID, PN | Stream Data, ACKs, Control |
+------------------+------------------+------------------+
^
Everything here is authenticated and encryptedIoT Impact: Eliminates the separate DTLS handshake overhead while providing equivalent security.
| Metric | TCP+TLS 1.2 | UDP+DTLS 1.2 | QUIC |
|---|---|---|---|
| Initial handshake | 3.5 RTT (1.5 TCP + 2 TLS) | 2-3 RTT | 1 RTT |
| Resumed connection | 1-2 RTT (session ticket) | 1 RTT | 0 RTT |
| Header overhead | 20-60 B (TCP) + 5 B (TLS record) | 8 B (UDP) + 13 B (DTLS record) | 1-21 B (short/long header) |
| Packet loss impact | All streams blocked | Application handles | Per-stream only |
| Network migration | Connection drops | Application handles | Transparent |
| Encryption | Optional (TLS) | Optional (DTLS) | Mandatory (TLS 1.3) |
Memory Requirements:
Lightweight TCP stack (uIP): 4-10 KB code, 1-2 KB RAM per connection
Lightweight UDP: 2-4 KB code, minimal RAM
QUIC (minimal): 50-100 KB code, 10-20 KB RAM per connection
QUIC (full featured): 200-500 KB code, 50-100 KB RAM per connectionWhen QUIC Makes Sense for IoT:
When to Stick with TCP/UDP:
Scenario: Sensor sending 100-byte reading every 60 seconds over 100ms RTT network
TCP+TLS 1.2 (new connection each time):
TCP handshake: 1.5 RTT x 100ms = 150ms active
TLS 1.2 handshake: 2 RTT x 100ms = 200ms active
Data transfer: 1 RTT = 100ms active
Total per reading: ~450ms radio time
Daily (1440 readings): 648 seconds active
QUIC (0-RTT resumption, after first connection):
Data piggybacked on Initial packet: 0 RTT wait
Response: 1 RTT = 100ms active
Total per reading: 100ms radio time
Daily (1440 readings): 144 seconds active
Energy savings: ~78% reduction in radio-on time!Explore how network RTT and message frequency affect radio-on time for QUIC (0-RTT resumption) versus TCP+TLS (full handshake each time).
viewof quic_rtt = Inputs.range([10, 500], {
value: 100, step: 10, label: "Network RTT (ms)"
})
viewof quic_msg_interval = Inputs.range([10, 600], {
value: 60, step: 10, label: "Message interval (seconds)"
})
viewof radio_tx_ma = Inputs.range([20, 300], {
value: 120, step: 10, label: "Radio TX current (mA)"
}){
const msgs_per_day = Math.floor(86400 / quic_msg_interval);
// TCP+TLS 1.2: 1.5 RTT TCP handshake + 2 RTT TLS 1.2 + 1 RTT data = 4.5 RTT per message
const tcp_radio_per_msg_ms = quic_rtt * 4.5;
const tcp_daily_sec = (msgs_per_day * tcp_radio_per_msg_ms) / 1000;
// QUIC 0-RTT: response takes 1 RTT
const quic_radio_per_msg_ms = quic_rtt * 1;
const quic_daily_sec = (msgs_per_day * quic_radio_per_msg_ms) / 1000;
const savings_pct = ((tcp_daily_sec - quic_daily_sec) / tcp_daily_sec * 100).toFixed(1);
// Energy: mAh = (seconds * mA) / 3600
const tcp_daily_mah = (tcp_daily_sec * radio_tx_ma / 3600).toFixed(2);
const quic_daily_mah = (quic_daily_sec * radio_tx_ma / 3600).toFixed(2);
const colors = { navy: "#2C3E50", teal: "#16A085", orange: "#E67E22", blue: "#3498DB" };
const width = 580;
const height = 220;
const margin = { top: 30, right: 100, bottom: 50, left: 100 };
const svg = d3.create("svg")
.attr("viewBox", `0 0 ${width} ${height}`)
.attr("width", "100%")
.style("max-width", `${width}px`)
.style("font-family", "Arial, sans-serif");
const barData = [
{ label: "TCP+TLS", value: tcp_daily_sec, color: colors.orange, mah: tcp_daily_mah },
{ label: "QUIC 0-RTT", value: quic_daily_sec, color: colors.teal, mah: quic_daily_mah }
];
const maxVal = d3.max(barData, d => d.value);
const xScale = d3.scaleLinear()
.domain([0, maxVal * 1.2])
.range([margin.left, width - margin.right]);
const yScale = d3.scaleBand()
.domain(barData.map(d => d.label))
.range([margin.top, height - margin.bottom])
.padding(0.4);
svg.append("text")
.attr("x", width / 2).attr("y", 16)
.attr("text-anchor", "middle")
.style("font-size", "13px").style("font-weight", "bold").style("fill", colors.navy)
.text("Daily Radio-On Time (seconds)");
svg.selectAll("rect")
.data(barData).join("rect")
.attr("x", margin.left)
.attr("y", d => yScale(d.label))
.attr("width", d => Math.max(2, xScale(d.value) - margin.left))
.attr("height", yScale.bandwidth())
.attr("fill", d => d.color)
.attr("rx", 4);
svg.selectAll(".bar-label")
.data(barData).join("text")
.attr("class", "bar-label")
.attr("x", d => xScale(d.value) + 6)
.attr("y", d => yScale(d.label) + yScale.bandwidth() / 2 + 4)
.style("font-size", "11px").style("fill", colors.navy)
.text(d => `${d.value.toFixed(1)}s (${d.mah} mAh)`);
svg.selectAll(".y-label")
.data(barData).join("text")
.attr("class", "y-label")
.attr("x", margin.left - 8)
.attr("y", d => yScale(d.label) + yScale.bandwidth() / 2 + 4)
.attr("text-anchor", "end")
.style("font-size", "11px").style("fill", colors.navy)
.text(d => d.label);
svg.append("text")
.attr("x", margin.left).attr("y", height - 10)
.style("font-size", "11px").style("fill", colors.navy)
.text(`${msgs_per_day} msgs/day | Energy savings: ${savings_pct}% | Per-message latency: ${tcp_radio_per_msg_ms.toFixed(0)} ms (TCP) vs ${quic_radio_per_msg_ms.toFixed(0)} ms (QUIC)`);
return svg.node();
}Phase 1: QUIC for gateway-to-cloud (immediate benefit)
Phase 2: QUIC for capable edge devices
Phase 3: CoAP-over-QUIC for constrained devices (when mature)Understanding the mechanics of connection reuse reveals why it saves energy:
TCP Keep-Alive Mechanism:
Energy Savings Formula:
Energy_per_message = (handshake_cost / messages_per_connection) + data_transmission_costKeep-alive connections amortize the handshake cost across multiple messages. For a sensor sending 10-byte readings every 30 seconds over an hour:
Number of messages per hour: \[N = \frac{3600\text{ sec}}{30\text{ sec}} = 120\text{ messages}\]
TCP per-message (reconnect each time): \[\begin{align} \text{Per message} &= 120\text{ B handshake} + 64\text{ B data} + 120\text{ B teardown} = 304\text{ B} \\ \text{Hourly total} &= 120 \times 304 = 36{,}480\text{ B} \end{align}\]
TCP keep-alive (persistent connection): \[\begin{align} \text{Initial} &= 120\text{ B handshake (once)} \\ \text{Per message} &= 64\text{ B data} \\ \text{Keep-alive probes} &= 0\text{ (data every 30s keeps connection alive)} \\ \text{Hourly total} &= 120 + (120 \times 64) = 7{,}800\text{ B} \end{align}\]
Note: With data sent every 30 seconds, the connection stays active without explicit keep-alive probes (typically triggered only after 60–120 seconds of idle time).
Overhead reduction: \[\text{Savings} = \frac{36{,}480 - 7{,}800}{36{,}480} = 78.6\%\]
At 250 kbps (31,250 B/s) with 50 mA TX current: - Reconnect: \(\frac{36{,}480}{31{,}250} = 1.17\text{ sec active} \Rightarrow 1.17 \times \frac{50}{3{,}600} = 0.016\text{ mAh/hour}\) - Keep-alive: \(\frac{7{,}800}{31{,}250} = 0.25\text{ sec active} \Rightarrow 0.25 \times \frac{50}{3{,}600} = 0.0035\text{ mAh/hour}\)
These are the raw byte-transmission costs only. In practice, radio wake-up, idle listening, and RTT waiting dominate. For LTE-M (120 mA TX, 200 ms RTT): each reconnection holds the radio active for ~550 ms at 120 mA, giving 1.1 mAh/hour (reconnect) vs 0.27 mAh/hour (keep-alive), a ~79% energy reduction.
For 120 messages over a 1-hour connection: - Amortized handshake: 120 bytes / 120 = 1 byte per message - Data transmission: 64 bytes per message - Total: 65 bytes vs 304 bytes (reconnect) = 79% reduction
DTLS Session Resumption:
Why It Works:
Trade-off: Connection state consumes memory (500 bytes TCP + 100 bytes DTLS session = 600 bytes per device). For 10,000 devices, that’s 6 MB server RAM—trivial for cloud servers, but prohibitive for 64 KB RAM gateways.
Use this calculator to explore how message frequency and connection parameters affect the overhead savings of TCP keep-alive connections compared to per-message reconnection.
viewof msg_interval = Inputs.range([5, 300], {
value: 30, step: 5, label: "Message interval (seconds)"
})
viewof payload_size = Inputs.range([10, 500], {
value: 64, step: 10, label: "Payload size (bytes)"
})
viewof tls_handshake = Inputs.range([0, 5000], {
value: 2000, step: 100, label: "TLS handshake (bytes)"
})
viewof rtt_ms = Inputs.range([10, 500], {
value: 100, step: 10, label: "Round-trip time (ms)"
}){
const tcp_handshake = 120;
const tcp_teardown = 120;
const ack_header = 40;
const keepalive_probe = 54;
const msgs_per_hour = Math.floor(3600 / msg_interval);
const keepalive_interval = 60;
// Reconnect: full handshake + TLS + data + teardown per message
const reconnect_per_msg = tcp_handshake + tls_handshake + payload_size + ack_header + tcp_teardown;
const reconnect_hourly = reconnect_per_msg * msgs_per_hour;
// Keep-alive: one handshake + TLS, then data only
const probes_per_hour = msg_interval > keepalive_interval
? Math.floor(3600 / keepalive_interval) - msgs_per_hour
: 0;
const keepalive_hourly = tcp_handshake + tls_handshake
+ msgs_per_hour * (payload_size + ack_header)
+ Math.max(0, probes_per_hour) * keepalive_probe;
const savings_pct = ((reconnect_hourly - keepalive_hourly) / reconnect_hourly * 100).toFixed(1);
// Latency
const reconnect_latency = rtt_ms * 4.5; // 1.5 TCP + 2 TLS + 1 data
const keepalive_latency = rtt_ms * 1; // data only
const monthly_reconnect = (reconnect_hourly * 24 * 30 / 1e6).toFixed(1);
const monthly_keepalive = (keepalive_hourly * 24 * 30 / 1e6).toFixed(1);
const colors = { navy: "#2C3E50", teal: "#16A085", orange: "#E67E22", blue: "#3498DB" };
const barData = [
{ label: "Reconnect", value: reconnect_hourly, color: colors.orange },
{ label: "Keep-Alive", value: keepalive_hourly, color: colors.teal }
];
const width = 580;
const height = 200;
const margin = { top: 30, right: 120, bottom: 40, left: 100 };
const svg = d3.create("svg")
.attr("viewBox", `0 0 ${width} ${height}`)
.attr("width", "100%")
.style("max-width", `${width}px`)
.style("font-family", "Arial, sans-serif");
const maxVal = d3.max(barData, d => d.value);
const xScale = d3.scaleLinear()
.domain([0, maxVal * 1.15])
.range([margin.left, width - margin.right]);
const yScale = d3.scaleBand()
.domain(barData.map(d => d.label))
.range([margin.top, height - margin.bottom])
.padding(0.4);
svg.append("text")
.attr("x", width / 2).attr("y", 16)
.attr("text-anchor", "middle")
.style("font-size", "13px").style("font-weight", "bold").style("fill", colors.navy)
.text("Hourly Data Overhead Comparison");
svg.selectAll("rect")
.data(barData).join("rect")
.attr("x", margin.left)
.attr("y", d => yScale(d.label))
.attr("width", d => xScale(d.value) - margin.left)
.attr("height", yScale.bandwidth())
.attr("fill", d => d.color)
.attr("rx", 4);
svg.selectAll(".bar-label")
.data(barData).join("text")
.attr("class", "bar-label")
.attr("x", d => xScale(d.value) + 6)
.attr("y", d => yScale(d.label) + yScale.bandwidth() / 2 + 4)
.style("font-size", "11px").style("fill", colors.navy)
.text(d => `${(d.value / 1000).toFixed(1)} KB`);
svg.selectAll(".y-label")
.data(barData).join("text")
.attr("class", "y-label")
.attr("x", margin.left - 8)
.attr("y", d => yScale(d.label) + yScale.bandwidth() / 2 + 4)
.attr("text-anchor", "end")
.style("font-size", "11px").style("fill", colors.navy)
.text(d => d.label);
const summaryY = height - 8;
svg.append("text")
.attr("x", margin.left).attr("y", summaryY)
.style("font-size", "11px").style("fill", colors.navy)
.text(`${msgs_per_hour} msgs/hr | Savings: ${savings_pct}% | Monthly: ${monthly_reconnect} MB vs ${monthly_keepalive} MB | Latency: ${reconnect_latency.toFixed(0)} ms vs ${keepalive_latency.toFixed(0)} ms`);
return svg.node();
}A logistics company operates 2,000 delivery trucks, each equipped with an ESP32 tracking unit that reports GPS, speed, and cargo temperature every 30 seconds to a cloud server over LTE-M (100 ms RTT). The engineering team must decide between TCP keep-alive (persistent connection) and per-message reconnection.
Given:
Option A: Reconnect Every Message (TCP+TLS each time)
| Step | Bytes | Time |
|---|---|---|
| TCP handshake | 120 | 150 ms (1.5 RTT) |
| TLS handshake | 2,000 | 200 ms (2 RTT) |
| Data + ACK | 64 + 40 = 104 | 100 ms (1 RTT) |
| TCP teardown | 120 | 100 ms (1 RTT) |
| Total per message | 2,344 | 550 ms |
Monthly data per truck: 2,344 bytes x 2 msg/min x 60 min x 24 hr x 30 days = 202 MB/month
Monthly cost per truck: 202 x $0.50 = $101/month
Fleet monthly cost: 2,000 x $101 = $202,000/month
Option B: TCP Keep-Alive (persistent connection)
| Step | Bytes | Time |
|---|---|---|
| Initial TCP+TLS (once per hour) | 2,120 | 350 ms |
| Data + ACK per message | 104 | 100 ms |
| MQTT keep-alive probes (1/min) | 55 | – |
| Total per message (amortized) | ~149 | 100 ms |
Monthly data per truck:
Monthly cost per truck: 12.9 x $0.50 = $6.45/month
Fleet monthly cost: 2,000 x $6.45 = $12,900/month
Result:
| Metric | Reconnect | Keep-Alive | Improvement |
|---|---|---|---|
| Data per truck/month | 202 MB | 12.9 MB | 15.7x reduction |
| Cost per truck/month | $101 | $6.45 | 15.7x cheaper |
| Fleet monthly cost | $202,000 | $12,900 | Saves $189,100/month |
| Latency per message | 550 ms | 100 ms | 5.5x faster |
| Annual fleet savings | – | – | $2.27 million |
Why Not Always Use Keep-Alive? Keep-alive connections consume memory on the server side (~10 KB per connection for TLS session state). For 2,000 trucks, the server needs 20 MB – trivial for a cloud server. But for 2 million devices, that becomes 20 GB, requiring connection multiplexing or QUIC. The break-even point depends on message frequency: keep-alive wins when messages arrive more often than every 5 minutes. For hourly or daily sensors, the keep-alive overhead itself dominates.
TCP Optimizations:
QUIC Benefits:
When to Optimize TCP vs Switch to UDP:
Memory Requirements:
Builds on:
Extends to:
Contrasts with:
Common Misconceptions:
Key Insight: Optimization doesn’t change protocol semantics—TCP keep-alive is still TCP, QUIC is still reliable. Optimizations reduce overhead while maintaining guarantees.
Related Transport Concepts:
Implementation Guides:
Deep Dives:
External Resources:
Objective: Configure and measure TCP keep-alive on an ESP32 sending MQTT data.
Equipment:
Task 1: Baseline (No Keep-Alive)
// Arduino/ESP32 code
#include <WiFi.h>
#include <PubSubClient.h>
WiFiClient espClient;
PubSubClient client(espClient);
void setup() {
// Connect to Wi-Fi
WiFi.begin("SSID", "PASSWORD");
while (WiFi.status() != WL_CONNECTED) delay(500);
// Connect to MQTT broker
client.setServer("broker.hivemq.com", 1883);
client.connect("ESP32_Client");
// Publish message
client.publish("test/topic", "Hello from ESP32");
delay(1000);
// Disconnect immediately
client.disconnect();
}Task 2: Enable TCP Keep-Alive
void setup() {
WiFi.begin("SSID", "PASSWORD");
while (WiFi.status() != WL_CONNECTED) delay(500);
client.setServer("broker.hivemq.com", 1883);
client.setKeepAlive(60); // 60-second keep-alive
client.connect("ESP32_Client");
// Publish 10 messages over 10 minutes
for (int i = 0; i < 10; i++) {
client.publish("test/topic", String("Message " + String(i)).c_str());
delay(60000); // Wait 60 seconds
client.loop(); // Maintain connection
}
client.disconnect();
}Task 3: Packet Analysis Using Wireshark, capture packets during both tests: 1. Filter for TCP traffic: tcp.port == 1883 2. Count handshake packets (SYN, SYN-ACK, ACK) 3. Identify keep-alive probes (ACK with 1-byte payload) 4. Measure total bytes transmitted
Expected Results:
Challenge: Modify the code to use TLS (via WiFiClientSecure on port 8883) and measure the difference between full TLS handshake overhead and TLS session resumption.
TCP Fast Open requires both client and server support. Sending TFO data (SYN+data) to a server that does not support TFO causes the server to retransmit a plain SYN-ACK (dropping the data in the SYN), wasting the optimization and potentially causing compatibility issues with stateful firewalls. Test TFO support with: tcp_fastopen sysctl=3 on Linux, verify with ss -i to check tcpi_options for TFO flag. Disable TFO in firmware for IoT devices that cannot control the server environment.
QUIC provides benefits for web/HTTP workloads (multiplexed streams, 0-RTT resumption, no head-of-line blocking). For IoT, QUIC’s TLS 1.3 requirement and connection establishment overhead (still 1 RTT minimum) may not improve on well-tuned DTLS+CoAP (stateless, 0-RTT possible). QUIC is most beneficial for gateway-to-cloud communication where multiple parallel IoT streams benefit from multiplexing without head-of-line blocking. For constrained device-to-gateway, CoAP/DTLS with session resumption is typically more efficient.
Manually setting SO_RCVBUF and SO_SNDBUF to large values (e.g., 4 MB) overrides Linux kernel autotuning, which already adjusts buffers based on measured throughput. Forcing large buffers on low-bandwidth paths wastes kernel memory without performance benefit; on high-bandwidth paths, autotuning typically matches or exceeds manual settings. Measure actual throughput bottleneck with iperf3 -J (JSON output) before adjusting buffer sizes.
Blocking send() on a non-blocking socket returns EAGAIN when the socket buffer is full; on a blocking socket, it blocks until space is available. For large IoT data uploads (firmware images, data dumps), blocking send() in the main application thread prevents concurrent operations (sensor reading, watchdog petting, UI updates). Use non-blocking I/O with select()/poll()/epoll() or a dedicated transmission thread with a message queue to allow concurrent operations during large data uploads.
Continue your study of transport protocols with these chapters:
| Chapter | Topic | Why Read It |
|---|---|---|
| Transport Protocol Decision Framework | Structured selection matrices | Apply optimization knowledge to choose the right protocol for any IoT scenario |
| Overhead Analysis | Quantitative overhead comparisons | Calculate exact byte and energy costs for TCP, UDP, QUIC, and CoAP |
| DTLS Security | Datagram TLS for constrained devices | Extend session resumption concepts to secure UDP communications |
| CoAP Protocol Fundamentals | Application-layer efficiency over UDP | Build on TCP optimization principles using a protocol designed for constrained networks |
| MQTT Keep-Alive | Application-layer connection maintenance | See how MQTT leverages TCP keep-alive at the messaging layer |
| Protocol Selection | When to use TCP, UDP, or QUIC | Consolidate all protocol trade-off knowledge into practical selection guidelines |