亲啊嘴金，发布于：2024-12-26T20:51:06 | 0 浏览
原来这个就是HTTP3的用途嗷！
[之前研究到](jottings.php?artid=178)，外网访客1份请求，可以WebApp后端多节点，多份、多次返回。有可能是大文件，视频帧等。
当时自己研究已经成功了，用 http2 over quic，外网访问网关机的时候，多开TCP去请求后端，然后网关机把后端发来的包 慢慢的 【merge】 ，
分发给外网访客。虽然满足需求，但是性能和各种奇怪问题伴随而生。而且标题很明显了，
不能算是纯血quic，更加不是纯血Udp，而且网关机发给访客的时候，访客断了，网关机之前做的就白费了。
再之前的例子中就是怎么弄都可能存在“重放攻击”，即便以热情待客的伺服器的心态容许所有的“重放”。
也依然存在着对“重放的误判”，就是明明他就是之前的，又得重新发头包。
接着就是，今天准备整HTTP3的，看了下完整的HTTP3协议。。然后热泪盈眶，这不就是我之前的所有需求的实现么。
- HTTP3 什么断线继续
- 纯靠Udp ID识别标记你
- 以及Udp的随时发包特性。。
当然啦，依然有“重放攻击”这个可能性。还有运营商的UDP，QOS。。这些并不关HTTP3协议本身的事！
再接着就是 支持HTTP3的 应用基本没得选，比如 嗯姬，砍蒂啥的，但是我又不想用嗯姬，因为想跟ru软件创始人割席，我知道嗯姬的商业版不是ru的了，但是还是不想用。
至于为什么也不想用Caddy 的原因就是 Caddy 他也有商业版的版本，既然商业版了，为什么不买一个成熟的 LiteSpeed ？但是LiteSpeed又太贵了，又买不起。
就是这么挑三拣四。。