WebTransport 目前未被 .NET 9 官方支持，运行时及 ASP.NET Core 均无相关 API；其缺失主因是依赖尚未完善的 HTTP/3 底层能力，且微软暂未将其列入短期路线图。
WebTransport 在 .NET 9 中还不存在
直接说结论：WebTransport 目前（截至 .NET 9 预览版发布阶段）**并未被官方实现或公开支持**。.NET 运行时、System.Net.Http 或 Microsoft.AspNetCore 均无 WebTransportClient、WebTransportServer 或任何相关 API。你查不到 WebTransport 命名空间，也找不到对应 NuGet 包。
这是个常见误解来源：浏览器（Chrome 97+）已支持 WebTransport（基于 HTTP/3 的 UDP 类协议），但 .NET 生态尚未跟进。它不是“隐藏功能”，而是根本未启动开发 —— 官方 GitHub 仓库中尚无对应 issue 或设计提案（截至 2024 年中）。
为什么 .NET 没有 WebTransport 支持
根本原因在于协议栈依赖和优先级：
-
WebTransport依赖底层 HTTP/3 实现，而 .NET 的HttpClient虽已在 .NET 6+ 启用 HTTP/3（需启用AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http3Support", true)），但仅限请求-响应模型；WebTransport需要双向流、可靠/不可靠数据报、连接生命周期管理等更底层能力，这些不在当前SocketsHttpHandler范围内 - ASP.NET Core 也没有暴露 HTTP/3 连接原始 QUIC 流的接口，无法让上层框架（如 SignalR 或自定义传输层）接管
WebTransport所需的流复用与控制帧处理 - 微软当前重心仍在完善 gRPC-Web、SignalR over WebSockets/Server-Sent Events 等成熟方案，
WebTransport属低采用率、高复杂度新标准，暂未列入短期路线图
现在想在 C# 里对接浏览器 WebTransport 怎么办
只能绕过 .NET 原生支持，用“两端分离 + 协议桥接”方式：
- 浏览器端用标准
WebTransportAPI（new WebTransport(url)）发送数据 - 服务端不用 ASP.NET Core 直接处理，改用支持 QUIC / HTTP/3 的独立服务器，例如：
quiche（Rust）、lsquic（C）或nodejs的webtransport实验包（如@webtransport/server） - 若必须用 C# 作后端逻辑，可在上述 QUIC 服务器中通过进程间通信（如命名管道、gRPC-over-Unix-domain-socket）把解包后的数据转发给 .NET 进程处理
- 不推荐自己用
UdpClient手搓 QUIC —— QUIC 协议极其复杂（加密握手、丢包恢复、流量控制、连接迁移），没有成熟 C# QUIC 栈（MsQuic是 C 接口，.NET 绑定极不完善且无文档）
别踩坑：那些看似相关的但其实无关的 API
搜索时容易误入歧途，以下技术常被混淆，但和 WebTransport 无实质关系：
-
WebSocket：基于 TCP，全双工但非多路复用流，不支持数据报，也不能复用 HTTP/3 连接 -
HttpClient的SendAsync+ HTTP/3：只做单次请求响应，无法维持长连接并动态创建子流 -
System.Net.Quic命名空间：.NET 6 引入过实验性类型，但已在 .NET 7 中完全移除，不是 WebTransport 基础 -
Microsoft.AspNetCore.Connections：用于自定义传输（如 Kestrel 底层），但不暴露 QUIC 流，也无法拦截 WebTransport 控制帧
真正需要 WebTransport 互通时，目前唯一靠谱路径是接受“C# 不当网络层”，把它放在业务层，让更底层的语言或现成 QUIC 服务器扛协议解析 —— 这不是权宜之计，而是现实约束。
