choose-network-transport

Choose Network Transport

Purpose

Choose the smallest transport that fits the feature before code changes start. The practical decision is whether the work needs request/response HTTP, bidirectional messages, browser media, low-latency object delivery, direct QUIC behavior, or a higher-level framework route.

Source Check

Check repo-local docs and current protocol sources before making claims:

• RFC 9000: QUIC
• RFC 9114: HTTP/3
• W3C WebRTC
• RFC 8825: Real-Time Protocols for Browser-Based Applications
• IETF MoQ working group documents

State whether the chosen protocol is stable, draft-driven, browser-dependent, platform-dependent, or blocked by deployment infrastructure.

Classification Workflow

1. Inspect the feature:
   • client runtime: browser, Apple app, Android app, CLI, backend service, embedded device, or server-to-server
   • payload shape: request/response, events, streams, media frames, files, game state, telemetry, commands, or arbitrary bytes
   • latency, reliability, ordering, congestion, and back-pressure needs
   • network reality: proxies, CDN, firewalls, NAT, mobile networks, UDP availability, TLS termination, and HTTP version support
   • existing stack plugins that own implementation details
2. Choose the candidate:
   • plain HTTP routes for simple request/response APIs, CRUD, webhooks, and service commands
   • Server-Sent Events for one-way server-to-browser event streams where HTTP infrastructure matters more than bidirectional transport
   • WebSocket for widely deployed bidirectional app messages when media, NAT traversal, and multiplexed streams are not the core job
   • HTTP/3 when the app benefits from QUIC-backed HTTP semantics, modern CDN/browser support, reduced head-of-line blocking, or migration from HTTP/2
   • direct QUIC only when the application must own streams, datagrams, connection migration, or transport behavior below HTTP
   • WebRTC for browser or native real-time audio, video, screen sharing, data channels, NAT traversal, and peer/media topology work
   • Media over QUIC when the work is low-latency media distribution, relay/subscription/object delivery, or draft experimentation where MoQ terminology is central
   • gRPC or RPC when typed service contracts, generated clients, streaming RPCs, or internal service boundaries are the dominant need
3. Reject overbuilt options:
   • do not choose QUIC only because HTTP/3 exists
   • do not choose WebRTC for ordinary app messages that a WebSocket or HTTP route can handle
   • do not choose MoQ for general video chat, conferencing, or stable production media unless the draft and implementation risk is explicit
   • do not choose MCP, custom RPC, or a bespoke protocol when a plain route is clearer
4. Route implementation to the owning stack plugin.

Handoffs

• Use http3-quic-workflow for HTTP/3, QUIC, ALPN, Alt-Svc, UDP, proxy, or transport-version work.
• Use webrtc-workflow for WebRTC media, data channels, signaling, ICE, TURN, browser/native constraints, or peer/media topology.
• Use realtime-media-over-quic-workflow for Media over QUIC or MoQ draft-driven media distribution.
• Use network-protocol-diagnostics when the task begins with logs, packet captures, browser failures, proxy behavior, TLS, CDN, or NAT traversal.
• Use stack plugins for implementation: server-side-swift, rust-skills, python-skills, server-side-jvm, web-dev-skills, apple-dev-skills, android-dev-skills, and cloud-deployment-skills.

Output Shape

Return:

1. Chosen transport: HTTP, SSE, WebSocket, HTTP/3, direct QUIC, WebRTC, MoQ, gRPC/RPC, or mixed.
2. Why: concrete feature and deployment evidence.
3. Maturity: RFC-backed, W3C-backed, draft-driven, browser-dependent, platform-dependent, or infrastructure-gated.
4. Implementation owner: stack plugin, framework, package, service, or client surface.
5. Validation: exact build, test, browser, runtime, trace, curl, qlog, packet-capture, or deployment check.
6. Handoffs: next skill or plugin to use.