Skip to content

feat(domaintest): 域名连通性测试套件 + proxy-vs-直连报告, 验证 connect_timeout 5s 修复 - #21

Open
ccijunk wants to merge 5 commits into
mainfrom
feat/domaintest
Open

feat(domaintest): 域名连通性测试套件 + proxy-vs-直连报告, 验证 connect_timeout 5s 修复#21
ccijunk wants to merge 5 commits into
mainfrom
feat/domaintest

Conversation

@ccijunk

@ccijunk ccijunk commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

背景

Squid + BuildKit + metrics 整套 CI 缓存代理调研中,需要一份"白名单域名在真实 squid 路径下的连通性/Proxy-vs-直连"基线,用于支撑 deploy/chart 的配置决策(尤其 connect_timeout)。

本 PR 内容(新增 domaintest/ 调研套件)

文件 说明
ascend_ci_domains.json 92 条 CI 白名单实域名
test-domains.sh / test-domains-x20.sh / x20-remote.sh 域名连通性测试(20 轮),proxy 走 squid 3129
test-proxy-vs-direct-x20.sh Proxy vs 直连 对比测试(新增):三集群 × 92 域 × 20 轮 proxy + 20 轮直连,同 pod 同出口
REPORT.md / REPORT-x20.md 单集群/三集群连通性基线报告
REPORT-proxy-vs-direct.md Proxy vs 直连对比报告(修正版)

关键结论

  1. connect_timeout 5s 修复实测生效:多 IP 域(goproxy.cn gy-001 8/20→20/20、pytorch-package.obs wlcb 10/20→19/20、op-svc-swr 14/17→20/20)的系统性 proxy 劣化消失,剩余差值 ≤1 次(噪声)。
  2. 0 个"两路径全挂"(旧版 3~4 个):github.com gy-001 黑洞 0/20→20/20
  3. proxy 稳定性反超直连:repo.openeuler.org / data.pyg.org 等域直连偶发 DNS/超时,squid 路径反而 20/20。
  4. 方法学修正:旧版 proxy 误用 3128(registry-proxy nginx)而非 squid 3129,本版已用 squid-3129 全量重测;mirrors.ustc.edu.cn / 123.60.114.225 的 proxy 成功实为 squid 503 快速失败(已在报告中标注,非真实可达)。

测试方法

三集群(gy-001 / wlcb-001 / gy-002)squid-cache-0 pod 内 kubectl exec,curl -sk --max-time 6,proxy 用 127.0.0.1:3129(squid http_port 3129 ssl-bump),与直连同 pod 同出口对比。

- ascend_ci_domains.json: ascend CI 白名单 96 条
- test-domains.sh / test-domains-x20.sh / x20-remote.sh: 单次与 ×20 轮压测脚本(经 squid 代理, 采集域名解析 IP + 连通成功率)
- REPORT.md / REPORT-x20.md: wlcb(.49) vs gy-001(.37) 域名+IP+可达性报告, 含结构性不可达/间歇性域名/关键修正
4 组合(wlcb/gy-001 × 经squid proxy/直连)每域20轮, 92域全量。
核心: proxy 路径独有劣化(goproxy.cn gy-001 8/20、pytorch-package.obs
wlcb 10/20 等), 根因= squid 单IP固定/keep-alive半开复用/超时口径错配;
github.com gy-001 两路径0/20 为出口层间歇黑洞, 与 squid 无关。
对照 Squid 7.7 官方文档核实(线上实测 7.7.1):
- 根因1改写: squid 有顺序 failover(坏 IP 判死后换下一个), 并非"单IP固定";
  差距在 connect_timeout 2m 判死过慢, 赶不上 curl 6s 预算(合并原1+3为主因)
- 次因: positive_dns_ttl(默认6h上限)内坏 IP 被重复首选
- pconn 半开复用降级为存疑: 空闲由 pconn_timeout(默认1min)管而非 read_timeout,
  NAT idle 回收 <60s 才成立, 需 A/B 验证
- 修复建议勘误: connect_retries 不支持 acl 且管同连接重开(默认不重试);
  balance_on_multiple_ip 已在 Squid5+ 移除; connect_timeout 建议 3~5s 而非 15s;
  新增 forward_max_tries 说明
- 根因: pod 内 127.0.0.1:3128 是 registry-proxy(rpardini nginx), squid 监听 3129
  (http_port 3129 ssl-bump); CI 客户端经 Service 3128 被 DNAT 到 3129。
  旧版所有 x20/proxy-vs-direct 报告测的是 nginx 出口, 结论无效。
- 脚本: x20-remote.sh / test-domains.sh / test-domains-x20.sh 代理端口改为 3129,
  x20-remote.sh 增加端口说明注释。
- REPORT-x20.md: 重写为修正版, 新增三集群(gy-001/wlcb-001/gy-002)真实基线:
  92 域 0 个全挂, 9 个间歇(全为 CDN 多 IP 偶发抖动); 旧的 "mirrors.ustc/
  123.60.114.225/data.pyg.org/github.com 黑洞" 结论推翻。
- REPORT-proxy-vs-direct.md: 顶部加作废声明, 标注其 3128 分析不适用 squid 路径。
…5s 修复

- 新增 test-proxy-vs-direct-x20.sh: 三集群(gy-001/wlcb-001/gy-002) × 92 域 × 20 轮
  proxy(127.0.0.1:3129=squid) + 20 轮直连, 同 pod 同出口对比
- 重写 REPORT-proxy-vs-direct.md: 修正版取代作废的 nginx-3128 版
- 关键结论: connect_timeout 5s 消除系统性 proxy 劣化(goproxy.cn 8/20→20/20);
  0 个两路径全挂(github.com gy-001 黑洞恢复); proxy 稳定性反超直连;
  mirrors.ustc/123.60.114.225 为 squid 503 快速失败(已标注, 非真实可达)
@opensourceways-bot

Copy link
Copy Markdown

Welcome To opensourceways Community

Hey @ccijunk , thanks for your contribution to the community.

Bot Usage Manual

I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands.

Contact Guide

If you have any questions, please contact the SIG: infratructure ,
and any of the maintainers: @GeorgeCao-hw, @TangJia025, @pkking, @zhongjun2 ,
and any of the committers: @TommyLike, @ccijunk, @happyaron, @pkking .

@opensourceways-bot

Copy link
Copy Markdown

CLA Signature Pass

ccijunk, thanks for your pull request. All authors of the commits have signed the CLA. 👍

@opensourceways-bot

Copy link
Copy Markdown

Linking Issue Notice

@ccijunk , the pull request must be linked to at least one issue.
If an issue has already been linked, but the needs-issue label remains, you can remove the label by commenting /check-issue .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants