.NET 10网络堆栈解析：HTTP/3、性能优化与后量子加密

第一次在预览环境里把配置从 .NET 8 切到 .NET 10 时，我其实没有太当回事，觉得无非是版本号往上抬一抬，编译过了就行。真正跑起来才发现，.NET 10 的网络堆栈已经从传输层、连接层到 TLS 握手层都做了一次结构性重构。HTTP/3 不再是“可以用但别认真”的实验特性，后量子加密也不再是安全团队 PPT 里的远期规划。这篇东西我从一个实际使用者的角度出发，拆一下 .NET 10 网络堆栈的架构变化、HTTP/3 的落地配置、性能优化的完整路径，以及后量子加密到底在我们的 TLS 握手里处在什么位置。适合正在评估或准备迁移 .NET 10 的团队，也适合那些只想把服务调快、把连接质量调稳的人。

1. .NET 10 网络栈为什么值得“重新学一遍”

1.1 三个层面看架构变化

我习惯把 .NET 的网络栈拆成三层来看，这样理解新版改动会轻松很多。

第一层是传输层，也就是 System.Net.Sockets。这一层最核心的变化是底层 Socket 已经全面走现代异步模型，SocketAsyncEventArgs 在高并发场景下的分配开销进一步下降，同时 NativeAOT 场景下对 Socket 的裁剪适配也做得更干净。

第二层是连接协议层，指的是 SocketsHttpHandler 和 Kestrel 内部对 HTTP/1.1、HTTP/2、HTTP/3 的协议实现。这一层的架构变化最大。HTTP/3 在 .NET 6 里以预览形式出现，.NET 7 在 Windows 上提供 Kestrel 的 HTTP/3 支持，.NET 8 改善了稳定性，但到 .NET 10 才真正把它放进了“默认优化路径”里：无论是 HttpClient 的协议版本协商策略，还是 Kestrel 对多路复用连接的处理，都不再需要你额外加奇奇怪怪的开关。

第三层是 TLS 层，也就是 SslStream 和 QUIC 握手背后的加密逻辑。这一层在 .NET 10 里引入了后量子密钥交换的混合组（hybrid group），例如经典的 X25519 与 ML-KEM 组合。它的原理一句话可以概括：即使将来量子计算机能破解经典椭圆曲线，攻击者拿到的当前流量也无法被解密。

三层合在一起，才构成你真正感受到的网络栈。只谈其中一个层面，都会忽略掉整体设计的重心。

1.2 这次升级想解决的真实问题

如果只让我说一个动机，那就是降低网络链路的延迟和不确定性。

传统 HTTPS 是 TCP + TLS 的组合。一个简单的页面请求要经历 TCP 三次握手，再经历 TLS 1.3 的一次往返；在弱网环境里，丢包导致的队头阻塞会让整个页面白屏好几秒。HTTP/2 虽然通过多路复用缓解了一部分问题，但 TCP 层面的队头阻塞依然存在。HTTP/3 把传输层换成基于 UDP 的 QUIC，连接建立时握手和密钥协商并行，还能做到连接迁移——手机从 Wi-Fi 切到 5G 时，TCP 连接大概率断开重建，QUIC 可以用连接 ID 直接保住会话。

.NET 10 把这一整套能力推进到了“生产默认可用”的状态，而不是“底层已经支持、但业务需要绕很多路”的演示状态。

1.3 演进脉络：从 SocketsHttpHandler 到 Pipelines 再到 QUIC

回头看 .NET 网络栈这几年的演进，其实有一条非常清晰的主线：减少分配、减少线程阻塞、减少拷贝。

• .NET Core 2.1 引入 SocketsHttpHandler，统一了 HttpClient 的底层 socket 实现；
• .NET Core 3.0 引入 System.IO.Pipelines，解决了网络读写缓冲区的生命周期问题；
• .NET 5 开始对 Kestrel 做大规模异步重写，把线程池模型和 IO 完成端口调度理顺；
• .NET 6 到 .NET 8 把 HTTP/3 逐步从实验室抬到生产；
• .NET 10 把 QUIC、性能优化、后量子加密三者放到了一个版本里。

理解了这条时间线，你就明白为什么我说 .NET 10 网络栈值得重新学一遍：它不是某一天的突然爆发，而是过去多个版本积累后的总成。

