Transport Protocols · Study deck

Transmission Control Protocol (TCP)

A gateway streams sensor history to a remote service that has slowed down.

Packet Pete is your guide for this deck.

tcp-reviewconnection-stateacknowledgements

Packet Pete, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: After a SYN arrives, a conventional listener chooses its initial sequence number, returns SYN-ACK, creates a half-open control block in SYN_RCVD, and waits for the final ACK.
Explain: 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.
Explain: 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.
Explain: Connection evidence begins with the state transition both endpoints must complete.

Major section

Start With One Connection

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.

Major section

Start With One Connection (continued)

TCP gives the path connection state, acknowledgements, retransmission, and stream behavior, but it still cannot prove that the application accepted the command correctly.

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.
This test does not prove the remote service, user permission, or physical device by itself.
The review starts by separating connection evidence from end-to-end outcome evidence.

Three transport panels for normal TCP FIN teardown, forged RST acceptance, and spoofed UDP sweep with ICMP amplification controls.

Major section

Connection-State Attacks

The backlog meter reaches 9 of 10 slots, showing how a small amount of incomplete work can crowd out a legitimate client.

The: VALIDATE strips connect ordered close, sequence-window checks, ICMP rate limits, and ingress source validation to the state transition they protect.
SYN cookies or rate controls reduce stored state, while backlog, half-open age, and completion-rate monitoring show whether the protection is working under real traffic.

Normal TCP handshake beside spoofed SYN branches stuck in SYN RCVD, a backlog meter, and defensive controls.

Major section

Practitioner: Build the TCP Review Record

Connection evidence begins with the state transition both endpoints must complete.

The sequence proves negotiated transport state between endpoints; it does not show how later bytes are framed or acted upon.
The three-way handshake costs the listener state before it has proof that the apparent client can receive traffic at its claimed address.
The SYN itself consumes one sequence number, so a legitimate final acknowledgement confirms the server's initial sequence plus one.

TCP connection setup evidence shows the SYN, SYN-ACK, and ACK exchange that establishes transport state, but it still needs application framing and receiver evidence.

Major section

Practitioner: Build the TCP Review Record (continued)

After a SYN arrives, a conventional listener chooses its initial sequence number, returns SYN-ACK, creates a half-open control block in SYN_RCVD, and waits for the final ACK.

A SYN flood exploits that gap with many requests whose final acknowledgements never arrive.
Spoofed source addresses make the SYN-ACK packets go elsewhere; non-spoofed bots can simply abandon the handshake.
Until each half-open entry expires, it consumes backlog, timer, and retransmission work.

Major section

Under the Hood: TCP State Moves Below the Application Boundary

The lifecycle review is incomplete until close, reset, and application cleanup evidence are recorded beside setup and transfer behavior.

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.

A compact TCP decision record keeps stateful transport evidence tied to one application path and one retest boundary.

Major section

Observe Backpressure before the Gateway Runs out of Memory

The backlog grows at 80 bytes per second.

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.
A new established connection does not remember that record's application identity.

TCP review follows the path from application purpose to endpoint role, stream framing, acknowledgement behavior, flow control, close state, and retest trigger.

Major section

Observe Backpressure before the Gateway Runs out of Memory (continued)

Neither mechanism determines which telemetry records the product may discard or how long a command remains valid in a sender-side queue.

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.
The service needs a repeat-handling rule if storing it twice would be wrong.
The gateway must retain the difference between delivered bytes and rejected content.
This module's TCP promise is powerful but bounded: ordered transport bytes, connection state and flow mechanisms support the service.

Major section

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.
Missing framing, missing receiver evidence, or unclear close behavior should lead to revision instead of broad acceptance.

Deck summary

Key takeaways

A healthy connection did not prove a successful action.

TCP gives the path connection state, acknowledgements, retransmission, and stream behavior, but it still cannot prove that the application accepted the command correctly.
The backlog meter reaches 9 of 10 slots, showing how a small amount of incomplete work can crowd out a legitimate client.
Connection evidence begins with the state transition both endpoints must complete.
After a SYN arrives, a conventional listener chooses its initial sequence number, returns SYN-ACK, creates a half-open control block in SYN_RCVD, and waits for the final ACK.

Retrieval practice

Recall check 1 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q1A trace shows that an IoT device opened a TCP connection before sending a command. What is the strongest bounded conclusion?

ATreat connection setup as proof that parsing, authorization, and action all succeeded.

BUse ordered bytes as proof that the path is secure and the command was accepted.

CSkip close and retry evidence once the socket reaches established state.

DConnection setup is shown; parsing, authorization, action, and cleanup still need evidence.

Show answer

Answer: D The trace bounds the transport claim but leaves application behavior to separate evidence.

Retrieval practice

Recall check 2 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q2How should the team assess application message delivery from this TCP trace?

ARevise the record until the application framing evidence is visible.

BAccept the record when the TCP exchange completes successfully.

CUse TCP segment boundaries as the receiver's application message boundaries.

DChoose UDP datagrams to supply the missing framing evidence for this TCP exchange.

Show answer

Answer: A TCP carries a byte stream, so the application boundary needs its own framing evidence.

Retrieval practice

Recall check 3 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q3A device sends a command over TCP and receives a reset before the response is complete. What evidence is still needed before deciding whether to retry?

AInspect app state, idempotency, receiver cleanup, and retry owner.

BUse the reset packet because it proves the receiver changed to the expected state.

CUse the TCP port alone as evidence of the command's final outcome.

DUse retransmitted bytes because successful retries establish safe repeat handling and cleanup.

Show answer

Answer: A TCP reset evidence is not enough by itself; the application state and retry boundary decide the safe action.

Print reference

Answers

Answer key.

D · The trace bounds the transport claim but leaves application behavior to separate evidence.
A · TCP carries a byte stream, so the application boundary needs its own framing evidence.
A · TCP reset evidence is not enough by itself; the application state and retry boundary decide the safe action.