Web

WebSocket is often described as “HTTP that can talk both ways” or “HTTP better suited for real-time scenarios”. That gets the direction right, but if you stop there, implementation, packet capture, and troubleshooting will go off track. WebSocket is not adding a push feature to HTTP. It keeps the browser and existing Web infrastructure path intact, then turns request/response, which is naturally half-duplex, into a persistent full-duplex channel.

What it really solves is not “how to let the server send something occasionally”. It is “how to keep one connection alive between browser and server where both sides can speak at any time, while still reusing the current HTTP / TCP / TLS deployment reality as much as possible.” That is why the important parts are not the JavaScript API, but the upgrade handshake, connection lifetime, frame boundaries, heartbeats, and middlebox compatibility.

HTTP is so common that it is easy to reduce it to “the client sends a request and the server returns a response.” But as soon as you work on caching, proxies, authentication, cross-origin access, long connections, packet capture, or performance debugging, the hard part turns out not to be the start line and headers. It is the fact that HTTP must serve browsers, origins, intermediaries, caches, and later Web applications all at once.