WebSocket

WebSocket이란

WebSocket은 하나의 TCP 연결을 계속 열어 두고 서버와 클라이언트가 아무 때나 서로 메시지를 보내는 프로토콜이다(RFC 6455). HTTP는 클라이언트가 요청해야만 서버가 응답할 수 있다. 채팅, 알림, 주식 시세, 협업 편집처럼 서버가 먼저 보내야 하는 기능에 쓴다.

주소는 ws://, 암호화된 연결은 wss://다. 실서비스에서는 항상 wss://를 쓴다.

소켓 자체의 동작은 전송 계층의 「소켓과 역다중화」에 있다.

채팅·게임이 WebSocket을 고르는 이유는 세 가지다. 서버가 사건이 생긴 즉시 밀어 줄 수 있고(폴링 지연 없음), 연결을 한 번 맺은 뒤에는 메시지마다 HTTP 헤더가 붙지 않아 프레임 오버헤드가 2~14바이트에 그치며, 양쪽이 동시에 보내는 전이중(full-duplex)이라 입력과 상태 갱신이 서로 기다리지 않는다. 다만 TCP 위라서 패킷 하나가 사라지면 뒤 메시지가 모두 기다린다. 위치처럼 최신 값만 의미 있는 빠른 액션 게임은 UDP 계열(WebRTC 데이터 채널, WebTransport)을 쓰기도 한다(WebRTC).

연결 과정: HTTP에서 갈아타기

처음에는 일반 HTTP 요청으로 시작해 프로토콜을 바꾼다.

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
 
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
 
──── 이후 같은 TCP 연결에서 WebSocket 프레임을 양방향으로 주고받는다 ────

HTTP와 같은 80·443 포트를 쓰므로 방화벽을 통과하기 쉽다. 연결 후에는 HTTP 헤더가 붙지 않아 메시지당 오버헤드가 작다.

서버는 Sec-WebSocket-Key 값에 고정 GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 이어 붙여 SHA-1 해시를 구하고 Base64로 인코딩한 값을 Sec-WebSocket-Accept로 돌려준다. 보안 장치가 아니라 상대가 정말 WebSocket을 이해하는 서버인지(캐시된 HTTP 응답이 아닌지) 확인하는 절차다. 서버는 Origin 헤더를 검사해 허용한 사이트에서 온 연결만 받는다(아래 「보안과 인증」).

버전과 서브프로토콜

Sec-WebSocket-Version: 13은 RFC 6455의 프로토콜 버전이다. 표준이 되기 전 초안들(hixie-76, hybi 초안)은 핸드셰이크와 프레임 형식이 서로 호환되지 않았고, 13으로 확정된 뒤 브라우저가 모두 13만 쓴다. 서버가 모르는 버전이 오면 426 Upgrade Required와 함께 지원하는 버전 목록을 Sec-WebSocket-Version으로 돌려준다. 프로토콜 버전이 고정돼 있어도 메시지 형식은 응용이 진화시켜야 하므로, 그 버전은 서브프로토콜(Sec-WebSocket-Protocol: chat.v2)이나 메시지 안의 버전 필드로 관리한다. 서버를 바꿔도 옛 클라이언트가 한동안 붙어 있으므로, 두 형식을 함께 받다가 옛것을 내리는 식으로 옮긴다(브라우저 실시간 통신의 「연결과 상태」).

프레임

연결 뒤 데이터는 프레임 단위로 오간다.

종료는 양쪽이 close 프레임(상태 코드 1000 정상, 1001 떠남 등)을 주고받은 뒤 TCP를 닫는다. 종료 코드 표는 브라우저 실시간 통신의 「종료 코드」에 있다. 직접 구현할 일은 드물고 Node.js의 ws, 각 언어의 검증된 라이브러리를 쓴다. Node.js 22부터는 클라이언트용 WebSocket이 전역으로 들어 있다.

텍스트 프레임과 바이너리 프레임은 페이로드를 해석하는 약속이 다르다.

메시지가 작고 드물면 JSON 텍스트가 무난하고, 초당 수십 번 상태를 보내는 게임·시세처럼 대역폭과 CPU가 병목이면 바이너리로 바꾼다.

Ping/Pong과 연결 유지

ping(0x9)을 받은 쪽은 같은 데이터로 pong(0xA)을 자동으로 돌려줘야 한다. 이 왕복은 두 가지에 쓴다.

