WEB / WEB-04.01

How is a TCP connection established?

Read the three-way handshake through separate peer states and sequence information as well as flags.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Three-way handshake

Initial separate states
The listener is a selected ready condition. This inert trace does not open an actual socket.
Client TCP
CLOSED; client 192.0.2.10:51000
Server TCP
LISTEN; server 198.51.100.200:443
Local active open
The client became SYN-SENT; the server has not received SYN. Local preparation is not a transfer.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
LISTEN; server 198.51.100.200:443
SYN arrived at server
SYN consumes one sequence position despite having no payload. The server is now SYN-RECEIVED and client SYN-SENT.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; client next=1001; server ISN=7000
Local SYN+ACK preparation
The server combines its SYN with acknowledgment of the client SYN. Client state is unchanged.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
SYN+ACK arrived at client
ACK=1001 acknowledges client SYN. The client becomes ESTABLISHED; the server has not yet received final ACK.
Client TCP
ESTABLISHED; received SYN+ACK; server next=7001
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
Local final ACK preparation
The payload-free ACK consumes no sequence space; the client’s next data start remains 1001.
Client TCP
ESTABLISHED; ACK prepared SEQ=1001 ACK=7001
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
ACK arrived at server
The server received acknowledgment of its SYN and became ESTABLISHED. This is transport synchronization only.
Client TCP
ESTABLISHED; ACK prepared SEQ=1001 ACK=7001
Server TCP
ESTABLISHED; received ACK=7001; client next=1001

Final ACK arrival unobserved

Initial separate states
The listener is a selected ready condition. This inert trace does not open an actual socket.
Client TCP
CLOSED; client 192.0.2.10:51000
Server TCP
LISTEN; server 198.51.100.200:443
Local active open
The client became SYN-SENT; the server has not received SYN. Local preparation is not a transfer.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
LISTEN; server 198.51.100.200:443
SYN arrived at server
SYN consumes one sequence position despite having no payload. The server is now SYN-RECEIVED and client SYN-SENT.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; client next=1001; server ISN=7000
Local SYN+ACK preparation
The server combines its SYN with acknowledgment of the client SYN. Client state is unchanged.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
SYN+ACK arrived at client
ACK=1001 acknowledges client SYN. The client becomes ESTABLISHED; the server has not yet received final ACK.
Client TCP
ESTABLISHED; received SYN+ACK; server next=7001
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
Local final ACK preparation
The payload-free ACK consumes no sequence space; the client’s next data start remains 1001.
Client TCP
ESTABLISHED; ACK prepared SEQ=1001 ACK=7001
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
Missing-arrival boundary
Final ACK arrival at the server is not shown. Its last modeled state is SYN-RECEIVED; later behavior is undetermined.
Client TCP
ESTABLISHED; final ACK arrival unobserved; cause unknown
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001

SYN+ACK arrival unobserved

Initial separate states
The listener is a selected ready condition. This inert trace does not open an actual socket.
Client TCP
CLOSED; client 192.0.2.10:51000
Server TCP
LISTEN; server 198.51.100.200:443
Local active open
The client became SYN-SENT; the server has not received SYN. Local preparation is not a transfer.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
LISTEN; server 198.51.100.200:443
SYN arrived at server
SYN consumes one sequence position despite having no payload. The server is now SYN-RECEIVED and client SYN-SENT.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; client next=1001; server ISN=7000
Local SYN+ACK preparation
The server combines its SYN with acknowledgment of the client SYN. Client state is unchanged.
Client TCP
SYN-SENT; SYN prepared SEQ=1000
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001
The trace stops here
There is no SYN+ACK arrival. This state observation is not a diagnosis of timeout, filtering or OS error.
Client TCP
SYN-SENT; SYN+ACK arrival unobserved; cause unknown
Server TCP
SYN-RECEIVED; SYN+ACK prepared SEQ=7000 ACK=1001

ACTORS · STATE · DATA FLOW

Transport identifies endpoints within hosts

IP helps carry packets between addressed hosts. TCP and UDP use ports to distinguish transport endpoints within a host, with protocol included in the identity. The artifact selects a TCP endpoint pair between client 192.0.2.10:51000 and server 198.51.100.200:443. A UDP endpoint using the same numeric port is not this TCP connection.

A port is not an immutable process name; a listening endpoint can accept multiple connections. Each connection has local/remote address and port context. DNS, routing and the server listener are selected ready conditions here, not measured outcomes inferred from the handshake diagram.

