https://youtu.be/EMXnJMCoFYI
WSJ 在 2023-06 拍摄的揭露瓦格纳雇佣军团背景的纪录片。
我第一次见识瓦格纳是在乌克兰战场以俄军炮灰的身份出现，但其实在俄罗斯全面入侵乌克兰以前，瓦格纳一直在小心翼翼地和俄罗斯政府撇清关系。
虽然瓦格纳的背后完全是俄罗斯的政府资金和军火，但是瓦格纳明面上是一个完全私人的雇佣军集团，发家于叙利亚战争。它在叙利亚的运营模式是，帮助叙利亚的巴沙尔政府夺取油气田，然后从中获取 25% 的利润分成。这套模式让瓦格纳在叙利亚赚得盆满钵满，这些钱一部分用于维护自身运作，一部分进入普里戈金的腰包，还有相当大一部分回流回克林姆林宫。
在叙利亚还发生了一起小插曲，2018年2月瓦格纳军团进攻由美军支持的抵抗军油气田，美军询问俄军是否参与，被俄军否认后，美军出动空军全歼了这支瓦格纳军队，造成数百人死伤。(Battle of Khasham)
叙利亚模式让克林姆林宫尝到了甜头，于是开始在全球范围内推广这套模式，罪恶的魔爪遍及四大洲，前阵子九名中国工人在中非被杀就是出自瓦格纳之手。
然而乌克兰战争让瓦格纳从幕后走向了台前，和俄军的关系逐渐明朗化，部队组成也从精英战士向囚犯炮灰转变。
当专家们预言这代表着瓦格纳即将面临转型时，军事叛变发生了，不过这是发生在这部纪录片以后的事情了。
WSJ 在 2023-06 拍摄的揭露瓦格纳雇佣军团背景的纪录片。
我第一次见识瓦格纳是在乌克兰战场以俄军炮灰的身份出现，但其实在俄罗斯全面入侵乌克兰以前，瓦格纳一直在小心翼翼地和俄罗斯政府撇清关系。
虽然瓦格纳的背后完全是俄罗斯的政府资金和军火，但是瓦格纳明面上是一个完全私人的雇佣军集团，发家于叙利亚战争。它在叙利亚的运营模式是，帮助叙利亚的巴沙尔政府夺取油气田，然后从中获取 25% 的利润分成。这套模式让瓦格纳在叙利亚赚得盆满钵满，这些钱一部分用于维护自身运作，一部分进入普里戈金的腰包，还有相当大一部分回流回克林姆林宫。
在叙利亚还发生了一起小插曲，2018年2月瓦格纳军团进攻由美军支持的抵抗军油气田，美军询问俄军是否参与，被俄军否认后，美军出动空军全歼了这支瓦格纳军队，造成数百人死伤。(Battle of Khasham)
叙利亚模式让克林姆林宫尝到了甜头，于是开始在全球范围内推广这套模式，罪恶的魔爪遍及四大洲，前阵子九名中国工人在中非被杀就是出自瓦格纳之手。
然而乌克兰战争让瓦格纳从幕后走向了台前，和俄军的关系逐渐明朗化，部队组成也从精英战士向囚犯炮灰转变。
当专家们预言这代表着瓦格纳即将面临转型时，军事叛变发生了，不过这是发生在这部纪录片以后的事情了。
https://pkg.go.dev/crypto/ecdh #golang
Go 1.20 引入的这个 ECDH 包性能相当可以，比我之前用的第三方 DHKX 包快 80 倍😂。
Ps. DH 是密钥交换算法（Diffie-Hellman key agreement/exchange protocol），Alice 和 Bob 各自生成自己的公私钥对，并交换公钥。
然后各自用自己的私钥和对方的公钥可以计算出一个相同的共享密钥，这个密钥可以用来作为后续通信的对称密钥。
Go 1.20 引入的这个 ECDH 包性能相当可以，比我之前用的第三方 DHKX 包快 80 倍😂。
Ps. DH 是密钥交换算法（Diffie-Hellman key agreement/exchange protocol），Alice 和 Bob 各自生成自己的公私钥对，并交换公钥。
然后各自用自己的私钥和对方的公钥可以计算出一个相同的共享密钥，这个密钥可以用来作为后续通信的对称密钥。
前文提到过，HTTP/2 的分帧是不彻底的，仅仅是应用层 stream，而在传输层 TCP 看来仍然是一个 stream。HTTP/3 将 stream 拆分做到了传输层，在 UDP 层面就以 stream 为单位，声称解决了所有的 stream 间 HoLB 问题。
https://laisky.notion.site/HoL-Blocking-and-Priority-Inversion-LiteSpeed-Blog-4601095b01ed4f8d87bc3bc40ed665d7
很可惜现实是残酷的，其实 stream 间的阻塞也没解决。这次问题出在 QPACK: Field Compression for HTTP/3 上。
HTTP/1 时代，大量流量被浪费在重复传输 HTTP fields 上（如 HEADERS），所以从 HTTP/2 时代起，就引入了 HPACK 来压缩 HTTP fields。客户端和服务端各自维护一个 fields table，然后进行增量的更新。
在 HTTP/3 上保留了这个设计，并更名为 QPACK。但是 QPACK 的设计有个问题，它让 stream 间失去了独立，带来了依赖关系，而我们都知道，依赖关系会导致 HoLB。
具体来说，因为 QPACK 只传输增量更新，所以每一个 request/response 都需要指定一个
这就导致了一个很可怕的现象，一个高优先级的 stream，可能会因为缺乏必要的
更可怕的是，按照 RFC-9204 规定，当一个 stream 被
prev: https://t.me/laiskynotes/40
next: https://t.me/laiskynotes/62
https://laisky.notion.site/HoL-Blocking-and-Priority-Inversion-LiteSpeed-Blog-4601095b01ed4f8d87bc3bc40ed665d7
很可惜现实是残酷的，其实 stream 间的阻塞也没解决。这次问题出在 QPACK: Field Compression for HTTP/3 上。
HTTP/1 时代，大量流量被浪费在重复传输 HTTP fields 上（如 HEADERS），所以从 HTTP/2 时代起，就引入了 HPACK 来压缩 HTTP fields。客户端和服务端各自维护一个 fields table，然后进行增量的更新。
在 HTTP/3 上保留了这个设计，并更名为 QPACK。但是 QPACK 的设计有个问题，它让 stream 间失去了独立，带来了依赖关系，而我们都知道，依赖关系会导致 HoLB。
具体来说，因为 QPACK 只传输增量更新，所以每一个 request/response 都需要指定一个
REQUIRED INSERT COUNT，表示这个 request/response 至少依赖于哪一个版本的 fields table 的更新。而 HTTP/3 的 fields 更新是以 HEADER 的形式和 DATA 一起传输的（gQUIC 原始设计中独立的 HEADER stream 被 IETF/QUIC 取消了），换言之，fields 的更新属于某一个 data stream。而这个 data stream 的优先级，是由 data 而不是 header 决定的。这就导致了一个很可怕的现象，一个高优先级的 stream，可能会因为缺乏必要的
REQUIRED INSERT COUNT 而被另一个携带 fields 更新的低优先级 stream 阻塞。更可怕的是，按照 RFC-9204 规定，当一个 stream 被
REQUIRED INSERT COUNT 阻塞时，接收方应该一直缓存这个 stream 直到 REQUIRED INSERT COUNT 满足为止。如前文所述，如果是高优先级的 stream 被低优先级的 stream 阻塞，那么接收方必须很傻地接受完全部高优先级数据后，才能继续处理低优先级的数据。而高优先级的数据就只能躺在缓存里傻等低优先级的增量更新完成后，才能被处理。prev: https://t.me/laiskynotes/40
next: https://t.me/laiskynotes/62
Laisky on Notion
HoL Blocking and Priority Inversion in QUIC | Notion
Background
https://github.com/Laisky/sdxl-turbo/blob/main/app.py
顺手分享下，我目前在用的，在 windows 电脑上跑一个支持 txt-to-image 和 image-to-image 的 sdxl-turbo 服务端。接口通过 tailscale 接入到公网的网关上对外服务。
用 windows 是因为我只有一张破显卡，然后这破显卡是接入到 win 上打游戏的（虽然根本没时间玩游戏，唉）。
我这 3060 的破显卡文生图大约 3s，图生图小于 1s，AI 走进千家万户真不是梦。
Ps. 集成进 https://chat.laisky.com/ 了，free
顺手分享下，我目前在用的，在 windows 电脑上跑一个支持 txt-to-image 和 image-to-image 的 sdxl-turbo 服务端。接口通过 tailscale 接入到公网的网关上对外服务。
用 windows 是因为我只有一张破显卡，然后这破显卡是接入到 win 上打游戏的（虽然根本没时间玩游戏，唉）。
我这 3060 的破显卡文生图大约 3s，图生图小于 1s，AI 走进千家万户真不是梦。
Ps. 集成进 https://chat.laisky.com/ 了，free
昨天那篇文章介绍了 QUIC 并不一定更快。这篇文章则更犀利地指出，QUIC 不仅不快，简直慢得要命😂。
原生 QUIC 的吞吐只有 TCP 的 27.7%，只有 TCP+TLS 的 42.5%。
https://laisky.notion.site/QUIC-vs-TCP-Which-is-Better-ad3bcd403c2340038a6d761fe70b1984
而从优化的思路可以看出导致 QUIC 慢的主要原因：逐包 ACK、逐包加密、用户态处理导致的额外切换开销。
而优化方式也是对症下药，延迟 ACK、批量处理、增加包大小，最终能够实现和 TCP+TLS 相媲美的吞吐。
（精心优化的 QUIC 也仅仅是和 TLS 一样快而已…）
prev: https://t.me/laiskynotes/34
next: https://t.me/laiskynotes/42
原生 QUIC 的吞吐只有 TCP 的 27.7%，只有 TCP+TLS 的 42.5%。
https://laisky.notion.site/QUIC-vs-TCP-Which-is-Better-ad3bcd403c2340038a6d761fe70b1984
而从优化的思路可以看出导致 QUIC 慢的主要原因：逐包 ACK、逐包加密、用户态处理导致的额外切换开销。
而优化方式也是对症下药，延迟 ACK、批量处理、增加包大小，最终能够实现和 TCP+TLS 相媲美的吞吐。
（精心优化的 QUIC 也仅仅是和 TLS 一样快而已…）
prev: https://t.me/laiskynotes/34
next: https://t.me/laiskynotes/42
读完一套非常棒的丛书《美国的故事》，从 1517 年马丁·路德的宗教改革说起，发生在欧洲的宗教改革运动和英国的改朝换代，最终促使了一批新教徒选择了走向新大陆的漫长征程。一直写到 1836 年最后一位建国国父麦迪逊去世。
读完后感慨万千，成功的人背后都是一系列的机遇，强大的国家的历史上也必然是一个个的奇迹，美国这个国家真的是深受上帝的庇佑。位高权重的华盛顿没有成为拿破仑或克伦威尔，而是激流勇退，避免美国从共和走向帝国。聪明绝伦的汉密尔顿没有成为他所崇拜的凯撒，而是在设计了现代国家的蓝图后就离开了政坛。充满不切实际幻想的杰斐逊还没能让这个国家彻底落入旧时代的深渊，反而在精英共和中融入了民主。第二次美英战争让现实主义的麦迪逊从杰斐逊传人摇身一变成了最坚定的汉密尔顿主义者，为美国的重商主义和工业化奠定了基础。老奸巨猾的马歇尔在夹缝中求发展，成就了强大而且独立的司法权。 #book
next: https://t.me/laiskynotes/270
读完后感慨万千，成功的人背后都是一系列的机遇，强大的国家的历史上也必然是一个个的奇迹，美国这个国家真的是深受上帝的庇佑。位高权重的华盛顿没有成为拿破仑或克伦威尔，而是激流勇退，避免美国从共和走向帝国。聪明绝伦的汉密尔顿没有成为他所崇拜的凯撒，而是在设计了现代国家的蓝图后就离开了政坛。充满不切实际幻想的杰斐逊还没能让这个国家彻底落入旧时代的深渊，反而在精英共和中融入了民主。第二次美英战争让现实主义的麦迪逊从杰斐逊传人摇身一变成了最坚定的汉密尔顿主义者，为美国的重商主义和工业化奠定了基础。老奸巨猾的马歇尔在夹缝中求发展，成就了强大而且独立的司法权。 #book
next: https://t.me/laiskynotes/270
https://youtu.be/gvAyykRvPBo 看了部纪录片，记者在俄乌战争开战前来到 Mariupol，并在围城中坚守二十天，记录下了战争中平民的恐惧与苦难。唉，又想起富兰克林的那句话
There never was a good war or a bad peace
There never was a good war or a bad peace
这张图我忍不住想单独拎出来分享下。
作者屡次强调，在网络上传输文件，串行往往比多路复用更快。
而且，即使多路复用号称可以预防 HOL，但是因为常见的丢包模式是低频而且集中的，所以其实多路复用反而可能受丢包的影响更为严重。
因为一个短暂时间的丢包，在多路复用的连接上，可能会干扰更多的 stream，
并导致这些 stream 全部面临队首阻塞。而预防 HOL 最核心的思想，就是尽可能地让丢包影响的数据（stream）越少越好。
顺带一提，HTTP/3 并没有完全避免队首阻塞，而是化解了 stream 间的队首阻塞。stream 内部仍然需要分包，仍然有队首阻塞。和 HTTP/2 的一个重要区别就是，HTTP/2 的 stream 是应用层，而 HTTP/3 的 stream 是传输层。
prev: https://t.me/laiskynotes/33
next: https://t.me/laiskynotes/40
作者屡次强调，在网络上传输文件，串行往往比多路复用更快。
而且，即使多路复用号称可以预防 HOL，但是因为常见的丢包模式是低频而且集中的，所以其实多路复用反而可能受丢包的影响更为严重。
因为一个短暂时间的丢包，在多路复用的连接上，可能会干扰更多的 stream，
并导致这些 stream 全部面临队首阻塞。而预防 HOL 最核心的思想，就是尽可能地让丢包影响的数据（stream）越少越好。
顺带一提，HTTP/3 并没有完全避免队首阻塞，而是化解了 stream 间的队首阻塞。stream 内部仍然需要分包，仍然有队首阻塞。和 HTTP/2 的一个重要区别就是，HTTP/2 的 stream 是应用层，而 HTTP/3 的 stream 是传输层。
prev: https://t.me/laiskynotes/33
next: https://t.me/laiskynotes/40
https://laisky.notion.site/Head-of-Line-Blocking-in-QUIC-and-HTTP-3-The-Details-2039eb7574b649f785d9c8c70e3ec433
终于看完了这篇万字长文，可以称其为“关于队首阻塞的一切”。
作者细致探讨了队首阻塞（HOL Blocking）的相关话题，详述了 TCP、TLS、HTTP/1、HTTP/2、HTTP/3 HOL 的差异和权衡。
HTTP/2 和 HTTP/3 不一定更快，多路复用不一定好。一切的目的都是减少丢包的影响范围，但是丢包模式是无法预测的，这让事情变得很复杂。多路复用的核心优点不是快，而是优先级调度。
HTTP 的性能优劣是一个极其复杂的问题，很难说哪个方案很好。
HTTP/3 很大程度上是一个开放而且富有生命力的协议，它的重点并不是快，
事实上 HTTP/3 性能的很大程度上得益于 UDP 的 0-RTT，而不是多路复用。
但是多路复用开启了很大的想象力空间，包括优先级抢占、Server Push 103 Early-Hints 等等。
连接是我的 notion 笔记，我做了细致的链接和注释。
next: https://t.me/laiskynotes/34
终于看完了这篇万字长文，可以称其为“关于队首阻塞的一切”。
作者细致探讨了队首阻塞（HOL Blocking）的相关话题，详述了 TCP、TLS、HTTP/1、HTTP/2、HTTP/3 HOL 的差异和权衡。
HTTP/2 和 HTTP/3 不一定更快，多路复用不一定好。一切的目的都是减少丢包的影响范围，但是丢包模式是无法预测的，这让事情变得很复杂。多路复用的核心优点不是快，而是优先级调度。
HTTP 的性能优劣是一个极其复杂的问题，很难说哪个方案很好。
HTTP/3 很大程度上是一个开放而且富有生命力的协议，它的重点并不是快，
事实上 HTTP/3 性能的很大程度上得益于 UDP 的 0-RTT，而不是多路复用。
但是多路复用开启了很大的想象力空间，包括优先级抢占、Server Push 103 Early-Hints 等等。
连接是我的 notion 笔记，我做了细致的链接和注释。
next: https://t.me/laiskynotes/34
Laisky on Notion
Head-of-Line Blocking in QUIC and HTTP/3: The Details | Notion
TL;DR
今天躺床上玩了会儿手机画图的时候发现自己干了几件蠢事，首先是刚发现 img-to-img 模型忘了对免费用户解除限流😓。另外就是画图的时候一直报错
另外一个问题是，我这个破显卡（3060）在并行推理的时候会出现马赛克花纹图，暂时没空调研，如果遇到了重试就好。（出一张图的平均耗时是 0.9s，冲突的概率不是特别大）。
ps. 我还遇到一次显卡跑挂了（maybe），表现为显示器点不亮，远程桌面也连不上，但是没有图形的命令行能连上。重启后恢复。
quota exceeded，搜了一下发现 local storage 默认就 10mb，我把原图以 base64 保存在本地很容易就超了（之前在 PC 上玩了那么久都没遇到，可能是因为 ios 的切图特别大）。刚才改了一版，把历史记录都存到 pouchdb（indexeddb）了。另外一个问题是，我这个破显卡（3060）在并行推理的时候会出现马赛克花纹图，暂时没空调研，如果遇到了重试就好。（出一张图的平均耗时是 0.9s，冲突的概率不是特别大）。
ps. 我还遇到一次显卡跑挂了（maybe），表现为显示器点不亮，远程桌面也连不上，但是没有图形的命令行能连上。重启后恢复。
昨晚没忍住又改了一版，img-to-img 模型现在一次可以出两张图，这可能才是“正确玩法”，原图不要有太复杂的背景，然后简单描述后重绘，效果相当好。（ps, 没有内容过滤器，注意身体）。好了，搬砖干活去了。
ps: 原图仅保存在本地，不用担心隐私。但是 AI 生成的图会存在我的 s3。
ps. 注意图片的长宽比，只接收正方形的图片，所以如果你的图太长，实际上只读取了头部。
next: https://t.me/laiskynotes/32
ps: 原图仅保存在本地，不用担心隐私。但是 AI 生成的图会存在我的 s3。
ps. 注意图片的长宽比，只接收正方形的图片，所以如果你的图太长，实际上只读取了头部。
next: https://t.me/laiskynotes/32
顺手集成到 https://chat.laisky.com/ 了，选 img-to-img 可玩，效果一般，主要就是快（目前免费，反正只花我点电费）。等改天有空看看没有用其他模型可以换换。