Handshake

When two devices want to talk to each other over a network, they don’t immediately send their actual data. First, they exchange a few short initial messages. This lets them check whether the other side responds at all, and agree on common rules for everything that follows. This preliminary step is called a handshake. The name fits well: two people shake hands before the conversation begins. The handshake itself transmits almost no payload data, only the agreement on how and with whom the transmission will take place.

What goes wrong without a handshake

Without this preliminary clarification, a device would send into the void. It wouldn’t know whether the recipient is switched on, overloaded, or not present at all. All the data would still be sent anyway and would be lost. The handshake ensures that both sides are ready before things get serious.

The second reason is security. When you visit a website with a lock symbol in the browser, a handshake takes place that clarifies far more than mere reachability. There, the server proves with a digital ID that it really is the requested site. Afterward, both sides negotiate a secret key with which they encrypt their messages. Without this step, someone on the same Wi-Fi could read along or pose as your bank.

The third reason is mutual understanding. Different devices support different, more or less modern procedures. In the handshake, each side states what it is capable of, and they agree on the best procedure they have in common. This way, a new browser can also talk to an older server without anyone having to switch languages.

The three messages at the start of every connection

The best-known example is the three-way handshake of the internet protocol TCP, which is responsible for practically every data request on the net. Your device sends a short request: I would like a connection. The server replies: Understood, I am ready. Your device confirms this reply once more. Only after that does the actual transmission begin.

Why three steps and not two? After two messages, only the requester knows that the connection works in both directions. The server has no proof yet that its own reply has arrived. The third message provides exactly this proof. Incidentally, both sides also exchange starting numbers with which they later check the order of the data packets.

In the encrypted handshake, the TLS handshake, further rounds are added. The server sends its certificate, i.e., its digital ID. The browser checks whether a trustworthy authority issued this ID. Both sides then compute the same secret key from exchanged numbers, without ever sending it directly. This takes milliseconds, but it’s the reason why secure sites start up minimally slower.

From the loading bar to the AI interface

You experience handshakes every day without seeing them. Every page load, every Bluetooth pairing with headphones, and every Wi-Fi login begins with one. Even older technology used the term: the beeping and hissing of a modem in the nineties was an audible handshake between two devices.

In the world of AI, the term comes up wherever programs automatically talk to servers. When an app sends a request to a language model, an encrypted handshake takes place beforehand. With very many small requests, this preliminary step can noticeably add up. That’s why systems keep a once-established connection open and use it multiple times instead of renegotiating every single time.

In news reports, the term is often read in connection with disruptions: a handshake error usually means that a security certificate has expired or that both sides cannot find a shared encryption method. A common misconception is to confuse the handshake with logging in via password. The handshake only establishes the secure channel. Who you are is only clarified afterward, within the protected conversation.