QUIC协议承载了HTTP/3，默认使用UDP 443端口，并且把传输层安全和头部保护做进了协议内部。对于传统防火墙、入侵检测系统和流量审计工具来说，以前看到的TCP三次握手、明文TLS ServerHello、证书字段等识别依据，在QUIC流量中要么消失，要么被加密。因此，检测QUIC不能只依赖端口，还要从UDP载荷特征、QUIC首部格式、TLS握手片段和连接行为多个层面入手。
QUIC协议检测的底层难点
QUIC运行在UDP之上，UDP本身无连接，没有TCP的SYN、ACK状态可以关联。传统设备常把UDP 443当作某种自定义流量放过或误报，而HTTP/3正是使用这个端口。更麻烦的是，QUIC从Initial包开始就使用加密保护，虽然Initial包使用固定算法，但载荷不是明文TCP流，不能直接从中读取完整HTTP头部。
QUIC还有一个重要设计是连接ID。连接ID可以脱离源IP和端口标识连接，因此NAT重绑定或网络切换后，连接仍然可以继续。这给基于五元组的会话检测带来挑战：单靠IP和端口无法稳定关联一个QUIC连接，必须解析连接ID并结合迁移行为。
此外，QUIC的头部保护会加密部分首部字段，例如包号长度和部分标志位，但第一个字节中的Header Form和版本信息仍可读。长包和短包的结构差异，为快速识别提供了入口。理解这些底层特性，才能设计有效检测。
基于端口与载荷特征的快速识别
最直接的过滤条件是UDP 443端口。由于QUIC支持版本协商和后续连接迁移，端口并非绝对固定，但绝大多数公网HTTP/3服务仍使用443。抓包或安全设备可以先通过udp.port==443建立候选流量，再用载荷特征二次确认。
QUIC首部第一个字节的最高两位可以区分长包和短包。长包最高位固定为1，第二个最高位为固定位，当前版本为1；短包最高位为0。长包中包含版本字段，版本号常见为0x00000001或0x6b334d20等，取决于实现和协商阶段。根据这一特征，可以排除大量非QUIC的UDP 443流量，例如某些VPN或自定义加密协议。
在Wireshark中可直接使用过滤器quic，或者组合条件：
udp.port == 443 && quic
如果要排除QUIC版本协商流量，可使用quic.version字段。Wireshark对QUIC解析较为完善，能识别短包、长包、Initial、Handshake和1-RTT包。
对于无法依赖Wireshark的环境，可以用Python读取UDP载荷并判断首字节。下面给出一个简单解析脚本，用来区分长包和短包：
def is_quic_long_header(payload: bytes) -> bool:
if len(payload) < 1:
return False
first = payload[0]
# QUIC长包第一个字节最高位为1
return (first & 0x80) != 0
def extract_version(payload: bytes):
if not is_quic_long_header(payload) or len(payload) < 6:
return None
# 长包版本字段位于第2到第5字节
version = int.from_bytes(payload[1:5], "big")
return version
这段代码只做初步判断。真实检测还需要处理版本协商包、重连包以及部分中间设备对UDP载荷的分片和重组。
从Initial包中提取TLS ClientHello与SNI
光识别QUIC帧还不够，很多安全策略需要知道访问的是哪个域名。QUIC的Initial包中携带CRYPTO帧，里面包含TLS ClientHello消息。虽然Initial包使用固定初始密钥保护，但客户端初始密钥可以由目标连接ID推导，因此离线解析或者中间设备也可以解密Initial包，提取ClientHello中的SNI。
QUIC的TLS握手与TCP上的TLS 1.3结构基本一致，但被拆分成CRYPTO帧，并且受到QUIC包边界限制。解析流程通常为：先解析QUIC头部，提取目标连接ID，按RFC 9001生成初始密钥，然后解密Initial包载荷，去掉CRYPTO帧头，最后按TLS记录格式读取ClientHello。
Wireshark可以在具备密钥或使用内置初始密钥推导的情况下解析QUIC握手信息。使用tshark批量提取SNI的命令如下：
tshark -r quic.pcap -Y "quic" -T fields \ -e ip.src -e udp.port -e tls.handshake.extensions_server_name
注意反斜杠用于命令换行，在Windows命令行中可以去掉或替换为对应的续行符号。实际抓包中，很多QUIC ClientHello的SNI字段会显示在tls.handshake.extensions_server_name中，这为域名级检测提供了条件。
如果设备没有解密能力，也可以利用Initial包的明文特征做辅助判断。例如Initial包通常较长，前几个字节固定特征明显，并且版本字段与TLS ClientHello出现的频率高度相关。虽然无法读取SNI，但可以识别为QUIC并标记高优先级审计对象。
检测连接迁移、0-RTT与行为特征
QUIC连接迁移允许客户端更换IP或端口而保持连接ID不变。安全设备如果只按五元组维护会话，可能把一个连接拆成多个，或者把迁移后的流量误判为新连接。检测迁移需要持续跟踪QUIC连接ID，并关联不同五元组。
0-RTT是另一个检测难点。客户端在恢复会话时，第一个RTT就可以携带加密的应用数据，此时没有新的TLS握手可供分析。设备只能根据首包中的连接ID和会话票据状态判断是否放行或审计。对于需要域名级策略的环境，0-RTT可能让策略失效，因为0-RTT数据不包含完整SNI，只能依赖之前建立的会话缓存。
行为特征方面，QUIC有独立的流控制和严格的包号递增规则。异常的大流量、高频短连接、同一连接ID在不同IP间快速跳变、或大量版本协商包，往往提示隧道、扫描或规避行为。eBPF可以在内核层挂载UDP接收路径，提取QUIC首字节和连接ID，实现高性能检测而无需把所有流量复制到用户态。
企业网络中的检测与策略建议
在防火墙或安全网关中检测QUIC，常见做法是先识别UDP 443的QUIC流量，再根据SNI或连接行为做允许、阻断或限速。若设备支持TLS解密代理，需要同时支持QUIC和HTTP/3；若不支持，则只能依赖SNI和端口策略，无法看到HTTP路径和内容。
对于高安全要求的内网，可以限制出站UDP 443，或者只允许特定QUIC版本。也可以部署旁路审计，用tshark、Zeek或自研eBPF工具记录连接ID、SNI、字节数和持续时间。这样即使不阻断，也能在安全事件发生时回溯。
另外，QUIC的版本演进较快，检测规则需要定期更新。新版本的头部格式总体保持兼容，但部分扩展会改变帧类型和传输参数。建议将检测逻辑拆成独立模块：UDP候选过滤、QUIC首部解析、TLS握手提取、行为关联，每个模块单独测试，避免因版本升级导致整体误报。