@lslqtz 不需要 SNI 转发。这种域名固定的，直接转发到源站就行。多个域名才需要 SNI 转发。

@iqoo
"不会自签更节省" --> "不如自签更节省"
"随便解决" --> "顺便解决"

换了个输入法打出一堆错别字 - -

@jinliming2 防止主动探测确实不是好策略，只是想省点流量。。。

不过伪造源 IP 的方式倒有办法解决。后来用的是数据包敲门的方式加信任 IP ，敲门数据是用私有算法生成并且可防重放，随便解决同个公网 IP 下（比如公司其他人）也能访问服务器的缺陷。

@estk
@popzuk

shadowtls 出来之前就用试过类似的方案了，但反代会浪费流量。如果握手环节没破绽，不会自签更节省。

主动探测也是没用的，因为服务端只允许自己的 ip 访问。

@agagega 之前也发现这个配置，不过加上后 emcc 提示报错。网上搜到的 wasm32-unknown-emscripten 都是 rust 里的配置。

国内 CDN 基本都有坑，一不小心一晚一套房没了

@pursuer 循环里的指针被优化成了 64 。目前通过修改源码的方式暂时解决了。

@pursuer Memory64 是内存寻址扩展到 64 位，可以用 4G 以上的内存。寄存器一直都是 64 位的，这也是 wasm 比 asm.js 性能高的一个特点。

@PhaSelEza 遇到恶意刷流量的分分钟欠费。

@UIXX 这里省略了。因为 x_hi 小于 D ，所以模了之后还是本身。

@akira 最好是用几个 u64 简单算出来，毕竟除数的已知的。之前用 gcc 的 __u128_t 类型，展开后一大堆逻辑。

这点流量能省多少，普通的富强流量 1TB 十块钱都不到。

@tool2d http1 没问题。和机房关系不大，测试了多个机房，都存在这个现象。

只要客户端和服务端都是 nodejs 的 http2 ，它们之间可能就会降速。尝试让双方都增加窗口大小也没用。

其实国际上并没有 cc 攻击这个名词，只是国内约定俗成的叫法而已。本质上就是 L7/L4 DDOS 。L7 在应用层，自然可拿到 HTTP 头里的 host 字段。

g.zip

给诈骗网站做压力测试

ChatGPT：人工智能
文心一言：能治工人

密钥怎么协商，用固定的？ TLS 不是就是帮你协商密钥之后再 AES 了。

轻量云 + 免费 CDN