WebSocket

WebSocket은 클라이언트와 서버가 하나의 연결을 유지하면서 양방향으로 메시지를 주고받는 프로토콜입니다.

HTTP 요청·응답
클라이언트 ── 요청 ──> 서버
클라이언트 <─ 응답 ─── 서버

WebSocket
클라이언트 <==========> 서버
          지속 연결

서버가 클라이언트의 새 요청을 기다리지 않고 먼저 메시지를 보낼 수 있어 채팅, 게임, 협업 편집, 실시간 관제에 적합합니다.

WebSocket 연결은 처음에 HTTP Upgrade 요청으로 시작합니다.

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

서버가 전환을 수락하면 이후에는 WebSocket 프레임으로 메시지를 주고받습니다. 암호화 연결은 wss://, 암호화되지 않은 연결은 ws://를 사용하며 실제 서비스에서는 wss://가 기본입니다.

WebSocket은 통신 통로를 제공하지만 업무 메시지의 의미까지 정해주지는 않습니다.

{
  "type": "chat.send",
  "requestId": "req-123",
  "payload": {
    "roomId": 10,
    "message": "안녕하세요"
  }
}

팀은 다음을 정해야 합니다.

• 이벤트 이름
• 요청·응답·알림 구분
• 메시지 데이터 구조
• 오류 표현
• 요청과 응답을 연결하는 ID
• 메시지 순서와 중복 처리
• 버전 관리 방법

이 약속 전체를 WebSocket API라고 부를 수 있습니다.

지속 연결에는 연결 끊김이 정상적으로 발생합니다. 모바일 네트워크 변경, 화면 절전, 프록시 Timeout, 서버 배포 등으로 끊길 수 있습니다.

필요한 처리:

• 재연결 간격을 점차 늘리는 Backoff
• Ping/Pong 또는 Heartbeat로 연결 생존 확인
• 재연결 후 누락 메시지 복구
• 중복 메시지를 막는 이벤트 ID
• 연결 종료 시 리소스 정리

연결이 살아 있다고 해서 메시지를 빠짐없이 받는다는 보장은 없습니다.

연결 시 쿠키나 토큰으로 사용자를 인증할 수 있습니다. 연결 이후에도 각 방 입장이나 이벤트 처리에서 권한을 검사해야 합니다.

연결 인증 성공
≠ 모든 채팅방 메시지를 볼 권한이 있음

토큰 만료와 갱신, 로그아웃 시 연결 종료, Origin 검사도 고려해야 합니다.

서버가 여러 대라면 한 사용자의 연결이 어느 서버에 붙어 있는지 고려해야 합니다. 다른 서버에서 발생한 이벤트를 전달하려면 Redis Pub/Sub, 메시지 브로커 같은 공유 계층을 사용할 수 있습니다.

사용자 A ─> WebSocket 서버 1 ─┐
                              ├─ 메시지 브로커
사용자 B ─> WebSocket 서버 2 ─┘

장점

• 클라이언트와 서버 모두 먼저 메시지를 보낼 수 있습니다.
• 반복 HTTP 요청보다 실시간 상호작용에 적합합니다.
• 텍스트와 바이너리 메시지를 모두 다룰 수 있습니다.

한계

• 재연결, 상태, 순서, 중복을 직접 설계해야 합니다.
• 서버 연결 수와 메모리·네트워크 자원을 관리해야 합니다.
• 일반 HTTP보다 관측과 장애 분석이 복잡할 수 있습니다.
• 단순 CRUD에는 불필요하게 복잡합니다.

• 채팅과 멀티플레이 게임
• 클라이언트도 서버에 빈번히 이벤트를 보내는 실시간 기능
• 공동 편집과 실시간 커서
• 관제 화면과 기기 제어처럼 양방향성이 필요한 경우

서버에서 클라이언트로만 데이터를 보내면 된다면 SSE가 더 단순할 수 있습니다.

WebSocket은 지속 연결을 통해 클라이언트와 서버가 양방향으로 메시지를 주고받게 하는 프로토콜이다.