当前位置： 首页 > news >正文

QUIC 协议域名封堵：核心原理、关键技术与实现路径（C/C++代码实现）

news 2025/9/17 8:11:03

随着 QUIC 协议在互联网领域的广泛应用，其基于 UDP 的传输特性与加密设计，打破了传统 TCP 协议下的域名封堵逻辑，给网络合规管理与安全防护带来新的技术难题。本文将脱离具体代码实现，聚焦 QUIC 协议域名封堵的核心原理、关键技术环节与实际落地路径，从协议特性本质出发，解析如何在遵循 RFC 9000、RFC 9001 等规范的前提下，实现对 QUIC 流量的精准域名封堵。

一、QUIC 协议特性与域名封堵的核心挑战

要实现 QUIC 协议的域名封堵，首先需明确其与传统 TCP 协议的本质差异 —— 这些差异既是 QUIC 提升性能的关键，也是封堵技术需要突破的核心难点。

1. QUIC 协议的三大核心特性

  • 传输层载体：UDP 替代 TCP

    QUIC 摒弃了 TCP 的三次握手与重传机制，基于 UDP 实现可靠传输。传统域名封堵依赖的 TCP 443 端口过滤、TCP 连接重置（RST）等手段，对 UDP 承载的 QUIC 流量完全失效，需重新构建基于 UDP 的流量识别与拦截逻辑。

  • 加密层深度整合：TLS 封装于协议帧内

    根据 RFC 9001，QUIC 将 TLS 握手过程与传输层帧结构深度绑定，客户端请求的目标域名（通过 SNI 扩展传递）被封装在加密的 QUIC 帧中。与 TCP+TLS 分离的架构不同，QUIC 无法通过单独解析 TLS 记录提取域名，必须先完成 QUIC 帧的解析与解密预处理。

  • 连接标识与动态端口：流量关联性难追踪

    QUIC 使用 “连接 ID” 替代传统 IP + 端口的标识方式，支持 “连接迁移”（如手机从 WiFi 切换到 4G 时连接不中断），且部分应用会随机使用非标准 UDP 端口（如 3000-60000 区间）。这导致仅通过端口或 IP 无法锁定完整的 QUIC 连接，增加了流量关联与持续封堵的难度。

2. 域名封堵的核心目标与技术诉求

QUIC 域名封堵的本质目标是：在不影响合法 QUIC 流量的前提下，精准识别并阻断目标域名的 QUIC 连接。这要求技术方案满足三个核心诉求：

  • 合规性：严格遵循 RFC 9000 对 QUIC 帧结构、连接生命周期的定义，以及 RFC 9001 对 TLS 加密的规范，避免因协议解析偏差导致误封堵或漏封堵；

  • 精准性：能从加密的 QUIC 流量中提取真实目标域名（SNI），排除 IP 欺骗、端口伪装等干扰；

  • 低侵入性：采用旁路监听或轻量级拦截模式，不破坏正常 QUIC 连接的建立与数据传输，避免引入额外延迟或网络波动。

二、QUIC 域名封堵的核心原理与技术架构

QUIC 域名封堵系统的设计需围绕 “流量识别→域名提取→规则匹配→连接阻断” 四大环节展开，每个环节均需针对性解决 QUIC 协议带来的技术难题。其整体技术架构遵循 “分层处理、模块解耦” 原则，确保各环节可独立优化与扩展。

1. 架构图层级与模块布局

建议采用 “横向分层 + 纵向数据流向” 的布局绘制示意图，整体分为 “网络输入层”“核心处理层”“执行输出层” 三大横向层级，各层级包含具体功能模块，模块间用带箭头的线条标注数据流向，具体结构如下：

