首页 最新 热门 推荐

  • 首页
  • 最新
  • 热门
  • 推荐

BLE 技术(五)--- Generic Access Profile + Security Manager(Core_v5.2)

  • 24-03-03 03:23
  • 4580
  • 8139
blog.csdn.net

文章目录

  • 前言
  • 一、GAP Roles and Requirements
  • 二、Operational Modes and Procedures
    • 2.1 Broadcast mode and Observation procedure
    • 2.2 Discovery modes and procedures
    • 2.3 Connection modes and procedures
    • 2.4 Bonding modes and procedures
    • 2.5 Periodic advertising modes and procedure
    • 2.6 Isochronous broadcast modes and procedures
  • 三、GAP Security Aspects
    • 3.1 Security Manager Protocol
    • 3.2 GAP security modes and procedures
  • 更多文章:

前言

前篇博文链路层广播通信与连接通信介绍了蓝牙协议在链路层是怎样实现广播通信与连接通信的,链路层可以说是蓝牙控制器部分的协议实现主体,通过蓝牙链路层提供的报文就可以实现蓝牙的广播通信与连接通信功能。

对于蓝牙控制器与主机分体设计的方案,蓝牙控制器芯片与蓝牙主机芯片之间通过标准的HCI 命令交互数据,这里的HCI 命令实际上就是对蓝牙链路层报文的简单封装。开发者不管是操作蓝牙链路层报文还是HCI 命令,都不直观方便,会大幅降低蓝牙开发的效率。
BLE Protocol stack layer
蓝牙主机部分为开发者提供了Profile 规范,比如GAP(Generic Access Profile) 和GATT(Generic Attribute Profile),让蓝牙应用开发更简单高效。两个蓝牙设备之间要想实现通讯,首先应能够发现彼此、建立连接,甚至完成绑定,这些过程都是由GAP 规范定义的,开发者可以通过GAP 实现待通讯蓝牙设备间的访问控制。

一、GAP Roles and Requirements

要理解BLE,首先应了解两个蓝牙设备之间如何能发现对方、与对方协作以及不断找到对方并彼此连接,这些都在GAP 中定义。GAP 为BLE 定义了四种主要角色:

  • Broadcaster role:发送advertising events 或 periodic advertising events 的设备,Bluetooth 5.2 版本设备还可以发送Broadcast Isochronous Stream (BIS) events,处于广播者角色的设备应具有发射机功能,也可以具有接收机功能;
  • Observer role:接收advertising events 或 periodic advertising events 的设备,Bluetooth 5.2 版本设备还可以接收Broadcast Isochronous Stream (BIS) events,处于观察者角色的设备应具有接收机功能,也可以具有发射机功能;
  • Central role:在LE 连接建立阶段,支持中央角色的设备将处于“Initiating” 状态以发起连接,当LE 连接建立后,处于中央角色的设备将处于“Connection” 状态的Master 角色,处于中央角色的设备应同时具有发送机和接收机功能;
  • Peripheral role:在LE 连接建立阶段,支持外围角色的设备可以接受来自中央角色设备的连接请求,当LE 连接建立后,处于外围角色的设备将处于“Connection” 状态的Slave 角色,处于外围角色的设备应同时具有发送机和接收机功能。

如果控制器支持,一个设备可以同时以多个GAP角色运行,比如既可以是Broadcaster role,又可以同时为Peripheral role。

为了便于说明低功耗蓝牙的工作原理,下面给出一个典型的用户场景:

一用户刚购买一个支持BLE 的心率带,可以通过一部支持BLE 的智能手机连接该心率带设备,并通过特定的APP 访问该蓝牙心率带采集到的心率值。

用户打开心率带包装并启动设备,该蓝牙心率带将处于Broadcaster role;打开智能手机蓝牙功能并扫描或添加设备,该智能手机将处于Observer role。智能手机会扫描到附近的多个蓝牙设备,如果蓝牙心率带离手机比较近,将会在蓝牙设备列表顶部看到刚购买心率带的设备名,甚至显示该心率带的图标。用户选择要连接的心率带设备,智能手机将会向心率带设备发送连接请求报文(如果待连接设备需要安全认证则输入说明书中给定的密码即可),心率带设备接受连接请求后双方都进入连接状态,此时智能手机处于Central role,心率带设备处于Peripheral role。

