실시간 통신: Polling, Long Polling, SSE, WebSocket

1. 과도기적 기술(Polling, Long Polling, SSE)

 

- HTTP는 단방향 통신과 Stateless를 유지하기 위해 무거운 헤더 오버헤드가 있기 때문에 요청-응답의 구조에서 실시간 웹을 구현하는데 있어 치명적 결함을 가집니다. 

 

- WebSocket이 표준화 되기전에 HTTP의 한계를 우회하기 위해 고안된 기법으로는 Polling, Long Polling, SSE가 있습니다.

(1) 폴링(Polling): 클라이언트가 일정한 주기마다 서버에 새로운 데이터가 있는지를 반복적으로 HTTP 요청을 보내는 가장 원시적인 방법입니다. 구현이 매우 단순하지만, 서버에 변경된 데이터가 없음에도 무의미한 요청과 응답이 지속적으로 발생하기 때문에 서버의 CPU와 네트워크 대역폭을 심각하게 낭비하여, 실시간성 역시 폴링 주기에 종속됩니다.

 

(2) 롱 폴링(Long Polling): 일반 폴링의 단점을 보완한 방식으로, 클라이언트가 요청을 보내면, 서버는 즉시 응답하지 않고 새로운 데이터가 발생할 때까지 HTTP 연결을 열어둔 상태로 대기(Pending)합니다. 이벤트가 발생하면 그때 응답을 반환하고 연결을 닫고, 클라이언트는 응답을 받고 다시 롱 폴링 요청을 보냅니다. 무의미한 빈 응답은 줄어들었지만, 데이터 갱신이 빈번하게 일어나는 환경에서는 매번 HTTP 연결을 새로 맺어야 하므로 일반 폴링보다 오히려 서버 부하가 가중될 수 있습니다.

 

(3) SSE(Server-Sent Events): 서버에서 클라이언트로의 단방향 실시간 통신을 구현하기 위한 W3C 표준 기술입니다. 클라이언트가 처음 HTTP 요청을 맺을 때 헤더에 Accept: text/event-stream을 명시합니다. 서버는 연결을 닫지 않고 이벤트가 발생할 때마다 이 단일 연결 통로를 통해 일련의 텍스트 데이터를 지속적으로 스트리밍합니다. 뉴스 피드나 알림 시스템 등 클라이언트에서 서버로 데이터를 보낼 필요가 없는 도메인에서는 WebSocket보다 가볍고 효율적으로 동작합니다.

 

2. WebSocket

 

- WebSocket은 독자적인 프로토콜(ws://또는 wss://)을 사용하지만, 기존의 80(HTTP) 또는 443(HTTPS) 포트를 그대로 활용하기 위해 초기 연결은 HTTP 요청으로 시작됩니다.

-> 클라이언트가 일반적인 HTTP GET 요청을 보낼 때 헤더에 Connection: Upgrade와 Upgrade: websocket을 포함하여 전송합니다. 서버가 이를 지원한다면 101 Switching Protocols 상태 코드와 함께 응답하며, 이 순간부터는 TCP 통신 통로는 더 이상 HTTP 규약을 따르지 않고 WebSocket 프로토콜로 업그레이드되어 영구적인 양방향 파이프가 형성됩니다.

 

- HTTP는 메세지(Message) 단위로 통신한다면, WebSocket은 오버헤드를 줄인 프레임(Frame) 단위로 통신합니다. WebSocket의 프레임 헤더는 수백 바이트에 달하는 HTTP 헤더와는 달리 단 2~10 바이트에 불과하며, 헤더 뒤에는 실제 전송하려는 페이로드가 위치합니다. 초기 핸드셰이크 이후에는 거대한 HTTP 메타데이터 없이 순수한 목적 데이터만을 빠른 속도로 주고받을 수 있습니다.

 

- WebSocket 보안: 클라이언트가 서버로 전송하는 모든 데이터 프레임의 페이로드는 반드시 마스킹(XOR 난독화)처리가 되어있어야합니다.  옛날 웹 인프라에서는 HTTP Proxy, CDN 캐시, 중간 게이트웨이에서 HTTP 트래픽만을 이해하면 됐습니다. 하지만 HTTP에서 업그레이드 된 후 바이너리 프로토콜이 된 WebSocket에서는 클라이언트가 보낸 데이터를 프록시가 HTTP 요청으로 오인하여 캐시에 저장하고 다른 사용자에게 전달되면 캐시 오염 공격(Cache Poisoning)이 발생합니다. 

-> 클라이언트는 32 bit 랜덤 키를 생성하여 XOR 난독화를 진행합니다. 

 

Q. WebSocket은 캐시로 갈 필요가 없어서 마스킹하는 건가요?
A. WebSocket은 시작은 HTTP 위에서 하기 때문에 HTTP 인프라를 지나갑니다. 하지만 프록시(캐시) 서버는 HTTP만을 이해하기 때문에 HTTP처럶 보이면 캐시하려고 할 수 이고 이를 방지하기 위해 HTTP처럼 보이지 않기 위해 마스킹 과정을 합니다.

 

- Fragmentation(단편화)는 큰 메세지를 여러 프레임으로 쪼개서 전송하는 것으로, 너무 큰 메세지를 한번에 전송하게 되면 네트워크 버퍼가 터짐, 다른 메세지 대기, 연결 독점 등의 문제가 발생합니다. 

-> WebSocket에서는 Frame을 여러개로 조개고 FIN = 1이 나왔을 때 하나의 메세지로 합친 뒤에 Application Layer로 전달합니다. 중간에 Control Frame이 낄수도 있다는 편리함이 있습니다.

*Control Frame은 데이터가 아니라 연결 상태를 제어하기 위한 프레임으로, Close(연결 종료), Ping(살아있는지 요청), Pong(Ping 응답)의 3가지 상태가 있습니다. 프레임 단위의 전송에서 중간에 컨트롤 프레임이 들어오더라도 하나의 메세지가 아니니 당연히 합쳐지지 않고 즉시 처리됩니다.