DeukPack 프로토콜 보안(Fail-Fast) 및 대용량 페이로드 아키텍처 가이드¶
이 문서는 DeukPack(득팩) 1.7.0 아키텍처에 구현된 통합 프로토콜 보안 쉴드(OOM 방어 시스템)의 설계 철학과, 이로 인해 파생되는 대용량 데이터 처리(Large Payload) 분산 구조 가이드를 제공한다.
1. 근본 철학: Zero-Overhead 와 Fail-Fast¶
네트워크 계층에서 직렬화(Serialization)/역직렬화(Deserialization) 모듈은 외부 공격(DDoS, 악의적인 변조 패킷)에 가장 먼저 노출되는 최전선이다. 잘못된 메모리 할당으로 인해 전체 서버 프로세스나 클라이언트 앱이 터지는 Out-Of-Memory(OOM)가 발생해서는 안 된다.
DeukPack은 Zero-Overhead(성능 저하 0) 와 Fail-Fast(즉시 에러 차단) 를 핵심 철학으로 삼아, 5대 백엔드 엔진(C#, C++, Java, JS, Elixir) 전반에 걸쳐 강력한 보안 실드를 구축했다.
- 성능 저하 없음: 보안 가드는 CPU가 100% 분기 예측(Branch Prediction)을 성공시킬 수 있는 단순 상수(Constant) 기반의 길이 체크 컴파일(
if (len > MAX))로 설계되어 있어 추가적인 벤치마크 지연(Nanoseconds)을 발생시키지 않는다. - Fail-Fast: 프로토콜 버퍼에서 객체 인스턴스를 메모리에
new하기 직전 길이(Length / Count)를 먼저 읽어 상한을 위반하면 즉시 예외(throw Exception)를 던지고 버퍼를 버린다.
2. 유니버설 OOM 방어망 정책¶
DeukPack의 모든 프로토콜(패킷 바이너리, 콤팩트, JSON 등)은 파싱 단계에서 아래의 엄격한 상한선이 하드코딩되어 강제 적용되어 있다.
2.1. 단일 데이터 크기 제한 (MAX_SAFE_LENGTH: 10MB)¶
바이너리 블록, 문자열(String) 타입 등 단일 메모리 버퍼로 할당되어야 하는 요소는 최대 10MB (10 * 1024 * 1024 Bytes) 를 초과할 수 없다.
- 해커가 변조된 바이너리를 보내 문자열 길이가 2GB인 것처럼 조작할 경우, 메모리를 할당하기 전에 10MB 조건식에서 즉각 차단된다.
2.2. 컬렉션 요소 개수 제한 (MAX_ELEMENT_COUNT: 1,000,000)¶
List, Set, Dictionary/Map 같은 컬렉션 구조가 가질 수 있는 최대 원소의 개수는 1백만 개 로 제한된다.
- 해커가 배열 요소 개수 헤더를 인위적으로 MAX_INT32로 보내 악의적인 루프를 유도하더라도, 루프에 진입조차 못하고 바로 메모리가 방어된다.
2.3. 무한 재귀 및 뎁스 제어 (MAX_RECURSION_DEPTH: 64)¶
중첩된 구조체나 재귀적으로 정의될 수 있는 계층 구조는 최대 64 뎁스 까지만 파싱할 수 있다. (StackOverflow 방지)
3. JSON 스트리밍 파서 취약점 완벽 차단¶
통상적으로 JSON 파싱에서 가장 큰 OOM 취약점은, 스트림 전체의 데이터를 메모리로 끝까지 읽어들인 이후(예: StreamReader.ReadToEnd()) 객체로 역직렬화하는 전통적인 구현 방식이다. (2GB짜리 JSON 문자열 공격 시 2GB 메모리 증발)
DeukPack 1.7.0에서는 Java, C++, C# 엔진 전반의 JSON 스트리밍 레이어를 점진적 청크 로딩 방식으로 전면 교체 완수했다.
- ReadToEnd() 같은 메모리 블랙홀을 금지.
- 스트림에서 한계치까지만 버퍼를 읽으며 누적 바이트가 10MB를 초과하는 순간 바로 std::runtime_error, RuntimeException 등의 예외를 던지고 폐기.
이 모든 상황은 새로 도입된 자동 퍼즈 검증 파이프라인(test-fuzz-oom.js)에 의해 영구적으로 지속 검증(CI)된다.
4. 실무 대용량 페이로드 전략 가이드¶
개발 실무에서 "합법적으로 10MB가 넘는 매우 거대한 데이터(예: 바이너리 통계, 용량이 큰 에셋 페이로드 등)를 전송해야 하는데, 득팩의 보안 실드를 올리면 어떻게 처리해야 하나?" 라는 의문이 들 수 있다. 제한선을 풀 수 있는 환경설정을 오픈하는 것은 보안 원칙을 훼손하므로, 시스템 설계 방향을 다음과 같이 안내한다.
4.1. "득팩은 시리얼라이저이지 파일-트랜스퍼(FTP)가 아니다"¶
DeukPack의 핵심 타겟과 목적은 가장 빠르고 가벼운 RPC 직렬화 및 객체 상태 보존이지, 파일 전송 프로토콜(File Transfer)이 아니다. 네트워크 메시지 또는 게임 패킷은 본질적으로 수 바이트에서 많아도 수십 킬로바이트 사이에 수렴해야 한다.
4.2. 대용량 처리는 "청크 분할"과 "페이지네이션" (Application Layer 책임)¶
10MB가 넘는 거대한 정보가 발생했다면, 그것은 구조체의 단일 패킷으로 한 번에 보낼 영역이 아니다. 서버와 클라이언트 아키텍처 레벨(Application Layer)에서 데이터를 나누어야 한다.
- 데이터 페이지네이션 (Pagination): 10만 건이 넘는 랭킹 리스트라면, 클라이언트의 화면이 표출할 수 있는 페이지(예: 100단위) 크기별로 여러 번 RPC 규격으로 주고받는 방식으로 잘라 설계한다.
- 청크 분리 스트리밍 (Chunking): 이미지/파일 데이터를 전달해야 한다면, 구조체 패킷에는 파일의
metadata(GUID, size, checksum)만 담아서 전달하고, 실제 데이터 본체 크기는 HTTP 스트리밍이나 파일 다운로드 파이프라인(S3 Presigned URL, CDN 등)을 통해 별도로 분리 우회 취득하는 것이 올바른 아키텍처이다.
4.3. 내부 인트라넷 배치(Batch) 서버¶
일부 서버-대-서버(Server-to-Server) 백엔드 배치 워크로드 등 물리적으로 신뢰할 수 있는 구간에서 초-대용량 구조체를 Dump 해야 할 경우라면 JSON/Binary 스펙 대신, 대용량 파일 내보내기/불러오기에 특화된 스트림 처리 파이프라인을 사용해야 한다. (현재 DeukPack의 목표는 신뢰 없는 외부 클라이언트-서버 간 초고속 안전 통신망 확립에 초점이 맞추어져 있다)