智能手机与心率带设备建立连接后,Central role 将会发现Peripheral role 支持的服务列表,以便更方便的使用外围设备公开的各种服务,比如心率带设备支持的读取当前心率值的服务,通过特定的APP就可以在智能手机上访问心率带设备的当前心率值。为了实现设备间高效及时的数据传输,不仅Central role 可以主动访问Peripheral role 公开的服务数据,Peripheral role 还可以主动通知Central role 自身服务数据的更新。为Peripheral role 公开服务开发的专有APP 还可以利用服务数据扩展新的功能(如果需要Peripheral role 提供更多的服务数据,则可以增加Peripheral role 公开的服务),比如利用一段时间持续采集的心率值绘制心电图。

如果该心率带设备后续有很大可能再次连接该智能手机,双方在首次建立连接后可以建立绑定关系,当心率带设备与智能手机完成绑定后,智能手机内将保存一部分该心率带设备的信息,下次启动心率带设备并打开智能手机蓝牙功能后,双方可以自动快速建立连接(使用High duty cycle connectable directed advertising,已完成绑定设备不需要再次进行安全认证),如果有通信加密需求还可以对通信链路进行加密。

上面的应用场景中,可以分为两部分理解:一部分是手机发现心率带蓝牙设备并建立连接的过程(包括绑定过程和重连过程),该部分主要在GAP 中定义;另一部分是手机发现心率带蓝牙设备公开的服务并完成服务数据传输的过程,该部分主要在GATT 中定义。本文主要介绍GAP 相关规范,限于篇幅将在下一篇博文介绍GATT 相关规范。

GAP 规范比较靠近用户层,主要由链路层实现,前面已经介绍过主要的四种GAP 角色(也即Broadcaster、Observer、Central、Peripheral),每个GAP 角色对物理层和链路层功能的合规性要求如下:
GAP compliance requirements
每个GAP 角色对物理层的功能要求比较简单,也就是支持Transmitter 或Receiver 功能;对链路层的功能要求比较复杂,主要包括链路层States、Advertising event types、Scanning type、Link Layer control procedures、Broadcast control procedures 等部分,这些在前篇博客链路层广播通信与连接通信中都有介绍过。

二、Operational Modes and Procedures

GAP 规范中有两个基本概念用来描述蓝牙设备的行为,即模式Mode 和过程Procedure:

  • Mode:当一个设备被配置为按照某种方式工作一段较长的时间,则称该设备正处于某种模式。比如当一个设备正在进行广播时,称其为“广播模式”;
  • Procedure:当一个设备被配置为在某一段有限的时间内执行某种特定的操作时,则称该设备正执行某个过程。比如当一个设备正在找寻广播者时,称其为“观察过程”,观察过程往往持续一段较短的时间,用以构建用户界面或者寻找需要的指定信息。

Bluetooth 5.2 版本的GAP 定义了如下几种模式与过程:

  • Broadcast mode and Observation procedure
  • Discovery modes and procedures
  • Connection modes and procedures
  • Bonding modes and procedures
  • Periodic advertising modes and procedure
  • Isochronous broadcast modes and procedures

上述模式和过程中的每一个组合彼此独立,且又密切相关,蓝牙设备也可以同时执行几种不同的模式和过程(对于大多数蓝牙设备的彼此通信,模式和过程的组合是必需的)。

2.1 Broadcast mode and Observation procedure

广播模式与观察过程允许两个蓝牙设备使用广播事件以单向无连接方式进行通信。下表定义了Broadcaster role 与Observer role 在广播模式与观察过程组合中的要求:
Broadcast mode and observation procedure requirements
广播模式与观察过程是广播通信的典型组合,Broadcaster role 处于Broadcast mode,Observer role 处于Observation procedure,一个广播者可以向一个或多个主动侦听的观察者通过广播信道单向发送广播报文。由于广播报文没有任何确认过程,无法保证观察者接收到的广播报文是正确的,因此广播通信过程是不可靠的。

2.2 Discovery modes and procedures

