WebSocket · Real-Time Communication
WebSocket
What Is a WebSocket?
- Always-open, two-way real-time communication
- The foundation of chat, notifications, and collaboration
- Compared with polling and SSE
Adding WebSocket shifts control of screen updates from the user to the server. Before, new data reached the screen only when someone pressed a button or refreshed, but with an open connection, the server speaks first. So the wording in specs changes from “you see it when you look it up” to “you see it when it changes,” and the dev team stops using requests per second as the measure of server capacity and uses the number of simultaneous open connections instead. It also means resources stay tied up for as long as users keep the screen open.
A connection starts over HTTP just once. When the browser requests an upgrade, the server returns a 101 response, and from then on the connection switches to the ws protocol (wss when encrypted). The hundreds of bytes of headers attached to every request disappear, leaving only a 2–14 byte frame header, so compared with polling once per second, both traffic and latency drop. But WebSocket is not the answer to every real-time feature. For screens where the server only pushes data down, such as price tickers or notifications, one-way SSE handles reconnection automatically and is far lighter to build, while WebSocket earns its keep in features where both sides send at once, such as chat or simultaneous editing.
The point where things break most often in practice is when you add servers. A WebSocket is a connection tied to a specific server, so the moment traffic grows and you scale to 2 servers, messages vanish between people connected to server A and people connected to server B. Without a relay channel linking the servers, everything works in development and fails only in production. Dropped connections are the same story. Load balancers usually close a connection after about 60 seconds without data, so a ping every 30 seconds is needed, and if connections dropped in a subway or elevator go undetected, the app is left in a state where the screen looks fine but no messages arrive. If you let every client reconnect immediately, thousands of requests pile in right after a deployment and knock the servers over again.
Seungtae ParkA hands-on AX instructor who builds and teaches AI business development and marketing automation
Jaryong KooA marketing PhD and leading authority on AI, data analysis, and personal brandingIt emerged from the need for real-time, two-way web communication, was finalized as a standard in 2011 (RFC 6455), and became the foundation of real-time web services.
Consider a hypothetical case. Company A, an industrial parts distributor, has 320 employees and KRW 110 billion (≈ US$82,298,400) in annual revenue. Its 80 sales reps across 6 branches nationwide view the same inventory screen, but because quantities only update after a refresh, branches kept claiming stock that had already been sold. In Q3 2024, a 3-month project began to make the inventory screen real-time.
- The project started when Kim, a manager on the sales support team, raised a problem in a meeting: 'Seoul and Busan are grabbing the same inventory at the same time, and we get 12 canceled shipments a month.'
- The dev team started by removing the 5-second polling on the inventory screen. The lookup API that 80 sales reps had been hitting 43,000 times a day became 80 persistent connections.
- Lee, a deputy manager in infrastructure, got a report that connections drop about a minute after login. After confirming the load balancer's idle timeout was 60 seconds, Lee added a 30-second ping and cut dropped-connection logs from 210 a day to 3.
- On the day they scaled up to 2 servers for peak season, only the Busan branch lost its notifications. The team lead found that the relay channel linking the servers was missing and added it within a day.
- When on-site tablets kept dropping and reconnecting, 1,800 reconnection requests flooded in right after a deployment. The team changed retries to back off at 1, 2, 4, and 8 seconds, and the servers held up.
- Three months later, average inventory-update delay fell from 8 seconds to 0.4 seconds, duplicate orders dropped from 12 a month to 1, and lookup-server CPU fell from 45% to 18%.