@daisyfloor tun 走 v4 了吧

@allplay 有 GPG 签名的

@hefish 据说得配置一下鉴权，被扫到也没事

理论上海外域名不应该解析，直接落地机器处理，速度会快很多。平时用阿里云那个 DoH 就行（不过也有被投毒的说法了）。

直接让 DoH 走代理得了，需要注意，最好是支持 EDNS 的，否则服务器境内境外解析不一样的解析到海外地址很蛋疼，不如直接代理了。Cloudflare 的不支持。

acme.sh 主要是重复签发，很多台机器都要来一遍好麻烦，功能性非常好了，算是事实上的标准之一？

不知道有没有开源的单机部署然后把证书文件推送到其他机器的方案，然后自动触发服务重载。

可以看看我的总结，和牢 B 的 PCDN 斗争久了经验还是有的

https://github.com/the1812/Bilibili-Evolved/issues/3234#issuecomment-1504764774

目前根据 bench 结果:

```
Gnuplot not found, using plotters backend
Anyhow/anyhow/v1.0.76 time: [46.255 ns 50.158 ns 54.338 ns]
change: [-3.3466% +7.6940% +20.010%] (p = 0.18 > 0.05)
No change in performance detected.
Found 5 outliers among 100 measurements (5.00%)
3 (3.00%) high mild
2 (2.00%) high severe
Anyhow/anyhow/v1.0.90 time: [48.072 ns 56.167 ns 63.721 ns]
change: [-29.746% +34.093% +175.67%] (p = 0.69 > 0.05)
No change in performance detected.
Found 16 outliers among 100 measurements (16.00%)
11 (11.00%) high mild
5 (5.00%) high severe
```

但是我的测试环境发生变动: AMD AI9 HX370, 7500MT LPDDR5.

```
rustc 1.84.0-nightly (e7c0d2750 2024-10-15)
binary: rustc
commit-hash: e7c0d2750726c1f08b1de6956248ec78c4a97af6
commit-date: 2024-10-15
host: x86_64-pc-windows-msvc
release: 1.84.0-nightly
LLVM version: 19.1.1
```

测试代码:

```rust
use criterion::{criterion_group, criterion_main, BatchSize, Criterion};

fn bench_maps(c: &mut Criterion) {
let mut group = c.benchmark_group("Anyhow");

group.bench_function("anyhow/v1.0.76", |b| {
b.iter_batched(
|| anyhow_1_0_76::anyhow!("test error"),
|e| {
criterion::black_box({
let _ = e;
});
},
BatchSize::SmallInput,
)
});

group.bench_function("anyhow/v1.0.90", |b| {
b.iter_batched(
|| anyhow_1_0_90::anyhow!("test error"),
|e| {
criterion::black_box({
let _ = e;
});
},
BatchSize::SmallInput,
)
});
}

criterion_group!(benches, bench_maps);
criterion_main!(benches);
```

切换至当前 stable rust 测试:

```
rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-pc-windows-msvc
release: 1.81.0
LLVM version: 18.1.7
```

```
Running benches/anyhow.rs (target\release\deps\anyhow-e035dda9f6eff98f.exe)
Gnuplot not found, using plotters backend
Anyhow/anyhow/v1.0.76 time: [7.3229 ns 7.5644 ns 7.9092 ns]
change: [-5.8063% -1.9072% +1.6252%] (p = 0.33 > 0.05)
No change in performance detected.
Found 7 outliers among 100 measurements (7.00%)
3 (3.00%) high mild
4 (4.00%) high severe
Anyhow/anyhow/v1.0.90 time: [46.830 ns 53.064 ns 59.741 ns]
change: [-16.795% -3.3065% +13.223%] (p = 0.68 > 0.05)
No change in performance detected.
Found 6 outliers among 100 measurements (6.00%)
3 (3.00%) high mild
3 (3.00%) high severe
```

emmm, 奇怪的结果.

说白了要不是大小核谁升级 Windows 11, 用 Windows 不还是因为蛮多专业软件只有 Windows 版本, 游戏也是... 所以求稳才是第一.

卧槽, 分分钟被取消备案, 国内机器搭 DNS 是违法的我记得

想趟浑水就买, 最多买点短期的.

楼上有说屏蔽 MCDN 的, 实测会导致更加卡顿, 因为得等播放器 fallback 到备用地址.

一个相对有效的解决方案是: 有软路由的话直接 ban 掉 HTTP DNS, 没有就只能安装 AdGuard 一类的软件本地拦截, 同时 api.bilibili.com / app.bilibili.com / *.biliapi.net / *.biliapi.com 仅解析 IPv6(遇到 CNAME 是 *.bilicdn.* 这种自建机房可能没 IPv6 的就麻烦了), 拿到的资源连接大多数就是 mirror 型的 CDN, 也就是大厂提供的 CDN 了.