在GAP 规范中,只有Peripheral role 才允许被发现,Central role 则执行发现外围设备的过程。为了提供不同的可发现性,外围设备提供了三种工作模式:不可发现模式、有限可发现模式、常规可发现模式。为了应对不同的可发现性,中央设备提供了两种发现过程:有限发现过程、常规发现过程,中央设备和外围设备都提供了一个名称发现过程。
Device Discovery requirements

  • Non-Discoverable mode:正在执行常规发现过程或有限发现过程的任何设备都不会发现以不可发现模式配置的设备。处于不可发现模式的外围设备可以发送广播事件,如果设备发送广播事件,则不得在Flags AD类型中设置“LE General Discoverable Mode”标志或“LE Limited Discoverable Mode”标志;
  • Limited Discoverable mode:配置为有限可发现模式的设备可以由执行有限或常规发现过程的设备在有限时间段TGAP(lim_adv_timeout)内发现。处于有限可发现模式的外围设备应发送广播事件,且应在Flags AD类型中设置“LE Limited Discoverable Mode flag” 为1,“LE General Discoverable Mode flag” 为0;
  • General Discoverable mode:执行常规发现过程的设备可以无限期的发现以常规可发现模式配置的设备,但执行有限发现过程的设备不会发现处于常规可发现模式的设备。处于常规可发现模式的外围设备应发送广播事件,且应在Flags AD类型中设置“LE Limited Discoverable Mode flag” 为0,“LE General Discoverable Mode flag” 为1;
  • Limited Discovery procedure:执行有限发现过程的中央设备只能发现配置为有限可发现模式的外围设备;
  • General Discovery procedure:执行常规发现过程的中央设备可以发现配置为常规可发现模式或有限可发现模式的外围设备;
  • Name Discovery procedure:执行名称发现过程的设备(可以是中央设备,也可以是外围设备)可以发现对端设备的名称。

处于Limited Discoverable 或General Discoverable 模式的设备发送的广播报文中,除了配置AD(Advertising Data) Type Flags 字段的可发现性标识外,为了提高发现效率,还应该在广播数据中包含下列有用信息:

  • TX Power Level AD type:用于计算路径损耗,判断距离,实现发现设备列表的排序;
  • Local Name AD type:用于显示设备的命令;
  • Service UUIDs AD type:可根据设备支持的服务对设备进行过滤。

上面谈到的这些AD Type 字段都属于广播报文数据的一部分,前篇博文链路层空口报文设计已经介绍了链路层的广播报文结构。我们知道分层协议报文是层层封装的,从上层至下层要逐层添加相应的报文头部,更上层Host 部分的Advertising, Periodic Advertising, and Scan Response data 都属于链路层广播报文中的AdvData field,或者链路层扩展广播报文中的ACAD(Additional Controller Advertising Data) field。蓝牙Host 部分Advertising, Periodic Advertising, and Scan Response data 的格式如下:
Advertising and Scan Response data format
蓝牙Host 中广播或扫描相应报文数据分为重要部分和非重要部分,其中重要部分包含一系列AD structures,每个AD structure 包含Length 字段、AD Type 字段、AD Data 字段 三部分,前面介绍的Flags、TX Power Level、Local Name、Service UUIDs 字段都是属于AD Type字段的内容,下面给出一些常用的AD Types 字段供参考:
AD Types

2.3 Connection modes and procedures

在GAP 中,只有Peripheral role 才可使用可连接模式,Central role 则执行连接建立过程。 就可连接性而言,可连接的外围设备可处于下列三种模式:不可连接模式、定向可连接模式、不定向可连接模式。对中央设备而言,存在四种不同的连接建立过程:自动、常规、选择、定向连接建立过程。
Connection modes and procedures requirements

  • Non-connectable mode:处于不可连接模式的设备不允许建立连接,但允许执行广播模式和观察过程,处于该模式的设备允许发送ADV_NONCONN_IND 或 ADV_SCAN_IND 广播报文;
  • Directed connectable mode:处于定向可连接模式的外围设备可以通过ADV_DIRECT_IND 广播报文通告中央设备,并接受来自已知中央设备的连接请求,该请求会执行自动连接建立过程或常规连接建立过程;
  • Undirected connectable mode:处于不定向可连接模式的外围设备可以通过ADV_IND 广播报文通告中央设备,并接受来自执行自动连接建立过程或常规连接建立过程的设备的连接请求;
  • Auto connection establishment procedure:执行自动连接建立过程的中央设备通常将绑定过的设备添加进白名单,当发现一个或多个处于定向可连接模式或不定向可连接模式的外围设备,且该设备在白名单中,将自主向这些设备发起连接请求以建立连接。通过自动连接建立过程建立的连接只能使用一套基本的连接参数,连接建立成功后双方可以更新连接参数;
  • General connection establishment procedure:执行常规连接建立过程的中央设备通常不使用白名单,当发现一个或多个处于定向可连接模式或不定向可连接模式的外围设备,将使用定向连接建立过程向用户选择的设备发起连接请求以建立连接;
  • Selective connection establishment procedure:执行选择连接建立过程的中央设备首先将选定的待连接设备添加进白名单,而后启用白名单并开始扫描,当发现一个或多个处于可连接模式且在白名单中的外围设备,将使用定向连接建立过程向这些设备发起连接请求以建立连接,中央设备可以查找并使用外围设备期望的连接参数发起连接请求;
  • Direct connection establishment procedure:执行定向连接建立过程的中央设备可以忽略白名单,直接向指定外围设备发起连接请求以建立连接,中央设备可以使用外围设备建议的连接参数发起连接请求;

