2026 年 9 月 20 日 | 作者：交流科技圈
.NET 11 的 ASP.NET Core 更新文档已经上线，从 Kestrel 网络栈到 Blazor、SignalR、OpenAPI，几十个新特性一口气放出。其中最值得关注、也最容易被忽略的，是一批围绕 HTTP/2 / HTTP/3 和底层网络性能的改进。这篇文章带你快速过一遍重点，文末附完整特性清单。[citation:31.4][citation:31.9]
如果说以前的版本是在"支持"HTTP/2 和 HTTP/3，那么 .NET 11 则是在认真"打磨"它们。这一版针对现代网络协议做了三件大事。
---
一、HTTP/3：首请求延迟大幅降低
过去 Kestrel 在处理 HTTP/3 新连接时，会先等待控制流和 SETTINGS 帧就绪，然后才开始处理应用请求。这意味着新连接上的第一个请求白白多等了一个握手往返。
.NET 11 的 Kestrel 不再等待控制流和 SETTINGS 帧，直接开始处理 HTTP/3 请求，显著减少了新连接上第一个请求的延迟。
对于面向移动端、网络环境复杂、连接频繁新建销毁的场景——这正是 QUIC/HTTP/3 的主场——这个优化是实打实的体验提升。[citation:31.6][citation:31.8]
.NET 10：新连接 → 等待控制流就绪 → 等待 SETTINGS → 开始处理请求
.NET 11：新连接 → 直接开始处理请求（省去一个往返）
---
二、HTTP/2 与 HTTP/3：碎片化尾部标头超时保护
这是一个容易被忽视但非常关键的健壮性改进：Kestrel 现在会把 RequestHeadersTimeout 同时应用到 HTTP/2 和 HTTP/3 的碎片化尾部标头（trailers）上。
此前这个超时只保护初始请求标头。如果客户端故意只发一半的尾部 HEADERS 帧，Kestrel 可能让连接无限期挂起——这是一个潜在的慢速攻击（Slowloris 类）面。
现在，等待尾部标头完成的连接同样受超时约束，默认 10 秒可配置：[citation:31.47]
builder.WebHost.ConfigureKestrel(options =>
{
options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(10);
});
---
三、HTTP/1.1 解析器重构：畸形请求吞吐量提升 20-40%
虽然不是 HTTP/2/3，但属于同一批网络栈性能工作：Kestrel 的 HTTP/1.1 请求解析器改为不抛异常的代码路径。解析器返回一个结果结构体（成功 / 不完整 / 错误），而不是每次失败都抛 BadHttpRequestException。
在面对大量畸形请求时（端口扫描、恶意流量、配置错误的客户端），吞吐量提升 20-40%，且对正常请求处理零影响。[citation:31.47]
---
四、配套安全增强：TLS 通道绑定与可观测性
网络栈还顺手收了一波安全与诊断能力：[citation:31.47]
| 特性 | 说明 |
|------|------|
| 协商式身份验证使用 TLS 通道绑定 | Kestrel 上的 Kerberos/NTLM 认证绑定到 HTTPS 连接的 TLS 终结点，防止凭据被中继，无需任何配置变更 |
| ITlsHandshakeFeature.Exception | TLS 握手失败的原因终于可以被中间件和日志捕获，不再是裸的 IOException |
| UseTlsClientHelloListener | 新的连接中间件方式检查 ClientHello，替代已弃用的回调形态 |
| TryGetChannelBindingBytes | 应用可直接读取通道绑定令牌防范中继攻击 |
| HTTP.sys 认证硬化级别 | 新增 HttpAuthenticationHardeningLevel（Legacy / Medium / Strict）分级控制 |
---
五、响应压缩与请求解压缩：Zstandard 支持，默认启用
响应压缩和请求解压缩中间件新增 Zstandard（zstd）支持，且默认启用。zstd 在压缩率和速度上全面优于 gzip，对高流量 API 是免费的带宽红利：[citation:31.47]
builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
options.CompressionOptions = new ZstandardCompressionOptions
{
Quality = 6 // 1-22，越高压缩越好、越慢
};
});
响应压缩始终输出 Vary: Accept-Encoding，防止共享缓存和 CDN 把压缩内容发给没请求压缩的客户端——这是缓存正确性修复。
---
六、共享框架启用 runtime-async
ASP.NET Core 共享框架库在 net11.0+ 上启用 runtime-async 编译——由运行时而非编译器生成 async/await 状态机，减少每次 await 的内存分配。纯内部实现变更，应用无需改代码即自动受益。[citation:31.47]
这与 Stephen Toub 在《Performance Improvements in .NET 11》中描述的 Runtime Async 升级是一脉相承的：同步完成的 async 路径快 3 倍且零分配，真正的提升已经内化到了 ASP.NET Core 的每个请求处理管道中。[citation:31.12]
---
七、其他值得关注的打磨
SignalR 与 Blazor
身份验证刷新：SignalR 连接在访问令牌过期时可刷新认证而不断开。服务器新增 /refresh 终结点，客户端在过期前自动重新认证
客户端可取消普通 Hub 调用：此前只有流式调用可取消，现在 InvokeAsync 传 CancellationToken 即可
Blazor SSR 客户端验证：表单输入错误时浏览器端即可反馈，不一定要等服务器返回
异步验证支持：AsyncValidationAttribute + IAsyncValidatableObject，查库、调远程 API 不再阻塞线程
Blazor AI 组件（实验性）：Microsoft.AspNetCore.Components.AI 包，支持流式聊天、富文本与工具渲染、人工审批流
OpenAPI
默认面向 OpenAPI 3.2
文件下载类终结点自动映射为 type: string, format: binary
SSE 端点用 3.2 的 itemSchema 描述
[Obsolete] 自动映射为 deprecated: true
C# 联合类型在 OpenAPI 中呈现为 anyOf
其他
HTTP 日志中间件池化 ResponseBufferingStream，减少每次请求分配
速率限制中间件返回精确的 Retry-After 标头
原生支持 OpenTelemetry HTTP 语义约定属性，不再需要 OpenTelemetry.Instrumentation.AspNetCore 库
[ShortCircuit] 特性：路由匹配后立即执行，跳过其余中间件管道，适合健康检查、robots.txt
---
升级建议
如果你维护着跑在 Kestrel 上的高并发服务，HTTP/2/3 相关的三项改进值得在升级后第一时间压测验证：
HTTP/3 首请求延迟：在移动端或弱网环境下测试新连接建连速度
解析器性能：用畸形请求/恶意流量压测 Kestrel 的吞吐
zstd 压缩：开启后观察带宽节省与 CPU 开销的平衡
如果你在探索 AI 应用，MCP + Blazor AI 组件的组合值得现在就开始尝鲜。[citation:31.10]
完整的更新日志可查阅 dotnet/core 仓库和 What's new in .NET 11。
发布评论