HTTP & WebSocket 기술 분석 가이드

먼저 설명할 핵심

이 시스템은 HTTP 요청·응답과 실시간 WebSocket을 별도 파이프라인으로 운영한다. 공통점은 바이너리 프로토콜과 암호화지만, 상태 관리와 장애 복구 책임은 서로 다르다.

책임과 경계

기술 리뷰에서는 클래스를 나열하기보다 각 계층이 무엇을 소유하고 어디까지 책임지는지 설명하는 편이 명확하다.

설계 해석

HTTP는 “요청 순서를 보장하는 단일 차선”에 가깝고, WebSocket은 “연결을 유지하면서 양방향 이벤트를 처리하는 상태 머신”에 가깝다. 따라서 HTTP의 핵심 질문은 큐·타임아웃·콜백 상관관계이고, WebSocket의 핵심 질문은 연결 수명·프레임 무결성·재접속 후 상태 복구다.

HTTP 요청과 응답 흐름

요청은 즉시 병렬 전송되지 않는다. readyQueue에 들어간 뒤 현재 요청 하나만 처리되고, 완료 응답은 doneQueue를 거쳐 Unity 프레임에서 콜백으로 전달된다.

정확한 순서

1. WebClient.Request(...)가 프로토콜을 ProtoWebClient.Request(...)로 전달한다.
2. ReqAndRes가 요청 당시 Suid, 암호화 단계와 ProtocolReq를 캡처한다.
3. Process()가 현재 요청이 없을 때 큐의 선두를 currentRAR로 잡는다.
4. 요청 본문은 [Encrypted:1][Hash:4][ProtocolReq:N] 형태로 구성된다.
5. 응답은 암호화 플래그를 먼저 읽고 XXTea 키를 선택한 뒤 ProtocolRes로 역직렬화한다.
6. 완료 응답을 doneQueue로 옮기고, 다음 Unity Update()에서 프로토콜별 Process(req, res)가 호출된다.

코드 확인 Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:33 · Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:240 · Client/Assets/Haegin/Network/Web/WebClient.cs:2749

연결, 인증, 송수신 흐름

소켓은 TCP 스트림처럼 자체 프레임을 구성하지만 실제 전송 수단은 ClientWebSocket의 Binary 메시지다.

연결 상태 머신

코드 확인 Client/Assets/Haegin/Network/Socket/NetSocket.cs:93 · Client/Assets/Haegin/Network/Socket/NetSocket.cs:168 · Client/Assets/Haegin/Network/Socket/SocketClient.cs:60

프로토콜 디스패치

수신 프레임은 ProtocolSerializer.Deserialize 이후 ProtocolId로 분기된다. 역직렬화 실패나 알 수 없는 ProtocolId는 false를 반환해 연결 종료로 이어진다. Handshake 버전 불일치와 Auth 실패도 명시적으로 연결을 끊는다.

Client/Assets/Haegin/Network/Socket/SocketClient.Process.cs:10 · Client/Assets/Haegin/Network/Socket/SocketClient.ProcessHandshakeA.cs:8 · Client/Assets/Haegin/Network/Socket/SocketClient.ProcessAuthA.cs:8

에러는 어디에서 어떻게 처리되는가

이 구현은 전송 예외, 프로토콜 오류, 업무 결과 코드를 서로 다른 채널로 전달한다. 분석에서는 “에러를 잡는다”보다 “누가 어떤 정보로 어떤 복구를 결정하는가”를 설명해야 한다.

HTTP 재시도와 Socket 재연결

HTTP 재시도의 실제 동작

코드 확인 Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:171 · Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:261 · Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:763

WebSocket은 재연결하지 않는다

NetSocket은 연결 종료와 자원 정리만 제공한다. CoopManager.EnsureConnected()는 기능 호출 시 한 번 연결을 보장하지만, 플레이 중 비정상 종료 후 자동 재시도·동일 방 재합류·누락 상태 동기화는 구현하지 않는다. 현재 정책은 끊김을 세션 종료로 보고 ResetRoomState()를 호출하는 것이다.

Client/Assets/Game/Scripts/GamePlay/Coop/CoopManager.cs:453 · Client/Assets/Game/Scripts/GamePlay/Coop/CoopManager.cs:579

직렬화, 프레이밍, 암호화

HTTP 본문

Handshake 이전·이후 암호화 키를 xxtea1, xxtea2로 분리한다. 인증 성공 후에는 서버 Hash와 첫 키를 XOR해 두 번째 키를 만든다.

Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:292 · Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:905

WebSocket 프레임

수신은 최소 5바이트를 기다린 뒤 length를 읽고, 전체 프레임이 버퍼에 쌓일 때까지 반환한다. Key Index가 0보다 크면 해당 IV로 복호화한 뒤 프로토콜을 역직렬화한다.

Client/Assets/Haegin/Network/Socket/NetSocket.cs:223 · Client/Assets/Haegin/Network/Socket/NetSocket.cs:327

보안상 중요한 사실

XXTea와 AES-CBC는 payload 기밀성을 제공할 수 있지만 TLS 서버 인증을 대체하지 않는다. 또한 코드에 보이는 프레임은 별도 MAC이나 AEAD 태그를 포함하지 않으므로 무결성 보장은 전송 채널과 프로토콜 구현의 다른 부분에 의존한다.