connection establishment procedure

  • Connection parameter update procedure:连接参数更新过程允许中央设备或外围设备更新已建立的ACL连接的参数。
  • Terminate connection procedure:终止连接过程允许中央设备或外围设备终止与对等设备的连接,如果存在CIS 连接,则应先终止CIS 连接,然后再终止ACL 连接;
  • Connected Isochronous Stream Central Establishment procedure:执行CIS 连接建立过程的中央设备可以使用主机选择的参数向外围设备发起建立CIS 的请求,中央设备与外围设备可以使用已建立的CIS 传输同步数据流;
  • Connected Isochronous Stream Peripheral Establishment procedure:执行CIS 连接建立过程的外围设备可以接受或拒绝中央设备发起的建立CIS 请求;
  • Connected Isochronous Stream Terminate procedure:CIS 终止过程允许中央设备或外围设备终止与对等设备直接的CIS,当中央设备或外围设备执行终止ACL 连接程序时,若存在CIS 则需先终止CIS 连接。

2.4 Bonding modes and procedures

绑定允许两个连接的设备之间交换或存储安全性与身份信息,以创建可信任的关系。像前面介绍的可发现性和可连接性类似,绑定也定义了相应的模式与过程,外围设备与中央设备之间的绑定模式只有两种:不可绑定模式、可绑定模式,过程也只有一种:绑定过程。
Bonding compliance requirements

  • Non-Bondable mode:处于不可绑定模式的设备不允许与对等设备创建绑定,且应在配对过程中将Bonding_Flags设置为“ No Bonding”,双方不得交换或存储绑定信息;
  • Bondable mode:处于可绑定模式的设备允许与处于可绑定模式的对等设备创建绑定,且应在配对过程中将Bonding_Flags设置为“ Bonding”,双方交换并视情况存储密钥等绑定信息;
  • Bonding procedure:当非绑定设备尝试访问需要绑定的服务时可以执行绑定过程,执行绑定过程的设备应发起配对并设置Bonding_Flags,如果对等设备是可绑定的则回复响应并同样设置Bonding_Flags。一切顺利的话,将在连接链路加密后进行密钥的分发与存储,也即交换并存储绑定信息。

The bonding procedure

2.5 Periodic advertising modes and procedure

周期广播模式和过程允许两个或多个设备使用扩展广播事件和周期广播事件以单向无连接方式进行通信,下表定义了各GAP role 在周期广播模式和过程中的要求:
Periodic advertising modes and periodic advertising procedure requirements

  • Periodic Advertising Synchronizability mode:处于周期性广播同步模式的设备可以在扩展广播事件中发送周期性广播序列的同步信息,处于该模式的设备也处于周期性广播模式;
  • Periodic Advertising mode:处于周期性广播模式的设备可以在确定时间间隔内,使用周期性广播同步信息中指定的跳频序列发送周期性广播事件;
  • Periodic Advertising Synchronization Establishment procedure:执行周期性广播同步建立过程的设备可以扫描包含有关周期性广播序列的同步信息的广播事件,也可以通过现有连接来接收周期性广播同步信息。当设备接收到用于周期性广播同步的同步信息时,可以使用在周期性广播同步信息中指定的时间间隔和跳频序列来侦听周期性广播事件;
  • Periodic Advertising Synchronization Transfer procedure:执行周期性广播同步传输过程的设备可以在现有连接上发送有关周期性广播序列的同步信息。

2.6 Isochronous broadcast modes and procedures

