WebSocket과 실시간 통신

HTTP는 기본적으로 클라이언트가 요청을 열고 서버가 응답을 돌려주는 모델입니다.

서버가 브라우저 쪽에 임의의 순간 새 연결을 열어 데이터를 밀어 넣는 구조가 아니기 때문에, 채팅, 실시간 알림, 주식 시세처럼 지연이 짧은 양방향 통신에서는 단순한 요청-응답만으로 한계가 드러납니다.

HTTP로 실시간을 흉내 내는 방법들

짧은 주기로 계속 물어보는 polling은 구현이 쉽지만 빈 응답과 HTTP 헤더 비용이 큽니다.

Long polling은 서버가 새 이벤트가 생길 때까지 응답을 늦춰 낭비를 줄이지만, 응답이 끝날 때마다 다시 요청을 열어야 합니다.

SSE는 서버에서 클라이언트로 흐르는 이벤트 스트림에 잘 맞고, WebSocket은 한 번 연결한 뒤 같은 연결에서 양쪽이 독립적으로 메시지를 보낼 수 있습니다.

WebSocket 핸드셰이크

브라우저의 WebSocket 연결은 보통 HTTP/1.1 Upgrade 메커니즘으로 시작합니다.

wss://를 쓰면 이 핸드셰이크도 TLS 연결 위에서 이뤄집니다.

Sec-WebSocket-Accept는 클라이언트가 보낸 키에 매직 문자열 258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 결합하고 SHA-1 해시를 취한 뒤 Base64로 인코딩한 값입니다.

이 값은 서버가 WebSocket 핸드셰이크를 이해했는지 확인하기 위한 장치이지, 사용자 인증이나 암호화 기능은 아닙니다.

예시: Accept는 사용자 비밀번호가 아닙니다 RFC 6455의 예시 키 dGhlIHNhbXBsZSBub25jZQ== 뒤에 위 매직 문자열을 그대로 붙여 SHA-1·Base64를 적용하면 s3pPLMBiTxaQ9kYGzzhZRbK+xOo=가 됩니다. 키를 먼저 Base64 디코딩한 바이트에 매직 문자열을 붙이는 계산과는 다릅니다. HTTP 상태가 101이어도 Accept가 예상 값과 다르면 브라우저는 연결을 받아들이지 않습니다. 공개된 계산을 누구나 할 수 있으므로 이 일치는 사용자가 로그인했다거나 전송이 암호화됐다는 증거가 아닙니다.

HTTP/2에서는 일반적인 Upgrade 헤더 대신 RFC 8441의 Extended CONNECT 방식으로 WebSocket을 시작할 수 있습니다.

다만 클라이언트, 서버, 프록시, 로드 밸런서가 모두 지원해야 하므로 실무에서는 인프라 지원 여부를 확인해야 합니다.

WebSocket 프레임 구조

WebSocket은 메시지를 하나 이상의 프레임으로 나눠 보낼 수 있습니다.

클라이언트가 서버로 보내는 프레임은 마스킹이 필수이며, 이는 중간 장비 오동작을 줄이기 위한 프로토콜 장치이지 암호화가 아닙니다.

제어 프레임은 분할할 수 없고 페이로드는 최대 125바이트입니다.

프레임 길이를 독립적으로 계산하기 확장을 사용하지 않고 UTF-8 변환 뒤 125 B인 텍스트를 클라이언트가 한 프레임으로 보냅니다. 기본 헤더 2 B와 마스킹 키 4 B를 더하면 WebSocket 프레임은 몇 B인가요? 본문이 126 B로 늘면 무엇이 더 필요할까요? 같은 126 B를 Ping의 페이로드로 보낼 수 있을까요?

WebSocket 구현

import asyncio
import websockets
from websockets.exceptions import ConnectionClosed

connected = set()

async def handler(websocket):
    connected.add(websocket)
    try:
        async for message in websocket:
            # 보낸 사람을 제외한 클라이언트에게 순차 전송
            for ws in connected.copy():
                if ws != websocket:
                    try:
                        await ws.send(message)
                    except ConnectionClosed:
                        pass
    finally:
        connected.discard(websocket)

