1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
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 비교는 남아 있다.
|
