What is Socket.IO?

Socket.IO is not WebSocket

This is the single most important fact about Socket.IO: it is a custom protocol built on top of WebSocket (with HTTP long-polling as a fallback transport). A plain browser WebSocket client cannot talk to a Socket.IO server. A plain WebSocket server cannot accept Socket.IO clients. They share words like "rooms" and "events" but interoperate only through their own SDKs.

What Socket.IO adds

Auto-reconnection, rooms and namespaces (multiplexed channels), acknowledgements (callback-style request-response), automatic transport fallback (WebSocket → HTTP long-polling), and built-in scaling adapters (Redis, Postgres). For applications that fit the chat/collab/notification mold, Socket.IO is faster to ship than rolling raw WebSocket.

The cost: lock-in

Once you pick Socket.IO, every client must use a Socket.IO library. Web, mobile, server-to-server — all need an SDK. That is fine if your audience is your own clients. It is a problem if you need third parties (game studios, partners, IoT devices) to connect with arbitrary tooling.

Code

Socket.IO protocol layers·text

  Application code              <-- what you write
  --------------------------
   Socket.IO API              <-- rooms, namespaces, acks, events
  --------------------------
   Engine.IO                  <-- connection mgmt, transport switching
  --------------------------
   WebSocket | HTTP polling    <-- actual transport(s)

Exercise

Boot a Socket.IO server. Open browser devtools, look at the network tab during connect. Note the two-step pattern: first a plain HTTP polling exchange, then an upgrade to WebSocket. Now use a raw WebSocket client (websocat ws://localhost:3000) — it will fail. Confirm with your eyes that they are not the same protocol.