QUIC 几乎把防火墙半废了,特别是基于五元组的防火墙:
除非把特定两台主机的 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,真正的传输协议该展现出的样子。
浙江温州皮鞋湿,下雨进水不会胖。