TCP, UDP, and the three-way handshake

02Setup, close, and a datagram

A sequence number identifies a position in one side's TCP stream. Each side chooses its own initial sequence number. An acknowledgement number states the next sequence position the sender expects from the other side; it acknowledges that other side's earlier positions, not its own starting number.

SYN consumes one sequence position even when it carries no application data. In a fresh paper example, suppose a client sends SYN with sequence 1200 and a server chooses 6400. The server's SYN-ACK acknowledges 1201. The client then acknowledges 6401. Add one to the peer's SYN number, keeping the two directions separate. The drawing uses different numbers for the same rule.

In the basic setup shown here, the client sends SYN, the server responds SYN-ACK and the client responds ACK. A retransmission repeats data or control after a presumed loss. A repeated segment can be part of reliability handling; it is not by itself proof of an attack. Real TCP supports cases beyond this introductory sequence.

FIN means its sender has no more data to send. The two directions close independently: one side can stop sending while still receiving. This is a half-close. One FIN alone therefore does not establish that both directions have finished. FIN belongs to closing, rather than completing setup.

UDP itself has no TCP-style setup handshake and does not guarantee delivery, order or protection from duplicates. Its receiver might see no datagram, a later one first, or a duplicate. An application can add acknowledgements or other reliability behavior above UDP, but those are application choices rather than promises supplied by UDP.

Choosing UDP is a design decision, not a sign that the transport is broken. The application must tolerate its limits or add the behavior it needs. Likewise, TCP's transport acknowledgement does not prove that an application accepted or acted on the received data.

03Put the shuffled cards in setup order

First trace the new 1200/6400 setup on paper: label whose sequence each side acknowledges. Then use the shuffled activity labels M1, M2 and M3 in the worksheet. Those labels name messages; they do not state their time order.

Make your label order before reading the printed check. Finally separate the FIN and UDP cards from TCP setup, giving a reason for each. All evidence is printed; you need no connection, packet transmission or capture.

Read setup, acknowledgements and closing separately

TCP means Transmission Control Protocol. It provides an ordered,
reliable byte stream; application success still needs application
evidence. SYN synchronizes starting sequence numbers. ACK marks an
acknowledgement, the next sequence position expected from the peer.

Fresh paper calculation, separate from the diagram and later checks:
Client SYN seq=1200; server SYN-ACK seq=6400, ack=1201.
Client ACK acknowledges 6401. Each SYN consumes one sequence position
without carrying application bytes. Each side acknowledges the peer.

A FIN stops its sender from sending more data. The other direction can
remain open: a half-close. One FIN alone does not finish both directions.
UDP is a different transport. UDP itself has no setup handshake or
promises of delivery, ordering or duplicate protection. Applications
can add behavior above UDP, but those are not UDP guarantees.

Procedure cards for the TCP setup shape. Not a packet capture.

Worked order, peers alfa then beta
1 SYN      alfa -> beta
2 SYN-ACK  beta -> alfa
3 ACK      alfa -> beta
These three messages set up the connection. Application data is a later fact.
A reply from the application is not guaranteed by the third message.

Activity cards, peers shelf and desk, labels shuffled
M1  ACK
M2  SYN
M3  SYN-ACK
Predict the setup order before reading the check. Check: M2, then M3, then M1.

Close card, separate from setup
FIN means the sender has no more data. It belongs to closing, not to the third setup step.

UDP card
One datagram from desk to shelf.
No SYN, no SYN-ACK, and no ACK.
UDP does not guarantee delivery or duplicate protection for that datagram.

1. Read M1, M2, and M3. Match each label to SYN, SYN-ACK, or ACK.
2. Write the setup order as label, then label, then label.
3. Check: M2, then M3, then M1.
4. Read the FIN card and the UDP card. Do not open a connection and do not send a datagram.

04Optional challenge

Allow about ten extra minutes. One application sends short updates and can tolerate an occasional missing update. Explain why it might choose UDP. Name one extra behavior the application would need if it required a confirmation, and keep that behavior separate from UDP's own guarantees.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Independent connection:
T1 client → server SYN
T2 server → client SYN-ACK
No T3 is shown. No application payload is shown.
The table is a limited observation, not a complete history.

U1 client → server SYN
U2 server → client SYN-ACK
U3 client → server ACK
U4 client → server application request
U5 client → server FIN
No server application response or server FIN is supplied.

06Explain your prediction

Optional written self-check: Trace whose sequence is acknowledged, mark the basic setup boundary and distinguish a transport ACK from an application response. Explain one-direction FIN and UDP guarantees separately.