A TCP connection is state held at both ends

A connection does not build a physical circuit. TCP endpoints maintain state, sequence numbers, acknowledgments and buffers to provide an ordered reliable byte stream. The two directions need not traverse the same IP path. This lesson focuses on the two transport peers rather than repeating intermediate routing.

Reliability does not mean the peer application processed the data or approved a business operation. Transport-delivery evidence differs from an application response, persistence or authorization result. A connection may fail later; completing a handshake promises neither an eternal connection nor a loss-free network.

Separate streams from message boundaries

TCP does not preserve application-write boundaries as matching receiver reads. Writes NO and TE01 may be read as N, OTE and 01, reconstructing NOTE01 in byte order. The application protocol defines message framing. Neither a TCP segment nor a read chunk is automatically one complete HTTP message.

UDP preserves datagram boundaries but does not itself guarantee delivery, ordering or duplicate protection. An upper protocol can add such properties: QUIC uses UDP datagrams with its own connection and ordered-stream mechanisms. It does not use TCP’s three-way handshake. Detailed UDP/QUIC behavior belongs to later topics.

First arrival: SYN reached the server

Initially the client is CLOSED and the server LISTEN. A local active open moves the client to SYN-SENT and prepares SYN with selected ISN=1000. On SYN arrival the server becomes SYN-RECEIVED; the client has received nothing from the server and remains SYN-SENT. One arrival does not establish both endpoints simultaneously.

SYN consumes one sequence-space position even with no payload, so the server next expects client sequence 1001. Values 1000/7000 are chosen for this original example, not a real ISN-generation algorithm or security choice. The artifact summarizes flags/seq/ack rather than encoding full packets.

Second and third arrivals: readiness is staggered

The server’s SYN+ACK communicates its ISN=7000 and ACK=1001. On valid arrival, the client becomes ESTABLISHED while the server remains SYN-RECEIVED until it receives the final ACK. The client prepares an ACK acknowledging server SYN with 7001. Arrival of that ACK moves the server to ESTABLISHED.

The payload-free final ACK has SEQ=1001 and ACK=7001. An ACK flag alone consumes no sequence space, so the client’s next data byte can still start at 1001. This lesson selects ordinary active/passive open with no handshake payload. Simultaneous open, data in SYN, options, windows, retransmission timers and closing are outside the model.

An incomplete observation does not prove a failure cause

If final ACK arrival is absent from this trace, the last modeled states are client ESTABLISHED and server SYN-RECEIVED. Without SYN+ACK arrival the client remains SYN-SENT. These are limits of the selected trace, not diagnoses of packet loss, firewall policy, OS timeout or server failure. Real TCP may later retransmit, continue or abort.

The handshake shows transport synchronization only. Selecting port 443 does not establish TLS identity verification, an HTTP request or application authorization. Two ESTABLISHED labels at the end of an animation do not prove Atlas Notes displayed successfully or that a user may access private data.

Read every scenario without motion

ACK scope

SYN state belongs to one endpoint
Active open puts the client in SYN-SENT while the server remains LISTEN. Local SYN preparation is not server receipt; both states are not updated at once.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
No completion gate
Application outcome
No business outcome
State is asymmetric after SYN+ACK
SYN+ACK arrival makes the client ESTABLISHED while the server remains SYN-RECEIVED. Server completion cannot be inferred before final ACK arrival.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
Client established / server pending
Application outcome
No business outcome
A false-success gate was closed
TCP synchronization is not application receipt or database commit. TLS handshake and HTTP request are not-modeled in evidenceBoundary.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
Client established / server pending
Application outcome
Transport complete ≠ business complete
Sequence space and payload were separated
Client SYN has sequence 1000. Even without payload, SYN consumes one position, making the next expected value 1001. Server SYN 7000 yields 7001; a payload-free final ACK consumes no new space.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Client established / server pending
Application outcome
Transport complete ≠ business complete
Application framing remains separate
NO+TE01 writes and N+OTE+01 reads concatenate to NOTE01. TCP preserves no message boundaries; reconstructed bytes alone do not establish a complete application message.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Stream NOTE01 / framing separate
Application outcome
Transport complete ≠ business complete
No unsupported failure cause was selected
A normal final ACK may complete synchronization states; business success still needs a separate application result. Port 443 or ESTABLISHED does not provide identity.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Stream NOTE01 / framing separate
Application outcome
Transport separate / application unknown

