TCP connection lifecycle
TCP opens a conversation before carrying the stream.
The client starts by sending a segment with the SYN flag. The server answers with SYN-ACK: it acknowledges the client's request and announces that it is ready. The client completes the three-way handshake with ACK, after which both sides can exchange the ordered byte stream.
SYN
Requests a new TCP connection and synchronises an initial sequence number.
SYN-ACK
Accepts the request, acknowledges it, and sends the server's own sequence information.
ACK
Confirms the server response and completes the opening handshake.
FIN or RST
FIN closes a conversation gracefully; RST terminates it abruptly when the state is invalid or refused.
The transport choice
The network delivers. Transport shapes the conversation.
IP can move packets toward a destination, but an application also needs to identify a service and decide how the exchange should behave. Ports direct traffic to the right process, while a transport protocol defines the rules of the conversation.
There is no single best transport for every situation. A file download values completeness and order. A live update may prefer fresh data over waiting for an old packet.
Build the model
Two different promises
TCP
Connection-oriented transport that uses acknowledgements, ordering, and retransmission to provide a reliable byte stream.
UDP
Lightweight datagram transport without built-in delivery, ordering, or retransmission guarantees.
Port
Identifies the service or process that should receive transport data on a device.
Tradeoff
Choose between transport help, delay, overhead, freshness, and application control.
Share the path
Multiplexing lets many conversations share a network.
A device may download a file, resolve a name, and receive a live update at the same time. Transport multiplexing combines those flows onto the available network path; source and destination ports let the receiving host deliver each flow to the correct process.
The destination port 443 identifies the web service, while the source port identifies this browser conversation.
Look inside the message
A UDP datagram keeps the transport header small.
UDP adds only the information needed to deliver one transport message to a process. Its header is 8 bytes, followed by the application data.
The ports identify the sending and receiving processes. UDP does not add ordering, acknowledgements, or retransmission fields.
Look inside the reliable stream
A TCP segment carries state for the conversation.
TCP uses its header to identify the connection, number the bytes, acknowledge received data, and advertise how much more data it can accept.
Sequence and acknowledgement numbers support ordering and reliable delivery. Flags describe control events such as opening or closing a connection.
Mini experiment
Choose a transport
Pick the kind of exchange you want to support. The simplified result explains which transport contract fits best.
A file download needs complete, ordered data.
TCP fits this exchange because missing or reordered data must be repaired.
Knowledge check
Test your transport model
Answer fourteen questions. The answer order changes each time.