横向层级包含模块模块功能简述模块位置（绘图建议）
网络输入层网络接口（如 eth0/wlan0）接收互联网或内网的 UDP 流量，是系统的流量入口架构图最左侧（作为起点）
核心处理层流量捕获层过滤 UDP 流量，筛选出疑似 QUIC 数据包网络输入层右侧（第一层处理）
核心处理层协议解析层解析 QUIC 帧、提取 TLS 握手信息与 SNI 域名流量捕获层右侧（第二层处理）
核心处理层规则匹配层比对 SNI 域名与封堵规则，判断是否需要封堵协议解析层右侧（第三层处理）
执行输出层封堵执行层发送 QUIC 重置帧或联动网络设备，阻断目标连接规则匹配层右侧（最终执行）
辅助支撑层规则管理模块加载、更新、存储封堵规则（如从 rules.txt 读取或接收 API 动态配置）规则匹配层上方（支撑模块）
辅助支撑层日志 / 缓存模块记录封堵事件、缓存会话票据与连接 ID 映射（支撑 0-RTT 握手与连接迁移场景）协议解析层与规则匹配层之间（支撑模块）

  • 数据流向逻辑：

    网络接口的 UDP 流量先进入 “流量捕获层” 进行初步过滤，筛选出疑似 QUIC 的数据包；随后传递至 “协议解析层”，完成 QUIC 帧解析与 SNI 域名提取；提取的域名进入 “规则匹配层”，与预设的封堵规则进行比对；若命中封堵规则，触发 “封堵执行层” 对目标 QUIC 连接实施阻断。

2. 各核心层的工作原理

（1）流量捕获层：QUIC 流量的初步筛选

核心目标是从海量 UDP 流量中，高效筛选出疑似 QUIC 的数据包，减少后续解析层的处理压力。关键原理包括：

  • 端口特征过滤：优先捕获 UDP 443 端口（QUIC 标准端口）与 UDP 8080（常见备选端口）的流量，覆盖 80% 以上的标准 QUIC 应用；

  • 协议特征验证：对非标准端口的 UDP 流量，通过 QUIC 帧的 “首字节特征” 进一步判断 —— 根据 RFC 9000，QUIC 长包头（INITIAL/HANDSHAKE 包）的首字节高 4 位为 “0x1”（如 0x10、0x11），短包头的首字节最高位为 “1”，通过这一固定特征可快速识别 QUIC 数据包，排除 DNS、NTP 等其他 UDP 协议流量。

（2）协议解析层：从加密帧中提取 SNI 域名（核心环节）

这是 QUIC 域名封堵的技术核心，需突破 “QUIC 帧解析→TLS 握手提取→SNI 扩展解析” 三重难关，最终获取客户端请求的目标域名。

  • 第一步：QUIC 帧解析（遵循 RFC 9000）

    QUIC 数据包分为 “长包头” 与 “短包头” 两类，仅长包头中的 INITIAL 包（首字节 0x10）和 HANDSHAKE 包（首字节 0x11）包含 TLS 握手信息，是域名提取的关键对象。解析过程需：

  1. 识别包头类型：通过首字节高 4 位判断是否为 INITIAL/HANDSHAKE 包；

  2. 提取 payload 长度：从包头字段中解析出后续加密 payload 的长度，确定 TLS 数据的范围；

  3. 去除帧加密：QUIC 的 INITIAL 包使用 “初始密钥”（基于客户端随机数与服务器配置生成）进行加密，需先通过密钥派生算法（如 HKDF）生成解密密钥，解密后得到原始 TLS 握手记录。

  • 第二步：TLS 握手记录提取

    解密后的 QUIC payload 本质是 TLS 记录流，需从中定位 “Client Hello” 消息 —— 这是客户端向服务器发送域名信息的唯一载体。关键判断依据：

    • TLS 记录类型：“Client Hello” 属于 “握手消息”，对应的 TLS 记录类型字段为 0x16；

    • TLS 版本：QUIC 通常关联 TLS 1.3，对应的版本字段为 0x0304（TLS 1.3）或 0x0303（TLS 1.2 兼容模式）；

    • 消息长度：从 TLS 记录头中提取 “Client Hello” 消息的总长度，确保完整读取后续内容。

  • 第三步：SNI 扩展解析

    “Client Hello” 消息中包含多个扩展字段，其中 “Server Name Indication”（SNI，扩展类型 0x0000）专门用于传递目标域名。解析逻辑：

  1. 遍历扩展列表：从 “Client Hello” 的扩展字段区域，按 “扩展类型 + 扩展长度 + 扩展数据” 的格式遍历所有扩展；

  2. 匹配 SNI 类型：找到扩展类型为 0x0000 的字段，其扩展数据中包含 “服务器名称列表”；

  3. 提取域名：服务器名称列表中，“名称类型” 为 0x00（DNS 域名）的条目即为客户端请求的目标域名，直接读取该条目对应的字符串即可。

