WebSocket 이란? WebSocket Best Practice!

🧊 개요

모든 세부적 개념보다는, 반드시 알아야 할 개념과 이 개념들을 알게 됐을 때,
WebSocket 을 통한 개발에 문제가 없게 하기 위해 만들게 됨

🧊 WebSocket 과 HTTP 의 주요 차이점?

🐑 요약

• 공통점: 둘 다 TCP 소켓 위에서 동작한다.
• 차이점: HTTP는 요청-응답 기반의 단방향 통신 모델, WebSocket은 양방향(Full Duplex) 통신 모델이다.

🐑 3-way-handshake

• TCP 계층에서 이뤄지는 “SYN → SYN+ACK → ACK” 과정을 통해 소켓 연결을 확립한다.
• HTTP, WebSocket 모두 결국 TCP 위에서 동작하므로, 연결 시 이 과정을 거친다.
• 그러나 WebSocket 핸드셰이크는 추가로 HTTP Upgrade 요청/응답을 통해 프로토콜을 ws로 전환한다는 점에서 다르다.

🐑 양방향 통신

• 요청/응답이 아닌, 양방향(Full Duplex) 연결이 수립되면, 클라이언트와 서버는 독립적으로 서로에게 메시지를 보낼 수 있다.
• HTTP의 Keep-Alive(Connection: keep-alive)는 동일 TCP 연결을 재사용할 뿐이지, 양방향 통신을 제공하지는 않는다.

🐑 특징 차이점 요약

 

특징WebSocketHTTP

통신 방식	양방향(Full-duplex)	단방향 (요청-응답)
연결	연결 지향적(Connectionful)	비연결 지향적(Connectionless) 또는 연결 재사용
프로토콜	ws:// 또는 wss://	http:// 또는 https://
데이터 전송	프레임(Frame) 단위	메시지(Message) 단위
실시간성	높음	낮음
서버 푸시	가능	불가능 (Polling, Long Polling, SSE 등으로 구현 가능)
오버헤드	연결 수립 후 오버헤드 낮음	요청/응답마다 헤더 정보 전송으로 인한 오버헤드
상태 관리	Stateful (연결 상태 유지)	Stateless (상태 정보 없음)

🧊 실전

🐑 개발자 도구 - network

▫️ Headers - GET

WebSocket 연결은 HTTP GET 요청으로 시작하지만, 이는 WebSocket Handshake를 위한 초기 요청일 뿐이며, 이후:의 데이터 전송은 HTTP GET과는 무관하다.

▫️ Headers - 101 Switching Protocols

스위칭 프로토콜, 말 그대로 프로토콜이 스위칭 됐다는 뜻이다. http 프로토콜에서. ws 프로토콜로 업그레이드 됐다. http 프로토콜에서 ws 프로토콜로 스위칭 됐다 라고 보면 된다.

▫️ Headers - Response Headers - upgrade

Connection: Upgrade, Upgrade: websocket 등 헤더를 통해, 기존 HTTP 프로토콜이 ws 프로토콜로 전환되었음을 알 수 있다.

▫️ Messages

🔻 빨강 : Server에서 Client로 보낸 메세지
🟢 초록 : Client에서 Server로 보내는 메세지

🐑 요청과 응답이 아닌, 일방적인 메세지 전송

• 응답을 내려주지 않음
• 독립적인 메세지 전송
• http 처럼 메세지를 보낼 때 마다 Http Status 코드를 받는게 아님

🐑 WebSocket을 사용 시 장애 대비 전략

http 프로토콜과 다르게, 요청에 대한 응답을 제대로 내려주지 않는다. 해당 요청이 얼마나 걸렸는지, 요청을 보냈을 때 어떠한 오류 응답 코드도 받을 수 없다.

▫️ Health Check(Clinet → Server) - - Silent Failure 감지

• 연결이 끊겼는지, WebSocket 서버에 주기적으로 PING(혹은 Health Check 메시지)을 보내고, 서버가 응답(PONG)을 한다면 연결이 유지되고 있음을 알 수 있다.

