Establish native micro runtime checkpoint

1 files changed, 70 insertions, 0 deletions

diff --git a/docs/research/055-authenticated-peer-transport-cost.md b/docs/research/055-authenticated-peer-transport-cost.md
new file mode 100644
index 0000000..b060594
--- /dev/null
+++ b/docs/research/055-authenticated-peer-transport-cost.md
@@ -0,0 +1,70 @@
+# 055 — 인증 문서 피어의 공통 전송 지연과 서버 전용 비용
+
+같은 문서 앱의 직접 저장 비교 [054](054-direct-document-path.md)에 이어, 실제
+인증 RPC 경계까지 직접 기준선을 만들었다. [실험 구현·재현 절차](../../research/experiments/005-direct-document-peer/README.md)의
+두 서버는 같은 `editor.pure`, 프로그램 파서·평가기, 파일 저장소,
+OpenSSL TLS 1.3, 상호 인증, ALPN, 요청·응답 형식을 사용한다. Pure 서버는
+작업 접수·수명·결과 대여를 실행 코어에 맡긴다. 직접 서버는 이 성공
+문서 작업을 수동으로 처리하므로 **일반 런타임 기능까지 동등한 기준선은 아니다.**
+
+처음에는 양쪽에서 인증된 8 KiB 문서 읽기 **32회에 약 1.412초**가 걸렸다.
+요청당 약 44ms였다. [변경 전 원자료](../../research/experiments/005-direct-document-peer/results/2026-09-24-before-nodelay-8k-linux-aarch64.json)의
+중앙값은 직접 1,411.866ms, Pure 1,411.853ms다. 응답의 13B 머리와
+본문을 별도 TLS 쓰기로 보내는 공통 전송 경로에 `TCP_NODELAY`를 적용한 뒤,
+[같은 32회 작업](../../research/experiments/005-direct-document-peer/results/2026-09-24-after-nodelay-8k-linux-aarch64.json)은
+직접 3.024ms, Pure 2.790ms였다. 같은 루프백 조건의 이 짧은 작업에서
+각각 약 467배·506배의 시간 감소다. TLS/TCP 경로에 있던 지연이
+Pure 디스패치 비용을 가렸다는 해석과 맞다. Nagle·지연 ACK의 구체적인
+패킷 상호작용은 캡처하지 않았으므로 **원인 메커니즘은 추론**이다.
+이 배수를 원격망 처리량이나 범용 RPC 성능으로 내세우지 않는다.
+`TCP_NODELAY`는 작은 TCP 패킷을 늘릴 수 있다. 패킷 수·원격망 지연·전력
+비용은 측정하지 않았으므로 이 선택의 범용 최적성도 아직 주장하지 않는다.
+
+수정 뒤 더 긴 실제 문서 읽기를 새 저장소·인증 연결에서 번갈아 실행했다.
+Linux AArch64, GCC 14 `-O2`, OpenSSL 3.6.4, ext4 저장소의 루프백 결과다.
+TLS 핸드셰이크·문서 생성·첫 읽기는 측정 밖이고, 매 요청의 8 KiB 또는
+1 MiB 본문 전체를 Python 클라이언트가 받았으며 결과를 확인했다.
+
+| 인증된 읽기 배치 | 직접 서버 중앙값 | Pure 서버 중앙값 |
+|---|---:|---:|
+| 8 KiB × 1,024회, 6쌍 | 84.436ms | 91.455ms |
+| 위 배치의 요청당 시간 | 82.46µs | 89.31µs |
+| 1 MiB × 64회, 4쌍 | 149.964ms | 152.685ms |
+| 위 배치의 요청당 시간 | 2.343ms | 2.386ms |
+| 벤치마크의 링크된 `text` | 37,862B | 43,454B |
+
+[8 KiB 원자료](../../research/experiments/005-direct-document-peer/results/2026-09-24-nodelay-8k-linux-aarch64.json)의
+쌍별 Pure−직접 시간은 +17.06, −2.19, +15.97, +3.42, −1.13,
+−22.65ms다. [1 MiB 원자료](../../research/experiments/005-direct-document-peer/results/2026-09-24-nodelay-1m-linux-aarch64.json)는
++0.75, −1.22, +18.14, +0.08ms다. 중앙값만 보면 Pure가 느리지만
+쌍별 편차와 역전이 있어 추가 지연의 안정적인 크기를 판정하지 않는다.
+두 서버의 최종 저장 파일 SHA-256은 매 쌍에서 같았다. 서버 RSS는
+반복 읽기 뒤 대체로 약 8.6 MiB로 겹쳤다. OpenSSL·libc의 공유 매핑과
+프로세스 메모리를 포함하므로 전체 TLS 서버를 6 KiB 런타임이라고
+부를 수 없다.
+
+서버만 설치하는 경우를 위해 제품 피어에서 클라이언트 명령을 제외하는
+`make -C prototypes/connections document-server` 선택 빌드를 추가했다.
+기존 클라이언트 겸용 빌드의 `text`는 46,934B, 서버 전용은
+[43,462B](../../research/experiments/005-direct-document-peer/pure-server-after-nodelay-profile-linux-aarch64.json)로
+3,472B 작다. 이 서버만의 [크기·의존성 상한](../../prototypes/connections/peer-server-budget.json)은
+선택 빌드에만 적용한다. 실험기가 별도 컴파일 명령으로 만든 43,454B와
+8B 차이가 있으므로 둘을 같은 실행물의 수치로 합치지 않는다.
+기본 실행 코어와 CLI에는 TLS가 추가되지 않았다.
+[서버 전용 이동 묶음과 크기 상한](056-server-only-document-package.md)도
+추가해, 같은 문서·인증 시나리오를 추출한 아카이브에서 재검증했다.
+
+[기존 클라이언트 겸용](../../research/experiments/005-direct-document-peer/pure-peer-after-nodelay-parity-linux-aarch64.json),
+[서버 전용](../../research/experiments/005-direct-document-peer/pure-server-after-nodelay-parity-linux-aarch64.json),
+[직접 서버](../../research/experiments/005-direct-document-peer/direct-peer-parity-linux-aarch64.json)의
+실제 인증·충돌·1 MiB·오류·복원 시나리오가 통과했다.
+[직접 서버 ASan/UBSan 검사](../../research/experiments/005-direct-document-peer/direct-peer-sanitized-parity-linux-aarch64.json)와
+[Pure 서버 전용 ASan/UBSan 검사](../../research/experiments/005-direct-document-peer/pure-server-sanitized-parity-linux-aarch64.json)도
+통과했다. 공통 TLS 코드를 쓰는 기존 scalar 피어도
+[회귀 검사](../../research/experiments/005-direct-document-peer/scalar-peer-after-nodelay-parity-linux-aarch64.json)를
+통과했다. 이 검사는 기존 생성된 Zig 아카이브와 새 C 전송 코드를 다시
+링크한 것이며 Zig 전체 재생성은 아니다. 이는 현재 시나리오의 기능·메모리
+오류 증거이며, 여러 연결의
+공정성이나 장애망·공격 부하를 입증하지 않는다. 서버는 여전히 한 번에
+연결 하나만 처리하고, 5초 절대 요청 기한을 쓴다. macOS 실행,
+실제 네트워크와 Kitex/QUIC 비교는 남아 있다.