Peer-state split

SYN state belongs to one endpoint
Active open puts the client in SYN-SENT while the server remains LISTEN. Local SYN preparation is not server receipt; both states are not updated at once.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
No completion gate
Application outcome
No business outcome
State is asymmetric after SYN+ACK
SYN+ACK arrival makes the client ESTABLISHED while the server remains SYN-RECEIVED. Server completion cannot be inferred before final ACK arrival.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
Client established / server pending
Application outcome
No business outcome
A false-success gate was closed
final-ack-unobserved supplies two completed arrivals with cause=not-determined. The branch is not labeled as a completed server handshake.
Transport evidence
Client SYN-SENT / server LISTEN
Completion gate
Client established / server pending
Application outcome
UNKNOWN: final ACK arrival
Sequence space and payload were separated
Client SYN has sequence 1000. Even without payload, SYN consumes one position, making the next expected value 1001. Server SYN 7000 yields 7001; a payload-free final ACK consumes no new space.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Client established / server pending
Application outcome
UNKNOWN: final ACK arrival
Expected ACK is not an arrival
The client's expected final ACK carries seq 1001 and ack 7001. This branch has no observation of its arrival at the server; calculating its fields cannot change the server from SYN-RECEIVED to ESTABLISHED.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Client ESTABLISHED / server SYN-RECEIVED
Application outcome
UNKNOWN: final ACK arrival
No unsupported failure cause was selected
A missing arrival is not a scan/filter/timer/OS-error diagnosis. TimeoutOrPermanentFailureClaimed remains false; the needed evidence is final ACK receipt.
Transport evidence
SYN consumes one / ACK zero
Completion gate
Client ESTABLISHED / server SYN-RECEIVED
Application outcome
UNKNOWN: server completion cause

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: an ACK proves the operation finished

A design using a transport ACK as application receipt or database commit confuses distinct acceptance stages. The necessary condition is interpreting transport evidence as a business outcome. The impact can be a misleading success report or missing operation evidence.

The control is defining the application protocol’s own success/error result and any needed persistence evidence. This scene does not generate those upper-layer outcomes.

Broken assumption: every read is one message

A parser assuming matching write/read boundaries can misinterpret legitimate split or coalesced stream data. The necessary condition is tying application framing to transport chunks. Normal I/O behavior can expose this problem without a network attack.

The control is accumulating bytes and completing messages according to protocol framing. Comparing NOTE01 partitions is inert reasoning, without a vulnerability payload or reproduction workflow.

Broken assumption: one ready peer means both are ready

Treating client receipt of SYN+ACK as server receipt of the final ACK loses state ownership. It can turn an incomplete trace into false evidence of bilateral success. Separate endpoint snapshots make the mistake visible.

The control is changing receiver state on arrival and leaving the cause of an unobserved step undetermined. An incomplete trace is not a scan result, filtering diagnosis or actual OS error.

Read every scenario without motion

SEQ arithmetic

The tuple was separated from the listener
The TCP tuple is client 192.0.2.10:51000 ↔ server 198.51.100.200:443. serverListenerSelected=true is supplied, not an accept-queue or kernel-socket observation.
Tuple evidence
TCP / client51000 / server443
Sequence / arrival review
No arithmetic
Layer conclusion
No review
SYN arithmetic was calculated independently
Client SYN 1000 consumes one position, so its next expected value is 1001. The same calculation for server SYN 7000 gives 7001. These small teaching values do not test real ISN generation.
Tuple evidence
TCP / client51000 / server443
Sequence / arrival review
1000+1=1001 / 7000+1=7001
Layer conclusion
No review
Final ACK fields were read
Final ACK carries seq 1001 and ack 7001. It contains no payload and consumes no sequence space, so the next client data still starts at 1001. An ACK does not imply a data payload.
Tuple evidence
ACK: seq1001 / ack7001 / zero payload
Sequence / arrival review
1000+1=1001 / 7000+1=7001
Layer conclusion
No review
Arrival coverage was read separately
Three supplied arrivals leave both endpoints ESTABLISHED. Each state change belongs to receiver arrival, not one local whole-handshake operation.
Tuple evidence
ACK: seq1001 / ack7001 / zero payload
Sequence / arrival review
Coverage: three supplied arrivals
Layer conclusion
No review
Transport families were not confused
Selected UDP receives preserve datagram boundaries without guaranteeing delivery/order. QUIC has stream abstractions over a UDP carrier; sameAsTCPHandshake=false and modeled=false remain intact.
Tuple evidence
ACK: seq1001 / ack7001 / zero payload
Sequence / arrival review
Coverage: three supplied arrivals
Layer conclusion
TCP bytes / UDP datagrams / QUIC separate
Completion evidence stayed at its layer
Sequence and endpoint-state calculations agree in this inert transition model. It proves no real TCP implementation, TLS identity or application commit.
Tuple evidence
ACK: seq1001 / ack7001 / zero payload
Sequence / arrival review
Coverage: three supplied arrivals
Layer conclusion
Sequence arithmetic agrees / application unknown