▫️ Heartbeat(server → Client) - Silent Failure 감지

• 반대로, 연결이 수립된 후, 연결된 Client에게, 주기적으로 Heartbeat 메세지를 전송하도록 한다.
  이렇게 하면, Client 는 주기적으로 오던 메세지를 받지 못했을 때, 서버에 이상이 있다고 판단할 수 있다.

▫️ Ack(Acknowledgement)

• 서버는 클라이언트에게 메세지를 받으면, 반드시 클라이언트에게 어떤 메세지를 받았는지, 다시 메세지를 보내줘야 한다.
• 이 때, 메세지에 ID를 부여해서 처리할 수 있다.

▫️ Reconnect - 회복 탄력성

• WebSocket 서버와 연결이 끊겼을 때를 대비해 재연결 로직을 구현해야 한다
• WebScoket 서버에 부담을 주지 않으려면, 백오프(BackOff) 기법(재연결 시도 간격을 점차 늘리는 방식) 방법도 고려한다.

▫️Exponential BackOff (지수 백오프)

• 연결하려는 클라이언트 1대만 생각했을 때는, 연결 재시도를 지속적으로 시도했을 때 얼마나 많은 부하가 갈까 생각할 수 있지만, 서버가 정말로 죽어있다가 다시 정상 상태가 되었을 때, 연결 재시도를 받는 서버 입장에서는, 동시에 수많은 클라이언트가 동시에 연결을 시도하는 경우, 한번에 모든 부하를 받는 문제가 생길 수 있음. 이 지수 백오프를 통해서, 모든 클라이언트가 동시에 접속 시도하는 문제를 방지할 수 있다.
  예시)
  1. 재연결 1회차 → 즉시 시도
  2. 재연결 2회차 → 1초 뒤 시도
  3. 재연결 3회차 → 2초 뒤 시도
  4. 재연결 4회차 → 4초 뒤 시도 …

▫️메세지 저장 및 복구 전략

• 서버와 연결이 끊어졌을 때 전송 실패한 메시지를 임시로 저장했다가 재전송하는 방안도 생각해 봐야 한다.
• 저장 위치는 다음을 고려할 수 있다
  • 메모리 저장 : 빠르지만, 앱이나 브라우저 종료 시 유실 가능성
  • 로컬 DB 저장 : 앱 종료 이후에도 보존 가능(안정성 높음), 개발 비용 증가
  • 로컬 파일 저장 : 간단한 방법이나 관리가 불편하고 데이터가 많으면 속도 저하 가능

▫️로그 기반 장애 대응

• 메세지 저장 및 복구 전략을 펼칠 수 없을 때, 장애에 대응하기 위해서 로그라도 남기는 방법을 고려해야 한다.
• 로그 필수 기록항목을 정의해서 기록한다.
  예시)
  - 메세지 발송 실패 시점
  - 메세지 내용 및 식별자(ID)
  - 재발송 여부 및 상태…..

▫️실패 알림(모니터링) 전략

• 모니터링을 통해서, 장애 및 이상 감지가 발생한 경우 슬랙 등 알림을 통해 유저가 장애를 인지하기 전에 개발팀 및 운영팀에서 먼저 확인할 수 있도록 알림을 받도록 해야 한다.

🧊 장애대응 전략에 대한 요약

 

전략설명

Reconnect	회복탄력성(Resilience)
Health Check (PING/PONG)	연결상태 감지(Connection Health)
Heartbeat	Silent Failure 감지
ACK	메시지 신뢰성 보장 (Reliability)
BackOff	서버 보호 (Server Protection)
메모리/로컬DB 큐잉	메시지 유실 방지 (Message Durability)
알림 (Slack 등)	빠른 장애 대응 및 복구 (Rapid Response)
로그 기반 대응	장애 추적성 (Traceability)

🧊 참고 자료

• https://developer.mozilla.org/ko/docs/Web/API/WebSocket
• https://websockets.spec.whatwg.org/#the-websocket-interface
• https://spring.io/guides/gs/messaging-stomp-websocket