（3）规则匹配层：域名与封堵策略的高效比对

核心是建立灵活、高效的规则匹配机制，支持精准域名匹配与批量封堵场景。关键原理包括：

  • 规则模型设计：采用 “域名 - 动作 - 原因” 的三元组模型，其中 “动作” 分为 “block”（封堵）与 “allow”（允许），“域名” 支持精确匹配（如example.com）与通配符匹配（如 *.example.com，覆盖所有子域名）；

  • 匹配效率优化：将规则存储在哈希表（精确匹配）与前缀树（通配符匹配）中，对于提取的域名，先通过哈希表快速匹配精确规则，若未命中则通过前缀树匹配通配符规则，确保单次匹配耗时控制在微秒级；

  • 规则优先级处理：当多个规则同时命中时（如 “*.example.com” 与 “test.example.com”），遵循 “精确规则优先于通配符规则”“后加载规则覆盖先加载规则” 的原则，避免匹配冲突。

（4）封堵执行层：QUIC 连接的精准阻断

根据 RFC 9000 的 QUIC 连接管理规范，需采用符合协议标准的方式阻断连接，避免客户端反复重试或触发异常流量。主流阻断原理有两种：

  • 方式 1：发送 QUIC 重置帧（ CONNECTION_CLOSE / RST_STREAM ）

    这是最合规的阻断方式，直接向客户端或服务器发送 QUIC 标准重置帧，告知对方 “连接已被终止”：

    • CONNECTION_CLOSE 帧：终止整个 QUIC 连接，适用于刚建立的连接（如 INITIAL 阶段），帧中需携带 “错误码”（如 0x00000001，表示 “通用错误”）与 “原因短语”；

    • RST_STREAM 帧：仅终止特定的流（如 HTTP/3 的请求流），适用于已建立连接后的封堵，避免影响同一连接中的其他流（若存在）。

      发送重置帧时，需使用与原连接相同的 “连接 ID” 与 “密钥”，确保对方能正常解析并终止连接。

  • 方式 2：联动网络层阻断（如 iptables/ACL）

    适用于对实时性要求不高、需批量阻断的场景：

    • 基于 IP + 端口阻断：在识别出目标 QUIC 连接的客户端 IP 与服务器 IP 后，通过 iptables（Linux）或 ACL（网络设备）添加规则，丢弃后续从该客户端 IP 到服务器 IP 的 UDP 流量；

    • 基于连接 ID 阻断：部分高级网络设备支持识别 QUIC 连接 ID，可直接针对特定连接 ID 的流量进行丢弃，避免影响同一 IP 下的其他合法 QUIC 连接。

三、关键技术难点与解决方案

在 QUIC 域名封堵的落地过程中，需解决三大技术难点，这些难点直接决定了封堵系统的准确性与稳定性。

1. 难点 1：QUIC 0-RTT 握手的域名提取

问题：根据 RFC 9000，QUIC 支持 “0-RTT” 握手 —— 客户端在首次连接时缓存服务器的 “会话票据”，后续重连时可直接发送应用数据（如 HTTP 请求），无需再次进行 TLS 握手，导致无法通过 “Client Hello” 提取 SNI 域名。