스레드 전환과 동시성

콜백 덮어쓰기 위험

WebClient는 handshakedResult, authResult, maintenanceCheckResult 같은 콜백을 요청 객체가 아니라 인스턴스 필드에 저장한다. 전송 큐가 요청 실행을 직렬화하더라도 같은 종류의 두 번째 요청을 첫 응답 전에 등록하면 첫 요청이 두 번째 콜백을 호출할 수 있다.

리뷰 판단 Client/Assets/Haegin/Network/Web/WebClient.cs:163 · Client/Assets/Haegin/Network/Web/WebClient.cs:769

정적 HttpClient 취소 범위

ProtoWebClient.Client는 정적이지만 Abort()는 인스턴스 타임아웃에서 Client.CancelPendingRequests()를 호출한다. URL별 WebClient가 여러 개 존재할 수 있으므로 한 인스턴스의 타임아웃이 공유 클라이언트의 다른 진행 요청까지 취소할 수 있다.

High Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:78 · Client/Assets/Haegin/Network/Web/Source/ProtoWebClient.cs:206 · Client/Assets/Haegin/Network/Web/WebClient.cs:252

Connection ID가 해결하는 문제

소켓의 증가 ID는 이전 연결에서 늦게 도착한 송수신 continuation이 새 연결을 종료하거나 버퍼를 처리하는 것을 막는다. DisconnectAsync(socketId)와 루프 조건이 동일한 ID인지 확인하므로 stale task를 구별할 수 있다.

코드 확인 Client/Assets/Haegin/Network/Socket/NetSocket.cs:22 · Client/Assets/Haegin/Network/Socket/NetSocket.cs:261 · Client/Assets/Haegin/Network/Socket/NetSocket.cs:297

설명할 가치가 있는 강점

강점은 “좋다”가 아니라 어떤 실패를 줄이고 어떤 비용을 치르는지로 설명한다.

주요 리스크와 심화 검토 지점

심각도는 “발생 가능성 × 영향 × 탐지 난이도”를 기준으로 한 리뷰 판단이다.

개선 우선순위

전면 재작성보다 보안과 장애 전파 범위를 먼저 줄이고, 이후 요청 상관관계와 세션 복구를 구조화하는 순서가 현실적이다.

1. 인증서 검증 복원

   기본 플랫폼 검증을 사용하고, 개발 인증서가 필요하면 빌드 환경별 명시적 trust store 또는 제한된 pinning을 적용한다.

2. 요청별 CancellationToken과 응답 컨텍스트 도입

   CancelPendingRequests()를 제거하고 요청별 취소를 사용한다. callback도 ReqAndRes 또는 Task 결과에 결합한다.

3. 재시도 정책을 프로토콜 메타데이터로 분리

   멱등 요청만 exponential backoff + jitter로 재시도하고, 구매·소비는 idempotency key와 서버 중복 제거를 전제로 한다.

4. 에러 모델과 관측성 통합

   Transport, Timeout, Serialization, Protocol, Business 결과를 구조화하고 request ID, protocol ID, elapsed, attempt를 로그에 포함한다.

5. 소켓 종료 수명 보장

   인증 타임아웃·실패 경로에서 반드시 await DisconnectAsync() 후 참조를 비우고 timer와 event 구독을 정리한다.

6. 재접속을 세션 복구 프로토콜로 설계

   backoff 연결, resume token, room ID, last acknowledged sequence, snapshot/delta 동기화를 하나의 복구 상태 머신으로 만든다.

7. 프레임·버퍼 정책 명시

   최대 프레임 크기를 상수로 검증하고, send backpressure 또는 bounded queue로 burst를 흡수하며 초과 정책을 메트릭으로 노출한다.

개선 후 기대하는 인터페이스

예상 질문과 답변

먼저 30초 요약을 말하고, 세부 근거나 대안을 확인할 때 심화 설명으로 확장한다.

빠른 복습

• WebClient는 facade + callback router라고 설명한다.
• ProtoWebClient는 한 번에 한 HTTP 요청만 처리한다.
• 기본 RetryMax는 0, non-WebGL Timeout은 20초다.
• 재시도에는 backoff, jitter, 멱등성 분류가 없다.
• 공유 HttpClient와 전역 취소 범위의 차이를 설명한다.
• 콜백 필드 덮어쓰기 조건을 구체적으로 말한다.
• ThreadSafeDispatcher의 메인 스레드 이점과 예외 은폐를 함께 말한다.
• NetSocket의 4단계 상태와 connection ID 목적을 설명한다.
• Socket frame은 length 4 + key index 1 + payload다.
• 복호화·프로토콜 오류는 fail-closed로 연결 종료된다.
• 자동 재접속과 세션 복구는 별개라고 설명한다.
• 첫 개선은 인증서 검증 복원이라고 답한다.

이 문서는 저장소의 현재 코드만을 근거로 작성했다. 서버 구현과 배포 인프라가 분석 범위에 없으므로 서버 측 중복 제거, TLS termination, 모니터링 체계에 대한 결론은 포함하지 않는다.