2. HTTP/3 落地的正确姿势：从 Kestrel 到 HttpClient 再到网关

2.1 Kestrel 监听 HTTP/3 的具体配置

Kestrel 启用 HTTP/3 在代码层面并不复杂，但有几个细节非常容易踩坑。

csharp复制var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        listenOptions.UseHttps();
    });
});

var app = builder.Build();
app.MapGet("/", () => "Hello HTTP/3");
app.Run();

这段配置的意思是，同一个端口上同时支持 HTTP/1.1、HTTP/2、HTTP/3，客户端能连哪个就用哪个。这里必须注意一个关键点：HTTP/3 是强制要求 TLS 的，UseHttps() 必须有，而且不能是那种只在开发环境用的临时证书。原因在于 HTTP/3 的握手指纹（QUIC 传输参数的签名）和我们熟知的 TCP 完全不同，中间网络设备如果识别不了，会直接丢包。

另外要确认服务器端的 UDP 443 或指定端口没有被防火墙拦截。HTTP/3 基于 UDP，很多云环境的网络安全组默认只放行 TCP，UDP 被静默丢弃，表现为“客户端一直在尝试，但永远握手失败”。

2.2 HttpClient 协议版本策略与场景取舍

客户端这边用起来更直观：

csharp复制HttpRequestMessage request = new(HttpMethod.Get, "https://example.com/")
{
    Version = HttpVersion.Version30,
    VersionPolicy = HttpVersionPolicy.RequestVersionOrHigher
};

using HttpClient client = new();
HttpResponseMessage response = await client.SendAsync(request);

Console.WriteLine($"Response version: {response.Version}");

VersionPolicy.RequestVersionOrHigher 的含义是：你希望优先用 HTTP/3，但如果服务端不支持，就自动降级到 HTTP/2 或 HTTP/1.1。这个策略在实际生产里非常重要，因为它解决了“客户端支持 / 服务端不支持”的兼容问题。

但这里有一个人很容易踩的心理误区：并不是所有流量都应该切到 HTTP/3。我见过有人把内网服务之间的调用也硬切到 HTTP/3，结果性能反而下降。原因是 QUIC 的加密开销和 UDP 在公网弱网下的优势，在内网低延迟高带宽环境里并不明显；服务间调用如果都在同一机房、延迟本来就在 0.1ms 级别，HTTP/3 的收益非常有限，反而增加 CPU 消耗和排查难度。我的建议是：公网客户端、移动端、弱网场景优先开；内网服务调用保持 HTTP/2 甚至 HTTP/1.1 都完全足够。

2.3 网关与部署层最容易卡住的地方

HTTP/3 的客户端和服务端都准备好了，不代表你的链路通了。最大的变数往往在网关和负载均衡这一层。

很多团队用的是 Nginx 做反向代理，如果你希望用户通过 Nginx 直接访问后端 HTTP/3，那么 Nginx 本身需要支持 HTTP/3（一般需要编译时开启 --with-http_v3_module），并且监听 UDP 443 端口。另一种更常见的架构是：Nginx 对客户端只提供 HTTP/2 或 HTTP/3，回源到后端时用 HTTP/1.1 或 HTTP/2，不在后端直接暴露 HTTP/3。这种架构其实非常合理，因为后端服务往往不需要承接公网的 UDP 连接压力，把 QUIC 终结在网关层，内部的稳定性反而更好。

还有一个容易被忽略的点：如果你使用了云厂商的负载均衡或 CDN，需要先确认它是否支持 HTTP/3 和 QUIC，以及是否开放 UDP 端口。很多云产品长期默认只处理 TCP，UDP 流量会在入口就被丢弃。我的经验是，在所有环境变更之前，先用一个干净的测试域名、直接走服务器 IP + 端口验证后端是否支持 HTTP/3，再一层一层把网关加上去，这样定位问题会容易很多。

2.4 实测中 HTTP/3 并不是万能药，别被 benchmark 误导

我在压测环境里对比过同一服务的 HTTP/1.1、HTTP/2、HTTP/3，结论是：在 5% 丢包的弱网模拟环境下，HTTP/3 的传输完成时间比 HTTP/2 快 30% 到 50%；但在 0 丢包、低延迟的机房环境里，HTTP/3 的吞吐量有时反而略低于 HTTP/2。

