踩了个小坑，我有一台廉价的 storage VPS，系统是 ubuntu 16.04 + 2.6.32。这台机器上我跑了一个 minio + nginx + tailscale 当 s3 用。配置非常差，我一般懒得登上去。然后我家里的台式机上也有一个 minio 作为 replica，这个 minio 我经常升级。两个 minio 的版本就越差越远。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
然后昨天晚上，线上的 minio 因为鉴权不兼容，在 sync 的时候居然挂了。我登上去手动更新了一下可执行文件即可。
借此机会想抒发几个感慨：
1. storage vps 除了硬盘大没其他优点，除了跑 s3 没其他用处。廉价 VPS 我也买过不少了，之所以便宜都是因为有大坑，😮💨。
2. Go 的静态编译真香，这破机器上我就只能跑得起来 Go 的程序。
这系列的后续两篇文章描述的都是同样的 QUIC HoLB 问题，即对 http fields table 更新的依赖所导致的 HoLB。
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
* https://laisky.notion.site/HoL-Blocking-Allows-Attacks-in-QUIC-52f6f3876b5943b0ae257d56c70d0549
* https://laisky.notion.site/HoL-Blocking-and-the-Deadlock-Hazard-in-QUIC-614658fee16e4c23b276c98e7300d4b0
但是更进一步介绍了可能带来的风险：
1. 单 stream 死锁风险：某个 stream 可能会依赖该 stream 后续的 header 更新
2. 多 stream 死锁风险：当接收端的 flow control window 被塞满，header 更新可能无法送达，导致死锁
3. DoS 攻击：攻击者伪造一个请求，该请求依赖一个不存在的 fields table 版本。
prev: https://t.me/laiskynotes/42
next: https://t.me/laiskynotes/84
Laisky on Notion
HoL Blocking Allows Attacks in QUIC | Notion
Protocol designers underestimate how badly people will implement their designs.
https://arxiv.org/pdf/2311.00871.pdf 这篇论文指出，大模型（LLM）对上下文的理解能力（ICL）不是一种通用的泛化能力，而是对预训练数据的检索能力。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。
用通俗的话说就是，不是一个智能理解了你的问题，而是它从数据集里搜索到了关联数据。
我现在愈发认为 LLM 只是一种高效的信息压缩算法，它的特色在于解压的效果也依赖于输入（prompt）。而 ICL 其实类似于心理学的“锚定效应”，所谓的 prompt engineering 只是在试图让 LLM 的答复锚定到更高质量的预训练数据集上。
至于能不能通向 AGI，对既有方法的灵活运用也是能够导向创新的，但是目前 LLM 的问题在于知识质量鱼龙混杂，需要人类高效 prompt 才能引出高效的答复，这可能预示着它只能扮演一个 copilot 角色，而且它的能力和人类搭档的能力是成正比的。
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