WebSocket
In the early 2000s, web developers faced a recurring problem. The applications they were building—instant messaging systems, online games, collaborative dashboards—required constant exchanges between browsers and servers. However, the Web as it existed at the time couldn’t really handle this type of dialogue. HTTP, the protocol governing Internet communications, operated on a rigid model: the client requests, the server responds. No room for fluid two-way conversation.
Engineers found workarounds. The most common, "HTTP polling," consisted of bombarding the server with regular requests to check if it had anything new to say. A variant, "long polling," kept the connection open until information arrived. These makeshift solutions worked, certainly, but generated considerable network traffic. Each HTTP request carried bulky headers—hundreds of bytes each time—sometimes to transport just a few bytes of useful information.
RFC 6455, published by the IETF in December 2011, put an end to this era of improvisation. WebSocket proposed a radically different approach. The protocol starts with a standard HTTP handshake, then switches to a permanent connection. Once established, this channel sends messages in both directions with minimal overhead—a few control bytes instead of the hundreds previously required. The protocol handles text and binary data indifferently, and integrates connection monitoring mechanisms via "ping" and "pong" messages.
Browsers adopted this innovation. Chrome, Firefox, and Safari deployed experimental implementations as early as 2010. Internet Explorer joined the movement in 2012. This rapid convergence among vendors testified to a genuine market need. Developers could finally create responsive web applications without resorting to complex and fragile workarounds.
The numbers speak for themselves. On a trading site displaying real-time stock prices, WebSocket reduces traffic by 417 bytes per update per client. With 4,835 simultaneous visitors, the bandwidth savings climb to 16 megabits per second. The impact is also measured in adoption statistics: 1.6% of the top million sites in 2018, 6.3% in 2020. This growth testifies to a technology that has reached maturity.
The ecosystem structured itself around the protocol. Socket.io and SockJS offer high-level APIs that simplify its use. Chat services, collaborative platforms, and financial applications made it their workhorse. Web analytics tools use it to collect real-time data on user behavior. WebSocket finds its place in the Internet of Things and microservices architectures, where its lightness and bidirectionality offer tangible advantages.
The technology doesn’t escape misuse. Some developers neglect security best practices—Origin header verification, systematic TLS encryption. Malicious actors misuse the protocol for tracking or distributing unwanted software. These shadow areas remind us that no technical innovation is neutral.
HTTP/2, standardized in 2015, introduced the Server Push feature. Servers can now send resources to clients without waiting for a request. This capability doesn’t replace WebSocket, however: it doesn’t create a true bidirectional channel. Google implicitly acknowledged this by dropping support for Server Push in Chrome in 2020, confirming WebSocket’s unique position in the web landscape.
Competing technologies emerged, such as Server-Sent Events. WebSocket nonetheless retains its relevance. The stabilization of its adoption rate since 2019 suggests it has found its place in the palette of available tools. Modern frameworks integrate it by default, developers master it, use cases multiply.
The protocol didn’t revolutionize anything: it simply made possible what previously required acrobatics. This conceptual simplicity, combined with measurable operational efficiency, explains its success.