Understanding Comet and WebSocket Server Push Technologies

Web server push technologies enable real‑time interaction between client browsers and servers, with the two most common approaches being Comet and WebSocket.

Comet Technology Model – Before WebSocket, Comet was the primary method for server push. Traditional HTTP follows a request/response pattern, preventing servers from initiating communication. To simulate asynchronous events, clients repeatedly poll the server, which is inefficient and bandwidth‑heavy.

Comet implementations are generally classified into two categories: stream‑based and long‑polling.

Stream‑Based Comet – A persistent connection is opened so the server can continuously send events without closing the HTTP link. Implementations use hidden iframes or XHR. Hidden iframes are simple and widely supported but lack reliable error handling and state tracking. XHR allows JavaScript to parse custom data formats and provides better request tracking, though cross‑browser support varies and XHR is subject to same‑origin restrictions.

Long‑Polling Comet – To avoid the drawbacks of continuous polling, long‑polling keeps the request open until the server has data, then returns the response and the client immediately issues a new request. This method includes XHR long‑polling (still facing cross‑origin issues) and script‑tag long‑polling, where a dynamically created <script> element receives JavaScript‑wrapped events from the server, offering better cross‑browser compatibility without same‑origin constraints.

WebSocket Technology – WebSocket, introduced in HTML5, provides a true full‑duplex communication channel over a single TCP connection. The client initiates a handshake via an HTTP Upgrade request; upon successful upgrade (HTTP 101), both sides can exchange messages freely. WebSocket reduces overhead compared to HTTP‑based push, is supported by major browsers, and is implemented in popular servlet containers such as Tomcat, Jetty, and Undertow. The protocol uses ws:// for unencrypted and wss:// for encrypted connections.

When deploying WebSocket behind Apache or Nginx, additional configuration is required (e.g., proxying WebSocket connections). Despite its advantages, older browsers may lack support, which is why Comet remains relevant for compatibility.

Conclusion – Both Comet and WebSocket enable real‑time web applications, each with trade‑offs. Understanding their mechanisms helps developers choose the appropriate solution for their performance, compatibility, and security requirements.