首页 › security › 5G AKA主认证与密钥推演全链拆解

5G AKA主认证与密钥推演全链拆解:从SUCI解密到KAMF生成的逐IE深度解析

聚焦规范:3GPP TS 33.501 V18.10.0(Release 18)Section 6.1 ~ 6.2
核心机制:5G-AKA主认证完整信令流、认证向量(5G HE AV / 5G AV)生成、多级密钥推演函数(KDF)链式调用

一、5G-AKA在安全架构中的定位

5G系统安全架构定义于TS 33.501 Section 5,包含六个安全特征域:网络接入安全(I)、网络域安全(II)、用户域安全(III)、应用域安全(IV)、SBA域安全(V)、可视化安全(VI)。主认证(Primary Authentication)属于网络接入安全(I)的基石,它解决三个核心问题:

  1. 网络对UE的认证:验证UE真实身份(SUPI)
  2. UE对网络的认证:验证所接入的SN(Serving Network)合法性
  3. 密钥协商:双方推演出共享的锚点密钥KSEAF,进而衍生全部会话密钥

与4G EPS-AKA相比,5G-AKA引入了SEAF/AUSF双层锚点架构、SUPI隐私保护(SUCI)以及服务网络名称绑定(SN_name binding)三大核心改进。

1.1 安全功能实体映射

逻辑功能 物理部署 核心职责 TS 33.501章节
SEAF (Security Anchor Function) 共址于AMF 接收认证向量、发起NAS认证、验证HXRES* §6.1.3
AUSF (Authentication Server Function) HPLMN核心网 向UDM请求认证向量、验证RES*、推演KSEAF §6.1.2
UDM/ARPF (Authentication Repository) HPLMN核心网 存储K、生成5G HE AV、管理SQN §6.1.1
SIDF (SUPI Subscription Identifier De-concealing Function) UDM内 解密SUCI恢复SUPI §6.12
UE/USIM 终端侧 存储K、计算RES*、验证AUTN §6.1.3.2
## 二、5G-AKA完整信令时序图

以下信令流严格对齐TS 33.501 Section 6.1.1.2(5G-AKA主认证流程)和TS 23.502 Section 4.2.2.2(注册过程中的认证):

sequenceDiagram
    participant UE as UE/USIM
    participant SEAF as SEAF(AMF)
    participant AUSF as AUSF
    participant UDM as UDM/ARPF/SIDF

    Note over UE,UDM: 阶段0: 注册请求触发
    UE->>SEAF: Registration Request<br/>SUCI或5G-GUTI + SNN

    Note over SEAF,UDM: 阶段1: 认证向量请求
    SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>SUCI(或SUPI) + SNN(Serving Network Name)
    AUSF->>UDM: Nudm_UEAuthentication Get Request<br/>SUCI + SNN

    Note over UDM: 阶段2: SIDF解密SUCI→SUPI
    Note over UDM: ARPF生成5G HE AV<br/>K,Milenage算法→CK,IK,RAND,AUTN<br/>KDF(CK||IK,...)→KAUSF<br/>KDF(KAUSF,...)→KSEAF<br/>KDF(CK||IK,...)→XRES*

    UDM->>AUSF: 5G HE AV[RAND, AUTN, XRES*, KAUSF]

    Note over AUSF: 阶段3: AUSF构造5G AV
    Note over AUSF: 计算HXRES*=SHA-256(XRES*)<br/>推演KSEAF=KDF(KAUSF,FC=0x6C,SNN)

    AUSF->>SEAF: 5G AV[RAND, AUTN, HXRES*]

    Note over SEAF,UE: 阶段4: NAS认证挑战
    SEAF->>UE: Authentication Request<br/>RAND + AUTN + ngKSI

    Note over UE: 阶段5: UE侧认证计算
    Note over UE: USIM验证AUTN(MAC=XMAC?)<br/>验证SQN范围<br/>计算RES*<br/>KDF(CK||IK,...)→KAUSF→KSEAF

    UE->>SEAF: Authentication Response<br/>RES*

    Note over SEAF: 阶段6: SEAF初步验证
    Note over SEAF: 计算HRES*=SHA-256(RES*)<br/>比较HRES*==HXRES*?

    SEAF->>AUSF: Nausf_UEAuthentication Authenticate Request<br/>RES*(完整值)

    Note over AUSF: 阶段7: AUSF最终验证
    Note over AUSF: 比较RES*==XRES*?<br/>认证成功→存储KSEAF

    AUSF->>SEAF: Nausf_UEAuthentication Authenticate Response<br/>Result=SUCCESS + KSEAF + SUPI

    Note over SEAF: 阶段8: 推演KAMF
    Note over SEAF: KAMF=KDF(KSEAF,FC=0x6D,SUPI,ABBA)

    SEAF->>UE: Security Mode Command<br/>选定的NAS安全算法 + ngKSI
    UE->>SEAF: Security Mode Complete<br/>(NAS安全激活)