解决方案：

  • 会话票据关联：在客户端首次连接时（1-RTT 握手），记录 “客户端 IP + 会话票据→域名” 的映射关系，存储在缓存中；

  • 0-RTT 流量匹配：当后续检测到 0-RTT 流量时，提取客户端发送的 “会话票据”，通过缓存查询对应的域名，再执行规则匹配；

  • 缓存失效机制：设置缓存过期时间（与会话票据的有效期一致，通常为 24 小时），避免缓存膨胀或失效票据导致误判。

2. 难点 2：QUIC 加密密钥的获取

问题：QUIC 帧的加密密钥（尤其是 INITIAL 包的初始密钥）是解析 TLS 握手信息的前提，而初始密钥的生成依赖 “客户端随机数” 与 “服务器配置”（如服务器的初始向量），传统旁路监听模式无法直接获取服务器配置。

解决方案：

  • 被动捕获服务器配置：监听服务器对 INITIAL 包的响应（如 SERVER_INITIAL 包），从响应帧中提取 “服务器配置”（如初始向量、密钥交换参数），结合客户端 INITIAL 包中的 “客户端随机数”，通过 HKDF 算法派生初始密钥；

  • 预配置常见服务器密钥：对于已知的公共服务（如谷歌、阿里云），可预配置其公开的初始密钥参数，减少实时捕获的压力；

  • 使用 TLS 1.3 的密钥派生逻辑：严格遵循 RFC 8446（TLS 1.3）的密钥派生流程，确保生成的密钥与服务器、客户端一致，避免解密失败。

3. 难点 3：动态端口与连接迁移的流量关联

问题：QUIC 的 “连接迁移” 特性允许客户端在 IP 或端口变化后（如手机切换网络），继续使用原连接 ID 通信，导致传统 “IP + 端口” 的流量关联方式失效，无法对迁移后的连接进行持续封堵。

解决方案：

  • 基于连接 ID 的流量跟踪：将 “连接 ID” 作为 QUIC 连接的唯一标识，在首次识别到连接时，记录 “连接 ID→域名→封堵状态” 的映射；

  • 全端口流量监听：对已标记为 “需封堵” 的连接 ID，监听所有 UDP 端口的流量，一旦检测到该连接 ID 的数据包，立即执行封堵；

  • 连接 ID 过期处理：QUIC 连接 ID 有生命周期（通常与连接时长一致），定期清理过期的连接 ID 映射，避免资源浪费。

四、QUIC 域名封堵的应用场景与技术扩展

QUIC 域名封堵技术并非单一工具，而是可根据不同场景需求进行扩展，形成多样化的网络管理方案。

1. 典型应用场景

  • 企业内网合规管理：封堵员工访问违规社交平台（如特定 QUIC 协议的聊天软件）、视频网站的 QUIC 流量，保障办公带宽与合规性；

  • 公共网络安全防护：在校园网、网吧等场景中，阻断恶意网站（如钓鱼网站、恶意软件分发站）的 QUIC 流量，防止用户被攻击；

  • 运营商流量管控：对低优先级服务（如 P2P 下载的 QUIC 流量）进行限速或封堵，保障关键服务（如网页浏览、视频通话）的带宽资源。

2. 技术扩展方向

  • 与 HTTP/3 协议的深度整合：QUIC 是 HTTP/3 的传输层基础，可进一步解析 HTTP/3 的请求行（如 GET /index.html），实现 “域名 + 路径” 的精细化封堵（如仅封堵example.com/download路径）；

  • AI 驱动的异常流量识别：通过机器学习模型分析 QUIC 流量的特征（如连接频率、数据包大小、重传率），自动识别疑似恶意 QUIC 流量，结合域名封堵形成 “主动防御 + 被动封堵” 的双层防护；

  • 分布式封堵协同：在大型网络（如多区域企业网）中，通过中心节点同步封堵规则与连接 ID 映射，实现跨区域的统一封堵，避免恶意流量通过区域间网络绕过封堵。

五、QUIC 协议域名封堵：核心原理、关键技术与实现路径（C/C++代码实现）

