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.

Major section

Connection-State Attacks

The: BACKLOG 9 / 10 meter makes state exhaustion visible, and the defence strip pairs prevention with monitoring.

The: VALIDATE strips connect ordered close, sequence-window checks, ICMP rate limits, and ingress source validation to the state transition they protect.

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.

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.

The SYN itself consumes one sequence number, so a legitimate final acknowledgement confirms the server's initial sequence plus one.
A SYN flood exploits that gap with many requests whose final acknowledgements never arrive.
The defensive response is not to rely on obscurity.

Major section

Practitioner: Build the TCP Review Record (continued)

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.
Once that queue or another resource limit is exhausted, legitimate SYN traffic is dropped or delayed even though the application workers may be healthy.
Port scanning is reconnaissance at the same boundary: different replies can reveal open, closed, or filtered services and sometimes expose a service fingerprint.

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.

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 9 / 10 meter makes state exhaustion visible, and the defence strip pairs prevention with monitoring.
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.

Q2A TCP trace shows a completed connection and byte transfer, but the record does not show how the receiver separates application messages inside the byte stream. What is the strongest review action?

ARevise the record until the application framing evidence is visible.

BAccept the record because TCP completion is the same as application acceptance.

CRemove peer identity evidence to focus only on connection setup.

DSwitch every IoT flow to UDP because TCP stream framing requires review.

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?

AApplication state after the partial exchange, command idempotency, receiver cleanup, and the retry owner.

BOnly the reset packet, without checking whether the receiver parsed the command, changed state, or logged cleanup.

COnly the TCP port number, because ports determine the command outcome.

DNo extra evidence after seeing retransmitted bytes, without checking command idempotency or receiver 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.