Skip to content

Feature Request: Add WebTransport Support #67

Description

@panuchka

Summary

Add first-class support for WebTransport as a transport protocol for game servers managed by the GameServer Ingress Controller.

Motivation

WebTransport provides a modern transport layer for browser-based multiplayer games by combining:

  • Low-latency communication over QUIC (HTTP/3)
  • Bidirectional streams
  • Unreliable datagrams
  • Built-in congestion control
  • Better connection migration than WebSockets

Supporting WebTransport would allow browser clients to communicate with game servers using a protocol that is better suited for real-time networking than traditional WebSockets.

Proposed Solution

Extend the controller to support multiple transport protocols when generating ingress resources.

For example:

metadata:
  annotations:
    octops.io/transport: webtransport

The controller would continue to create the required Service resources, while generating Gateway API or Ingress resources configured for WebTransport-compatible routing.

Implementation Considerations

This feature would primarily require:

  • Adding a transport selection mechanism (annotation or CRD field)
  • Supporting WebTransport-specific route generation
  • Documenting the required Gateway/Ingress configuration (HTTP/3 + QUIC)
  • Ensuring compatibility with Envoy/Contour implementations that support WebTransport

Since WebTransport is built on HTTP/3, the underlying Gateway implementation must expose HTTP/3 listeners. This is largely an infrastructure concern rather than controller logic.

Benefits

  • Modern browser-native transport for multiplayer games
  • Lower latency than WebSockets in many scenarios
  • Support for unreliable datagrams
  • Better handling of connection migration
  • Future-proof transport abstraction within the controller

Additional Notes

This feature should ideally be implemented as a generic transport abstraction rather than adding WebTransport-specific logic throughout the controller. That would make it easier to support additional protocols in the future while keeping the reconciliation logic largely unchanged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions