前言
上周因为回老家提前过年待了几天，没啥时间写文章(其实到有2篇正在写的文章，不过都卡在中间，需要时间来研究和试验)，所以这周的内容可以写一个简短却有必要单独用一篇文章来突出其重点的知识点：Cloudflare Tunnel的2种通信协议”QUIC(默认) 和 HTTP/2“。
Cloudflare Tunnel通信协议介绍
QUIC 协议
(1) 简介
QUIC（Quick UDP Internet Connections）是 Google 开发并随后成为 IETF 标准的协议，基于 UDP 构建，设计目的是提高现代网络的传输效率。
(2) 特性
• 低延迟连接：支持 0-RTT 和 1-RTT 握手，连接建立速度极快。
• 集成加密：QUIC 原生集成了 TLS 1.3，每次传输均加密，提升安全性。
• 多路复用：每个流独立，不受其他流的影响，解决了 TCP 中的“队头阻塞”问题。
• 高效应对丢包：QUIC 仅重新传输丢失的数据包，而不影响其他流。
• 连接迁移：QUIC 能在 IP 或网络切换时（例如从 Wi-Fi 切换到移动网络）保持连接。
(3) 优势
• 更快的性能：尤其在高延迟和高丢包环境下表现优异。
• 更灵活的适配：适用于动态和复杂的网络条件。
HTTP/2 协议
(1) 简介
HTTP/2 是基于 TCP 的协议，是 HTTP/1.1 的改进版本，专注于优化 Web 性能。
(2) 特性
• 多路复用：支持多个请求和响应共享一个 TCP 连接。
• 头部压缩：减少了请求和响应的体积。
• 优先级控制：支持为重要资源分配更高优先级。
(3) 局限性
• 队头阻塞：由于 HTTP/2 依赖于 TCP，一旦单个包丢失，整个 TCP 连接会被阻塞。
• 连接建立慢：TCP 需要三次握手，外加 TLS 握手，初次连接耗时较长。
• 连接迁移性差：无法像 QUIC 那样在 IP 或网络变化时保持连接。
Cloudflare Tunnel默认使用 QUIC 的理由
Cloudflare Tunnel 默认的通信协议选择了QUIC，而非 HTTP/2，主要基于以下原因：
1. 快速建立连接
QUIC 支持 0-RTT 或 1-RTT 握手，相比 HTTP/2 的多阶段 TCP+TLS 握手，显著减少了延迟，提升了用户体验。
2. 更优的抗丢包能力
QUIC 通过流级别的丢包恢复避免了队头阻塞，而 HTTP/2 依赖 TCP，丢包会阻塞整个连接，导致性能下降。
3. 动态环境的适应性
QUIC 的连接迁移能力允许客户端在 IP 或网络切换时保持连接，适合现代移动和多网络环境。
4. 集成安全性
QUIC 原生支持 TLS 1.3，安全性更高且加密开销更小，简化了传输层与安全层的结合。
5. 符合高性能需求
Cloudflare Tunnel 需要为用户提供高吞吐量、低延迟和高可靠性的连接，QUIC 在这些方面优于 HTTP/2。
总结
• QUIC 是 Cloudflare Tunnel 的默认协议，因为它具有快速连接、高效丢包处理、动态适应性和更高安全性的优势。
• HTTP/2 虽然也支持多路复用和头部压缩，但基于 TCP 的限制使其在高动态和复杂网络环境下表现不如 QUIC。
从上面的讲述可以看出，在正常的网络环境中，Cloudflare Tunnel默认采用QUIC作为通信协议是非常明智的，不过嘛，在非正常的网络环境下呢？
HTTP/2的优势
在非正常网络环境下，QUIC 的显眼特性(基于 UDP/443)可能导致其容易被干扰甚至封锁，而 HTTP/2 基于 TCP/443，流量隐蔽性更强，更适合应对严格的网络限制。因此，Cloudflare Tunnel 在这些场景中使用 HTTP/2，可以显著提高连接的隐蔽性和可用性，成为复杂网络环境中的可靠选择。
非正常网络环境对 QUIC 的限制
- QUIC 容易被识别和干扰
• QUIC 基于 UDP/443，而不是传统的 TCP/443。这使得其流量模式与传统 HTTPS 流量明显不同，容易被 DPI（深度包检测）设备识别。
• 部分运营商或防火墙可能会限制 UDP 流量，或者对 QUIC 流量进行限速甚至封锁，导致传输不稳定。
- UDP 流量的普及率低
• UDP 协议虽然技术上优秀，但在实际部署中并不像 TCP 那样通用。这使得 QUIC 流量更显眼，在封闭环境下容易被标记为异常。
- QUIC 的可用性受限
• 如果 UDP/443 被阻断，QUIC 无法正常工作，可能导致连接中断。
HTTP/2 的隐蔽性优势
在上述环境中，HTTP/2 作为基于 TCP/443 的协议，能够很好地掩盖流量特征并提高可用性：
1. 基于 TCP/443 的隐蔽性
• HTTP/2 使用 TCP/443，这是 HTTPS 的标准端口，流量模式与传统 HTTPS 流量几乎无异。
• 深度包检测设备更难区分 HTTP/2 和普通 HTTPS 流量，这有效降低了被识别和干扰的风险。
2. 高度兼容性
• TCP 是网络通信的主流协议，其流量在全球范围内的可用性和通过率高。
• HTTP/2 可以在任何支持 HTTPS 的网络环境中正常工作，而不受特定网络策略的限制。
3. 对干扰的抗性
• 即使网络中存在抖动、限速或丢包，TCP 的可靠性机制能确保数据的完整性，保障稳定的连接。
• 相较于 QUIC 可能因 UDP 受限而完全失效，HTTP/2 的传输更加稳健。
4. 部署的成熟度
• HTTP/2 依托于多年的 TCP 技术积累，其部署和调优在全球范围内更加成熟，适合复杂网络环境下的使用。
所以，在非正常的网络环境下，Cloudflare Tunnel使用HTTP/2来作为通信协议更加的安全和可靠。
附加知识：HTTP/2与长连接应用
长连接在使用QUIC时不稳定
在使用 Cloudflare Tunnel 时，选择不同的通信协议（QUIC 或 HTTP/2）会直接影响长连接的稳定性，尤其是在涉及复杂网络环境或特定应用场景时，我看到有很多文章谈到使用默认的QUIC作为通信协议时，长连接应用(比如gRPC)会不稳定，这是因为QUIC 协议虽然设计上支持长连接，但在特定场景下，长连接可能出现中断，原因分析如下：
(1) 网络干扰和阻断
• QUIC 基于 UDP/443，而许多网络环境（特别是防火墙或企业网络）对 UDP 流量有严格限制或优先封锁。对于需要长时间保持的连接，这种干扰会导致连接频繁中断。
(2) 网络切换引发的连接中断
• 虽然 QUIC 支持连接迁移（如从 Wi-Fi 切换到移动网络），但在部分网络环境中，切换可能导致延迟增加或连接被短暂中断，影响长连接的稳定性。
(3) 应用协议与 QUIC 的适配问题
• 某些需要稳定长连接的应用（如 WebSocket、实时通信）可能对延迟或中断更为敏感，而 QUIC 的特性未必能很好地适配这些需求。
(4) QUIC 的可靠性依赖于 UDP 的稳定性
• 如果网络丢包率较高，UDP 的无连接特性可能导致 QUIC 的长连接性能下降。
使用 HTTP/2 改善长连接
HTTP/2 基于 TCP/443，其设计天然适合需要长时间保持稳定连接的场景，而设置 http2 connection 功能后更能使长连接稳定性，原因分析如下：
(1) TCP 的可靠性
• TCP 是面向连接的协议，提供数据包传输确认和重传机制。在丢包或网络抖动情况下，TCP 能更可靠地保证数据传输，维持长连接的稳定。
(2) HTTP/2 多路复用的优势
• HTTP/2 支持在一个 TCP 连接上同时传输多个流，这意味着应用层长连接可以在单一连接上维持多路通信，避免了 TCP 连接耗尽的风险。
(3) 启用 http2 connection 的作用
• 在 Cloudflare Tunnel 中启用 http2 connection 功能时，服务端和客户端可以明确协商使用 HTTP/2 协议。这带来以下好处：
• 应用层优化：支持长连接的应用（如 WebSocket、gRPC 等）可以在 HTTP/2 的流特性上更高效地工作。
• 更少的握手开销：相比 HTTP/1.1，每个长连接只需一次握手，减少了协议级别的延迟。
• 保持连接更稳定：即使在有丢包或轻微干扰的网络环境中，TCP 的重传机制和 HTTP/2 的多路复用特性共同确保连接的持续性。
(4) TLS 和 HTTP/2 的协同作用
• HTTP/2 协议要求加密通信（TLS），并通过 ALPN（应用层协议协商） 明确指定使用 HTTP/2 协议。这种协商机制能有效避免协议切换带来的不稳定，因此，在需要稳定长连接的场景中，切换到 HTTP/2 并正确配置 Cloudflare Tunnel 是更优的选择(主要是启用http2 connection选项，具体配置参见后面的实操部分内容)。
配置 Cloudflare Tunnel 使用HTTP/2协议
Debian(Red Hat)方式部署的配置
通过zero trust–>网络–>Tunnel，然后选择想要在Debian上部署的连接器对应的隧道，以我的隧道”aliyuncloud”为例，点最右边3个竖点下的”配置”进入概览界面：
使用文本编辑工具编辑配置文件，以vim为例：
vim /etc/systemd/system/cloudflared.service
然后在”ExecStart=”这行末尾添加”–protocol http2″，然后保存退出即可，如下图：
最后使用如下命令重新加载systemd和重启cloudflared服务即可：
systemctl daemon-reload
systemctl restart cloudflared
也可以使用如下命令查看日志：
journalctl -u cloudflared -f
正常应该看到http2相关的内容，比如：”Connected to Cloudflare edge using HTTP/2″。
注：如果之前已经安装了Cloudflare Tunnel，直接编辑配置文件保存后重启cloudflared服务即可。
Docker方式部署的配置
然后在命令最后加上”–protocol http2″,然后运行即可：
docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token 你的token --protocol http2
Win和Mac
win和mac下的Cloudflare Tunnel修改协议为http2是依靠修改”config.yml”文件，yml文件内容如下：
tunnel: <tunnel-id>
credentials-file: /path/to/credentials.json
ingress:
- hostname: example.com
service: https://localhost:8080
originRequest:
http2: true # 启用 HTTP/2
- service: http_status:404
其中：
• tunnel 是你的 Tunnel ID。
• credentials-file 是登录时生成的凭据文件路径。
• http2: true 用于启用 HTTP/2 协议。
然后使用如下命令：
cloudflared tunnel --config /path/to/config.yml run <tunnel-name>
注：这部分内容我没有实际验证过，只是收集而来，因为实在不想在mac和win上安装cloudflared～。
优化长连接
在 Cloudflare Tunnel 中，配置 Public Hostname 并选择 HTTPS 服务类型，可以进一步优化了 HTTP/2 长连接的体验：
Public Hostname 提供全局可访问性
• Public Hostname 是 Cloudflare 提供的入口点，确保隧道可以在全球范围内路由最优路径，即使在复杂网络中也能提高服务的可用性。
服务类型选择 HTTPS
• HTTPS 强制所有通信加密，结合 HTTP/2 提供的多路复用，使得连接更加高效稳定。
结合 http2 connection 功能
• 明确启用 HTTP/2，可以让需要长连接的应用（如实时通信服务、持续数据流）在复杂网络条件下保持稳定。
具体操作如下图：
总结
其实，我本来想把默认协议切换到http2的那点操作命令直接加到之前写的关于Cloudflare Tunnel部署的相关文章中，但是后来想想，虽然这个操作很简单，但是从重要性的角度来说，却完全值得单独用一篇文章来讲：因为我相信有不少使用Cloudflare Tunnel的朋友还未必知道这个知识点。
另：对于在国内使用Cloudflare Tunnel进行站点发布的个人博主们，我推荐以后尽量都使用http2的方式(哪怕使用默认的QUIC协议目前能够正常工作)，毕竟，你懂的～。
