4 Transmission Control Protocol (TCP)

4.1 Start With One Connection

Separate a Working Connection From a Completed Action

Picture a building device sending a door command to a service. The connection opens and every byte arrives in order, yet the door stays locked because the service rejects the request. A healthy connection did not prove a successful action.

A protocol is an agreed set of message and timing rules. A gateway is a device that joins one network to another. Transmission Control Protocol (TCP) keeps an ordered byte stream between two endpoints and resends missing parts. Write the application result beside the connection result. Name the request identity, send time, reply, final physical state, and deadline after which the command is no longer safe.

Break one layer at a time. Refuse the connection, lose a segment, delay the reply, close halfway through a message, restart an endpoint, and return an application error over a healthy stream. Check that each failure has a distinct record and recovery rule.

This test does not prove the remote service, user permission, or physical device by itself. The deeper sections show how connection setup, flow, loss recovery, closing, and attack limits support transport evidence without overstating it as end-to-end proof.

Picture a gateway opening a TCP connection before it sends a command that must arrive in order. TCP gives the path connection state, acknowledgements, retransmission, and stream behavior, but it still cannot prove that the application accepted the command correctly. The review starts by separating connection evidence from end-to-end outcome evidence.

4.2 Overview: TCP Evidence Is Connection Evidence, Not Application Proof

TCP gives an application a connection-oriented byte stream. It can provide ordered bytes, acknowledgements, retransmission behavior, flow control, and close state below the application boundary. That makes TCP useful for many IoT paths that need a session, a command channel, a configuration transfer, or a gateway stream.

The review mistake is treating the transport evidence as proof of the whole system result. A completed TCP connection does not prove that the receiver parsed the message, authorized it, stored it, acted on it, or cleaned up application state after close.

Consider a controller that downloads a new sampling interval from a cloud service through a gateway. The TCP trace can show connection setup, bytes acknowledged, retransmissions, and whether the connection closed cleanly. The transport review still needs the application record: where the command frame begins and ends, which endpoint accepted it, whether the gateway forwarded or queued it, and whether the device rejected stale or repeated commands.

This distinction prevents two common overclaims. First, a sender-side ACK does not prove that the final device changed configuration. Second, an orderly close does not prove that the application cleaned up state or persisted the change. The TCP decision is strong only when it is paired with receiver-side evidence and a retest trigger for parser, gateway, security, or reconnect-policy changes.

4.3 Connection-State Attacks

Inspect Figure 4.1 to compare one successful handshake with spoofed branches that consume half-open state and backlog capacity.

Read Figure 4.1 from ACK → ESTABLISHED on the normal handshake path to the spoofed fan-out that leaves every branch in SYN_RCVD. The BACKLOG 9 / 10 meter makes state exhaustion visible, and the defence strip pairs prevention with monitoring.

Then inspect Figure 4.2 to compare three different acceptance boundaries rather than grouping all transport attacks together.

Compare NORMAL FIN with FORGED RST in Figure 4.2, then inspect UDP SWEEP. The VALIDATE strips connect ordered close, sequence-window checks, ICMP rate limits, and ingress source validation to the state transition they protect.

TCP’s guarantees are easiest to keep in scope when the review follows one application path through the transport lifecycle. Figure 4.3 previews that route before the chapter examines individual connection properties.

Trace Figure 4.3 from application purpose and endpoint roles into stream framing, acknowledgements, and flow control. Continue through close or reset state to the retest trigger. The route shows exactly where TCP evidence stops: it can establish byte-stream behavior, but parser acceptance, authorization, persistence, and actuator outcome still require application evidence.

Overview Knowledge Check

4.4 Practitioner: Build the TCP Review Record

A TCP review record should name the application path before it names the protocol. The same product might use TCP safely for configuration transfer, use UDP for replaceable status messages, and require a separate protected command path. The TCP record approves only the tested path and its stated boundaries.

For a practical review, capture one path at a time. If a device keeps a long-lived MQTT connection for telemetry and the same gateway opens a separate TCP connection for firmware download, those are different records. The telemetry record should focus on session reuse, backpressure, reconnect behavior, and message framing. The firmware record should focus on chunk ordering, resume behavior, integrity checks, close/reset recovery, and who owns retry after interruption.

Connection evidence begins with the state transition both endpoints must complete. Inspect Figure 4.4 before using an established socket as evidence for the wider application path.

Read Figure 4.4 from the client’s SYN and SYN_SENT state to the server’s SYN-ACK and SYN_RCVD state, then follow the final ACK until both endpoints are established. The sequence proves negotiated transport state between endpoints; it does not show how later bytes are framed or acted upon. That distinction feeds directly into the practitioner ledger.

4.5 Under the Hood: TCP State Moves Below the Application Boundary

TCP tracks byte-stream state below the application. The transport can acknowledge bytes, retransmit missing data, adjust sending to receiver capacity, and close or reset the connection. The application still owns message meaning, parser state, idempotency, command acceptance, authorization, persistence, and user-visible outcome.

