diff options
Diffstat (limited to 'docs/design/006-native-protocol.md')
| -rw-r--r-- | docs/design/006-native-protocol.md | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/docs/design/006-native-protocol.md b/docs/design/006-native-protocol.md new file mode 100644 index 0000000..9b51fec --- /dev/null +++ b/docs/design/006-native-protocol.md @@ -0,0 +1,139 @@ +# 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·새 전송 후보가 구현된 것은 아니다. + +## 결정 + +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보다 빠르다는 결과나 새 전송의 보안 동등성은 아직 없다. |