{
  "id": 5021840,
  "title": "WebSocket Engineering — Part 2",
  "url": "https://urgent.news/2026/09/02/websocket-engineering-part-2",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-02T05:27:23.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/surajrkhonde/websocket-engineering-part-2-20b5"
  },
  "original_language": "en",
  "account": "Part 2: Understanding WebSocket Disconnections and Heartbeats\n\nIn Part 1, I concluded that WebSocket disconnecting is normal. Recovery is the key feature. However, this led to another question: how can I know when a WebSocket connection has died? At first, it seemed obvious that the server would receive a disconnect event if the client vanished. Similarly, TCP and WebSocket should be aware of this. But then I learned about a type of connection failure that doesn't announce itself. The connection simply disappears without a clean goodbye.\n\nImagine a user connected over Wi-Fi. Then they walk into a lift, and Wi-Fi disappears instantly. Initially, I thought that when Wi-Fi died, WebSocket would send a close event, and the server could clean up the connection. But this isn't always the case. Sometimes, there's no clean TCP close handshake; packets simply stop arriving. The client is gone, but the server might still have its data, such as subscriptions, presence, and file descriptors. The server thinks the client is connected, but in reality, the client has disappeared. This is a zombie connection.\n\nInitially, I believed heartbeats were simply sending messages every few seconds to prevent WebSocket from disconnecting. But heartbeats serve two purposes: checking if the other side is alive and preventing intermediate proxies from considering the connection idle. There are at least three layers involved in keep-alive: application, WebSocket protocol, and TCP. Each layer has its own idea of keep-alive.\n\nThe easiest way to understand this is to think of three layers: application heartbeat, WebSocket ping/pong protocol frames, and TCP keepalive. At first, they all seemed like: \"ping something and check if it responds.\" However, the layer matters a lot. The application-level heartbeat allows us to send a custom message, like `{ type: \"ping\" }`, which the server can respond to with `{ type: \"pong\" }`. This heartbeat can be visible to our JavaScript code, allowing us to make decisions based on the connection status.\n\nHowever, there's a gap in browser JavaScript. The browser doesn't expose protocol ping/pong frames, and we can't directly send ping frames from JavaScript. Instead, we need to create our own heartbeat using application messages. While this may be slightly more expensive due to the extra bytes sent, it allows us to have visibility into the connection status and make appropriate decisions in our application.",
  "summary": "WebSocket connection :- Heartbeats, Zombie Connections, and the Connections That Never Said Goodbye In Part 1, I reached one uncomfortable conclusion: WebSocket disconnecting is normal. Reliable recovery is the feature. But that created another question. How do I even know that a WebSocket connection has died? At first this sounded obvious. Surely if the client disappears, the server gets a…",
  "key_points": [
    "WebSocket disconnections are normal, recovery is key",
    "Zombie connections occur when client vanishes without clean goodbye",
    "Heartbeats serve two purposes: checking alive status and preventing idle consideration"
  ],
  "editors_take": "Understanding WebSocket disconnections and implementing heartbeats reveals that zombie connections can be avoided and connection status can be better managed with application-level heartbeat messages.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}