docs: align core proposal to HTTP/3-based gRPC over QUIC and add HTTP/2 fallback
This commit is contained in:
@@ -27,7 +27,7 @@
|
||||
본 시스템의 모든 아키텍처 결정은 다음 7가지 guiding principle에 근거한다. 각 원칙은 엣지 AIoT의 물리적 이질성과 다중 에이전트 협업의 복잡성에서 도출되었다.
|
||||
|
||||
### P1. Tier-Appropriate Protocol (계층 적합 프로토콜)
|
||||
각 tier는 자신의 자원·연결성·전력 제약에 최적화된 프로토콜을 사용한다. T1 클라우드에는 gRPC/HTTP-2, T2 엣지에는 gRPC over QUIC, T3 현장 디바이스에는 MQTT/CoAP/BLE를 적용한다. **단일 프로토콜로 3-tier 전체를 포괄하려는 설계는 거부한다.** 이는 임베디드 디바이스에 gRPC 풀스택을 강제할 때 발생하는 RAM·Flash 초과 문제와, 클라우드 서버에 MQTT를 사용할 때 발생하는 스키마 안전성 부재 문제를 동시에 해결하는 근거다.
|
||||
각 tier는 자신의 자원·연결성·전력 제약에 최적화된 프로토콜을 사용한다. T1 클라우드와 T2 엣지 통신에는 gRPC over QUIC(HTTP/3)를 기본(Primary) 프로토콜로 채택하며, 방화벽 UDP 차단이나 레거시 인프라 제약 시 차선책으로 gRPC over HTTP/2를 활용한 전송 폴백(Fallback)을 적용한다. T3 현장 디바이스에는 MQTT/CoAP/BLE를 적용한다. **단일 프로토콜로 3-tier 전체를 포괄하려는 설계는 거부한다.** 이는 임베디드 디바이스에 gRPC 풀스택을 강제할 때 발생하는 RAM·Flash 초과 문제와, 클라우드 서버에 MQTT를 사용할 때 발생하는 스키마 안전성 부재 문제를 동시에 해결하는 근거다.
|
||||
|
||||
### P2. Semantic-Transport Separation (시맨틱-전송 분리)
|
||||
에이전트 간 "무엇을 할 것인가(Task 위임·역량 광고)"와 "어떻게 전달할 것인가(Byte 전송)"를 명확히 분리한다. A2A/MCP는 시맨틱 계층에서 동작하고, gRPC/MQTT/CoAP는 전송 계층에서 동작한다. 이 분리는 전송 프로토콜을 교체해도 에이전트 협업 로직이 영향받지 않도록 보장한다.
|
||||
@@ -70,7 +70,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
|
||||
║ └──────────────────────────────────────────────────────────────────────┘ ║
|
||||
╚══════════════════════════════════════════╦═══════════════════════════════════╝
|
||||
║
|
||||
gRPC over QUIC (HTTP/3) / gRPC over HTTP/2
|
||||
gRPC over QUIC (HTTP/3) [기본] / gRPC over HTTP/2 [폴백]
|
||||
W3C traceparent in gRPC Metadata
|
||||
mTLS + SPIFFE SVID
|
||||
║
|
||||
@@ -125,7 +125,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
|
||||
│ - SSE / Webhook: 비동기 Task 상태 업데이트 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Layer 2: Transport Layer (전송 계층) │
|
||||
│ - T1↔T2: gRPC over QUIC (HTTP/3) + Bidi Streaming │
|
||||
│ - T1↔T2: gRPC over QUIC (HTTP/3) [기본] / HTTP/2 [폴백] │
|
||||
│ - T2↔T2: gRPC Bidi Streaming (엣지 합의) │
|
||||
│ - T2↔T3: MQTT 5.0 / CoAP Confirmable / gRPC-Lite │
|
||||
│ - Retry Policy: Exponential Backoff + Jitter │
|
||||
@@ -142,7 +142,7 @@ T3 디바이스와 T2 게이트웨이 사이의 단절은 예외가 아닌 정
|
||||
|
||||
| 구간 | 전송 프로토콜 | 보안 | 지연 목표 | 단절 내성 |
|
||||
|------|------------|------|----------|----------|
|
||||
| T1 ↔ T2 | gRPC over HTTP/2 or QUIC | mTLS + SPIFFE SVID | < 100ms | Resume Token + QUIC conn-migration |
|
||||
| T1 ↔ T2 | gRPC over QUIC [기본] / HTTP/2 [폴백] | mTLS + SPIFFE SVID | < 100ms | Resume Token + QUIC conn-migration |
|
||||
| T2 ↔ T2 | gRPC Bidi Streaming | mTLS + SPIFFE SVID | < 10ms | 로컬 재연결 + Bidi 재확립 |
|
||||
| T2 ↔ T3 (임베디드) | MQTT 5.0 / CoAP | X.509 SVID + TLS-PSK | < 1s | MQTT Last Will + QoS 1/2 |
|
||||
| T2 ↔ T3 (고성능) | gRPC-Lite / nanopb | mTLS Lite | < 50ms | Resume Token |
|
||||
@@ -220,9 +220,9 @@ MCP 도구 호출은 T2 게이트웨이의 gRPC 인터셉터를 통해 tracepare
|
||||
|
||||
**Rationale**: Bidi Streaming을 T2↔T2 엣지 합의에 사용하는 이유는, 다수 엣지 노드가 단일 소켓을 통해 ms 단위의 상호 메시지 교환을 진행할 수 있어 소켓 수를 O(n²)에서 O(n)으로 줄이기 때문이다.
|
||||
|
||||
#### 3.2.2 gRPC over QUIC (T1↔T2)
|
||||
#### 3.2.2 gRPC over QUIC (T1↔T2) [기본] 및 HTTP/2 폴백
|
||||
|
||||
T1↔T2 광역 무선 구간에서는 gRPC를 QUIC(HTTP/3) 위에 실어 다음 이점을 얻는다.
|
||||
T1↔T2 광역 구간은 gRPC over QUIC(HTTP/3) 프로토콜을 기본(Primary) 전송 채널로 사용하며, 다음의 이점을 제공한다:
|
||||
|
||||
- **Connection Migration**: 모바일 IP 변경 시(5G→Wi-Fi) TCP 연결 단절 없이 마이그레이션
|
||||
- **0-RTT Handshake**: 재연결 시 0-RTT로 즉시 재개 (Resume Token과 시너지)
|
||||
@@ -236,6 +236,8 @@ gRPC Frame
|
||||
└── 5G NR / LTE / Wi-Fi Physical
|
||||
```
|
||||
|
||||
또한, 엣지 게이트웨이(T2)와 클라우드(T1) 사이의 전송 신뢰성을 보장하기 위해 **HTTP/2 폴백 협상(Fallback Negotiation)** 메커니즘을 내장한다. 클라이언트(게이트웨이)는 최초 접속 시 ALPN(Application-Layer Protocol Negotiation)에 `h3` 프로토콜을 우선 협상하며, UDP 포트 차단이나 방화벽 제약으로 인해 QUIC 연결이 실패하는 경우 즉시 표준 TCP 기반의 `h2`(gRPC over HTTP/2) 채택으로 강등(Downgrade)하여 연결 연속성을 유지한다.
|
||||
|
||||
#### 3.2.3 T2↔T3 프로토콜 선택 기준
|
||||
|
||||
```
|
||||
@@ -321,7 +323,7 @@ T2 엣지 게이트웨이는 본 아키텍처의 핵심 허브다. 이 컴포넌
|
||||
### 4.1 컴포넌트 다이어그램
|
||||
|
||||
```
|
||||
T1 방향 (gRPC over QUIC / HTTP-2)
|
||||
T1 방향 (gRPC over QUIC [기본] / HTTP/2 [폴백])
|
||||
│
|
||||
┌───────────────▼───────────────────────────────┐
|
||||
│ gRPC Server (T1 facing) │
|
||||
@@ -995,7 +997,7 @@ Jaeger (트레이스 저장) ← Grafana Tempo
|
||||
|
||||
| 설계 항목 | 스마트 팩토리 | 스마트 빌딩 | V2X | 헬스케어 |
|
||||
|---------|------------|-----------|-----|--------|
|
||||
| T1↔T2 백본 | gRPC + HTTP/2 | gRPC + 유선/4G | gRPC + QUIC (5G) | gRPC + 유선 |
|
||||
| T1↔T2 백본 | gRPC + QUIC (HTTP/2 폴백)* | gRPC + QUIC (HTTP/2 폴백)* | gRPC + QUIC (5G, HTTP/2 폴백) | gRPC + QUIC (HTTP/2 폴백)* |
|
||||
| T2↔T3 현장 | MQTT 5.0 / gRPC-Lite | MQTT + LoRa 브릿지 | C-V2X / ITS-G5 | BLE + MQTT |
|
||||
| 저지연 합의 | gRPC Bidi (AGV) | gRPC Unary (HVAC) | QUIC datagram | gRPC Unary (이벤트) |
|
||||
| 핸드오버 | Resume Token | Resume Token | QUIC conn-migration | Resume Token |
|
||||
@@ -1004,6 +1006,8 @@ Jaeger (트레이스 저장) ← Grafana Tempo
|
||||
| 긴급 이벤트 | gRPC Stream 알림 | gRPC Unary 알림 | C-V2X CAM/DENM | gRPC Unary < 1s |
|
||||
| A2A 위임 방향 | T1→T2→T3 계층 | T1→T2 목표 기반 | T1 교통→T2 RSU | T2 감지→T1 임상 |
|
||||
|
||||
* 주: T1↔T2 백본의 기본 전송 프로토콜은 gRPC over QUIC(HTTP/3)를 원칙으로 하나, 유선망 중심의 안정적인 고정 링크(스마트 팩토리, 헬스케어 유선망 등)에서는 인프라 호환성을 위해 gRPC over HTTP/2 폴백(Fallback)을 적극적으로 허용한다.
|
||||
|
||||
---
|
||||
|
||||
## 부록: Proto 설계 가이드라인
|
||||
|
||||
Reference in New Issue
Block a user