For a long time, the web worked like a polite but slow conversation. A user's browser (the client) would ask a server for something, like a webpage. The server would respond with the requested information. This is called the request-response model, and it's the foundation of HTTP, the protocol that powers most of the web.

Imagine you're at a restaurant. With HTTP, you'd have to call the waiter over to ask for a menu. They'd bring it and leave. Then you'd have to call them over again to order your food. They'd take your order and leave. Then you'd call them again for a glass of water. Each interaction is a separate request and response. It works, but it's not efficient for a continuous experience.

This model is fine for static websites, but it struggles with applications that need real-time data. Think of a chat app, a live sports score feed, or a stock ticker. If the client has to keep asking the server, "Is there anything new? Anything new now? How about now?", it creates a lot of unnecessary traffic and delays.

Developers came up with clever workarounds, like polling. The client would be programmed to automatically ask the server for updates every few seconds. Another technique, long polling, involved the client asking for an update and the server holding that connection open until it actually had something new to send. These methods felt like real-time communication, but they were inefficient hacks.

WebSockets were created to solve this problem permanently. Instead of a series of short-lived, one-off requests, a WebSocket opens a persistent, two-way communication channel between a client and a server.

Think of it like upgrading from sending letters to making a phone call. Instead of writing and mailing a letter for every single thing you want to say (HTTP), you just dial once. After the initial connection (the handshake), both you and the other person can talk freely, interrupting each other and exchanging information instantly. This is the power of a persistent connection.

This two-way flow is called full-duplex communication. The client can send information to the server at the same time the server is sending information to the client. There's no need to wait for a response before sending the next message. This dramatically reduces latency and makes applications feel incredibly responsive.

A WebSocket connection starts life as a standard HTTP request. The client sends a special request to the server, essentially asking to switch protocols. This is known as the WebSocket handshake.

If the server supports WebSockets and agrees to the request, it sends back a confirmation. The initial HTTP connection is then upgraded to a WebSocket connection that stays open. From that point on, data can be sent back and forth freely without the overhead of HTTP headers for every message. This makes it fast and efficient for applications like live-collaboration tools, multiplayer games, and instant messaging.

Now that you know the basics, let's check your understanding.

By establishing a single, lasting connection, WebSockets create a more efficient and responsive web for real-time applications.