The TCP handshake and a connection’s life

Before your Mac sends a single byte of a webpage request, it has already exchanged three short messages with the server. That exchange, the TCP three-way handshake, is what turns TCP’s reliability promises from the previous lesson into an actual, trackable connection between two machines.

Three messages before the first word

RFC 9293, the current TCP specification, describes the process as a synchronized exchange: “the synchronization requires each side to send its own initial sequence number and to receive a confirmation of it in acknowledgment from the remote TCP peer.”

1. SYN. The device opening the connection sends a segment with the SYN flag set, carrying a starting sequence number.
2. SYN-ACK. The other side replies with its own SYN, plus an acknowledgment of the first number.
3. ACK. The first device acknowledges that reply. RFC 9293 notes that “because steps 2 and 3 can be combined in a single message this is called the three-way (or three message) handshake.” Once it completes, both sides count the connection as ESTABLISHED and start sending real data.

Cloudflare’s Learning Center gives a plain-language version of the same idea, using an email as the example: “first, the source sends an SYN ‘initial request’ packet to the target server in order to start the dialogue. Then the target server sends a SYN-ACK packet to agree to the process. Lastly, the source sends an ACK packet to the target to confirm the process, after which the message contents can be sent.”

Ending a connection cleanly

Closing is more deliberate than opening. RFC 9293 explains that “the normal TCP close sequence delivers buffered data reliably in both directions” before the connection ends: each side sends a FIN segment once it has no more data to send, the other side acknowledges it, and only once both directions have finished does the connection fully close. A short waiting period (TIME-WAIT) follows, so that any stray, delayed packet from the old connection cannot be mistaken for part of a new one.

What a firewall in the middle sees

A stateful firewall, the kind built into most routers and into macOS itself, does not need to inspect every packet to make a decision. Cloudflare’s explanation of firewalls describes it this way: it “saves information regarding open connections and uses this information to analyze incoming and outgoing traffic, rather than inspecting each packet.” In practice, that means it watches for the SYN that opens a connection, remembers that this app asked for a reply, and then quietly allows the matching SYN-ACK back in; a reply that does not match any outgoing SYN gets dropped. That is also how a firewall can tell a normal reply from an unsolicited connection attempt arriving out of nowhere, which is the basis of blocking unwanted inbound traffic.

None of this exchange is encrypted by TCP itself; SYN, SYN-ACK and ACK are visible in plain form to anything watching the network path, including your Wi-Fi router. What is hidden or not depends on the layer above TCP, such as TLS for an HTTPS site, which the how-the-internet-works course covers separately.