纠正一个传出去的错误结论：不是「运营商封了 UDP」

我在给部署脚本的指示里写过：

    实测这条线路上运营商对 UDP 有限制 ——
    12 个 Cloudflare edge IP：TCP 12/12 通、UDP 0/12 通

它照这个把注释写进了 relay/deploy.sh。

**但这个测量是无效的。** relay-stability 后来自己纠正了：
那个 UDP 探测包是手搓的简化包，格式不对，
Cloudflare 本来就不该回应它 —— 「0/12 无回应」什么都证明不了。

用 cloudflared --loglevel debug 跑临时实例，真相是：

    UDP Connectivity  region1/region2  PASS  QUIC connection successful
    SUMMARY: Environment is healthy. cloudflared will use 'quic'
    Registered tunnel connection        （握手 1 秒）

**UDP 完全通。**

真因是：QUIC 建连要 6+ 个包往返，而 TCP 的 SYN 只有 3 个包、
内核还会按 1s/2s/4s 激进重传。约 5.4%/包 丢包下：

    (1 - 0.054)^6 ≈ 72%     <- 和实测的 72% 对得上

所以 QUIC 的弱点在「连不上」，不在「连上之后不好」；
一旦连上，它没有 TCP 的跨流队头阻塞，反而更稳。

结论的**用途**没变（还是要两条协议一起跑），但留着错误的根因注释会：
  * 误导后人以为 UDP 被封 -> 可能做出「干脆别用 QUIC」的错误决定
  * 掩盖真正可优化的方向（QUIC 握手对丢包敏感是链路物理属性，
    只能靠 HTTP/2 兜底来绕，不是「运营商限制」）

改动：relay/deploy.sh 两处、_build/test_deploy_sh.sh 一处。

教训记一笔：**手搓协议包去探测可达性非常容易得出错误结论** ——
那个包格式不对，对方根本没义务回应。要么用官方工具的自检
（cloudflared 自己会打 UDP Connectivity PASS/FAIL），
要么别下结论。

relay/deploy.sh

@@ -98,8 +98,13 @@ ykxmz 服务器端 · 一键部署   v$VERSION
     --protocol P        quic / http2 / both（默认 both）
                         默认**两条隧道一起跑**，这是实测最优：
                           主 quic + 8 条   副本 http2 + 2 条
-                        为什么两条一起跑 —— 运营商对 UDP 有限制
-                        （12 个 edge IP：TCP 12/12 通、UDP 0/12 通），
+                        为什么两条一起跑 —— QUIC 握手对丢包敏感：
+                        它要 6+ 个包往返才建得起来，而 TCP 的 SYN 只有
+                        3 个包、内核还会按 1s/2s/4s 激进重传。
+                        在约 5% 丢包下 (1-p)^6 只有 ~72% 能建成 ——
+                        所以刻意让 HTTP/2 占几条连接兜住那 28%。
+                        （UDP 本身是通的：cloudflared 自检 PASS，
+                          握手成功时只要 1 秒。不是"运营商封了 UDP"。）
                         所以 quic 拨号成功率只有约 72%；但连上之后
                         它的丢包恢复好于 http2。
                         两个一起 = http2 兜住 quic 拨号失败的那部分，
@@ -169,19 +174,36 @@ fi
 #     quic 3 + h2 7     可用率  97%   中位 1271   P90 2558   P99 13934
 #     quic 8 + h2 2     可用率 100%   中位 1250   P90 1715   P99  2632  <- 采用
 #
-# 根因也查清了：**运营商对 UDP 有限制**。
-# 对 12 个 Cloudflare edge IP 探测：
-#     TCP:7844   12/12 可达
-#     UDP:7844    0/12 有回应
-# 所以 QUIC 的拨号成功率只有约 72%；但只要拨上了，
-# 它的丢包恢复明显好于 HTTP/2（QUIC 没有队头阻塞）。
+# 根因也查清了：**QUIC 握手对丢包敏感**。
+#
+#     QUIC   注册 525  失败 197  掉线 48   拨号成功率 72%
+#     HTTP/2 注册  13  失败   0  掉线  7   拨号成功率 100%
+#
+# QUIC 建连要 6+ 个包的往返，而 TCP 的 SYN 只有 3 个包、
+# 内核还会按 1s/2s/4s 激进重传。约 5.4%/包的丢包下：
+#
+#     (1 - 0.054)^6 ≈ 72%        <- 和实测的 72% 对得上
+#
+# ⚠ 注意：**这不是「运营商封了 UDP」。** 曾经这么以为过 ——
+#   但那个判断来自一个格式不对的手搓 UDP 探测包，
+#   Cloudflare 本来就不该回应它，"0/12 无回应"什么都证明不了。
+#   用 cloudflared --loglevel debug 实测真相是：
+#
+#     INF | UDP Connectivity  region1.v2.argotunnel.com  PASS
+#     INF | UDP Connectivity  region2.v2.argotunnel.com  PASS
+#     INF | SUMMARY: Environment is healthy ...
+#     INF Registered tunnel connection     （握手 1 秒）
+#
+#   UDP 是通的。QUIC 的弱点在「连不上」，不在「连上之后不好」——
+#   一旦连上，它没有 TCP 的跨流队头阻塞，反而更稳。
 #
 # 于是：单独用 QUIC，会有近三成的时候连不上；
 #       单独用 HTTP/2，队头阻塞在高丢包下会拖长尾延迟。
 #       两个一起跑，HTTP/2 正好兜住 QUIC 拨号失败的那部分 ——
 #       这就是**协议级故障隔离**，比在同一个协议上堆连接数有效得多。
 #
-# （早先这里写的是"两条同时跑会互相争抢"，那个结论是错的，已作废。）
+# （早先这里写的是"两条同时跑会互相争抢"，那个结论是错的，已作废。
+#   再早还写过"运营商封 UDP"，那个测量方法本身是错的，也作废。）
 MAIN_PROTO=quic
 MAIN_CONNS="${QUIC_CONNS:-8}"
 ALT_PROTO=http2