原因是 QUIC 的每个包都有独立的加密保护，CPU 开销比 TCP + TLS 更大；在 CPU 充足但网络极好的情况下，这种开销没有换来延迟优势，纯粹变成了成本。所以你如果要在文章里引用性能数据，一定要标注清楚网络条件。网络栈调优最忌讳的就是拿一个环境的数据当普适结论。

另外，0-RTT 是一个听起来很美、用起来要小心的能力。HTTP/3 支持在握手第一个包里携带数据，省掉一个 RTT。但 0-RTT 的数据有重放风险，攻击者可以截获之后重复发送。我自己的处理原则是：只有幂等请求（如图片、静态资源配置）才考虑开启 0-RTT；涉及下单、登录这类操作的请求，绝不允许走 0-RTT。服务端如果默认开启了 0-RTT，要在业务层对请求来源做额外校验。

3. 性能优化的动手路径：从指标采集到参数矫正

3.1 先拿数据说话：计数器与跟踪工具

优化网络栈，最容易犯的错误是一上来就调参数。真正常见的瓶颈其实集中在几个地方：连接建立耗时、TLS 握手耗时、请求队列堆积、GC 压力和线程池饥饿。

我调优的一贯顺序是：先量化，再动手。.NET 提供了非常好用的诊断工具链条。

bash复制dotnet-counters collect --process-id <pid> --counters System.Net.Http,System.Net.Sockets

这条命令会周期性地采集 HttpClient 的请求队列长度、并发连接数、socket 读写字节数等指标。如果你发现 CurrentRequests 长时间不下降，说明业务层处理不过来；如果 OutgoingConnections 一直很高，说明连接复用做得不够。

想更细致地看 TLS 握手耗时的话，可以用 dotnet-trace 抓事件：

bash复制dotnet-trace collect --process-id <pid> --providers Microsoft-System-Net-Sockets,System.Net.Security

抓完用 PerfView 或 dotnet-trace report 分析。我第一次做网络栈优化时，就是在 trace 里看到某个自定义中间件在握手之后额外做了一次耗时 40ms 的远程缓存查询，把整个请求的延迟拖垮了。这种问题，不抓 trace 根本不可能定位到。

真实的网络栈性能问题，很少是单纯的“网速慢”，更多是应用程序在连接生命周期里的某一行代码产生了阻塞。

3.2 Kestrel 参数到底调什么

Kestrel 的参数网上说法很多，但很多人不明白每个参数背后的目的。我挑几个我用过的说实话：

• Limits.MaxConcurrentConnections：控制同时建立的连接数上限。默认是 null，也就是不限制。但对于一个容易受到连接洪水影响的公网服务，我建议设置一个合理上限，避免内存耗尽。注意 HTTP/3 的多路复用意味着一个连接可以承载多个请求，所以连接数上限对 HTTP/3 的影响和 HTTP/1.1 完全不同，不要沿用老经验。
• Limits.MinRequestBodyDataRate：控制请求体最低速率，防止慢速攻击。但如果你在做文件上传，默认值可能要放宽，否则用户网速一慢就被断掉。
• Limits.MaxRequestBodySize：默认 30MB，做文件上传时不改会直接 413。

另外要理解 Kestrel 现在的线程模型：它不会为每个连接创建一个线程，而是使用异步 IO 和线程池调度。因此，你不需要像旧时代那样“连接数多了就加线程”，反而要关注线程池饥饿问题。如果你在代码里用了 Task.Result 或者 .Wait() 去同步等待异步操作，在高并发下很容易把线程池线程占满，Kestrel 表现为吞吐量骤降、延迟陡增。碰到这种情况，优先排查所有阻塞调用，而不是去调 ThreadPool.SetMinThreads。

3.3 Pipeline、ValueTask 与分配优化

Kestrel 内部大量使用 System.IO.Pipelines，这是它能维持高吞吐的核心原因之一。普通业务代码里，如果你想自己读取请求体或响应体，也建议用 PipeReader 而不是反复把 Stream 数据拷贝进 byte[]。