async def main():
    async with websockets.serve(handler, "0.0.0.0", 8080):
        print("WebSocket server on ws://0.0.0.0:8080")
        await asyncio.Future()  # 서버 유지

asyncio.run(main())

접속 집합을 복사해 await 사이의 접속·종료가 순회를 깨뜨리지 않게 하고, 복사 후 종료된 수신자는 건너뜁니다. 공식 broadcast 문서에서 설명하듯 순차 send는 느린 수신자의 버퍼가 비워질 때까지 다른 전송도 기다립니다. 이 학습 예제에는 인증·Origin 검사·재연결·메시지 재생이나 수신자별 대기열 정책이 구현되어 있지 않습니다.

const ws = new WebSocket("ws://localhost:8080");

ws.onopen = () => {
  console.log("Connected");
  ws.send("Hello!");
};

ws.onmessage = (event) => {
  console.log("Received:", event.data);
};

ws.onclose = () => {
  console.log("Disconnected");
};

ws.onerror = (error) => {
  console.error("Error:", error);
};

원래 코드의 수신자를 먼저 예측하기 서버에 A만 연결돼 있고 A가 Hello!를 보낸다면 수신자는 없습니다. handler는 보낸 사람을 제외하므로 에코 서버처럼 A에게 그대로 돌려주지 않습니다. A가 계속 연결된 상태에서 B도 접속해 서버의 connected 집합에 들어간 뒤 B의 onopen이 Hello!를 보내면 A는 그 메시지를 받지만 B 자신은 받지 않습니다. B 접속 전의 A 메시지는 보관해 뒀다가 B에게 보내지 않습니다. 이 순서와 성공한 send를 가정한 코드 추론이며 새 서버·브라우저 실행 로그가 아닙니다.

받은 순서로 독립 추론하기 A·B·C가 모두 집합에 있고 종료나 전송 오류가 없을 때 A가 메시지를 보냅니다. 어느 클라이언트가 받을까요? B와 C 중 누가 먼저 받는지도 이 코드만으로 확정할 수 있나요?

SSE (Server-Sent Events)

모든 실시간 통신에 WebSocket이 필요한 것은 아닙니다.

SSE(Server-Sent Events)는 HTTP 응답을 text/event-stream으로 유지하면서 서버에서 클라이언트로 이벤트를 흘려보냅니다.

SSE는 브라우저의 EventSource가 재연결과 Last-Event-ID 전달을 도와주므로 알림·피드·진행률에 적합합니다. 누락 이벤트 복구에는 서버의 ID 부여·보관·재생 처리가 별도로 필요합니다.

반대로 클라이언트도 높은 빈도로 메시지를 보내야 하거나 바이너리 데이터를 주고받아야 한다면 WebSocket이 더 자연스럽습니다.

세 방식 모두 프록시의 버퍼링·유휴 시간 제한·연결 종료 정책을 확인해야 합니다. SSE라는 이유만으로 즉시 전달이 보장되지는 않습니다.

Socket.IO의 역할

Socket.IO는 단순한 WebSocket wrapper라기보다 자체 클라이언트와 서버 프로토콜을 가진 실시간 통신 라이브러리입니다.

Socket.IO의 기본 연결 순서는 HTTP long polling으로 연결한 뒤 WebSocket 업그레이드를 시도하는 방식입니다. 현재 지원 전송에는 WebTransport도 있으며, 순서와 대체 시도는 클라이언트 옵션·서버 지원에 따라 달라집니다.

Socket.IO는 재연결, heartbeat, 방(room), namespace, acknowledgement 같은 기능을 제공하지만, 순수 WebSocket 클라이언트와 그대로 호환되는 프로토콜은 아닙니다.

양쪽 모두 Socket.IO를 쓰는 애플리케이션인지, 아니면 표준 WebSocket API만 필요한지 먼저 구분해야 합니다.

운영에서는 heartbeat와 유휴 제한, 재접속 간격, 인증 만료 시 연결 종료, 메시지 ID에 의한 중복 처리 여부를 함께 정합니다. TCP 연결 유지나 재연결 성공은 메시지 전달 완료와 별개입니다.

다음 장에서는 코드를 넘어 실무 네트워크 인프라 — CDN, 로드 밸런서, 프록시, 클라우드 네트워크 — 를 다루겠습니다.