#ifndef QUIC_BLOCKER_H
#define QUIC_BLOCKER_H
...// RFC 9000 定义的常量
const uint16_t QUIC_DEFAULT_PORT = 443;
const size_t MIN_QUIC_PACKET_LENGTH = 12;  // 最小QUIC数据包长度// QUIC长包头类型 (RFC 9000 Section 17.2)
enum class QuicLongHeaderType {INITIAL = 0x0,ZERO_RTT = 0x1,HANDshake = 0x2,RETRY = 0x3,UNKNOWN = 0xFF
};// QUIC短包头标志 (RFC 9000 Section 17.3)
struct QuicShortHeaderFlags {bool spin_bit;bool reserved_bit;uint8_t key_phase;uint8_t packet_number_length;
};// QUIC长包头结构 (RFC 9000 Section 17.2)
struct QuicLongHeader {QuicLongHeaderType type;bool fixed_bit;bool reserved_bit;uint8_t version[4];uint8_t dest_connection_id_length;std::vector<uint8_t> dest_connection_id;uint8_t src_connection_id_length;std::vector<uint8_t> src_connection_id;uint8_t token_length;std::vector<uint8_t> token;uint8_t packet_number_length;uint64_t packet_number;
};// QUIC短包头结构 (RFC 9000 Section 17.3)
struct QuicShortHeader {QuicShortHeaderFlags flags;std::vector<uint8_t> dest_connection_id;uint8_t packet_number_length;uint64_t packet_number;
};// ALPN协商信息 (RFC 7301)
struct AlpnInfo {std::string protocol;std::string sni;  // Server Name Indication
};// 封堵规则
struct BlockRule {std::string domain;bool block;std::string reason;
};// QUIC数据包信息
struct QuicPacketInfo {bool is_long_header;union {QuicLongHeader long_header;QuicShortHeader short_header;} header;std::vector<uint8_t> payload;AlpnInfo alpn_info;std::string src_ip;std::string dest_ip;uint16_t src_port;uint16_t dest_port;
};// 封堵器类
class QuicBlocker {
private:pcap_t* handle;std::vector<BlockRule> block_rules;std::unordered_map<std::string, bool> connection_states;  // 连接ID -> 是否被封堵std::string interface;// 解析QUIC长包头bool parseLongHeader(const uint8_t* data, size_t length, QuicPacketInfo& info);// 解析QUIC短包头bool parseShortHeader(const uint8_t* data, size_t length, QuicPacketInfo& info);// 从负载中提取ALPN和SNI信息bool extractAlpnInfo(const std::vector<uint8_t>& payload, AlpnInfo& info);// 检查是否需要封堵bool shouldBlock(const QuicPacketInfo& info);// 执行封堵操作void blockPacket(const QuicPacketInfo& info);public:QuicBlocker(const std::string& iface);~QuicBlocker();// 加载封堵规则bool loadRules(const std::string& filename);// 添加单个封堵规则void addRule(const BlockRule& rule);// 启动监听和封堵bool start();// 停止监听void stop();// 数据包处理回调static void packetHandler(u_char* user, const struct pcap_pkthdr* pkthdr, const u_char* packet);
};#endif // QUIC_BLOCKER_H...// 全局QUIC封堵器指针，用于信号处理
QuicBlocker* global_blocker = nullptr;// 信号处理函数
void handleSignal(int signal) {if (signal == SIGINT || signal == SIGTERM) {std::cout << "\n收到终止信号，正在退出..." << std::endl;if (global_blocker != nullptr) {global_blocker->stop();}exit(0);}
}// 显示帮助信息
void showHelp(const std::string& program_name) {std::cout << "QUIC协议域名封堵器" << std::endl;std::cout << "用法: " << program_name << " [选项]" << std::endl;std::cout << "选项:" << std::endl;std::cout << "  -i <接口>   指定网络接口 (例如: eth0, wlan0)" << std::endl;std::cout << "  -r <文件>   指定规则文件路径" << std::endl;std::cout << "  -h          显示帮助信息" << std::endl;std::cout << std::endl;std::cout << "规则文件格式:" << std::endl;std::cout << "  <域名> <操作> [原因]" << std::endl;std::cout << "  其中操作可以是 'block' (封堵) 或 'allow' (允许)" << std::endl;std::cout << "  示例: example.com block 违规内容" << std::endl;
}int main(int argc, char* argv[]) {std::string interface;std::string rule_file;// 解析命令行参数for (int i = 1; i < argc; ++i) {std::string arg = argv[i];if (arg == "-i" && i + 1 < argc) {interface = argv[++i];} else if (arg == "-r" && i + 1 < argc) {rule_file = argv[++i];} else if (arg == "-h") {showHelp(argv[0]);return 0;} else {std::cerr << "未知选项: " << arg << std::endl;showHelp(argv[0]);return 1;}}// 检查必要参数if (interface.empty()) {std::cerr << "请指定网络接口" << std::endl;showHelp(argv[0]);return 1;}// 创建QUIC封堵器QuicBlocker blocker(interface);global_blocker = &blocker;// 加载规则if (!rule_file.empty()) {if (!blocker.loadRules(rule_file)) {std::cerr << "加载规则文件失败: " << rule_file << std::endl;return 1;}} else {std::cout << "警告: 未指定规则文件，使用默认规则" << std::endl;// 添加默认规则blocker.addRule({"example.com", true, "默认封堵示例"});}// 设置信号处理signal(SIGINT, handleSignal);signal(SIGTERM, handleSignal);std::cout << "按 Ctrl+C 停止程序" << std::endl;// 启动封堵器if (!blocker.start()) {std::cerr << "启动QUIC封堵器失败" << std::endl;return 1;}return 0;
}

