path: root/docs/design/006-native-protocol.md

# Pure의 자체 통신 형식과 보안 전송 경계

작성일: 2026-09-23, 구현 상태 갱신: 2026-09-24. 상태: 설계 방향과 제한된 첫 구현.
성능 결과나 QUIC 구현은 아니다.

2026-09-24 구현 상태: 선택한 scalar 앱과 `editor.pure` 문서 앱에 자체 이진 형식을
TLS 1.3/TCP 위에 실은 피어 호스트를 검증했다. [026 — scalar 피어](../research/026-secure-peer-link.md)와
[030 — 문서 피어·출력 소비 선택](../research/030-authenticated-document-peer.md)을 본다.
이 설계의 일반 RPC·QUIC·새 전송 후보가 구현된 것은 아니다.

2026-09-28: 노드 사이 전달의 새 UDP 전송 후보는 [011 — 연결 없는 전송](011-pure-transport.md)이다. 링크의 전송
상태를 앱 상태와 한 커밋에 두어 연결 개념을 없앤다. 아래 "새 UDP 전송은 … 별도 연구 후보로 연다"는 조건은 그 가설과
중단 기준이 판정한다.

## 결정

Pure 간 통신은 HTTP 메서드·URL·문자열 헤더를 필수 실행 모델로 삼지 않는다.
앱이 작성한 연결과 데이터 형식에서 자체 바이너리 통신 형식을 준비하는 방향으로 진행한다.
HTTP는 웹·기존 도구와 연결하는 호환 경계로 유지한다. 첫 검증 전송은 TLS 1.3/TCP이며,
최종 범용 전송 정책은 아직 선택하지 않았다.

외부 런타임·서비스·프로그램과의 통신도 핵심 요구사항이다. Pure끼리의 자체 형식과 별도로
상대가 사용하는 프로토콜·형식으로 요청을 받고 보낼 수 있어야 한다. 외부에 Pure 사용을
요구하지 않으며, 자체 형식의 계약을 구현한 외부 프로그램과의 연결도 허용하는 방향이다.

적용 범위 보완: [작은 OS로서의 Pure](007-execution-domains.md)가 연결의 의미와 운영 정책을
소유한다. 공유가 허용된 내부 데이터에는 직접 호출·대여·소유권 전달을 사용하며, 이 문서의
바이너리 경계 형식을 모든 내부 연결에 강제하지 않는다. 현재 호스트의 IPC·소켓은 가용한
전달 수단이며 Pure 앱의 필수 개념이 아니다.

`prototypes/connections/server.c`는 루프백 TCP 위의 평문 HTTP/1.1이며 요청마다 연결을 닫는다.
`on get` / `on put`과 요청 키도 그 작성 프로필에 들어 있다. 별도의 선택형 피어 호스트는
해당 scalar 앱에서 HTTP 없이 입력·상태·저장을 주고받는다. 이 둘은 아직 하나의 범용
프로토콜 선택기로 통합되지 않았다. 기존 HTTP 검증은 저장·범위·수명에 대한 것이며,
피어 검증도 인터넷 운영 보안이나 QUIC 대비 성능을 검증한 것이 아니다. 문서 피어는
같은 `editor.pure` 효과를 C·Python 클라이언트에서 실행하며, 응답 본문을 소비하지 않을
호출에서 그 바이트의 전송을 생략한다.

사용자가 말한 socket 직접 통신은 일반 TCP/UDP 소켓으로도 구현할 수 있다.
IP 패킷을 직접 구성하는 `SOCK_RAW`나 커널 우회까지 필요한 것은 아니다.
각 선택은 실제 제거할 비용이 확인되면 별도로 판단한다.

## HTTP 제거와 QUIC 대체는 다른 선택이다