ACK unobserved

The tuple was separated from the listener
The TCP tuple is client 192.0.2.10:51000 ↔ server 198.51.100.200:443. serverListenerSelected=true is supplied, not an accept-queue or kernel-socket observation.
Tuple evidence
TCP / client51000 / server443
Sequence / arrival review
No arithmetic
Layer conclusion
No review
SYN arithmetic was calculated independently
Client SYN 1000 consumes one position, so its next expected value is 1001. The same calculation for server SYN 7000 gives 7001. These small teaching values do not test real ISN generation.
Tuple evidence
TCP / client51000 / server443
Sequence / arrival review
1000+1=1001 / 7000+1=7001
Layer conclusion
No review
Expected final ACK fields were read
The expected final ACK for a normal handshake carries seq 1001 and ack 7001 with no payload. These are comparison fields. The two-arrival record has no observation of the server receiving that ACK.
Tuple evidence
Expected ACK: seq 1001 / ack 7001
Sequence / arrival review
1000+1=1001 / 7000+1=7001
Layer conclusion
No review
Arrival coverage was read separately
This branch shows only two completed arrivals. The client remains ESTABLISHED and the server SYN-RECEIVED. Knowing expected final-ACK fields is not the same as observing its arrival at the server.
Tuple evidence
Expected ACK: seq 1001 / ack 7001
Sequence / arrival review
Coverage: two arrivals
Layer conclusion
No review
Transport families were not confused
Selected UDP receives preserve datagram boundaries without guaranteeing delivery/order. QUIC has stream abstractions over a UDP carrier; sameAsTCPHandshake=false and modeled=false remain intact.
Tuple evidence
Expected ACK: seq 1001 / ack 7001
Sequence / arrival review
Coverage: two arrivals
Layer conclusion
TCP bytes / UDP datagrams / QUIC separate
Completion evidence stayed at its layer
Server-side endpoint evidence or an appropriate capture point is needed to establish final-ACK arrival. The supplied two arrivals leave its last state SYN-RECEIVED; the missing evidence's cause, TLS and application outcome remain unknown.
Tuple evidence
Expected ACK: seq 1001 / ack 7001
Sequence / arrival review
Coverage: two arrivals
Layer conclusion
UNKNOWN: final arrival

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Track the endpoint pair and state ownership

Record protocol and both endpoint addresses/ports first. Local active open changes only client state. For SYN, SYN+ACK and ACK arrivals, explain which peer gains information and which remains in its previous state.

This distinguishes a connection tuple from its listener. State that the two-peer teaching scene does not measure routers, socket APIs, accept queues or kernel results.

Compute sequence arithmetic independently

Compute 1000+1=1001 for client SYN and 7000+1=7001 for server SYN. The payload-free final ACK does not consume the next data start. Sequence-space usage is not identical to payload-byte count; SYN demonstrates the difference.

Compare both final states of the normal trace with states left in the missing-arrival branches. The selected small numbers do not test wraparound, window validation or real ISN generation.

Attach success evidence to its layer

Concatenate the stream’s read partitions without labeling each chunk a message absent application framing. The UDP comparison’s two successful receives are only a selected case, not a delivery guarantee.

Write separate expectations for TCP synchronization, TLS identity and application results. Correct local state arithmetic does not mean a real TCP implementation or browser network behavior has been executed.

For example, a Node.js TCP client must distinguish initiating a connection from receiving its connect event. Do not display connected merely because initiation was called; handle error and close outcomes too. connect reports an established socket connection, not the TLS identity or application permission kept separate in this lesson. Preserve that success boundary when comparing displayed states for successful and unsuccessful attempts.

NOW APPLY IT TO THE CASE

Which success layer do ACK and ESTABLISHED belong to?