三、认证向量生成深度解析

3.1 5G HE AV(Home Environment Authentication Vector)

由UDM/ARPF基于长期共享密钥K生成,定义于TS 33.501 Section 6.1.1.3。整个生成过程基于Milenage算法集(TS 35.206)和HMAC-SHA-256 KDF。

flowchart TD
    K[长期共享密钥 K<br/>128/256-bit] --> M[Milenage算法集<br/>f1~f5函数]
    RAND[RAND<br/>128-bit随机数] --> M

    M --> CK[CK Cipher Key<br/>128-bit]
    M --> IK[IK Integrity Key<br/>128-bit]
    M --> AK[AK Anonymity Key<br/>48-bit]
    M --> SQN[SQN Sequence Number]
    M --> MAC_A[MAC-A<br/>64-bit消息认证码]

    SQN --> AUTN_GEN[AUTN生成]
    AK --> AUTN_GEN
    MAC_A --> AUTN_GEN
AUTN_GEN --> AUTN[AUTN Authentication Token<br/>SQN⊕AK --> |AMF| MAC-A<br/>共128-bit]

    CK --> CONCAT[CK || IK<br/>256-bit]
    IK --> CONCAT

    CONCAT --> KDF_KAUSF["KDF(CK||IK, FC=0x6A)<br/>P0=SNN, P1=SQN⊕AK"]
    KDF_KAUSF --> KAUSF["KAUSF<br/>256-bit"]

    KAUSF --> KDF_KSEAF["KDF(KAUSF, FC=0x6C)<br/>P0=SNN"]
    KDF_KSEAF --> KSEAF["KSEAF<br/>256-bit"]

    CONCAT --> KDF_XRES["KDF(CK||IK, FC=0x6B)<br/>P0=SNN, P1=RAND, P2=RES"]
    KDF_XRES --> XRES_STAR["XRES*<br/>可变长度"]

    style K fill:#f9d5d5,stroke:#c0392b
    style AUTN fill:#d5e8f9,stroke:#2980b9
    style KSEAF fill:#d5f9e8,stroke:#27ae60
    style KAUSF fill:#f9f0d5,stroke:#f39c12

3.2 关键IE参数详解

IE名称 长度 生成方 作用 TS 33.501章节
RAND 128-bit UDM/ARPF 随机挑战值,每次认证唯一 §6.1.1.3
AUTN 128-bit UDM/ARPF 认证令牌=SQN⊕AK(48bit) || AMF(16bit) || MAC-A(64bit) §6.1.1.3
XRES* 可变 UDM/ARPF KDF(CK||IK, 0x6B, SNN, RAND, RES)推演的期望响应 Annex A.2
HXRES* 256-bit AUSF SHA-256(XRES*)的哈希值,交由SEAF做初步验证 §6.1.3.3
KAUSF 256-bit UDM/ARPF AUSF锚点密钥=KDF(CK||IK, 0x6A, SNN, SQN⊕AK) Annex A.2
KSEAF 256-bit AUSF SEAF锚点密钥=KDF(KAUSF, 0x6C, SNN) Annex A.2
ngKSI 3-bit SEAF NAS安全上下文标识,用于关联Security Mode Command §6.1.3.3

3.3 AUTN内部结构

