https://absx.pages.dev/assets/http_retry.html-w0dViy7V.js

1import{_ as t,e as a,f as s,o as r}from"./app-Qh4kDOoF.js";const n={};function i(o,e){return r(),a("div",null,e[0]||(e[0]=[s(`<h1 id="https-retry-测试" tabindex="-1"><a class="header-anchor" href="#https-retry-测试"><span>HTTPS retry 测试</span></a></h1><p>最近我司代理出公网质量下降得厉害，2%-20% 的 https 请求握手都会 tls eof（而且体感上首次建连爆炸的概率非常高），但是几次重试后往往可以成功（毕竟概率是乘算的）。这网络环境简直是一切开源闭源小玩具最严厉的父亲，只要是个会发 https 请求的玩意，一眼就能看出有没有做重试、报错行为和错误信息是啥。</p><p>于是在这里把我的日常测试都记录下来，嘲讽模式，启动！</p><h2 id="maaassistantarknights" tabindex="-1"><a class="header-anchor" href="#maaassistantarknights"><span>MaaAssistantArknights</span></a></h2><p>使用 MAA 挂机明日方舟时，无法自动更新软件本体，表现为点击「软件更新」，显示新版本下载失败。</p><p>查看日志，发现 GET api.maa.plus/MaaAssistantArknights/api/version/summary.json 下载有重试（实际上是 fallback 到 api2.maa.plus），而 https://github.com/MaaAssistantArknights/MaaRelease/releases/download/v6.16.5/MAAComponent-OTA-v6.16.4_v6.16.5-win-x64.zip 软件更新 zip 包下载没有重试，一次 fail 直接失败。</p><p>然后提了 issue 不久后就<a href="https://github.com/MaaAssistantArknights/MaaAssistantArknights/pull/17675" target="_blank" rel="noopener noreferrer">修了</a>，非常 nice。<s>果然还是国人最懂网络的苦</s></p><h2 id="rustup" tabindex="-1"><a class="header-anchor" href="#rustup"><span>rustup</span></a></h2><p>使用 cargo-msrv 找 MSRV 时（内部安装 toolchain 调用 rustup）获取到如下报错信息：</p><div class="language- line-numbers-mode" data-highlighter="shiki" data-ext="" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34;"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code><span class="line"><span>Unable to install toolchain &#39;1.74.0-x86_64-pc-windows-msvc&#39;, rustup reported:</span></span>
2<span class="line"><span>    info: syncing channel updates for 1.74.0-x86_64-pc-windows-msvc</span></span>
3<span class="line"><span>    error: could not download file from &#39;https://static.rust-lang.org/dist/channel-rust-1.74.0.toml.sha256&#39; to &#39;C:\\Users\\lxl\\.rustup\\tmp\\6ccizx52h6tfy891_file&#39;: error downloading file: error sending request for url (https://static.rust-lang.org/dist/channel-rust-1.74.0.toml.sha256): client error (Connect): tls handshake eof</span></span></code></pre><div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0;"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>显然 rustup 并没有做失败重试。</p><p>看了下 rustup 的重试机制只覆盖组件包下载，不覆盖 manifest / sha256 的下载。并且 rustup 只对 BrokenPartialFile 和 DownloadingFile 两种错误重试，tls handshake eof 根本不被包含在内，没有重试行为。</p><h2 id="topcoat" tabindex="-1"><a class="header-anchor" href="#topcoat"><span>topcoat</span></a></h2><p>我其实不用 tokio 出的这玩意，感觉也太玩具了点。只是 rust 群群友分享了下其 builtin tailwind support 源码，就点进去看了下。</p><p>它实现 tailwind support 的方式是……去 Github 下载一个 tailwindcss 的 binary😅。对你软的稳定性没点 b 数吗，要是 Github down 了我连程序都跑不起来。</p><p>扫了一眼代码，也就 <a href="https://github.com/tokio-rs/topcoat/blob/0c6d43fee8df66306754c67f72dc66b915de8dec/crates/topcoat-tailwind/src/build/executable.rs#L159" target="_blank" rel="noopener noreferrer">ureq 一发 download</a>，没有任何重试机制。这种玩具还是进垃圾桶吧。</p><h2 id="autocorrect" tabindex="-1"><a class="header-anchor" href="#autocorrect"><span>autocorrect</span></a></h2><p>执行 <code>autocorrect init</code>，下载无重试：</p><div class="language- line-numbers-mode" data-highlighter="shiki" data-ext="" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34;"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code><span class="line"><span>Fetching https://github.com/huacnlee/autocorrect/raw/main/.autocorrectrc.template</span></span>
4<span class="line"><span>Fetch config template error: </span></span>
5<span class="line"><span></span></span>
6<span class="line"><span>error sending request for url (https://github.com/huacnlee/autocorrect/raw/main/.autocorrectrc.template): error trying to connect: tls handshake eof</span></span></code></pre><div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0;"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>说实话我根本不懂这玩意去联网 init 的必要性是啥，每个 autocorrect 版本能解析的格式难道不是固定的吗？还有这玩意用 0 1 2 代表 off error warning，也是活久见了，感觉是 java 狗屎写多以后产生的幻觉。</p><h2 id="vscode" tabindex="-1"><a class="header-anchor" href="#vscode"><span>vscode</span></a></h2><p>我经常打开一个带有 <code>$schema</code> 的 json，看到 schema url 下面有一条黄线说 <code>无法从“https://json.schemastore.org/component-detection-manifest.json”加载架构: Client network socket disconnected before secure TLS connection was established。</code> 那我猜测十有八九 vscode 这货就是没有重试机制的了。</p><p>简单拉下 vscode 源码做个验证，vscode 拉 schema 用的 <a href="https://github.com/microsoft/node-request-light" target="_blank" rel="noopener noreferrer">node-request-light</a>，让我康康你的发育正不正常哟！果然没看到重试逻辑。request 调用方也没有做 error 重试，那么也基本确定这个问题真实存在了。</p><h2 id="dependi" tabindex="-1"><a class="header-anchor" href="#dependi"><span>Dependi</span></a></h2><p>这个机器上摸鱼，经常可以在 Cargo.toml 里看到每个依赖后面有三个大大的红色感叹号。不用看 Depen

6di 日志我都知道发生了啥事。</p><p>果然，日志内容：</p><div class="language- line-numbers-mode" data-highlighter="shiki" data-ext="" style="--shiki-light:#383A42;--shiki-dark:#abb2bf;--shiki-light-bg:#FAFAFA;--shiki-dark-bg:#282c34;"><pre class="shiki shiki-themes one-light one-dark-pro vp-code"><code><span class="line"><span>Error fetching versions for anyhow: Error: Client network socket disconnected before secure TLS connection was established</span></span></code></pre><div class="line-numbers" aria-hidden="true" style="counter-reset:line-number 0;"><div class="line-number"></div></div></div><p>并且每一个依赖都是全部失败，非常整齐，不知道怎么做到的。</p>`,28)]))}const c=t(n,[["render",i],["__file","http_retry.html.vue"]]),l=JSON.parse('{"path":"/gossip/http_retry.html","title":"HTTPS retry 测试","lang":"zh-CN","frontmatter":{"date":"2026-08-09T00:00:00.000Z","icon":"handshake-slash","category":["评价"],"tag":["测试"],"description":"HTTPS retry 测试 最近我司代理出公网质量下降得厉害，2%-20% 的 https 请求握手都会 tls eof（而且体感上首次建连爆炸的概率非常高），但是几次重试后往往可以成功（毕竟概率是乘算的）。这网络环境简直是一切开源闭源小玩具最严厉的父亲，只要是个会发 https 请求的玩意，一眼就能看出有没有做重试、报错行为和错误信息是啥。 于是在...","head":[["script",{"type":"application/ld+json"},"{\\"@context\\":\\"https://schema.org\\",\\"@type\\":\\"Article\\",\\"headline\\":\\"HTTPS retry 测试\\",\\"image\\":[\\"\\"],\\"datePublished\\":\\"2026-08-09T00:00:00.000Z\\",\\"dateModified\\":\\"2026-10-02T15:09:21.000Z\\",\\"author\\":[]}"],["meta",{"property":"og:url","content":"https://absx.pages.dev/gossip/http_retry.html"}],["meta",{"property":"og:site_name","content":"绝对值_x 的博客"}],["meta",{"property":"og:title","content":"HTTPS retry 测试"}],["meta",{"property":"og:description","content":"HTTPS retry 测试 最近我司代理出公网质量下降得厉害，2%-20% 的 https 请求握手都会 tls eof（而且体感上首次建连爆炸的概率非常高），但是几次重试后往往可以成功（毕竟概率是乘算的）。这网络环境简直是一切开源闭源小玩具最严厉的父亲，只要是个会发 https 请求的玩意，一眼就能看出有没有做重试、报错行为和错误信息是啥。 于是在..."}],["meta",{"property":"og:type","content":"article"}],["meta",{"property":"og:locale","content":"zh-CN"}],["meta",{"property":"og:updated_time","content":"2026-10-02T15:09:21.000Z"}],["meta",{"property":"article:tag","content":"测试"}],["meta",{"property":"article:published_time","content":"2026-08-09T00:00:00.000Z"}],["meta",{"property":"article:modified_time","content":"2026-10-02T15:09:21.000Z"}]]},"git":{"createdTime":1790953761000,"updatedTime":1790953761000,"contributors":[{"name":"lxl66566","username":"lxl66566","email":"[email protected]","commits":1,"url":"https://github.com/lxl66566"}]},"readingTime":{"minutes":2.97,"words":892},"filePathRelative":"gossip/http_retry.md","localizedDate":"2026å¹´8月9日","excerpt":"\\n","autoDesc":true}');export{c as comp,l as data};