Принцип рукопожатия WebSocket

Imagine you're calling a friend, but instead of just talking, you first agree on a secret language. The WebSocket handshake is similar!

It's the crucial initial step where your browser (client) and a server agree to switch from a standard HTTP connection to a WebSocket connection.

Traditional HTTP is designed for short, one-off requests and responses. Think of loading a webpage – you ask, the server sends, and the connection closes.

• One-way: Client requests, server responds.
• Short-lived: Connection closes after each interaction.
• Overhead: Each new request needs to set up a new connection.

WebSockets need a persistent, two-way street for real-time data.

The handshake begins with the client (your browser) sending a regular HTTP GET request to the server. But it's not truly "regular"!

This request includes special HTTP headers that signal the client's intention to "upgrade" to the WebSocket protocol. It's like adding a special note to your call asking to switch to the secret language.

Two key headers clearly tell the server the client wants a WebSocket connection:

• Upgrade: websocket: This header specifies the protocol the client wants to switch to.
• Connection: Upgrade: This header is a general HTTP header that indicates the client wishes to upgrade or switch protocols.

Together, they form the core of the upgrade request.

Another vital header from the client is Sec-WebSocket-Key.

• It's a 16-byte random value, encoded in Base64.
• It acts as a unique, unpredictable "nonce" (number used once) for each handshake.
• The server uses this key to prove it understands the WebSocket protocol and to prevent certain types of caching or proxy issues.

The Sec-WebSocket-Version header is straightforward but important.

It tells the server which version of the WebSocket protocol the client is using. Currently, the standard version is 13.

This ensures both client and server speak the same "dialect" of the WebSocket language, guaranteeing compatibility.

If the server supports WebSockets and agrees to the upgrade, it sends a special HTTP response back to the client.

The most important part of this response is the HTTP status code 101: Switching Protocols. This code explicitly means the server is changing protocols as requested by the client.

The server's response also includes key headers:

• Upgrade: websocket and Connection: Upgrade: Mirroring the client, these confirm the server's agreement to upgrade.
• Sec-WebSocket-Accept: This is a hash generated by the server using the client's Sec-WebSocket-Key plus a specific "magic string". It proves the server understood the key and is capable of WebSockets.

You've learned about the important headers involved in the WebSocket handshake.

Which of the following headers is sent by the client to initiate the WebSocket upgrade, and contains a random, unique value?

Once the client receives and validates the server's 101 response with the correct Sec-WebSocket-Accept header, the HTTP handshake is complete!

The connection is now upgraded to a full-duplex WebSocket. Both client and server can send and receive data simultaneously over this persistent connection, enabling true real-time communication.