AUTN是UE验证网络合法性的核心令牌,其内部编码结构如下:

AUTN (128 bits total):
┌─────────────────┬──────────┬──────────────────────────────┐
│   SQN ⊕ AK      │   AMF    │         MAC-A                │
│    (48 bits)     │ (16 bits)│        (64 bits)              │
└─────────────────┴──────────┴──────────────────────────────┘
  字节0-5            字节6-7     字节8-15

SQN ⊕ AK: 序列号与匿名密钥的异或值,UE通过AK还原SQN
AMF: Authentication Management Field,包含分离指示符
MAC-A: 基于K和RAND计算的消息认证码,f1(K, RAND, SQN, AMF)

UE验证逻辑(TS 33.501 §6.1.3.2): 1. USIM使用K和RAND通过f5算法计算出AK 2. 还原SQN = (SQN ⊕ AK) ⊕ AK 3. 使用K、RAND、还原的SQN、AMF通过f1计算XMAC-A 4. 比较XMAC-A与收到的MAC-A → 网络认证 5. 检查SQN是否在可接受范围内 → 重放攻击保护

四、KDF密钥推演全链拆解

5G密钥层级采用自顶向下的KDF链式推演,每一级的输入密钥来自上一级的输出。所有KDF统一使用HMAC-SHA-256(TS 33.220 Annex B)。

4.1 KDF通用公式

Derived Key = HMAC-SHA-256(Key, FC || P0 || L0 || P1 || L1 || ... || Pn || Ln)

其中: - Key: 输入密钥(256-bit) - FC: 函数码(1字节,标识推演用途) - Pi: 第i个参数值 - Li: 第i个参数的长度(2字节,大端编码)

4.2 完整密钥推演链

flowchart TD
    subgraph USIM_UDM["USIM / UDM (共享K)"]
        K["K<br/>永久密钥"] --> Milenage
        RAND2["RAND"] --> Milenage
        Milenage["Milenage<br/>f1~f5"] --> CK_IK["CK || IK"]
    end

    subgraph ARPF_KDF["ARPF密钥推演"]
        CK_IK -->|"FC=0x6A<br/>P0=SNN, P1=SQN⊕AK"| KAUSF["KAUSF"]
        CK_IK -->|"FC=0x6B<br/>P0=SNN, P1=RAND, P2=RES"| XRES2["XRES*"]
        KAUSF -->|"FC=0x6C<br/>P0=SNN"| KSEAF["KSEAF"]
    end

    subgraph AMF_KDF["AMF(SEAF)密钥推演"]
        KSEAF -->|"FC=0x6D<br/>P0=SUPI, P1=ABBA"| KAMF["KAMF"]
        KAMF -->|"FC=0x6E<br/>P0=UL NAS COUNT, P1=AccessType"| KgNB["KgNB"]
        KAMF -->|"FC=0x69<br/>P0=算法类型+算法ID"| KNAS["KNASint / KNASenc"]
    end

    subgraph GNB_KDF["gNB密钥推演"]
        KgNB -->|"FC=0x6F"| KRRC["KRRCint / KRRCenc"]
        KgNB -->|"FC=0x70"| KUP["KUPint / KUPenc"]
    end

    style K fill:#f9d5d5,stroke:#c0392b
    style KSEAF fill:#d5f9e8,stroke:#27ae60
    style KAMF fill:#d5e8f9,stroke:#2980b9
    style KgNB fill:#f9f0d5,stroke:#f39c12

4.3 各级KDF参数完整表

推演目标 FC 输入密钥 P0 P1 P2 规范章节
KAUSF 0x6A CK||IK SNN SQN⊕AK — Annex A.2
XRES* 0x6B CK||IK SNN RAND RES/XRES Annex A.2
KSEAF 0x6C KAUSF SNN — — Annex A.2
KAMF 0x6D KSEAF SUPI ABBA(0x0000) — Annex A.3
KgNB 0x6E KAMF UL NAS COUNT AccessType — Annex A.4
KNASint 0x69 KAMF algo_type||algo_id — — Annex A.3
KNASenc 0x69 KAMF algo_type||algo_id — — Annex A.3
KRRCint 0x6F KgNB algo_type||algo_id — — Annex A.7
KRRCenc 0x6F KgNB algo_type||algo_id — — Annex A.7
KUPint 0x70 KgNB algo_type||algo_id — — Annex A.7
KUPenc 0x70 KgNB algo_type||algo_id — — Annex A.7
## 五、5G-AKA vs EAP-AKA'双轨认证对比