If you need the complete source code, please add the WeChat number (c17865354792)

这个QUIC协议域名封堵器的实现遵循了RFC 9000（QUIC传输协议）和RFC 9001（QUIC TLS）等相关规范，主要功能包括：

  1. QUIC协议解析：实现了长包头和短包头的解析，能够识别INITIAL、HANDSHAKE等类型的数据包。

  2. 域名识别：通过解析TLS握手过程中的SNI（Server Name Indication）扩展，提取客户端请求的域名。

  3. 封堵规则管理：支持从文件加载封堵规则，也可以动态添加规则。

  4. 流量监控：使用libpcap库捕获网络接口上的QUIC流量（默认监听443端口的UDP流量）。

  5. 封堵执行：对匹配封堵规则的QUIC连接进行拦截处理。

使用方法

  1. 编译程序：

    make

  2. 运行程序（需要root权限）：

    sudo ./quic_blocker -i eth0 -r rules.txt

  3. 其中eth0是网络接口名称，rules.txt是封堵规则文件,如下。

# QUIC封堵规则文件
# 格式: 域名 操作 [原因]
# 操作: block(封堵) 或 allow(允许)example.com block 封堵域名
test.com block 测试用封堵域名
malicious.com block 恶意网站

总结

QUIC 域名封堵的技术本质，是在 “协议合规” 与 “管理需求” 之间寻找平衡—— 既要尊重 QUIC 协议的标准化设计（如加密、连接迁移），又要通过深度解析与精准干预，实现对域名的有效管控。其核心并非 “破解” QUIC 的加密机制，而是利用协议规范中 “可解析的元数据”（如 SNI 扩展、连接 ID）与 “标准化的连接管理机制”（如重置帧），构建合规的封堵逻辑。

未来，随着 QUIC 协议的持续演进（如 RFC 9369 对 QUIC 版本协商的优化）与应用普及，域名封堵技术将面临两大发展方向：

  1. 更深度的协议协同：与 QUIC 协议的标准化组织（IETF）保持同步，及时适配新的协议特性（如新型包头、加密算法），确保封堵技术的兼容性；

  2. 更智能的管控策略：结合网络流量分析、用户行为画像等技术，从 “静态规则封堵” 向 “动态智能管控” 升级，实现 “按需封堵、精准放行”，在保障安全的同时最大化网络可用性。