csharp复制static async ValueTask<long> ComputeBodyLength(Stream body, CancellationToken ct)
{
    PipeReader reader = PipeReader.Create(body);
    long total = 0;

    while (true)
    {
        ReadResult result = await reader.ReadAsync(ct);
        ReadOnlySequence<byte> buffer = result.Buffer;

        foreach (ReadOnlyMemory<byte> segment in buffer)
        {
            total += segment.Length;
        }

        reader.AdvanceTo(buffer.End, buffer.End);

        if (result.IsCompleted)
        {
            break;
        }
    }

    return total;
}

这段代码的核心思想是：读取、处理、推进三个步骤分离，缓冲区由 Pipeline 管理，而不是每次读取都申请新的 byte[]。对网络栈性能优化而言，减少大对象堆（LOH）分配比减少单次运算时间更重要，因为 GC 的停顿时间往往被大对象分配拉长。

ValueTask 在热路径中也很关键。Task 在异步方法每次 await 时都可能产生堆分配，ValueTask 则允许在同步完成时完全避免分配。像 ReadAsync、SendAsync 这类频繁调用的网络 API，如果返回类型设计成 ValueTask，能显著降低 GC 压力。.NET 10 里很多网络 API 的返回类型已经在朝这个方向收敛，自己在封装网络调用时也尽量遵循同样的设计。

3.4 一个低吞吐场景的完整优化记录

说一个真实的压测例子。我们团队有一个面向移动端的设备状态上报接口，所有客户端走公网，网络质量参差不齐。上线初期发现平均请求延迟 280ms，P99 高达 1.2s，但服务的 CPU 和内存都低于 30%。一开始以为是网络堆栈不行，后来按前面说的顺序排查：

1. 用 dotnet-counters 看 System.Net.Http.CurrentRequests，发现请求队列偶尔堆积；
2. 用 dotnet-trace 抓出每个请求的耗时分布，发现 60% 的时间花在 TLS 握手后的首次读取等待上；
3. 继续抓包，发现大量 TCP 连接因为客户端进电梯、切换 Wi-Fi 而断开重连；
4. 服务端为每次请求都创建了新的数据库连接，平均耗时 80ms。

整个优化分了三步：第一，把数据库连接改成复用池；第二，将客户端请求改成 HTTP/2 多路复用，减少频繁连接；第三，对非关键数据做响应合并延迟（coalescing），在 50ms 窗口内把多个请求的结果合并返回。压测结果平均延迟从 280ms 降到 110ms，P99 从 1.2s 降到 480ms。

这个案例里，最终起作用的不是某个 Kestrel 参数，而是链路层面的合理设计。网络栈优化永远要在整个链路上找瓶颈，而不是在单个配置项上较劲。

4. 后量子加密不是“未来”，而是 TLS 会话里的今天

4.1 量子威胁与“先存储、后解密”

后量子加密这个概念听起来很远，但它其实已经进入主流浏览器的默认握手。所谓“先存储、后解密”，就是攻击者今天把加密流量全部录制下来，等到将来拥有了足够强的量子计算机，再回头解密这些历史数据。

对大多数业务来说，数据库里的某些敏感数据生命周期长达 5 到 10 年，而当前 TLS 握手中使用的密钥交换算法（如 ECDHE 基于椭圆曲线）一旦被量子算法攻破，历史流量就没有保密性可言了。

很多人误以为量子计算机还远，所以不用管。问题是加密流量的价值恰恰在于它的时间跨度——你今天记录下来的数据，未来可能依然是敏感数据。这也是为什么 NIST 已经推出了后量子加密标准，而主流浏览器和操作系统都开始默认开启混合密钥交换。

4.2 混合密钥交换机制

“混合”这个词是理解后量子加密落地方式的关键。它不是在传统算法和后量子算法之间二选一，而是两者一起用。

以 X25519 和 ML-KEM 的组合为例：

• 客户端和服务器先生成一个经典椭圆曲线密钥对（X25519）；
• 同时生成一个后量子密钥对（ML-KEM，基于格密码）；
• 两者各自完成密钥交换后，把两边的共享密钥拼接或混合后作为最终 TLS 会话密钥。

这么做的安全逻辑是：就算未来量子算法能破解 X25519，ML-KEM 那一层依然保护着会话；如果 ML-KEM 被发现有实现漏洞，X25519 这一层也不会失效。这是目前行业最稳妥的过渡策略。

