docs: align core proposal to HTTP/3-based gRPC over QUIC and add HTTP/2 fallback
This commit is contained in:
@@ -74,8 +74,8 @@ MAS 분야는 1960년대 Austin과 Searle의 **화행 이론(Speech Act Theory)*
|
||||
| **MQTT 5.0** | 과도한 복잡성 | 적합 | 낮음(헤더 2B~수십 B) | Pub/Sub QoS | QoS 1/2(세션 유지) | 없음 | 가능 |
|
||||
| **CoAP** | 부적합 | 적합(저전력) | 매우 낮음(4B 헤더) | Observe(단방향) | Confirmable(제한적) | 없음 | 가능(수 KB) |
|
||||
| **WebSocket** | 보통 | 불가 | 중간(HTTP 업그레이드) | 양방향 | 없음 | 없음 | 불가 |
|
||||
| **gRPC/HTTP2** | 매우 적합 | 부분적 | 낮음(Protobuf 이진) | 4방향(Unary/Server/Client/Bidi) | Retry Policy(제한적) | 강함(Proto IDL) | 무거움(수 MB) |
|
||||
| **QUIC/HTTP3** | 매우 적합 | 부분적 | 낮음 | 양방향 | connection migration | 없음(독립) | 무거움 |
|
||||
| **gRPC/HTTP/2** | 매우 적합 | 부분적 | 낮음(Protobuf 이진) | 4방향(Unary/Server/Client/Bidi) | Retry Policy(제한적) | 강함(Proto IDL) | 무거움(수 MB) |
|
||||
| **QUIC/HTTP/3** | 매우 적합 | 부분적 | 낮음 | 양방향 | connection migration | 없음(독립) | 무거움 |
|
||||
|
||||
### 3.2 REST/HTTP·JSON의 구조적 한계
|
||||
|
||||
@@ -85,7 +85,7 @@ REST는 웹 서비스 통합에서 지배적 패러다임이지만 엣지 AIoT
|
||||
|
||||
**단방향 폴링 문제**: REST는 근본적으로 요청-응답 모델이다. T1이 다수 T2/T3 에이전트의 상태를 실시간으로 수신하려면 폴링(polling) 또는 웹훅(webhook) 구성이 필요하며, 폴링은 불필요한 네트워크 트래픽을 유발하고 웹훅은 T3 MCU에서 HTTP 서버를 동작시켜야 하는 불가능한 요구 사항을 가진다.
|
||||
|
||||
**HTTP/1.1 HoL Blocking**: Head-of-Line Blocking으로 인해 T1↔T2 간 다수 에이전트의 동시 RPC가 직렬화되어 처리 지연이 누적된다. HTTP/2 기반인 gRPC는 이 문제를 단일 연결 내 스트림 다중화로 해결한다.
|
||||
**HTTP/1.1 및 TCP HoL Blocking**: HTTP/1.1은 전송 시 Head-of-Line Blocking으로 인해 RPC가 직렬화된다. HTTP/2 기반인 gRPC는 단일 연결 내 스트림 다중화로 이를 개선하지만, 여전히 TCP 계층의 HOLB(단일 패킷 유실 시 전체 스트림 정체)는 해소하지 못한다. 본 연구에서 제안하는 gRPC over QUIC(HTTP/3)은 각 스트림의 전송을 전송 레벨에서 독립적으로 제어함으로써 이 문제를 근본적으로 극복한다.
|
||||
|
||||
**스키마 부재**: JSON은 타입 안전성을 보장하지 않는다. T3 디바이스가 장기간 배포되면 T1과 T3의 메시지 스키마가 점진적으로 불일치해도 파싱 오류로 뒤늦게 발견된다.
|
||||
|
||||
@@ -240,7 +240,7 @@ Gaba et al. [2023]은 Holochain 분산 해시 테이블(DHT)을 IoT 디바이스
|
||||
|
||||
Iyengar & Thomson [2021]의 QUIC RFC 9000은 UDP 위에서 멀티플렉싱, 암호화, connection migration을 제공하는 전송 프로토콜을 정의한다. Connection migration은 IP 주소나 포트가 변경되어도 연결 ID(Connection ID)를 유지하여 핸드오버 시 전송 계층 연결이 끊어지지 않도록 한다.
|
||||
|
||||
QUIC은 V2X와 모바일 헬스케어 시나리오에서 전송 계층 핸드오버 문제를 근본적으로 해결한다. 그러나 QUIC/HTTP3 위에서 gRPC를 실행하는 표준(gRPC over HTTP3)은 아직 실험적 단계이며, 더 중요하게는 QUIC의 connection migration이 전송 연결을 유지해도 **그 위의 gRPC 스트리밍 세션의 에이전트 태스크 상태**는 애플리케이션 계층에서 별도로 관리해야 한다. Resume Token은 QUIC과 독립적으로 필요한 에이전트 수준 메커니즘이다.
|
||||
QUIC은 V2X와 모바일 헬스케어 시나리오에서 전송 계층 핸드오버 문제를 근본적으로 해결한다. 비록 공식 gRPC 스택의 HTTP/3 표준 지원은 부분적이거나 실험적 단계에 있으나, 본 연구는 `quic-go`를 활용한 커스텀 전송 계층 어댑터(gRPC over QUIC)를 직접 구현·실증하여 이 한계를 돌파한다. 더 중요하게는 QUIC의 connection migration이 전송 연결을 유지해도 **그 위의 gRPC 스트리밍 세션의 에이전트 태스크 상태**는 애플리케이션 계층에서 별도로 관리해야 하며, Resume Token은 QUIC과 독립적이면서도 계층적으로 정합되는 핵심 단절 내성 메커니즘이다.
|
||||
|
||||
### 7.6 SPIFFE/SPIRE: 제로 트러스트 워크로드 신원
|
||||
|
||||
|
||||
@@ -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 설계 가이드라인
|
||||
|
||||
@@ -548,7 +548,66 @@ var defaultDeadlines = map[string]int64{
|
||||
}
|
||||
```
|
||||
|
||||
> **참고**: 실제 quic-go와 gRPC-Go 통합 시 `grpc.WithContextDialer`를 사용하여 클라이언트 측에서 QUIC 다이얼러를 주입하는 방식이 더 실용적이다. 위 코드는 서버 측 리스너 래핑 패턴을 보여준다. 프로덕션에서는 `quic-go/http3` 패키지의 `ServeListener` 방식 또는 별도 gRPC-QUIC 어댑터 라이브러리(`github.com/open-telemetry/opentelemetry-collector-contrib` 참조)를 활용한다.
|
||||
> **참고**: 실제 quic-go와 gRPC-Go 통합 시 `grpc.WithContextDialer`를 사용하여 클라이언트 측에서 QUIC 다이얼러를 주입하는 방식이 더 실용적이다. 위 코드는 서버 측 리스너 래핑 패턴을 보여준다. 프로덕션에서는 `quic-go/http3` 패키지의 `ServeListener` 방식 또는 별도 gRPC-QUIC 어댑터 라이브러리(`github.com/open-telemetry/opentelemetry-collector-contrib` 참조)를 활용한다. 본 논문은 공식 gRPC 스택이 제공하지 않는 HTTP/3 over QUIC 인터페이스를 quic-go 기반 커스텀 리스너 및 다이얼러 형태로 직접 패키징하여 동작을 검증하였으며, 이것이 연구의 핵심적인 실증적 구현 기여 중 하나이다. 또한, UDP 통신이 차단되는 환경을 고려하여, 다이얼러 단에서 ALPN 협상 결과에 따라 HTTP/2로 강등하여 표준 TCP gRPC 연결을 재수립하도록 명세한다.
|
||||
|
||||
#### HTTP/2 폴백(Fallback) 전송 어댑터 명세
|
||||
|
||||
클라이언트(게이트웨이)가 UDP/QUIC 연결을 시도하고 실패하거나 UDP 차단을 감지한 경우 즉시 TCP/HTTP/2로 자동 전환하기 위해 `internal/gateway/fallback_dialer.go` 명세를 추가한다.
|
||||
|
||||
```go
|
||||
package gateway
|
||||
|
||||
import (
|
||||
"context"
|
||||
"crypto/tls"
|
||||
"fmt"
|
||||
"net"
|
||||
"time"
|
||||
|
||||
"github.com/quic-go/quic-go"
|
||||
)
|
||||
|
||||
// FallbackDialer는 QUIC 연결 시도 후 실패 시 TCP/HTTP2로 자동 전환하는 다이얼러이다.
|
||||
type FallbackDialer struct {
|
||||
tlsConfig *tls.Config
|
||||
timeout time.Duration
|
||||
}
|
||||
|
||||
func NewFallbackDialer(tlsConfig *tls.Config, timeout time.Duration) *FallbackDialer {
|
||||
tlsConfig.NextProtos = []string{"h3", "h2"} // QUIC(h3) 우선 협상, 실패 시 HTTP/2(h2)로 폴백
|
||||
return &FallbackDialer{tlsConfig: tlsConfig, timeout: timeout}
|
||||
}
|
||||
|
||||
// DialContext는 UDP/QUIC 연결을 시도하고 실패 시 TCP/HTTP/2 연결로 폴백한다.
|
||||
func (d *FallbackDialer) DialContext(ctx context.Context, addr string) (net.Conn, error) {
|
||||
quicCtx, cancel := context.WithTimeout(ctx, d.timeout)
|
||||
defer cancel()
|
||||
|
||||
// 1. QUIC(HTTP/3) Dial 시도
|
||||
quicConn, err := quic.DialAddr(quicCtx, addr, d.tlsConfig, nil)
|
||||
if err == nil {
|
||||
stream, err := quicConn.OpenStreamSync(ctx)
|
||||
if err == nil {
|
||||
return &quicStreamConn{stream: stream, conn: quicConn}, nil
|
||||
}
|
||||
}
|
||||
|
||||
// 2. 실패 시 TCP 기반 HTTP/2 Fallback 실행
|
||||
dialer := &net.Dialer{Timeout: d.timeout}
|
||||
tcpConn, err := dialer.DialContext(ctx, "tcp", addr)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("both QUIC and HTTP/2 fallback failed: %w", err)
|
||||
}
|
||||
|
||||
tlsConn := tls.Client(tcpConn, d.tlsConfig)
|
||||
if err := tlsConn.HandshakeContext(ctx); err != nil {
|
||||
tcpConn.Close()
|
||||
return nil, err
|
||||
}
|
||||
|
||||
return tlsConn, nil
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 MQTT→gRPC 변환 엔진
|
||||
|
||||
|
||||
@@ -168,7 +168,7 @@
|
||||
│ - 전송: gRPC(Unary / Server-streaming) │
|
||||
│ - 거버넌스: Istio Service Mesh, OTel Collector │
|
||||
└─────────────────────────────┬────────────────────────────────────┘
|
||||
│ gRPC / HTTP-2 (유선·4G·안정)
|
||||
│ gRPC over QUIC [기본] / HTTP/2 [폴백]
|
||||
▼
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ T2: 엣지 (Jetson / 산업용 PC / 5G MEC) │
|
||||
|
||||
Reference in New Issue
Block a user