게이트웨이 정적서빙 dd 포크폭풍 제거 — 파일소켓전송(opcode 856) 복원

개요

크라우니 게이트웨이가 "예전엔 가벼웠는데 무겁다"는 사용자 직감의 근인을 코드 레벨에서 규명하고, 정적 파일 서빙의 dd 셸아웃 포크폭풍을 네이티브 파일소켓전송으로 교체했다. 오프라인 검증까지 완료, 라이브는 무접촉(gateway 세션 인계).

게이트웨이 본체는 가벼움: 순수 한선씨 gwlive.toau, 8.1MB, CPU 0.9%.
무게의 정체: _정적스트리밍(게이트웨이통합.한선 ~349-359)이 본문을 16KB 청크마다 체계("dd if=... bs=16000 skip=N count=1")로 fork/exec. 10MB 파일 = dd 625회 = fork 625회. 트래픽↑ 시 CPU 폭발.
왜 dd로 떨어졌나: 게이트웨이가 효율 프리미티브 파일소켓전송을 안 쓰고 자체 dd 루프로 짰기 때문.

첫 조사에서 "파일소켓전송=유령함수(미정의)"라 보고했으나 오판이었다:

crownyc.c case 856 = FILE_SOCKET_SEND = 실재하는 정상 네이티브 (C레벨 fread→write, 64KB 버퍼, 부분쓰기 루프 완비).
hanseonc_high.c:1328 {"파일소켓전송", 856, 2} = 키워드 배선도 있음.
오판 원인: crownyc.c(VM)만 grep하고 hanseonc_high.c(컴파일러)의 키워드 테이블을 안 봄.
교훈: opcode 구현=VM(crownyc.c), 키워드 배선=컴파일러(hanseonc_high.c). 둘 다 봐야 "유령" 판정 가능.

네이티브 실증: 200KB 랜덤 바이너리(65535 문자열캡 초과)를 헤더 TCP쓰기 + 본문 파일소켓전송(연결, 파일)로 서빙 → curl 수신본 sha256 = 원본 sha256 (b9c7d015410c9625...), 전송바이트 정확히 204800. fork 0회.
패치: _정적스트리밍의 dd 청크 while루프를 한 줄로 교체.

   변수 보냄 = 파일소켓전송(연결, 절대경로)
   만약 (보냄 < 0) { 반환 거짓 }
   반환 참

헤더(보안헤더 포함)는 기존대로 TCP쓰기 선송출 — 변경 없음.

요청당 1 fork 잔존: 헤더 Content-Length용 파일바이트수(SPA정적.한선:119)가 wc -c 셸아웃. 무fork화하려면 opcode 297(DISK_USAGE = stat→st_size, crownyc.c:8346 실재, hanseonc_high 키워드 배선 없음)에 {"파일바이트크기", 297, 1} 한 줄 추가 + hanseonc_high 재빌드 필요(소폭 컴파일러 변경, option 2). 본문 625→0 대비 부차적이라 이번 패치 범위 제외.
라이브 스왑 미수행: 라이브 게이트웨이(gwlive.toau:8080)는 gateway 세션 담당. 이 작업은 오프라인 검증만 — gateway 세션에 검증된 diff 인계 필요.

feedback_gateway_static_dd_fork_storm 갱신 (유령함수 오판 정정 + 패치 기록).