QUIC 与 防火墙

QUIC 几乎把防火墙半废了，特别是基于五元组的防火墙：

• 无法分析 payload，因为加密了。
• 无法阻断特定元组，因为元组可变。

除非把特定两台主机的 TCP/UDP 通信完全禁止，否则完全可以通过更改端口重试的方式绕开防火墙。这并不复杂。

接收端很容易实现 “侦听所有 UDP 端口” 的逻辑，学着 iptables REDIRECT 的样子就行，将收到的无主 UDP 报文交给 QUIC 解析，QUIC 本身即端口无关，QUIC 通过 Connection ID 来识别流。

即使禁掉所有 UDP，刚刚我不是展示如何将 socket(AF_INET, SOCK_DGRAM, 0) 传输给 socket(AF_INET, SOCK_STREAM, 0) 么。

传输层协议本身即运载协议，端口号本不应该和应用进程耦合，端口号的存在仅增加了复用率，在 1970～1980 年代，端口号只是不经意间让人觉得 “它真的代表特定服务，比如 80 就是 HTTP”。难道不该让服务自己识别自己吗？QUIC 着实解除了端口号和服务之间的耦合。

为防止协议僵化，QUIC 要求无条件加密，端与网络解耦，各自独立发展，网络不能再对传输协议进行任何假设，当然也就无法禁止特定流，传统防火墙依赖传输协议 IP 和端口进行流量阻滞， 便无法再发挥作用。

QUIC 传输本身甚至是可序列化的，虽然 TCP Repair 也做过类似尝试，但终究还是没能力尽力。

我曾经以为 QUIC 的部署会促使防火墙进行一波升级，但现在看来，事情并不是升级能解决的，传统的安全防火墙面对 QUIC 是无能为力的，无论怎么升级都不行。

看起来 QUIC 周边的配套还很苍凉。除了防火墙，可能还有 QoS，流量工程。仅存的 Connection ID 不变量能做什么？但仔细推敲，这个字段也是可以协商变更的，而协商的内容在 encrypted payload 里 …

但这就是 QUIC，真正的传输协议该展现出的样子。

浙江温州皮鞋湿，下雨进水不会胖。