@orangie 我也一样。直到和美国人工作才发现他们读库伯奶提斯，感到很奇怪

@skyworker 你遇到的是 Let's Encrypt OCSP 地址被墙，但这不是因为“免费”造成的。

1. 相当于保险。出现 SSL 相关漏洞造成损失，CA 有责任赔付
2. OV/EV 有信任加成
3. 有效期更长，减少运维成本（以前还可以长达三年五年，现在最多只能 1 年了）
4. （从采购视角）证书利润较高，相应的返点也比较高，花公司的钱鼓自己的腰包，何乐而不为
5. 有些特殊用途的证书目前只能花钱买，比如代码签名

我的认知是, c 语言很简单, 甚至是难度相当低, 原因为以下几点

c 语言几乎很少迭代, 语法很少变化, 你不学习, 也可能看懂 20 年后的代码
一些所谓复杂的语法, 后面其实包含非常简单的原理, 比如各种复杂声明语法, 背后无非都是指针那一套。不过有时候虽然了解原理你也根本写不出来那些 ugly 但又非常高效的代码。
c 库一点都不庞大, 标准库就那点函数，这年头也没多少新的第三方库，绝大多数人可以说 90%模块都用过
c 使用范围很窄, 基本上只用在那些历史悠久的基础软件上

https://i.imgur.com/agAJ0Rd.png

unix 时间戳是最不容易出错的，不用考虑夏令时，不用考虑闰秒，不用考虑特殊时间点（比如这个 https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-epoch-milli-times-in-year-1927-giving-a-strange-r ）

几十年来，web 一直都不是最优秀的 GUI 技术，但却是生命力最强的。

如果设定了 500M 上行，brutal 算法就会按照最低 500M 速度发包。brutal 算法检测到丢包时，会最高补偿到 1.25 倍的发包速率。因为 500M 上行远超你的上行带宽，所以严重丢包，于是 brutal 又补偿到按照 600M 速度发包。
大量丢包造成的重传可能又让上行流量放大数倍。

我觉得从运营商看，这个流量特征更像是 DDOS 而不是 PCDN 。不过我从来没听说过运营商会因为 DDOS 而局停。

4/5 优先。但是要吃满多核 cpu 需要前面有 gateway lb
所以有时候还用 pm2 cluster mode ，简单

https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension
部分 app 用了 notification service extension ，收到推送后会自己再从自己服务器拉取信息。

放几年前根本想不到干掉美团的是抖音，干掉阿里的是拼多多

文件在，不代表未发生 bit flip 。只有用带校验的文件系统，校验一遍才能知道。

我有台闲置了 5 年多没开机的笔记本电脑，系统盘是 SSD 。当初闲置时是全新安装的 Windows 10 系统。过了五年后尝试开机，开机过程中 BSOD 蓝屏。然后我重新安装了一次系统就好了。我高度怀疑是 SSD 里的数据变质了

别说国内云，就算 AWS 的 Amazon Linux 都是尽量不用的。

我试过 Safari 在 b 站如果播放 av1 ，也能硬解。但是 b 站不前不给 Safari UA 下发 av1 码流。

@hackpro 你看错了吧，我截图是 chrome 上吃不到 av1 硬解，cpu 占用很高。safari 支持 av1 硬解，cpu 占用很低。

M3 Max
用这个视频测试 8K 60FPS
https://www.youtube.com/watch?v=zCLOJ9j1k2Y

Chrome: CPU 占用 45% 左右，编码为 av01.0.17M.08 ，感觉没有启用硬解
Safari: CPU 占用无明显提升，编码确认也是 av1

但是 Safari 只出现过一次 8K 60FPS 选项，后来我刷新网页后就没了，变成了 4K 60FPS vp9

端口转发方案优于 VPN 组网方案。因为 VPN 组网底层都是 UDP ，我自己观察家宽的 UDP 质量是不如 TCP 的。

@icy37785 他说的可能是对的。

众所周知，要能够作为网关，内核层面必须开启 ip forwarding 能力。很显然 iOS 并没有开启，所以无法用 iphone/ipad 作为网关实现给局域网透明代理。

但是为什么 tvOS 破天荒却能够作为网关呢？这不符合苹果对系统限制的一贯作风。
原因正是因为 homekit 。苹果为了让 Apple TV / HomePod 能够作为 Thread Border Router 把家庭的 Thread 设备中继到局域网，在内核为 Apple TV / HomePod 开启了 ip forwarding 能力（ Thread 上层运行的是 IPv6 协议）。碰巧，开启 ip forwarding 之后，VPN 软件就能处理和转发经过设备的一切流量了。

但是家里有多个 Apple TV / HomePod 时，会随机协商一个设备作为中枢。但 tvOS 的实现是只在作为中枢时开启 ip forwarding 能力，如果不是中枢了，那么 ip forwarding 功能就会关闭。于是出现了 /t/976916 的问题，当 HomePod 成为中枢后，Apple TV 的 ip forwarding 功能失效，于是无法再作为网关处理流量。

大多数人不会同时拥有 HomePod 和 Apple TV 。只有一个 Apple TV 时，中枢只能是这台 Apple TV ，所以不会遇到问题。

---

题外话，如果家里接入了 Thread 设备后，Thread Border Router （比如 Apple TV / HomePod ）会通过 DHCPv6 PD 向上级路由器申请新的 IPv6 前缀，为每一个接入的设备分配 IPv6 地址，并路由 IPv6 流量。
我观察到，当运营商给自己家里分配了 /56 前缀后，每个 Apple TV/HomePod 会向家里路由器再申请个 /60 前缀，为底下的 Thread 设备分配地址。这意味着家里每一个通过 Thread 接入的设备，都会拥有全球可路由的公网 IPv6 地址，非常神奇。我尝试过关闭路由器防火墙后，Thread 设备的 IPv6 地址真的能从外网 ping 通。