至于代码层面的限速, 等人开发个模块吧.

B 的技术向来垃圾, 现在还搞降本增笑, AV1 的码率都压得面目全非了, 还会卡顿, 只能说褒姒.

B 站 APP 端的 ijkplayer 明确是有限速相关代码的, 可以用模块的方式干掉(? 但是目前似乎没有, 似乎是 native 层级别的限制).

此外, B 站大量运用了 MCDN / BCache CDN / PCDN, MCDN (mcdn.bilivideo.*) 和 PCDN (纯 IP 没域名那种, 或者迅雷那个 sy 什么什么的, 南方沿海见得多一点) 众所周知的质量相当差, BCache CDN 作为 B 自建的 VOD CDN, 速度各个地区差异蛮大, 有些地方机房带宽便宜速度就好.

以上是我给一个模块开发替换视频 UPOS 功能时的总结.

@Ocean810975 同意. 我个人不是科班出身, 拿 Rust 入的门, 然后因为参与维护了一个安卓项目, 从学习大佬的代码开始学会了 Kotlin, 后面才补课的 C, 现在因为自己的小项目用到略接触到 Go. Python, JavaScript or TypeScript 也会写一点. 我会的这些语言里面最擅长也最喜欢的就是 Rust, 其次是 Kotlin.

记得 This Week in Rust 分享了一篇文章关于如何加速编译的, 我试用后感受明显, 虽然最有用的那个把 linker 改成 Mold 只支持 Linux 平台, 改 codegen backend 为 cranelift 不支持 WoA(这个影响也不大), 不支持 SIMD, 不支持 unwinding on panics(这个影响蛮大, 不过可以单开个 build 配置继承 release 配置, 把 debug 打开啥的, 专用于测试版本构建). po 个链接供参考: https://blog.rust.careers/post/compile_rust_faster/

@shakoon IE 4 的机器, emmm 现在绝大部分网站都不支持 SSLv3 了吧

@RTSmile 毕竟是 std 的问题, 修复蛮麻烦的.

benchmark 一下就能看出来, 我原来还不信的.

最简单的复现代码, 虽然不够严谨. 严谨点得用 benchmark, 或者上火焰图看看什么情况, 我对为什么慢不感兴趣所以没弄.

```rust
fn main() {
let mut result = Vec::with_capacity(20);

for _ in 0..20 {
let now = Instant::now();

for _ in 0..10000 {
let _ = anyhow::anyhow!("test error");
}

result.push(now.elapsed().as_nanos());
}

let avg = result.iter().sum::<u128>() as f64 / 20f64 / 1000f64;

println!("avg cost: {}s", avg);
}
```

反正我现在是遵照一位大佬的建议锁 1.0.76 这最后一个正常的版本, 然后所有依赖 anyhow 的库也基本会对齐依赖版本. 还在观察中, 后天有空看看 nightly 版本下的情况.

对于此问题, 修复方法推荐强制指定 anyhow 版本到 =1.0.76

测试环境:
rustc 1.78.0 (9b00956e5 2024-04-29), PTLin 给出的代码

Linux 平台仍然观察到了明显性能折损, profile.release 下, 使用 =1.0.86 版本的 anyhow 比 =1.0.76 版本的 anyhow 慢了 2 倍有余(default-feature = true 下)... 相当恐怖...

btw, 个人有个 gRPC server 的项目, 观察到 prost 间接依赖了 anyhow, 只能说但凡涉及 gRPC 的几乎全都会受影响, 毕竟 prost 的影响力蛮大的...

bbtw, 得 anyhow = { version = "=1.0.70" } 这样才能强制指定版本.

29 的 2020 芝麻卡套餐其实还行, 5~7GB 可结转通用和 30GB 定向, 如果平时大流量需求在定向范围这个很合适, 就是不知道现在能不能办(应该不可以了除非投诉), 或者有没有类似物.

@securityCoding 毕竟写 c++ 的心智耗费蛮大的, 特别是所谓 modern c++.

贴个偶然间看到的 issuecomment 片段, 阐述了为什么 SRS 坚持使用 c++98, ref: https://github.com/ossrs/srs/issues/1191#issuecomment-917324341

```
No, I still firmly believe that if we can use C++98, we should definitely not use C++11. The more complex language features we use, the smaller the target audience of developers becomes. Even the senior brother finds C++98 too complicated, let alone C++11. I hope all C programmers can easily modify the code of SRS.
```