在 TLS 1.3 握手里，这个混合过程发生在 ClientHello 的 key_share 扩展里。传统的 TLS 1.2 设备不认识这种扩展时，通常会选择忽略；但 TLS 1.3 的握手对扩展的容忍度和处理方式不同，这也是为什么后量子加密必须绑定 TLS 1.3 来谈。

4.3 在 .NET 10 中启用后量子加密

.NET 10 中，SslStream 底层的加密库（Windows 上对应 Schannel，Linux 上对应 OpenSSL）已经支持混合后量子密钥交换组。对开发者的好消息是，只要你启用 TLS 1.3，客户端和服务端默认都会在 ClientHello 中携带混合密钥组。

csharp复制SslServerAuthenticationOptions serverOptions = new()
{
    EnabledSslProtocols = SslProtocols.Tls13,
    // 证书配置照常
    ServerCertificate = new X509Certificate2("server.pfx", "password")
};

csharp复制SslClientAuthenticationOptions clientOptions = new()
{
    TargetHost = "api.example.com",
    EnabledSslProtocols = SslProtocols.Tls13
};

using SslStream sslStream = new(networkStream, leaveInnerStreamOpen: false);
await sslStream.AuthenticateAsClientAsync(clientOptions);

这里我不建议你在代码里硬编码某个后量子算法组。原因是：整个行业还在快速演进，今天用 X25519MLKEM768，明天可能就切换到基于 ML-DSA 的签名方案；而且客户端和服务端的系统库版本不一致时，硬编码会导致握手失败。最好的策略是信任系统的默认组列表。你真正需要做的，是把 SslProtocols.Tls13 设好，并确保服务端和客户端的操作系统版本都支持后量子组。

如果你管理的服务需要强制校验“是否真的用了后量子密钥交换”，可以通过 SslStream.NegotiatedCipherSuite 查看最终协商的套件，或者开启 TLS 握手日志，从 key_share 中确认是否包含后量子组。

4.4 兼容性、性能开销与回退方案

后量子加密的性能开销是个很现实的问题。ML-KEM 的密钥生成、封装和解封装比 X25519 要重不少，TLS 握手时 ClientHello 和 ServerHello 的体积也会变大。实测下来，一次完整握手增加几十 KB 的传输量，CPU 耗时增加大约 0.1ms 到 0.5ms。对于正常业务请求来说，这个开销几乎可以忽略；但对于毫秒级延迟敏感的极高频服务，需要压测确认。

真正容易引发问题的反而是网络中间设备。有些企业防火墙、奇奇怪怪的网关设备，看到 TLS 扩展里出现了不认识的后量子 KEY_SHARE，会选择直接丢包或重置连接。遇到这种现象，你先不要怀疑代码，先抓包看 TLS ClientHello 是否正常到达服务端。如果是中间设备拦截，你就需要在这些设备上开启对 TLS 1.3 后量子扩展的透传支持，或者在业务侧先降级到纯经典密钥交换，等网络设备升级后再逐步开启。

我的建议是：在公网核心入口上先开启后量子加密，因为“先存储、后解密”的威胁真实存在；同时准备一个开关，一旦出现大面积握手失败，可以在网关层强制回退到经典 X25519，保证业务连续性。

5. 从 .NET 8 迁移时的兼容性排查与灰度策略

5.1 运行时与操作系统限制

.NET 10 网络栈的新特性对操作系统是有要求的。HTTP/3 在 Windows 上依赖基于 Schannel 的 QUIC 实现，Windows Server 2022 和 Windows 11 是相对稳妥的运行环境；在 Linux 上，需要安装或更新 msquic 库。不是说老版本完全跑不了，而是你要额外承担很多补丁级别的风险，出了问题排查成本非常高。

后量子加密同样依赖底层加密库。Linux 上 OpenSSL 版本过低，TLS 1.3 的混合组可能无法协商；Windows 上 Schannel 的版本取决于系统更新。所以迁移前我强烈建议把操作系统和运行时的版本要求列成一张清单，部署时逐项核对，而不是只关注 .NET 运行时版本。

5.2 问题排查链路：从 ERR_INCOMPLETE_CHUNKED_ENCODING 到连接重置