等时同步广播模式和过程允许两个或多个设备使用扩展广播事件、周期性广播事件、等时同步事件,以单向、无连接的方式进行通信。下表定义了Broadcaster role 和 Observer role 支持这些模式和过程的要求:
Isochronous Broadcast modes and procedure requirements

  • Broadcast Isochronous Synchronizability mode:处于广播等时同步模式的设备可以通过AUX_SYNC_IND 广播报文中的ACAD字段发送BIGInfo,处于该模式的设备也处于广播等时广播模式;
  • Broadcast Isochronous Broadcasting mode:处于广播等时广播模式的设备可以在BIG 的BIS 子事件中发送加密或未加密的广播等时同步数据流;
  • Broadcast Isochronous Synchronization Establishment procedure:执行广播等时同步建立过程的设备应首先执行周期性广播同步建立过程,并接收广播等时同步信息BIGInfo。当完成BIG 中BIS 的建立后,Broadcaster 和 Observer 之间就可以进行单向、无连接的等时同步通信了;
  • Broadcast Isochronous Channel Map Update procedure:广播等时信道映射更新过程允许Broadcaster 使用和发送BIG 的新信道映射,或者允许Observer 接收和使用BIG 的新信道映射;
  • Broadcast Isochronous Terminate procedure:广播等时终止过程允许Broadcaster 终止BIG,或者允许Observer 终止与BIG 的同步。

三、GAP Security Aspects

在介绍GAP 安全模式与过程之前,先介绍下BLE 的Security Manager Protocol,从下图可以看出GAP 安全模式与过程主要靠SM 协议来承载:
Relationship of the Security Manager to the rest of the LE Bluetooth architecture

3.1 Security Manager Protocol

在无线通信中,如何保证信息的安全可靠传输一直是不可或缺的一环,BLE 的通信安全主要由Security Manager Protocol (SMP) 保证。保证通信安全最简单直接的方法是对信息进行加密传输,BLE 使用的加密算法是AES-CMAC(可参考博文:TLS 加密原理),AES-CMAC 加密算法可以保证通信的机密性和完整性,但共享密钥的生成和分发如何解决呢?

BLE 借鉴了TLS 安全传输协议的设计思想,共享密钥的交换也使用了Diffie-Hellman 密钥交换算法,为了提高密钥交换效率,也引入了椭圆曲线运算,所以BLE 使用的密钥交换算法是ECDH(Elliptic Curve Diffie-Hellman,可参考博文:TLS 加密原理)。BLE 建立安全链路前的握手过程称为配对(Pairing),配对过程如下(可参考博文:TLS 握手过程):
LE pairing phases
从上图可知,BLE 配对过程主要有三个阶段(可参考配对过程发送的SMP 命令格式):

  • Phase 1(Pairing Feature Exchange):通过Pairing Request与Pairing Response报文交换I/O 能力、OOB身份认证数据可用性、身份认证请求(包括是否绑定、是否请求中间人攻击防护、是否支持安全连接等)、最大密钥大小、生成/分发哪些密钥等配对信息。I/O 能力和OOB数据也是跟身份认证相关的,跟TLS 远程网络协议需要数字证书验证身份不同的是,蓝牙设备一般都是近场局域网通信,可以直接由使用者辨识通信设备的身份,受限于蓝牙设备的I/O 能力,首次配对可以通过输入配对密钥、OOB数据传输(比如NFC 通信)等方式验证要连接的蓝牙设备身份,并交换配对信息(当重新连接已绑定过的设备时,由于双方都保存有之前的配对信息,可以直接通过一个签名数据完成身份验证,比首次连接更简单些);
    Phase 1(Pairing Feature Exchange)
  • Phase 2(Long Term Key Generation):最初每个设备都会生成自己的ECDH public-private key pair,要配对的设备双方先交换public key,然后通过ECDH 密钥交换算法生成共享长期密钥LTK(Long Term Key) ,经验证LTK 生成过程没有问题后,通信双方就可以使用生成的LTK 加密在连接链路上传输的信息,这就完成了安全加密连接的建立(在重新连接已绑定过的设备后,可以直接用LTK 加密,不需要再执行完整的配对过程);
    Long Term Key Generation
  • Phase 3(Transport Specific Key Distribution):双方建立安全加密通信链路后,还需要生成并分发一些专用的密钥,比如IRK(Identity Resolving Key) 和CSRK(Connection Signature Resolving Key),其中IRK 可用于生成或解析设备的Resolvable Private Address(由随机数和IRK生成的随机设备地址,只能被拥有相同IRK 的设备扫描到,防止被未知设备扫描和跟踪),CSRK 可用于对数据进行签名或验证接收到的数据签名信息(当重新连接已绑定过的设备时,可以通过验证配对信息的数据签名,直接完成身份认证)。如果还需要后续重新建立安全连接,则可以将配对信息(包括LTK、IRK、CSRK 等密钥信息)保存到本地安全数据库中,这个过程称为绑定(当重新连接已绑定过的设备时,只需验证配对信息,不需要再执行完整的配对过程)。
    Transport specific key distribution

