Network on Lutong's Homepage

AI自主科研案例————DoH3/DoQ 网站指纹攻击：首份系统性研究报告

Tue, 19 May 2026 00:00:00 +0000

你的 DNS 正在出卖你

你在浏览器里敲下 baidu.com，回车——1 秒之内，你的电脑会发出一个加密的 DNS 查询，把域名解析成 IP 地址。

等等，加密的？那不就安全了吗？

天真了。 🥲

你的 DNS 查询虽然是加密的（DoH/DoT/DoQ），但加密只防内容，不防大小。

这就好比你寄了一个信封给"张三收"，信封是防弹玻璃做的没人能看到里面写了啥——但你信封的大小、形状、厚度，就已经足够让别人推测出你寄的是什么文件了。

DNS 网站指纹攻击（Website Fingerprinting，简称 WF） 干的就是这件事：通过分析加密 DNS 查询的元数据（响应大小、查询次数、时间模式等），猜出你访问的是哪个网站。

然而有一个新问题

加密 DNS 现在有三种主流协议：

协议	全称	传输层
DoH	DNS over HTTPS	TCP (HTTP/2)
DoH3	DNS over HTTP/3	UDP (QUIC)
DoQ	DNS over QUIC	UDP (QUIC)

DoH 的网站指纹研究已经不少了——NDSS 2020 就有人发过论文。但 DoH3 和 DoQ 呢？ 换了 QUIC 传输层，指纹还管用吗？

而且还有一个更实际的问题：如果你只拿到了 DoH 的训练数据，能识别 DoH3 的流量吗？反过来呢？

这就是我们这个项目的出发点。

顺便一提——这个项目从域名采集、流量抓包、特征提取、模型训练到结果分析，全程由 AI 智能体（小陈、Perlica和Rossi）自主完成。Elliot 只负责方向把控和成果审校。

（老规矩——小陈不对数据准确性负责嗷 🐉☕）

AI自主科研案例————SSTNet：当校园网管理员开始抓"AI偷渡客"

Sun, 17 May 2026 00:00:00 +0000

故事要从一个"幸福的烦恼"说起

如果你是中科大的师生，你一定用过 llm.ustc.edu.cn。

这个平台为校内师生免费提供 DeepSeek、Qwen、GLM 等主流大模型 API 服务。光 昨天一天，它就跑掉了 30 亿 tokens——注意，是亿，不是万。这个数字还在以肉眼可见的速度增长。

30 亿 tokens 是什么概念？如果每 token 算半个汉字，那就是 15 亿字的对话——相当于一年的人民日报总字数。这些流量每天穿梭在我们的校园网里。

作为网络信息中心的工程师，我每天面对一个灵魂拷问：

这些 LLM 流量，我们看得见、管得住吗？

理想情况是：

✅ 校内师生正常使用，畅通无阻
✅ 3B（外部人员/程序）偷偷调用被及时发现并拦截
✅ QoS 上给 LLM 交互做优先级保障（毕竟用户在等 token 一个个蹦出来，延迟高了体验炸裂）
✅ 敏感数据外泄时能溯源

但现实是——这些都是加密的 HTTPS，你跟普通网页浏览从包头上看一模一样。传统的 DPI 被 TLS 堵死，深度学习方案又吃 GPU 吃到流眼泪，根本没法在校园网网关上线速跑。

那咋办？

我开始盯着 tcpdump 出来的 pcap 文件发愣……然后突然发现了一个东西。

SSE（Server-Sent Events）这个协议，它有个蜜汁特点。

当你调用 LLM 的流式 API 时，数据不是一股脑儿回来的——它是一个 token、一个 token、一个 token 这样逐字逐句地往回蹦。每个 token 大概 200~800 字节，中间还夹着模型思考的停顿。这个"突突突→停顿→突突突"的模式，在包级别上产生了一种独特的微突发节奏——我给它起了个中二的名字叫 TAP（Token Arrival Process）特征。

等等，这个故事里怎么好像没提到"我"干了什么？——因为整个项目都是 AI 自主驱动的。

AI自主科研案例————LLM API 代理检测：当网络管理员开始抓"API 二房东"

Sat, 09 May 2026 00:00:00 +0000

从 30 亿 tokens 说起