The selected SYN sequence values are 1000 for the client and 7000 for the server. Their next expected positions are 1001 and 7001. An ESTABLISHED client does not prove server synchronization when final ACK is unobserved there.

Where does the connection carrying the response differ from application outcome? Do not substitute network or transport evidence for body-parsing or DOM success.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Two endpoints, three arrivals: TCP state ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "tuple": {
    "protocol": "TCP",
    "client": {
      "address": "192.0.2.10",
      "port": 51000
    },
    "server": {
      "address": "198.51.100.200",
      "port": 443
    },
    "serverListenerSelected": true
  },
  "initialSequenceNumbers": {
    "client": 1000,
    "server": 7000,
    "kind": "selected-teaching-values-not-real-ISN-algorithm"
  },
  "initialStates": {
    "client": "CLOSED",
    "server": "LISTEN"
  },
  "activeOpen": {
    "localProcess": "client-prepares-SYN",
    "clientStateAfter": "SYN-SENT",
    "serverStateAfter": "LISTEN"
  },
  "arrivals": [
    {
      "from": "client",
      "to": "server",
      "flags": [
        "SYN"
      ],
      "seq": 1000,
      "ack": null,
      "payloadBytes": 0,
      "sequenceSpaceUsed": 1,
      "clientStateAfter": "SYN-SENT",
      "serverStateAfter": "SYN-RECEIVED",
      "receiverNextExpected": 1001
    },
    {
      "from": "server",
      "to": "client",
      "flags": [
        "SYN",
        "ACK"
      ],
      "seq": 7000,
      "ack": 1001,
      "payloadBytes": 0,
      "sequenceSpaceUsed": 1,
      "clientStateAfter": "ESTABLISHED",
      "serverStateAfter": "SYN-RECEIVED",
      "receiverNextExpected": 7001
    },
    {
      "from": "client",
      "to": "server",
      "flags": [
        "ACK"
      ],
      "seq": 1001,
      "ack": 7001,
      "payloadBytes": 0,
      "sequenceSpaceUsed": 0,
      "clientStateAfter": "ESTABLISHED",
      "serverStateAfter": "ESTABLISHED",
      "receiverNextExpected": 1001
    }
  ],
  "nextClientDataSeq": 1001,
  "observationalBranches": [
    {
      "case": "final-ack-unobserved",
      "completedArrivals": 2,
      "clientLastModeledState": "ESTABLISHED",
      "serverLastModeledState": "SYN-RECEIVED",
      "cause": "not-determined",
      "timeoutOrPermanentFailureClaimed": false
    },
    {
      "case": "synack-unobserved",
      "completedArrivals": 1,
      "clientLastModeledState": "SYN-SENT",
      "serverLastModeledState": "SYN-RECEIVED",
      "cause": "not-determined",
      "timeoutOrPermanentFailureClaimed": false
    }
  ],
  "framingComparison": {
    "tcp": {
      "applicationWrites": [
        "NO",
        "TE01"
      ],
      "possibleApplicationReads": [
        "N",
        "OTE",
        "01"
      ],
      "reconstructedBytes": "NOTE01",
      "messageBoundaryPreservedByTCP": false
    },
    "udp": {
      "sentDatagrams": [
        "NO",
        "TE01"
      ],
      "selectedSuccessfulReceives": [
        "NO",
        "TE01"
      ],
      "datagramBoundaryPreserved": true,
      "deliveryOrOrderingGuaranteedByUDP": false
    },
    "quic": {
      "carrier": "UDP datagrams",
      "streamAbstraction": "ordered bytes within a stream",
      "sameAsTCPHandshake": false,
      "modeled": false
    }
  },
  "evidenceBoundary": {
    "tcpSynchronization": "selected-inert-transition-model",
    "tlsHandshake": "not-modeled",
    "httpRequest": "not-modeled",
    "applicationAuthorization": "not-modeled",
    "packetChecksumsOptionsWindowsTimers": "omitted"
  }
}

tuple: Local/remote endpoint pair including protocol; distinct from a listener.
arrivals.flags/seq/ack: Selected payload-free handshake fields; ack=null denotes no meaningful acknowledgment when ACK is absent.
arrivals.sequenceSpaceUsed: SYN consumes one position; a payload-free pure ACK consumes zero.
observationalBranches: Separate peer states at the trace boundary, without an actual timeout/error diagnosis.
framingComparison: Difference between TCP write/read partitioning and UDP datagram boundaries.

Not a complete packet, pcap or kernel result. ISNs are selected small numbers. Checksums, options, windows, timers, retransmission, simultaneous open, TLS, HTTP and application authorization are not modeled.

Two reality checks

TCP delivers every write with matching receiver boundaries.

TCP provides an ordered byte stream. Read boundaries can differ; the application protocol determines message framing.

When SYN+ACK reaches the client, the server is also ESTABLISHED.

In the selected ordinary handshake the client becomes ESTABLISHED; the server remains SYN-RECEIVED until final ACK arrival.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

SYN+ACK reached the client, but the final ACK has not been observed at the server. What are the endpoint states?

Client ESTABLISHED; server SYN-RECEIVED.
Both are ESTABLISHED; client state automatically propagates to the server.

Read the explained answer

Client ESTABLISHED; server SYN-RECEIVED. — The client advances on SYN+ACK; the server has not yet processed final ACK arrival.

Why is the ACK 1001 when payload length is zero?

Selected lesson artifact fields; teaching example

arrivals[0].seq: 1000
arrivals[0].payloadBytes: 0
arrivals[0].sequenceSpaceUsed: 1
arrivals[1].ack: 1001

SYN consumes one sequence number: 1000+1.
ACK 1001 proves receipt of one application-body byte.

Read the explained answer

SYN consumes one sequence number: 1000+1. — There is no payload, but SYN has sequenceSpaceUsed=1; the next expected number is 1001.

Order the arrival prerequisites for the selected ordinary handshake, starting CLOSED/LISTEN.

The client prepares SYN and enters SYN-SENT.
SYN reaches the server; it enters SYN-RECEIVED.
SYN+ACK reaches the client; it enters ESTABLISHED.
The final ACK reaches the server; it enters ESTABLISHED.

Read the explained answer

The client prepares SYN and enters SYN-SENT. → SYN reaches the server; it enters SYN-RECEIVED. → SYN+ACK reaches the client; it enters ESTABLISHED. → The final ACK reaches the server; it enters ESTABLISHED. — Each endpoint advances on its own received message; preparing SYN does not change the remote server. This ordinary branch includes no data/TFO/simultaneous open.

The TCP handshake completed. Which evidence is still missing for TLS and authorization of the book endpoint?

Read the explained answer

The handshake synchronizes sequence state at two TCP endpoints. TLS handshake/certificate checks, HTTP requests and application authorization are not modeled in this artifact. TCP ESTABLISHED does not prove resource delivery or user permission.

□ I separated the TCP outcome from TLS identity checking.

□ I required a separate application authorization decision.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9293 — Transmission Control Protocol (TCP)2.2 Key TCP Concepts · 3.1 Header Format; 3.3.2 State Machine Overview · 3.4 Sequence Numbers; 3.5 Establishing a Connection; Figure 6 · 3.7 Segmentation; application buffer boundaries
RFC 768 — User Datagram ProtocolIntroduction; Format; Fields; User Interface
RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport1 Overview; 2 Streams
RFC 5737 — IPv4 Address Blocks Reserved for Documentation3 Documentation Address Blocks
Node.js Net — socket connection eventsEvent: 'connect' · Event: 'error' · Event: 'close' · Event: 'lookup'

YOUR NOTES / THIS BROWSER

How is a TCP connection established?

1. Core · Mechanism

Three-way handshake

Final ACK arrival unobserved

SYN+ACK arrival unobserved

Transport identifies endpoints within hosts

A TCP connection is state held at both ends

Separate streams from message boundaries

First arrival: SYN reached the server

Second and third arrivals: readiness is staggered

An incomplete observation does not prove a failure cause

2. Red · Trust & Impact

ACK scope

Peer-state split

Broken assumption: an ACK proves the operation finished

Broken assumption: every read is one message

Broken assumption: one ready peer means both are ready

3. Blue · Secure development & defense

SEQ arithmetic

ACK unobserved

Track the endpoint pair and state ownership

Compute sequence arithmetic independently

Attach success evidence to its layer

Which success layer do ACK and ESTABLISHED belong to?

Two reality checks

SYN+ACK reached the client, but the final ACK has not been observed at the server. What are the endpoint states?

Why is the ACK 1001 when payload length is zero?

Order the arrival prerequisites for the selected ordinary handshake, starting CLOSED/LISTEN.

The TCP handshake completed. Which evidence is still missing for TLS and authorization of the book endpoint?

Sources and scope