This boundary is why TCP evidence should be connected to receiver evidence. A command response can be truncated by a reset after the command changed state. A telemetry stream can reconnect and repeat the last application frame. A slow receiver can create backpressure that changes queue behavior before TCP itself reports a clear error.

A byte stream also means application framing is not optional evidence. A sender can write one 256-byte command and the receiver can read it as two smaller chunks, or the sender can write two short frames and the receiver can read them together. TCP has not violated its contract in either case. The application parser must still know where each command starts and ends, what to do with partial reads, and how to discard stale bytes after timeout or reset.

Backpressure creates another boundary. A receiver window can slow the sender, but the product behavior depends on queues above TCP: whether telemetry waits, drops, compresses, reports a fault, or closes the session. Under-the-hood review therefore asks for both transport state and application policy before accepting a reliability or latency claim.

Transport-layer state abuse: reset and session injection

A normal TCP close is an ordered state transition, usually exchanging FIN and ACK in each direction so queued bytes can be accounted for. A reset is different: an acceptable RST tells the endpoint to abandon the connection immediately. A forged reset attack therefore needs a packet that matches the connection tuple and passes the receiver's sequence-window validation. An on-path observer can see that state; a blind attacker must guess it. Modern randomized initial sequence numbers and stricter reset validation make blind guessing harder, but they do not stop an on-path party from causing denial of service.

Session injection asks for still more state. A forged segment must name one endpoint's source and destination addresses and ports and present sequence/acknowledgement values the receiver accepts. If a blind injection succeeds, replies normally travel to the spoofed peer, so the attacker may obtain one-way command injection rather than a readable two-way session. An on-path attacker can observe both directions and is consequently a different threat class.

TLS does not prevent an attacker from dropping packets or forcing availability failures, but authenticated record integrity prevents a forged TCP payload from becoming a valid protected application record. Application command ids, freshness windows, authorization, and idempotency remain necessary because a valid peer can still repeat a valid command. Monitor resets by direction, invalid sequence events, challenge acknowledgements, TLS record failures, reconnect storms, and receiver-side transaction ids rather than diagnosing every disconnect from one packet.

The lifecycle review is incomplete until close, reset, and application cleanup evidence are recorded beside setup and transfer behavior. Inspect Figure 4.5 for the fields that support the final bounded decision.

In Figure 4.5, begin with the application path and endpoint roles, then follow framing, acknowledgement, and backpressure evidence into close or reset state. Finish with the security boundary, decision limit, owner, and retest trigger. Reading the record in that order connects transport mechanics to the chapter’s central rule: TCP delivery evidence is necessary but not sufficient application proof.

Under-the-Hood Knowledge Check

4.6 Observe Backpressure before the Gateway Runs out of Memory

Assume the source produces 200 bytes per second while the receiving service drains only 120 bytes per second. The backlog grows at 80 bytes per second. A free queue of 4,800 bytes lasts 4,800 divided by 80 = 60 s under those constant rates. After that, the application needs a defined response such as pausing collection, storing elsewhere or reporting a gap; a successful socket connection does not create more memory.

The TCP receive window can apply flow control when the receiving endpoint cannot accept more bytes. Congestion control addresses a different limit: how much traffic the path can carry without excessive congestion. Neither mechanism determines which telemetry records the product may discard or how long a command remains valid in a sender-side queue.

Read Figure 4.3 from endpoint roles into framing, acknowledgements and flow control. Follow the trace through close or reset as well. The service may acknowledge bytes into its receive buffer before its parser accepts a complete record, so transport progress and durable application storage need separate evidence.

Predict what happens if the gateway reconnects after a timeout and resends the last record. A new established connection does not remember that record’s application identity. The service needs a repeat-handling rule if storing it twice would be wrong. Next, return an explicit validation error over the healthy connection. The gateway must retain the difference between delivered bytes and rejected content.

The connection-state attack diagrams extend the same resource lesson. Figure 4.1 contrasts completed handshakes with half-open backlog pressure, while the reset diagram identifies a separate acceptance boundary. Keep tuning and filtering tied to measured legitimate-service behaviour rather than assuming a larger queue solves every source of pressure.

This module’s TCP promise is powerful but bounded: ordered transport bytes, connection state and flow mechanisms support the service. The application still owns record framing, persistence, expiry and physical outcomes. A queue-growth calculation gives operations a concrete time budget for responding to a slow receiver before the gateway’s useful history is lost.

4.7 Summary

TCP is a strong transport candidate when a reviewed IoT path benefits from connection state, an ordered byte stream, acknowledgements, retransmission behavior, flow control, and explicit close behavior. The evidence still has to stay bounded. TCP can support a transport decision, but it does not prove the receiver parsed, authorized, stored, or acted on an application message.

The useful review record names the application path, endpoint roles, stream framing rule, acknowledgement and retransmission observations, backpressure behavior, close state, security boundary, decision, and retest trigger. Missing framing, missing receiver evidence, or unclear close behavior should lead to revision instead of broad acceptance.

4.8 Key Takeaway

4.9 See Also