• 죽은 연결 감지: 상대가 FIN 없이 사라진 반쯤 열린 TCP 연결은 보낼 데이터가 없으면 영원히 살아 있는 것처럼 보인다. 서버가 주기적으로(예: 30초) ping을 보내고, 정해진 시간 안에 pong이 오지 않으면 연결을 끊고 자원을 회수한다.
• 유휴 타임아웃 방지: 로드 밸런서·프록시·NAT는 트래픽이 없는 연결을 일정 시간(흔히 60초) 뒤 끊는다. 그보다 짧은 주기로 ping을 보내면 연결이 「사용 중」으로 유지된다.

브라우저는 서버의 ping에 pong을 자동으로 답하지만, JS에서 ping 프레임을 보낼 API는 없다. 클라이언트 쪽에서 끊김을 빨리 알아야 하면 {"type":"ping"} 같은 응용 메시지로 하트비트를 따로 둔다(브라우저 실시간 통신의 「재연결과 하트비트」). TCP keepalive와의 차이는 전송 계층의 「연결이 살아 있는지 확인하기」에 있다.

확장과 압축

확장(extension) 은 프레임 형식에 기능을 얹는 장치다. 클라이언트가 Sec-WebSocket-Extensions로 후보를 내고 서버가 받아들인 것만 응답에 담아 그 연결에서 쓴다. 확장은 RSV 비트와 새 opcode를 쓸 수 있다. 실제로 널리 쓰이는 것은 permessage-deflate(RFC 7692) 하나다. 브라우저는 이 확장을 자동으로 제안한다.

요청: Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
응답: Sec-WebSocket-Extensions: permessage-deflate; server_no_context_takeover

메시지 단위로 DEFLATE 압축을 하고, 압축한 메시지는 첫 프레임의 RSV1을 켠다. 텍스트 JSON은 크게 줄지만 공짜가 아니다.

브라우저 API

const ws = new WebSocket("wss://example.com/chat");
 
ws.addEventListener("open", () => ws.send(JSON.stringify({ type: "join", room: 1 })));
ws.addEventListener("message", (e) => console.log(JSON.parse(e.data)));
ws.addEventListener("close", (e) => console.log("closed", e.code));
ws.addEventListener("error", () => console.log("error"));

표준 API는 단순하다. 재연결, 방(room), 이벤트 이름, 응답 확인 같은 기능은 직접 만들거나 Socket.IO 같은 라이브러리를 쓴다. 상태 값, 바이너리 수신, bufferedAmount로 송신 속도 조절, 지수 백오프 재연결은 브라우저 실시간 통신에 정리했다.

실시간 통신 방식 비교

HTTP 서버는 브라우저에 먼저 연결을 걸 수 없다. 그래서 누가 일을 하느냐로 나눠 보면 정리가 쉽다. 폴링·롱 폴링은 브라우저가 계속 물어서 최신 데이터를 얻고, SSE·WebSocket은 연결을 맺은 뒤 서버가 바로 밀어 준다. 롱 폴링은 메시지를 하나 받을 때마다 요청을 새로 보내야 해서 메시지가 잦으면 헤더와 왕복이 쌓이고, 서버는 매달린 요청을 붙잡아 두는 비용이 든다. 서버끼리 이벤트를 알릴 때는 같은 고민이 폴링과 웹훅의 선택이 된다(웹훅과 폴링).

서버에서 받기만 하면 되면 SSE가 더 단순하다. 양방향이 필요할 때 WebSocket을 고른다.

HTTP/2와 무엇이 다른가

HTTP/2도 한 연결에서 여러 스트림을 동시에 주고받지만, 둘은 푸는 문제가 다르다.

둘을 겹쳐 쓸 수도 있다. RFC 8441은 HTTP/2 연결 안의 스트림 하나를 확장 CONNECT(:protocol = websocket)로 WebSocket 통로로 여는 방법을 정했고, RFC 9220은 HTTP/3에서 같은 일을 한다. 그러면 페이지 요청과 WebSocket이 TCP 연결 하나를 나눠 쓴다. 다만 서버·프록시 지원이 고르지 않아 대부분의 WebSocket은 여전히 HTTP/1.1 Upgrade로 열린다.

보안과 인증

인증은 핸드셰이크 때 한다. 브라우저 WebSocket API는 Authorization 같은 커스텀 헤더를 붙일 수 없어서 방법이 정해져 있다.

