문제 17 — WebSocket 프로토콜: 핸드셰이크, 프레임 구조, 게임 트래픽에서의 트레이드오프

브라우저 기반 실시간 게임(웹 캐주얼 게임, 카드 게임, 일부 웹 MMO 클라이언트)은 UDP 소켓을 직접 열 수 없어 WebSocket 을 실시간 통신 채널로 쓰는 경우가 많다. WebSocket 은 HTTP 위에서 시작해 양방향 지속 연결로 전환되는 프로토콜이다. 다음에 답하라.

1. WebSocket 연결은 HTTP 업그레이드 핸드셰이크로 시작한다. 클라이언트가 보내는 Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key 헤더와, 서버가 응답하는 101 Switching Protocols, Sec-WebSocket-Accept 의 역할을 설명하라. Sec-WebSocket-Accept 값은 어떻게 계산되며, 이 메커니즘이 막으려는 것은 무엇인가(순수 TCP 소켓이나 오래된 캐싱 프록시와의 오작동 방지 관점에서).

2. WebSocket 의 프레임 구조를 설명하라. FIN 비트, opcode(텍스트/바이너리/ close/ping/pong 등), MASK 비트, Payload length(7비트/16비트/64비트 확장 길이 인코딩) 각각이 무엇을 나타내는지 정리하라.

3. WebSocket 프레임은 클라이언트 → 서버 방향만 마스킹(masking)이 필수다. 왜 이런 비대칭 규칙이 존재하는가? 마스킹이 암호화가 아님에도 어떤 문제를 완화하기 위한 것인지 설명하라(캐시 오염/프록시 공격 관점).

4. 하나의 논리적 메시지가 여러 프레임으로 나뉘는 메시지 조각화(fragmentation) 를 설명하라. FIN=0 연속 프레임과 opcode=0x0(continuation) 이 어떻게 조합되는지, 그리고 서버가 이를 왜 지원해야 하는지(큰 메시지의 점진적 전송, 멀티플렉싱 없는 단일 스트림에서의 이점) 설명하라.

5. WebSocket 은 TCP 위에서 동작한다. 이 사실이 실시간 게임 트래픽에 주는 영향을 지연(latency)과 헤드오브라인 블로킹(HOL blocking) 관점에서 설명하고, raw UDP 나 QUIC/WebTransport 대비 WebSocket 의 트레이드오프를 정리하라. 그럼에도 브라우저 기반 게임 클라이언트가 WebSocket 을 선택하는 현실적인 이유(플랫폼 제약, 방화벽/프록시 통과성, 구현 단순성 등)는 무엇인가?