WebSocket 통신 방식이란?

요즘 통신을 할 때, Rest 통신 방식이 인기가 많은데, 이는 HTTP를 그대로 사용하고, URI를 통해 자원을 명시합니다.

클라이언트와 서버의 구분이 명확하고, GET, POST, DELETE, UPDATE, PATCH 등 REST API 메시지가 의도하는 바를 명확히 알 수 있어서 사용하기 편합니다. 이는 단방향 통신구조로 서버와의 클라이언트 간의 의존성을 최소화 했기 때문에 서버 상태와 상관없이 클라이언트가 동작할 수 있다는 장점이 있습니다. 하지만 이러한 장점은 데이터가 꾸준히 지속적으로 업데이트 되는 경우에 다음과 같은 단점으로 바뀝니다. 먼저 단방향 요청-응답 구조 때문에 클라이언트가 요청해야만 서버가 응답할 수 있어서 실시간 데이터 전송을 할 때 클라이언트가 새로운 데이터를 얻기 위해서는 계속해서 요청을 해야합니다. 이 때, 매번 새로운 HTTP 요청을 보내기 때문에 서버에 부하가 생기게 됩니다. 또한 변경되거나 새로운 데이터가 없을 때에도 클라이언트는 요청을 반복하여 불필요한 요청이 많아 자원 또한 낭비하게 됩니다.

이러한 HTTP 기반 통신의 단점을 해결하기 위해 Polling, Long Polling, SSE, WebSocket 같은 방식이 등장했습니다.

 

1. Polling (폴링)

개념

클라이언트가 일정한 간격으로 서버에 요청을 보내어 새로운 데이터가 있는지 확인하는 방식.

동작 과정

1. 클라이언트가 일정한 주기로 서버에 요청 (예: 5초마다 요청)
2. 서버는 요청을 받고 즉시 응답 (새로운 데이터가 있든 없든)
3. 클라이언트는 응답을 받고, 다시 일정 시간 후 요청

장점

• 구현이 간단하고, 기존 REST API 구조를 크게 변경할 필요 없음.
• 서버에서 별다른 설정 없이 바로 적용 가능.

단점

• 불필요한 요청 증가 → 새로운 데이터가 없더라도 계속 요청해야 함.
• 실시간성이 부족함 → 일정 주기마다 요청하므로, 데이터가 갱신된 후에도 클라이언트가 즉시 알 수 없음.

📌 사용 예시: 주기적인 데이터 갱신이 필요한 경우 (예: 대시보드, 뉴스 피드)

---

2. Long Polling (롱 폴링)

개념

Polling의 단점을 개선한 방식으로, 클라이언트가 요청을 보내면 서버가 즉시 응답하지 않고 새로운 데이터가 생길 때까지 기다렸다가 응답하는 방식.

동작 과정

1. 클라이언트가 서버에 요청.
2. 서버는 즉시 응답하지 않고, 새로운 데이터가 생성될 때까지 대기.
3. 새로운 데이터가 생기면 서버가 응답을 보냄.
4. 클라이언트는 응답을 받은 후 다시 요청을 보냄 (반복).

장점

• 새로운 데이터가 있을 때만 응답하므로 불필요한 요청을 줄일 수 있음.
• 기존 REST API와 큰 차이 없이 적용 가능.

단점

• 서버에서 요청을 오래 유지해야 하므로 동시 연결이 많아지면 서버 부하 증가.
• 클라이언트가 응답을 받을 때까지 대기해야 하므로, 실시간성이 완벽하지 않음.

📌 사용 예시: 채팅 시스템, 알림 시스템 (단, 실시간성이 완벽하지 않아 WebSocket보다 덜 사용됨)

---

3. SSE (Server-Sent Events)

개념

서버가 클라이언트로 단방향으로 지속적인 데이터를 푸시(Push) 하는 방식.

동작 과정

1. 클라이언트가 서버에 한 번만 요청을 보냄.
2. 서버는 지속적으로 데이터를 푸시함 (Connection을 유지).
3. 새로운 데이터가 있을 때마다 서버가 클라이언트에게 보냄.

장점

• HTTP 기반이므로 방화벽과 프록시를 통과하기 쉬움.
• 클라이언트가 요청을 여러 번 보낼 필요 없음.
• Polling, Long Polling보다 네트워크 부하가 적음.