3.2 GAP security modes and procedures

在GAP 规范中,也定义了与ACL 连接或广播的安全性相关的模式和过程如下(与CIS 安全相关的模式/过程与其关联的ACL 中使用的模式/过程相同):
Requirements related to security modes and procedures

  • LE Security mode 1:主要用于在建立连接的Peripheral 和Central 之间,提供不同级别的信息加密,该模式为连接加密提供四个等级:无身份认证且无加密、有加密但未经身份认证的配对、有加密且已经过身份认证的配对、使用128位强度加密且已经过身份认证的安全连接配对,这四个等级的安全性逐级增强;
  • LE Security mode 2:主要用于在建立连接的Peripheral 和Central 之间,提供不同等级的数据签名,该模式为数据签名提供两个等级:带有数据签名但未经身份认证的配对、带有数据签名且已经过身份认证的配对,这两个等级的安全性逐级增强;
  • LE Security mode 3:主要用于在同步广播的Broadcaster 和Observer 之间,提供不同等级的BIS 同步广播信息加密,该模式为BIS 信息加密提供三个等级:无身份认证且无加密、使用未经过身份认证的Broadcast_Code来加密在BIS中传输的数据、使用已经过身份认证的Broadcast_Code来加密在BIS中传输的数据,这三个等级的安全性逐级增强;
  • Authentication procedure:执行认证过程的设备要求对端设备提供身份认证信息,通过身份认证后才能继续安全通信,防止出现中间人攻击。Central 与Peripheral 之间发起服务请求和响应服务请求时的身份认证过程如下图示:
    Flow chart for a local device issuing and handling a service request
  • Authorization procedure:执行授权过程的设备可以授予对端设备访问某个服务的权限,只有对端设备拥有相应的权限才能继续访问对应的服务;
  • Connection data signing procedure:执行连接数据签名过程的设备会为与其连接的对端设备生成一个新的连接签名解析密钥CSRK,并通过加密链路将其发送给对端设备,以便对端设备使用CSRK 验证来自本设备的签名数据;
  • Authenticate signed data procedure:执行认证数据签名过程的设备使用CSRK 验证来自对端设备的签名数据,从而验证签名数据发送方的身份,防止第三方伪装身份发送虚假消息。数据签名常用于只需要身份认证不需要加密的连接通信中,比如需要快速建立连接和快速数据传输的服务(数据加密过程比数据签名过程更慢);
  • Encryption procedure:执行加密过程的设备可以对当前连接进行加密,为连接通信提供机密性和完整性。

更多文章:

  • 《BLE 技术(六)— GATT Profile + ATT protocol + L2CAP(Core_v5.2)》
  • 《BLE 技术(四)— Broadcast communication + Connection communication (Core_v5.2)》
  • 《Bluetooth Core Specification_v5.2》
  • 《BLE技术揭秘》
  • 《蓝牙协议分析》
注:本文转载自blog.csdn.net的流云IoT的文章"https://blog.csdn.net/m0_37621078/article/details/107850523"。版权归原作者所有,此博客不拥有其著作权,亦不承担相应法律责任。如有侵权,请联系我们删除。
复制链接
复制链接
相关推荐
发表评论
登录后才能发表评论和回复 注册

/ 登录

评论记录:

未查询到任何数据!
回复评论:

分类栏目

后端 (14832) 前端 (14280) 移动开发 (3760) 编程语言 (3851) Java (3904) Python (3298) 人工智能 (10119) AIGC (2810) 大数据 (3499) 数据库 (3945) 数据结构与算法 (3757) 音视频 (2669) 云原生 (3145) 云平台 (2965) 前沿技术 (2993) 开源 (2160) 小程序 (2860) 运维 (2533) 服务器 (2698) 操作系统 (2325) 硬件开发 (2492) 嵌入式 (2955) 微软技术 (2769) 软件工程 (2056) 测试 (2865) 网络空间安全 (2948) 网络与通信 (2797) 用户体验设计 (2592) 学习和成长 (2593) 搜索 (2744) 开发工具 (7108) 游戏 (2829) HarmonyOS (2935) 区块链 (2782) 数学 (3112) 3C硬件 (2759) 资讯 (2909) Android (4709) iOS (1850) 代码人生 (3043) 阅读 (2841)

热门文章

101
推荐
关于我们 隐私政策 免责声明 联系我们
Copyright © 2020-2025 蚁人论坛 (iYenn.com) All Rights Reserved.
Scroll to Top