开发者和运维在迁移过程中最常撞见的就是浏览器或客户端报的一堆网络错误。我在前后端联调时见过太多“服务端明明没报错，但客户端就是连不上”的情况。这里给出我自己的排查链路：

第一步，复现。不要直接看日志，先用命令行客户端复现：

bash复制curl -v --http3 https://your-service.example.com/

--http3 会强制走 HTTP/3；如果这条命令成功，说明 HTTP/3 链路本身没问题。如果失败，看输出的错误码和握手卡在哪一步。

第二步，判断错误发生在哪一层。这是最关键的一步。

• 如果 curl 输出卡在 connect to ... port 443，说明网络层不通；
• 如果输出 TLS handshake failure，说明 TLS 层有问题，可能是证书链、SNI、协议版本、后量子扩展被拦截；
• 如果输出 HTTP/3 stream 0 was not closed cleanly，说明 QUIC 连接状态异常；
• 如果服务器返回了响应头却缺少部分内容，那问题往往在响应写入或者代理层缓冲。

第三步，针对具体错误查根因。下面这个表是我实际排查中总结出来的：

第四步，抓包确认。如果前三步都找不到问题，用 Wireshark 或 tcpdump 在网络出口和服务器入口分别抓包，对比数据包是否完全一致。我曾经排查过一个诡异的 ERR_CONNECTION_RESET，最后发现是国内某云厂商的负载均衡在 TLS 握手阶段就丢掉了后量子 KEY_SHARE 扩展，导致服务端无法完成协商。这种问题，不抓包根本不可能通过代码日志定位。

5.3 灰度发布与一键回退

网络栈的变更影响面非常大，我不建议直接全量发布。合理做法是：先挑一个流量占比小、非核心的服务作为试点，验证 HTTP/3 和后量子加密在真实网络环境下的表现；同时保留配置项，确保出现问题时可以一键回退。

以 Kestrel 为例，发布时可以在环境变量或 appsettings 里加一个开关：

json复制{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://0.0.0.0:5001",
        "Protocols": "Http1AndHttp2AndHttp3"
      }
    }
  }
}

如果你想快速回退到 HTTP/2，把 Protocols 改成 Http1AndHttp2，重启服务即可，代码不用动。不要小看这个思路，真到了线上大面积握手失败的时候，每一秒都在损失业务，有一个明确的回退开关是救命稻草。

后量子加密的回退一般不需要改代码，多数情况下把系统加密库或运行时切换到不带后量子组的版本就行；但最好也在网关层留好策略，比如允许临时禁用 TLS 1.3，回到 TLS 1.2。

5.4 测试环境如何完整验证

测试环境不要只验证“功能正常”，要专门构造网络异常场景。我在团队里推进网络栈升级时，测试清单包括：

• 模拟 5% 丢包和 100ms 延迟，对比 HTTP/2 与 HTTP/3 的请求完成时间；
• 客户端在请求过程中切换 Wi-Fi 和移动网络，验证 QUIC 连接迁移是否生效；
• 用老版本操作系统和老版本 OpenSSL 的客户端访问，验证兼容性；
• 抓包确认握手中确实包含了后量子密钥交换扩展；
• 关闭 UDP 端口，验证客户端是否能正确回退到 TCP。

前四项保证新特性真正生效，第五项保证最坏场景下业务不中断。把这一套跑完，心里才有底。

6. 最后再聊几句实测后的个人体会

这里没有标准答案，全是我自己踩过坑之后的认知。网络栈这个东西，语法层面的迁移永远是最简单的，真正的难度在于部署环境的碎片化：操作系统、加密库、网关、防火墙、中间设备，每一个都可能成为新协议链条里最薄弱的环节。我强烈建议所有团队在做 .NET 10 网络栈升级前，先拿出一两天时间把测试网络里的完整链路画出来，从客户端到网关再到后端，每一段协议是什么、端口是什么、UDP 是否放行、TLS 版本是否对齐，全部标清楚。准备得越细，上线后需要救火的概率就越低。至于 HTTP/3 和后量子加密，虽然听起来都是大词，但它们已经是浏览器、操作系统和主流云厂商实际支持的技术，谁先把它稳妥落地，谁就能在弱网体验和数据保护上多一份主动权。