Answers · The network and the web

Why does opening a connection take three messages instead of two?

In shortThree messages are needed because the server must also learn that its own reply arrived; the third message is that proof, not a formality.

Three messages are needed because each side has to receive proof that something it sent arrived. The middle message can carry two jobs, an acknowledgement of the client's starting number and a proposal for the server's own, but it cannot acknowledge itself, so a third message is still required.

Why two cannot do it

Call the client C and the server S. C sends a proposal carrying a starting number x. S replies with a message that acknowledges x and proposes a starting number y of its own. At the end of those two messages, assuming both arrived, C has evidence that S received x, and C has y. S has no evidence that its own reply arrived. If that reply is lost, S is holding a connection that C knows nothing about, and S will hold it until a timer expires. C has sent nothing since its first message, so it cannot correct the situation. Each side needs one piece of evidence: that a message it sent was received. That needs an acknowledgement travelling in each direction. The middle message can be both the acknowledgement of C's proposal and the proposal from S, which is why the minimum is three rather than four. Two cannot do it because two messages give one proposal and one acknowledgement at most, leaving one side's proposal unacknowledged.

\underbrace{C\to S:\text{propose }x}_{1} \;+\; \underbrace{S\to C:\text{ack }x, \text{propose }y}_{2} \;+\; \underbrace{C\to S:\text{ack }y}_{3}

FIG 1Three messages, two acknowledgements

The middle message does two jobs at once: it acknowledges the client's starting number and proposes the server's. The third message is the acknowledgement of the server's proposal, so it is not a repeat.

Both starting numbers have to be agreed before either side can say what a later message means. The first message fixes the client's origin, the second fixes the server's, and the third closes the loop by telling the server that the client has accepted its origin. Until that loop is closed, the server cannot distinguish a client that received y from one that never saw it. That is why the third message changes the server's state rather than merely repeating a fact the client already knows. The client may have known y since the second message, but knowledge on one side is not agreement. The protocol needs both sides to know that both sides know.

The third message is not a formality

The third message is not a duplicate and it is not a formality. It is the only evidence the server ever gets that its own starting number reached the client. Without it, the server can know that the client can send, because the first message arrived. It cannot know that the client can receive, because the second message might have fallen into a hole. The third message says, in effect, I heard your y. It is also the point at which both sides have agreed on where numbering starts. That agreement is what makes every later message identifiable by position, and position is what makes loss detectable at all. A duplicate of the first message would add no new information; the third message adds the missing direction of proof.

Counting messages is not quite counting time. A one-way crossing takes half a round trip. A pure three-message handshake therefore spans one and a half round trips: C to S, S to C, C to S. At a round trip of 85 ms, each crossing is 42.5 ms, so three crossings cost 127.5 ms on the wire. If the third message carries the first request, the client can put useful bytes on the wire as soon as it has the server's proposal. That is why the practical wait before the request leaves is often quoted as one round trip rather than one and a half. The server still cannot treat the connection as fully open until the third message arrives. The proof has not been skipped; it has been folded into a message that had to be sent anyway.

Where the count changes

The three-message minimum belongs to a reliable channel starting from nothing. If the medium could not lose messages, two messages would be enough to exchange starting numbers, but then acknowledgements would not be needed for reliability at all. If the connection is already open, the count is zero. Encrypted setup adds round trips after this handshake, not extra copies of it, and resumption can remove the key-agreement round trip. A resumed session still begins on a channel that was opened with this three-message exchange at some earlier point. None of those changes alters the reason for the third message: the server needs to learn that its own proposal arrived.

Worth keeping

The third message is the server's only evidence that its own starting number reached the client, so it is the message that closes the loop in the other direction.
A reliable connection needs an acknowledgement in each direction, and the middle message can carry an acknowledgement one way and a new proposal the other, which makes three the minimum rather than four.
If the third message carries the first request, the client saves a separate wait, but the server still waits for that message before it can trust the connection.

Where this goes next

This question is one step of From an Address to a Page, a course that works through its subject from the beginning. The page that teaches this part of it is Opening a Conversation, and it reads the whole way through whether or not you have an account.

What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.

Read that page The whole course