对于技术学习者而言，理解 QUIC 域名封堵的原理，不仅能掌握一项实用的网络管理技术，更能深入理解传输层协议与加密层协议的协同逻辑，为后续学习 HTTP/3、TLS 1.3 等相关技术奠定坚实基础。

Welcome to follow WeChat official account【程序猿编码】


文章转载自：

http://sMdAbSJz.dwxqf.cn
http://BjBUf4SE.dwxqf.cn
http://tHXZyq8K.dwxqf.cn
http://ZD3EDUTy.dwxqf.cn
http://BvoNFMwU.dwxqf.cn
http://02Op01jZ.dwxqf.cn
http://TfxFKViM.dwxqf.cn
http://LMM4RaIJ.dwxqf.cn
http://ddx5rHTf.dwxqf.cn
http://MFMxtd32.dwxqf.cn
http://OytMZbsE.dwxqf.cn
http://gyTlKh59.dwxqf.cn
http://gdDinhLv.dwxqf.cn
http://2FYHs4tr.dwxqf.cn
http://HSskxML9.dwxqf.cn
http://GCKH9bjm.dwxqf.cn
http://RY4k5Osp.dwxqf.cn
http://mpYzetfq.dwxqf.cn
http://ofvO8gA1.dwxqf.cn
http://SoQPSDNh.dwxqf.cn
http://WjeK5zCG.dwxqf.cn
http://JyJ2Aynk.dwxqf.cn
http://XjNW5wGc.dwxqf.cn
http://cjpjHOmi.dwxqf.cn
http://Dck7tYXX.dwxqf.cn
http://NYRFe45J.dwxqf.cn
http://tGsGnCND.dwxqf.cn
http://1yeGAV9J.dwxqf.cn
http://t7HGJ5ZK.dwxqf.cn
http://UVJF31SX.dwxqf.cn
http://www.dtcms.com/a/386424.html

相关文章：

  • 8 基于机器学习进行遥感影像的地物分类-以随机森林为例
  • Qt读写SQLite示例
  • Jmeter性能测试之阶梯式场景、波浪式场景、服务器监控
  • 黄昏时刻复古胶片风格人像风光摄影后期Lr调色教程，手机滤镜PS+Lightroom预设下载！
  • Django ORM多对多关系实战指南
  • 【从零开始java学习|第十七篇】面向对象进阶
  • Three.js 开发实战教程（一）：环境搭建与第一个 3D 场景
  • 旅游小程序的功能优势
  • LeetCode:7.接雨水
  • Android 安卓 问题解决记录 腾讯IM和厂商离线推送问题 点击离线推送无法唤醒APP启动页但某些Service服务和Application被启动
  • 动态规划解决系列子序列问题
  • SCADE One vs Scade 6 - 标量积建模比较
  • Next.js 身份验证与授权：使用 NextAuth.js 保护你的应用
  • Spring MVC 的案例小练习
  • 贪心算法与动态规划
  • 香港期权市场的主要参与者有哪些？
  • 系统中间件与云虚拟化-serverless-基于阿里云函数计算的简单邮件发送服务设计与体验
  • 【LLM】GPT-OSS架构变化详解
  • 【开题答辩全过程】以 “寄情绿苑”绿色殡葬服务小程序的设计和实现为例，包含答辩的问题和答案
  • 容器化部署之dockerfile07
  • 一篇读懂Pormise！！【前端ES6】
  • spring-kafka的消息过滤器RecordFilterStrategy
  • gin中sse流式服务
  • 论文笔记（九十一）GWM: Towards Scalable Gaussian World Models for Robotic Manipulation
  • Simulink（MATLAB）与 LabVIEW应用对比
  • [BX]和loop指令，debug和masm汇编编译器对指令的不同处理，循环，大小寄存器的包含关系，操作数据长度与寄存器的关系，段前缀
  • Django RBAC权限实战全流程
  • 智启燃气新未来丨众智鸿图精彩亮相2025燃气运营与安全研讨会
  • Docker Push 常见报错及解决方案汇总
  • OCR 后结构化处理最佳实践