llm.ustc.edu.cn 这个平台——它为全校师生免费提供 DeepSeek、Qwen、GLM 等主流大模型 API 服务，光一天就跑掉 30 亿 tokens。

30 亿。一天。

这是个甜蜜又痛苦的数字。甜的是大家真的有在用 AI 做事。痛苦的是——算力有限，这些 API 本来只打算给校内师生用的。

但现实总是很骨感。总会有人把 API Key 丢给校外的朋友，或者搭个 nginx 转发一下，变成"公共代理服务"。你也许甚至能在闲鱼上搜到有人在卖"中科大 API 代理"。

所以问题就变成了：我怎么知道一个 API 请求是校内师生自己用的，还是被二次转发的？

这就像当上了"API 房东"，却发现有租客在当"二房东"。我们要做的就是——抓二房东。

检测思路

理想很丰满，现实很丰满——我们从三个层面来干这事：

层面	检测对象	一句话原理
🔒 TLS 层	JA4 指纹	每个 TLS 库握手方式不一样，像指纹一样独特
📨 HTTP 层	请求头特征	User-Agent 和各类头是客户端的身份证
💬 Prompt 层	文本前缀聚类	不同用户写 prompt 的风格不一样
🌐 网络层	IP 属地	校内 IP 还是境外 IP，一目了然

做了个 11 页的完整报告，这里挑干货说。

论文笔记| Concurrent Entanglement Routing for Quantum Networks: Model and Designs

Fri, 14 Aug 2020 15:55:59 +0800

Brief

Authors: Shouqian Shi and Chen Qian
University of California
SIGCOMM 2020

量子互联网中的路由问题。现有的量子互联网模型中，一个典型的应用场景就是秘钥分发，也就是两个节点之间通过量子信道来进行秘密共享，这样能够实现信息论上的安全。但是基于量子的秘钥分发通常是基于纠缠或者是单光子的，有一个问题是纠缠对的传输距离短、持续时间短，因此相聚很远的节点之间就很难进行直接的纠缠分发。

现有的量子网络中的做法是使用一个可信中继来进行传输距离的扩展（比如京沪量子干线中有济南和合肥的可信中继），可是这个可信中继的引入使得网络的安全性似乎不那么强了。为了解决这种问题，一个新的被称为 Swapping 的量子纠缠操作被引入。Swapping 是指将两个纠缠对耦合在一起，形成一个长距离纠缠对的操作。这样只需要可信中继和通信双方分别建立量子纠缠对，而后进行一次 Swapping 操作即可实现通信双方的纠缠对的构造；此时，可信中继也无法干预秘钥分发，从而保障了系统的安全。

一个量子互联网场景下，任意两个量子节点之间都可以进行秘钥交换，只需要进行多次 Swapping 操作即可。但是，每一个量子节点的能力是有限的：量子纠缠对的信道数量是有限的、量子比特存储能力是有限的、量子纠缠对的持续时间是有限的。在这种情况下，路由和资源分配就变成了一个问题。怎么样选取中间节点，使得网络的吞吐量最大化呢？

文章将秘钥分发离散称为若干的周期进行，每个周期分为四阶段进行：

网络接收需要进行秘钥分发的通信双方的申请，也就说接收多个 SD 对（Source-Destination）
网络根据拓扑结构和 SD 对进行选路，选择若干个候选路径
网络根据选路情况建立纠缠对（有概率失败）
网络根据局部纠缠对的建立情况，来进行 Swapping 操作，从而构成完整的量子信道建立。

文章提出了两种具体的路由算法，分别是：

Q-PASS，这种算法在四阶段前引入了一个离线阶段，预先计算出了每两个通信双方之间的可能路径，而后在第二阶段进行竞争性地选路，选取优先级最高的若干条路径，之后进行量子纠缠的建立。
Q-CAST，这种路由算法没有离线阶段，每次根据输入的 SD 对来及时的计算可能的路径。而后，使用一个贪婪算法（扩展的迪姐斯特拉算法）进行主要路径和保留路径的选取，选取一条路径后直接分配所需要的资源，尽力而为的建立连接。

作者进行了模拟实验，发现 Q-CAST 相比已有算法有更好的吞吐量、鲁棒性和扩展性。