QUIC은 HTTP 없이도 앱의 자체 프로토콜을 운반할 수 있다.
HTTP/3는 QUIC을 사용하는 앱 프로토콜 중 하나다.
따라서 자체 형식을 QUIC 스트림에 직접 싣는 경로를 첫 비교 후보로 둔다.
[RFC 9308 §1](https://www.rfc-editor.org/rfc/rfc9308.html#section-1)

| 후보 | Pure가 정하는 부분 | 전송에서 사용하는 부분 |
|---|---|---|
| 자체 형식 / QUIC / UDP | 연결 대상, 값 배치, 호출·완료·취소 의미, 전송할 데이터 | QUIC의 보안 연결·스트림·복구·혼잡 제어 |
| 같은 자체 형식 / TLS 1.3 / TCP | 위 의미와 메시지 경계; 필요한 경우 호출 다중화 | TLS의 데이터 보호와 TCP의 순서 있는 바이트 전달 |
| 자체 형식 / 새 전송 / UDP | 위 부분과 새 전송의 모든 계약 | 재사용할 암호 구현 외에 전송 설계·검증도 필요 |

두 번째 경로는 비교 및 UDP가 통하지 않는 환경의 연결 후보다. TCP+TLS를 QUIC과 모든 면에서
동일하다고 보지 않는다. 예를 들어 TCP 바이트 스트림 하나에 여러 호출을 실으면 손실로 인한
전달 대기를 공유하며, QUIC의 독립 스트림·경로 변경과 같은 기능은 자동으로 생기지 않는다.
보안 연결에 실패했을 때 평문으로 낮추는 동작은 후보에 포함하지 않는다.
[RFC 9308 §2](https://www.rfc-editor.org/rfc/rfc9308.html#section-2),
[RFC 9293 §2.2](https://www.rfc-editor.org/rfc/rfc9293.html#section-2.2)

QUIC의 보안은 TLS 1.3을 통한 인증·키 설정과 패킷 보호를 포함한다.
신뢰성·안정성에는 손실 복구, 혼잡·흐름 제어, 주소 검증과 증폭 제한 등의 별도 계약도 있다.
암호 알고리즘 하나를 붙이거나 헤더를 줄인 것만으로 이 전체와 동등하다고 평가하지 않는다.
전송 보호와 앱의 접근 권한·저장 완료·응답 유실 후 중복 실행 처리도 구분한다.
[RFC 9001 §2](https://www.rfc-editor.org/rfc/rfc9001.html#section-2),
[RFC 9000 §4, §8](https://www.rfc-editor.org/rfc/rfc9000.html#section-4),
[RFC 9002](https://www.rfc-editor.org/rfc/rfc9002.html)

## 연결에서 생략할 수 있는 정보

후보 흐름은 다음과 같다. 구체적인 패킷 배치나 필드 바이트 수는 아직 고정하지 않는다.

1. 인증된 세션에서 허용된 입력·출력, 형식 버전, 한도와 전달 의미를 확인한다.
2. 대상·형식을 연결이나 스트림에 결부하거나 짧은 세션 내 식별자로 정한다.
3. 후속 메시지는 합의에서 추론할 수 없는 값과 식별 정보만 운반한다.
4. 실행·저장 결과를 앱이 관찰할 수 있는 완료로 전달한다.

예를 들어 특정 문서의 변경 입력에 스트림을 결부했다면 매번 URL·메서드·필드 이름을 보낼
필요가 없을 수 있다. 여러 대상이 섞이면 대상 식별이 필요하고, 가변 길이면 길이 또는
명확한 종료 규칙이 필요하다. 조건부 갱신의 기대 버전, 동시 호출의 대응 관계, 오류 의미는
해당 동작에 필요하면 남긴다. TCP의 한 번의 `read`를 메시지 하나로 간주하지 않는다.

합의 비용도 비용이다. 추가 왕복, 세션별 표, 재연결, 형식 변경과 호환성 확인에 필요한
시간·메모리를 포함한다. 형식 불일치는 해석 전에 거부하고, 원격 식별자를 포인터나
임의 실행 권한으로 취급하지 않는다. 경계 형식은 명시적 바이트 순서·길이·한도를 가지며
네이티브 구조체의 패딩이나 포인터를 그대로 전송하지 않는다.

0-RTT로 저장 효과를 먼저 실행하는 동작은 초기 후보에서 제외한다. 보안 전송만으로 앱의
중복 실행 문제가 해결되지는 않으며, 0-RTT 데이터에는 재전송 공격에 대한 별도 고려가 필요하다.
[RFC 9308 §3.1](https://www.rfc-editor.org/rfc/rfc9308.html#section-3.1)

## Pure에서 확인할 연구 가설

바이너리 인코딩이나 연결별 형식 합의 자체를 신규 기술이라고 주장하지 않는다.
검증할 가설은 **준비된 연산·소비 관계를 전송까지 사용하면, 같은 앱 동작을 유지하면서
반복 해석과 중간 보관·대기를 줄일 수 있는가**다.

- 이미 정해진 대상·필드 접근을 송수신 경계에서 다시 문자열로 만들고 해석하는가?
- 소비자가 사용할 범위만 보낼 수 있는가? 부분 전송에서 필요한 형식·버전도 일치하는가?
- 전송의 수신 한도와 앱의 실제 소비·메모리 예산을 연결해 중복 큐를 줄일 수 있는가?
- 아직 전송하지 않은 최신 상태를 합쳐도 되는가? 모든 사건을 보존해야 하는 연결과 구분되는가?

수신 한도를 소비에 연결할 때 큰 메시지의 나머지를 받기 위해 필요한 여유까지 막으면
교착할 수 있다. 청크 소비 또는 메시지 단위 예산 예약 등으로 진행 가능성도 확인한다.
[RFC 9308 §4.4](https://www.rfc-editor.org/rfc/rfc9308.html#section-4.4)

전송 라이브러리가 소유하는 평문·암호문·재전송 버퍼도 계산에 넣는다. 읽기 전용 저장 매핑을
그대로 암호문으로 덮어쓸 수 없으며, `send`의 접수나 transport ACK를 앱의 저장 완료로
취급하지 않는다. 참조 해제는 실제 전송 API의 소유권 계약에 따라 정한다.
현재의 본문 예산만으로 전체 통신 메모리가 제한된다고 주장하지 않는다.

## 추가 구현과 비교의 경계

먼저 현재 get/put 전용 진입점을 앱 입력과 효과에 대한 내부 호출로 분리한다.
HTTP와 자체 형식은 같은 조건부 저장·응답 동작으로 연결한다. 별도의 범용 메시지 객체를
항상 만들도록 강제하지 않는다. 기존 CLI와 저장·충돌·실패·수명 검증은 유지한다.

첫 TLS 1.3 지속 연결은 [026](../research/026-secure-peer-link.md)에, 실제 문서 작업의
연결과 선택 빌드·메모리 비용은 [030](../research/030-authenticated-document-peer.md)에
기록했다. 다음에는 전체 앱의 실패망·혼합 작업 비용과 병목을 확인한다. 보안 없는 임시 소켓 경로를
인터넷용 완료물로 보고하지 않는다.
새 UDP 전송은 이 단계에서 확인된 구체적인 병목을 기존 전송의 설정·연결 방식으로
제거할 수 없을 때 별도 연구 후보로 연다.

비교가 답할 질문은 분리한다.

- 앱 형식의 효과: 같은 QUIC 구현에서 HTTP/3와 Pure 형식을 비교한다.
- 전송 선택의 효과: 같은 Pure 형식·동작을 QUIC과 TCP+TLS에서 비교한다.
- 새 전송의 효과: 동일한 보안·전달 요구를 충족한 뒤, 같은 Pure 형식을 기존 QUIC 구현과 비교한다.

이 비교들을 모두 선행해야 한다는 뜻은 아니다. 실제 병목에 대한 선택이 필요할 때 해당
비교만 수행한다. 연결 재사용·핸드셰이크·암호 설정·동시성·배치·내구성·완료 정의를 맞춘다.
현재의 평문·요청당 연결 종료 경로는 회귀 검증에 쓰며, QUIC 우위/열위의 근거로 쓰지 않는다.

대표 작업은 기존 작업물의 작은 변경·저장, 큰 내용 전달 중 작은 변경, 느린 수신자와
연결 종료 후 결과 확인이다. 새 전송 판단에는 지연·손실·재정렬이 있는 경로도 필요하다.
실제 성공 작업의 지연 분포, CPU, 전체 메모리와 연결별 비용, 전송 바이트·대기열을
필요한 결정에 맞춰 기록한다. 헤더 바이트 절감만으로 전체 성능 우위를 선언하지 않는다.

현재 결론은 HTTP를 내부 기본 모델로 요구하지 않는다는 것이다.
QUIC보다 빠르다는 결과나 새 전송의 보안 동등성은 아직 없다.