[WebSocket] 실시간 통신

이리·2025년 6월 26일

실시간 채팅 기능을 구현해보며 WebSocket이라는 기술을 직접 사용해보았는데요,

WebSocket을 사용하는데 있어 왜 필요한지, WebSocket이 무엇인지에 대해 공부해보았습니다!

WebSocket 왜 필요할까?

WebSocket의 필요성을 이해하기 위해, 흔히 사용하는 HTTP 통신 방식과 비교해보며 그 차이를 쉽게 이해할 수 있었습니다.

HTTP 통신의 단방향성

HTTP 통신은 클라이언트가 서버에 요청을 보내면 서버에서 이에 해당하는 응답을 보내주는 구조입니다. 즉, 클라이언트가 요청해야만 서버가 응답할 수 있는 단방향 통신 방식이라는 특징이 있습니다.

하지만, 채팅, 알림, 실시간 데이터 표시 기능처럼 실시간으로 클라이언트와 서버 간의 양방향 통신이 필요한 경우, HTTP 통신 방식으로는 한계가 있습니다. HTTP는 클라이언트가 요청해야만 서버가 응답할 수 있기 때문에 서버가 임의의 시점에 클라이언트에게 데이터를 보내는 것이 불가능합니다. 이는 곧, 실시간성이 중요한 기능들에서는 제약으로 작용하게 됩니다.

HTTP 통신의 대안

그렇다면 HTTP 통신으로는 실시간 통신과 유사한 기능을 구현하지 못하는 걸까요?

꼭 그렇지는 않습니다. 앞서 언급했듯이, 서버가 클라이언트에게 응답을 보내기 위해서는 클라이언트의 요청이 선행되어야한다고 했는데요, 그렇다면 클라이언트가 일정 주기로 계속해서 서버에 요청을 보내면 되지 않을까요?

맞습니다. 해당 방식을 사용한다면 실시간과 유사한 효과를 낼 수 있으며, 대표적으로 다음과 같은 방식들이 존재합니다

방식	특징	단점
Polling	클라이언트가 일정 주기로 서버에 요청을 보내는 방식	- 불필요한 요청이 다수 발생 - 매 요청마다 Connection, Header 등 HTTP 통신에 대한 서버 부담 - 실시간 ≠ 일정 주기
Long Polling	클라이언트가 요청을 보내면, 서버는 응답할 데이터가 생길 때까지 대기 후 응답	- Polling보다 요청 수는 적지만 여전히 HTTP 기반 통신의 서버 부담 - 클라이언트와 서버가 연결을 유지하고 있어야 해 리소스 관리 필요
Streaming	서버가 클라이언트와 연결을 유지한 채 데이터를 지속적으로 전송	- SSE(Server Sent Event)와 같이 알림 기능에 효율적이지만 Server → Client 단방향 통신만 가능

WebSocket

이러한 점들을 종합해 볼 때, WebSocket은 실시간 통신의 적합한 기술이 될 수 있습니다.

WebSocket은 서버와 클라이언트간 메시지 교환을 위한 통신 규약입니다.

WebSocket의 특징

양방향성(Full-Duplex): 클라이언트와 서버가 동시에 데이터를 송수신할 수 있어 실시간 상호작용이 가능합니다.
실시간성(Real-Time Networking): 연결을 유지한 상태에서 즉각적으로 데이터 전송이 가능하므로 실시간으로 데이터 전달이 가능합니다.

WebSocket 동작 과정

WebSocket 동작 과정은 크게 연결, 통신, 종료 세가지로 나눌수 있습니다.

연결

여기서 중요한 점은 WebSocket 연결의 시작은 항상 HTTP 통신으로 이루어진다는 점입니다.

클라이언트 → 서버: 업그레이드 요청(HTTP GET)
클라이언트는 기존의 HTTP 통신을 WebSocket 통신으로 바꾸기 위해 서버에게 HTTP ‘Connection: Upgrade, Upgrade: webSocket’ 헤더가 포함된 GET 요청을 보냅니다.
(ws://로 요청을 보내는 것으로 보이지만, 실제로는 HTTP 1.1 기반 GET 요청으로 진행됩니다!)
서버 → 클라이언트: 101 Switching Protocols 응답

서버가 해당 업그레이드 요청을 수락하면 HTTP 상태코드 101 Switching Protocols를 응답하며 WebSocket 프로토콜로 통신을 전환하게 됩니다.
WebSocket 연결 성립