4 Transmission Control Protocol (TCP)
TCP transport review, IoT TCP evidence, TCP connection state, TCP acknowledgement record, TCP close behavior
4.1 Start With One Connection
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.
If you only need the intuition, this layer is enough: TCP can protect byte-stream order and retry missing bytes below the application, but the review still needs message framing, receiver behavior, security boundary, and retest evidence.
Connection
Which endpoint opens the connection, which endpoint listens, what identifies the peer, and what evidence shows established state?
Byte Stream
How does the application find one complete message inside a stream that can split or combine reads?
Backpressure
What happens when the receiver, gateway, queue, or application cannot keep up with the sender?
Close State
How are graceful close, reset, idle timeout, reconnect, and stale application state handled?
Overview Knowledge Check
4.3 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.
Accept
The path, roles, framing, acknowledgements, backpressure, close state, security boundary, limits, and retest triggers are all visible for the reviewed scope.
Revise
The TCP trace is useful, but one required field is missing or overclaims what the transport evidence proves.
Defer
The reviewer cannot tie the trace, endpoint, parser, security boundary, or receiver action to the candidate configuration.
Practitioner Knowledge Check
4.4 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.
Acknowledgements
Acknowledgements show byte-stream progress below the application. They do not prove payload validity, authorization, storage, or command execution.
Retransmission
Retransmission can recover missing bytes for the stream, but it does not define whether an application operation is safe to repeat.
Flow Control
Receiver pressure can change system behavior before the final outcome is visible. The review should capture queue, wait, fault, or close decisions.
Close and Reset
Close and reset events can leave uncertainty about partial responses, stale session state, and retry ownership unless the record ties them to receiver evidence.
Under-the-Hood Knowledge Check
4.5 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.6 Key Takeaway
Use TCP evidence to review connection and byte-stream behavior; use receiver evidence to prove application meaning, cleanup, and retry safety. Do not let a successful connection stand in for an application outcome.