단점

• 단방향 통신이므로 클라이언트 → 서버로 메시지를 보낼 수 없음.
• WebSocket보다 기능이 제한적.

📌 사용 예시: 실시간 주식 가격, 뉴스 피드, 서버 알림 (단방향 데이터 스트리밍)

---

4. WebSocket

개념

기존 HTTP 요청-응답 방식과 다르게, 양방향 통신이 가능한 실시간 연결을 유지하는 방식.

동작 과정

1. 클라이언트가 WebSocket 연결을 요청 (HTTP handshake).
2. 서버가 연결을 승인하면 TCP 기반의 지속적인 연결이 형성됨.
3. 이후 클라이언트와 서버는 서로 데이터를 주고받을 수 있음.
4. 필요할 때까지 연결을 유지하며, 더 이상 필요하지 않으면 종료.

장점

• 양방향 실시간 데이터 전송 가능.
• 네트워크 부하가 적음 (한 번 연결 후 지속적으로 사용 가능).
• 낮은 지연시간 (Low Latency) → 거의 즉각적인 응답.

단점

• HTTP 기반이지만 기존 REST API와 다르게 동작하므로 구현이 복잡함.
• 클라이언트와 서버가 지속적으로 연결을 유지해야 하므로 메모리 사용 증가.
• 프록시나 방화벽에서 WebSocket을 차단할 수 있음.

📌 사용 예시: 실시간 채팅, 게임, 주식 거래 시스템, IoT

 

이를 정리하자면,

 

방식	특징	장점	단점	사용 예시
Polling	일정 주기마다 요청	구현이 간단함	불필요한 요청 많음, 실시간성이 부족	뉴스 피드, 대시보드
LongPolling	서버가 응답을 기다렸다가 전송	불필요한 요청 감소	서버 부하 증가	채팅, 알림 시스템
SSE	서버 -> 클라이언트 단방향 전송	지속적인 연결 유지, 부하 적음	양방향 통신 불가	뉴스 스트리밍, 실시간 알림
WebSocket	양방향 실시간 통신	빠르고 실시간성 뛰어남	구현 복잡, 서버 부담 증가	채팅, 게임, 주식 거래

---

이렇듯 여러 통신 방식이 나왔지만 WebSocket 통신 방식이 양방향으로 실시간성이 가장 뛰어나다고 할 수 있습니다. 

WebSocket을 사용하는 이유에 대해 알아보았는데, 다음은 WebSocket이 어떤식으로 동작하는지 자세히 알아보겠습니다.

 

한눈에 그림으로 보면, 다음과 같습니다.

이는 핸드셰이크(HandShake) 방식을 사용하고, Upgrade : Websocket 을 통해 프로토콜을 업그레이드 하여 사용합니다. 이게 무슨 뜻이냐면, 먼저 클라이언트 측에서 서버에 HTTP GET 요청으로 핸드셰이크 요청을 보냅니다. 이 때, 헤더에는 Upgrade: wesocket, Connection: Upgrade, Sec-WebSocket-Key 등을 포함합니다. 이를 통해 서버에 WebSocket으로 업그레이드를 요청합니다. 서버가 이를 수신하여 다시 HTTP 101 Switching Protocols 응답을 보내면, 클라이언트는 WebSocket 연결이 성공적으로 확립되었음을 확인합니다. 이 응답 헤더에는 Sec-WebSocket-Accept 값이 포함되어 있어, 요청의 유효성을 검증합니다. 이렇게 연결이 확립되면 클라이언트는 WebSocket 프레임 단위로 메시지를 전송하고, 서버에서의 응답 역시 동일한 방식으로 수신되며 양방향 통신이 가능해집니다. 통신을 지속하다가 한 쪽이 close 프레임을 보내어 연결 종료 요청을 하면, 상대측에서 종료 절차를 수행한 후 연결이 종료됩니다.

 

HandShake나 WebSocket 통신 방식에 대해 얕게나마 알고는 있었지만 이번에 사용 이유나 다른 통신 방식들도 함께 알아보면서 WebSocket 방식과 넓게는 통신 방식 자체를 더 자세히 알 수 있어서 의미있던 것 같습니다.

 

감사합니다.