TS 33.501 Section 6.1定义了两种主认证方法。5G-AKA用于3GPP接入(NR→5GC),EAP-AKA'用于非3GPP接入(Wi-Fi→N3IWF/TNGF→5GC)。

5.1 5G-AKA与EAP-AKA'流程差异对比

flowchart LR
    subgraph FiveG_AKA["5G-AKA (3GPP接入)"]
        direction TB
        F1["Authentication Request<br/>RAND+AUTN+ngKSI"] --> F2["Authentication Response<br/>RES*"]
        F2 --> F3["(隐式确认)<br/>Security Mode Command"]
    end

    subgraph EAP_AKAP["EAP-AKA' (非3GPP接入)"]
        direction TB
        E1["EAP-Request/AKA'-Challenge<br/>RAND+AUTN+AT_KDF+MAC"] --> E2["EAP-Response/AKA'-Challenge<br/>RES*+MAC"]
        E2 --> E3["EAP-Success<br/>(显式确认)"]
        E3 --> E4["Security Mode Command"]
    end

    style F3 fill:#f9d5d5,stroke:#c0392b
    style E3 fill:#d5f9e8,stroke:#27ae60

5.2 核心差异对比表

对比维度 5G-AKA EAP-AKA'
确认机制 隐式(Security Mode Command隐含认证成功) 显式(EAP-Success消息明确确认)
协议来源 3GPP原生协议 IETF RFC 9048(原RFC 5448)
密钥绑定 KDF中绑定SN_name AT_KDF属性协商 + 网络名绑定
额外KDF步骤 无(直接从CK||IK推演KAUSF) 先推演CK'||IK'再推演KAUSF
消息轮次 较少(2轮NAS认证) 较多(EAP-Request/Response多轮交互)
适用场景 3GPP接入(NR/LTE→5GC) 非可信非3GPP接入(Wi-Fi via N3IWF)
选择方 UDM/ARPF根据接入类型和签约决定 同左
SQN重同步 AUTS在Authentication Failure中发送 EAP-Response/AKA'-Synchronization-Failure

5.3 为什么5G-AKA采用隐式确认?

这是一个关键的设计决策(TS 33.501 §6.1.3.3): - 在4G EPS-AKA中,认证成功后没有显式确认,存在假基站攻击的可能 - 5G-AKA的改进在于:SEAF验证HXRES*后再发送Security Mode Command,该命令使用从KAMF推演的KNASint进行完整性保护 - UE收到经过完整性保护的Security Mode Command = 隐式证明网络确实拥有K并成功验证了RES* - 这比4G更安全(完整性保护证实了密钥持有),但不如EAP-AKA'的显式EAP-Success明确

六、SEAF双层验证机制详解

5G-AKA引入了一个4G没有的关键创新——SEAF初步验证 + AUSF最终验证的双层机制。

6.1 第一层:SEAF的HXRES*验证

HXRES* = SHA-256(XRES*)[0:128]  — 由AUSF计算,发送给SEAF
HRES*  = SHA-256(RES*)[0:128]   — 由SEAF在收到UE响应后计算

判断条件:HRES* == HXRES* ?

设计意图:SEAF(即AMF)位于访问网络(VPLMN),而AUSF位于归属网络(HPLMN)。HXRES*机制使得VPLMN可以在不暴露完整XRES*给SEAF的情况下,让SEAF独立完成初步验证。只有通过初步验证的RES*才会上送到AUSF做最终验证,减少HPLMN与VPLMN之间的信令交互。

6.2 第二层:AUSF的XRES*验证

AUSF直接比较RES*(来自SEAF转发)与XRES*(来自UDM),执行完整的比特级比对。这是最终认证判决点。