연결이 길게 살아 있는 동안 세션도 관리한다. 연결 시 확인한 사용자 ID를 연결 객체에 묶어 두고(connectionId → userId, 구독한 방), 서버가 여러 대면 「누가 어느 서버에 붙어 있나」를 Redis 같은 공용 저장소에 기록해 다른 서버가 그 사용자에게 보낼 수 있게 한다. 토큰은 연결보다 먼저 만료될 수 있으므로, 만료 시각에 서버가 4001 같은 응용 코드로 끊어 재인증을 유도하거나, 클라이언트가 새 토큰을 메시지로 보내 연장한다. 로그아웃·권한 회수 때는 해당 사용자의 연결을 서버가 찾아 끊는다. 세션·토큰 방식 자체는 세션 기반 인증과 토큰 기반 인증에 있다.

서버 여러 대로 늘리기

연결이 길게 이어지므로 일반 HTTP API와 확장 방식이 다르다. 설계 전체(브로커, 방 분할, 팬아웃, 부하 테스트)는 실시간 웹소켓 서버 설계에 있다.

장애 조치와 우아한 종료

서버 한 대가 죽으면 그 서버의 연결은 모두 끊긴다. 연결 자체는 옮길 수 없으므로 클라이언트가 다른 서버로 다시 붙고, 상태는 서버 밖에 둔다가 장애 조치의 기본이다.

• 방 구독·읽은 위치·놓친 메시지는 공용 저장소(Redis, DB)나 브로커에 두어 어느 서버로 재접속해도 이어 받게 한다. 클라이언트는 마지막으로 받은 메시지 ID를 들고 재접속해 빈 구간을 받아 온다.
• 로드 밸런서가 헬스 체크로 죽은 서버를 풀에서 빼고, 클라이언트는 지수 백오프 + 무작위 지연으로 재연결해 남은 서버에 몰리지 않게 한다.

배포처럼 계획된 종료는 연결을 한꺼번에 끊지 않고 비운다(draining).

1. 헬스 체크를 실패로 바꿔 로드 밸런서가 새 연결을 보내지 않게 한다
2. 붙어 있는 클라이언트에 close 프레임을 보낸다
   (1001 Going Away 또는 1012 Service Restart: 「곧 다시 붙으면 된다」는 뜻)
   한 번에 다 보내지 않고 나눠 보내 재접속이 다른 서버에 한꺼번에 몰리지 않게 한다
3. 클라이언트의 close 응답을 기다린다. 처리 중인 메시지는 마저 보낸다
4. 유예 시간(예: 30초)이 지나면 남은 연결을 강제로 닫고 프로세스를 끝낸다

쿠버네티스에서는 preStop 훅과 terminationGracePeriodSeconds를 이 유예 시간에 맞춘다(쿠버네티스 워크로드).

프록시를 지날 때

라이브러리 고르기

기준은 상대 클라이언트가 누구인가(표준 준수가 필요한가), 필요한 기능을 직접 만들 여력이 있나, 연결 규모다.

디버깅과 흔한 문제

브라우저 개발자 도구의 Network 패널에서 WebSocket 요청을 고르면 핸드셰이크 헤더와 101 응답, Messages 탭의 송수신 프레임(시각·크기·내용)이 보인다. 명령줄에서는 websocat이나 wscat -c wss://…로 직접 연결해 서버만 따로 시험한다. 연결이 안 되면 curl -i에 Upgrade 헤더를 붙여 핸드셰이크 응답 코드부터 본다.

정리

• WebSocket은 OS 소켓이 아니라 TCP 위의 응용 계층 프로토콜이다. HTTP 101 Switching Protocols로 시작해 하나의 연결로 양방향 메시지를 주고받는다.
• 프레임은 텍스트(UTF-8)와 바이너리로 나뉘고, ping/pong으로 죽은 연결과 유휴 타임아웃을 다룬다. 압축(permessage-deflate)은 연결당 메모리·CPU와 맞바꾼다.
• 서버 → 클라 단방향이면 SSE, 양방향이면 WebSocket, P2P면 WebRTC. HTTP/2는 요청·응답 다중화이지 양방향 메시지 채널이 아니다.
• CORS가 없으므로 Origin을 검사하고, 인증은 핸드셰이크 때 쿠키·일회용 티켓으로 한다.
• 다중 서버는 Pub/Sub 전파, 최소 연결 분산, 프록시 Upgrade 설정, 하트비트, 상태 외부화와 우아한 종료까지 함께 설계해야 버틴다.

관련 노트: 실시간 채팅 앱의 데이터 흐름, WebRTC, 전송 계층: 포트, TCP, UDP, HTTP 프로토콜, 브라우저 실시간 통신: 롱 폴링, SSE, WebSocket 클라이언트, 웹훅과 폴링, 실시간 웹소켓 서버 설계