6.3 状态转换图

stateDiagram-v2
    [*] --> WAIT_AUTH: Registration Request received
    WAIT_AUTH --> WAIT_RES: Authentication Request sent<br/>(RAND+AUTN+ngKSI)

    WAIT_RES --> SEAF_VERIFY: Authentication Response<br/>RES* received

    SEAF_VERIFY --> AUSF_VERIFY: HRES*==HXRES* ✓<br/>(初步验证通过)
    SEAF_VERIFY --> AUTH_FAIL: HRES*!=HXRES* ✗<br/>(初步验证失败)

    AUSF_VERIFY --> AUTH_SUCCESS: RES*==XRES* ✓<br/>(AUSF最终验证通过)
    AUSF_VERIFY --> AUTH_FAIL: RES*!=XRES* ✗<br/>(AUSF最终验证失败)

    AUTH_SUCCESS --> SMC_SENT: KSEAF+SUPI received<br/>KAMF推演完成<br/>Security Mode Command sent
    SMC_SENT --> SECURITY_ACTIVE: Security Mode Complete<br/>NAS安全激活

    AUTH_FAIL --> WAIT_AUTH: 可能重试<br/>(新认证向量)
    SECURITY_ACTIVE --> [*]

七、SUCI隐私保护机制

5G引入的SUCI(Subscription Concealed Identifier)是相对4G的重大安全增强,定义于TS 33.501 Section 6.12。

7.1 SUCI编码结构

SUCI = SUPI Type (4bit) | MCC (3 digits) | MNC (2~3 digits) | 
       Routing Indicator (1~4 digits) | 
       Protection Scheme ID (4bit) | 
       Home Network Public Key ID (8bit) | 
       Scheme Output (可变长度)
字段 长度 说明
SUPI Type 4-bit 0=IMSI, 1=NAI, 2=GCI, 3=GLI
MCC+MNC 5~6 digits 归属网络PLMN标识
Routing Indicator 1~4 digits 路由到UDM的指示符
Protection Scheme ID 4-bit 0=null-scheme, 1=ECIES, 2=...
Home Network PK ID 8-bit 归属网络公钥索引
Scheme Output 可变 ECIES加密的SUPI(使用HN公钥)

7.2 ECIES保护方案(Protection Scheme #1)

当Protection Scheme ID=1时,采用椭圆曲线集成加密方案(ECIES)保护SUPI:

  1. UE侧加密:使用存储在USIM中的HN公钥,通过ECIES加密IMSI → 生成密文 + 临时公钥 + MAC标签
  2. SIDF解密:UDM内的SIDF使用对应的私钥解密SUCI → 恢复SUPI
  3. 前向安全:每次加密使用临时ECDH密钥对,即使HN私钥泄露也无法追溯历史SUCI

八、实战连接:抓包识别与故障排查

8.1 Wireshark抓包识别要点

5G NAS Authentication Request(DL,未加密): - Wireshark过滤器:nas-5gs.message_type == 0x56 - 关键字段:RAND(16字节随机数)、AUTN(16字节认证令牌)、ngKSI(安全上下文标识)

5G NAS Authentication Response(UL,未加密): - Wireshark过滤器:nas-5gs.message_type == 0x57 - 关键字段:RES*(可变长度认证响应)

5G NAS Authentication Failure(UL,未加密): - Wireshark过滤器:nas-5gs.message_type == 0x5c - 关键字段:5GMM Cause(#20=MAC failure, #21=Synch failure, #26=Security mode rejected)

Nausf SBI接口(HTTP/2): - 过滤器:http2.headers.path contains "nausf-auth/v1/ue-authentications" - 观察AuthType字段确认使用5G-AKA还是EAP-AKA'

8.2 常见故障点

故障现象 可能原因 排查思路
Authentication Failure #20 (MAC failure) K不匹配、RAND生成异常、USIM与HSS密钥不一致 检查USIM的KI/K/OPC配置与UDM是否一致
Authentication Failure #21 (Synch failure) SQN超出可接受范围(USIM与UDM不同步) 检查USIM的SQN值与UDM侧SQN差距;关注AUTS中携带的SQN_MS
Authentication Reject AUSF验证失败或签约限制 查看AUSF日志中RES*比对结果;检查UDM签约数据
Security Mode Reject 算法协商失败(UE不支持网络选定的算法) 检查UE NAS Security Capability IE与AMF配置的算法优先级
循环认证(不断重发Auth Request) HXRES*验证反复失败或SQN持续不同步 抓包分析每轮的RAND/AUTN是否更新;检查UDM的SQN管理策略
## 九、5G-AKA的已知安全局限与演进

9.1 已知攻击面

根据近年学术研究(如arxiv 2507.17491、MDPI Sensors 2024文章):

  1. 缺乏前向安全(Forward Secrecy):如果长期密钥K被泄露,攻击者可以解密所有历史通信。5G-AKA-FS方案已被提出但尚未标准化
  2. 假基站攻击(IMSI Catcher演进版):虽然SUCI保护了SUPI,但攻击者仍可通过发送多个Authentication Request来追踪UE(linkability attack)
  3. SQN重同步攻击:恶意网络可以通过大量伪造AUTN迫使UE发送AUTS,导致SQN泄露
  4. 隐式确认的语义模糊:Security Mode Command的成功不能严格等同于"网络认证通过",理论上存在细微的安全缝隙

9.2 Release 18/19增强方向

常见问题

Q1: 5G-AKA中HXRES*和XRES*为什么不直接发给SEAF?

A: SEAF位于VPLMN(访问网络),如果直接将完整XRES*发给VPLMN,则VPLMN可以冒充UE。HXRES*=SHA-256(XRES*)的哈希值仅允许SEAF做等值比对而无法反推XRES*,确保只有HPLMN的AUSF才能执行最终的完整验证。这是归属网络控制(Home Control)原则的体现。

Q2: 5G-AKA的ngKSI和4G的KSI_ASME有什么区别?

A: 功能类似,都是安全上下文的标识符。但5G-AKA的ngKSI长度为3-bit(0~7),而4G的KSI_ASME为3-bit。关键区别在于ngKSI关联的是5G安全上下文(基于KAMF),而非4G的EPS安全上下文(基于KASME)。在N2切换时,ngKSI用于目标AMF索引正确的安全上下文。

Q3: SUPI在什么场景下会以明文(null-scheme)传输?

Q4: 为什么KAMF推演中需要ABBA参数?

A: ABBA(Anti-Bidding down Between Architectures)参数用于防止安全降级攻击。ABBA=0x0000表示5G安全架构,确保攻击者无法将5G认证降级到4G EPS-AKA的安全等级。ABBA的引入使得KAMF与特定的安全架构版本绑定,即使KSEAF相同,不同的ABBA值也会产生不同的KAMF。

Q5: 5G-AKA中如果UE检测到SQN不同步,会触发什么流程?

A: UE在AUTN验证中检查SQN是否在可接受窗口内。如果SQN超出范围,UE发送Authentication Failure(5GMM Cause #21 = Synch failure),并在AUTS字段中携带UE侧的SQN_MS(经过AK加密保护)。UDM收到AUTS后解密SQN_MS,与自身SQN_H比较,据此调整SQN_H并生成新的5G HE AV。这就是SQN重同步流程(TS 33.501 §6.1.3.2)。

参考来源

  1. 3GPP TS 33.501 V18.10.0 — 5G安全架构与过程,Section 6.1主认证、Section 6.2密钥层级、Annex A KDF定义
  2. 3GPP TS 35.206 — Milenage算法集规范,f1~f5函数定义
  3. free5GC Blog: Introduction to 5G AKA — 5G-AKA流程与密钥推演详解
  4. ShareTechnote: 5G Core Authentication — 5G认证向量生成与EAP-AKA'对比
  5. sqimway: 5GS Security Keys — KDF输入参数速查表(FC编码、P0/P1参数)
  6. MDPI Sensors 2024: Formal Security Reassessment of 5G-AKA-FS — 5G-AKA前向安全增强方案的正式安全分析

    本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
    出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入