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 可玩，效果一般，主要就是快（目前免费，反正只花我点电费）。等改天有空看看没有用其他模型可以换换。
GPT-4-turbo 的性能对比，在上下文小于 64K 时几乎完全准确。长度超过 64K 后准确性也远远超过 claude-2.1。而且 gpt-4-turbo 还便宜，太强了！
作者花了一千刀帮我们测试了 LLM 模型大上下文性能，使用 LLM 的最佳输入长度是小于 20K tokens，重要内容放于首尾，尾部比头部稍好。否则准确率会大幅降低。那些所谓的超大上下文模型都是以牺牲准确率为代价的。 https://x.com/gregkamradt/status/1727018183608193393
一个小推广：我有个供小范围朋友使用的 GPT 套皮站，在 API 基础上做了一些增强，比如基于网址的实时抓取、上传数据文本，E2E 加密的自定义 chatbot 等等。支持 gpt-3（免费）、gpt-4、gpt-4-vision、dall-e-3 等 openai 的全部主流模型。主要是面向受制于网络和支付，不方便用官方 openai 的人。gpt-3-turbo 免费，其他模型可以预付费后按需计费（官方价），计费是基于魔改后的 one-api，可以自己上后台查余额和使用日志（也可以输入自己的 openai token 直接使用）。这是个非商业项目，只是小圈子内自用，解决普通人的技术障碍。而且我觉得用 API 比 GPTPlus 便宜，一般人基本不可能一个月用掉 20 刀。OpenAI 现在前景也不明朗，不知道能活多久，唉。有兴趣的可以玩玩，有问题可以评论或者邮件联系我。 https://chat.laisky.com/#
Ps. 更新非常频繁，偶尔不可用稍等几分钟刷新即可。
Ps. 更新非常频繁，偶尔不可用稍等几分钟刷新即可。
https://youtu.be/3QpdU9LS540
周末看了部纪录片，Bloomberg 拍的关于币圈最大交易所（之一） FTX 的故事。
核心观点就是 Sam 作为一个硅谷科技天才开发了虚拟货币交易所 FTX，
然后随着 2020 年前后虚拟货币的涨价狂潮迅速崛起。
他一边对外塑造亲民朴素形象，一边在巴哈马大肆挥霍享乐。（有个投资人的评价很有意思，虽然 Sam 看上去不咋样，但是在币圈这个妖孽横行的地方，他已经是最正常的人了）
事情的转机出现在 FTX 试图获取美国证监会 SEC 的许可，而申请过程中需要大股东披露财务状况。
而币安作为持股 20% 的大股东却拒绝披露，Sam 被迫支付 20亿 美元赎回了币安的股份，
大部分是现金，还有数亿美元是代币 FTT。
币安借此掏空了 FTX 的现金流，然后宣布抛售持有的全部 FTT 从而引起市场恐慌和挤兑，
FTX 资不抵债，币安则借此机会提出收购 FTX。然而此时出问题了，币安发现 FTX 账目上存在 80 亿美元的黑洞，
将这事儿捅了出来。
事情到了这地步，美国的司法系统就介入了，最终判定 Sam 为主的管理层构成欺诈，导致了投资人 80 亿美元的巨额损失。
无数散户被套牢，而 Sam 也住进了监狱。
简而言之就是 Sam 借虚拟货币狂潮玩了一把骗局，然后因为和币安的商战而暴露。
最可怕的一点是 Sam 自己可能并没有明确的恶意，他可能就是对财富完全没有任何概念，
大肆挥霍投资人的钱，然后还自以为在改变世界。所以此片标题也很有意思，他就是搞砸（RUIN）了一切，在一个没有监管的资本市场， 这也是必然会发生的，相同的戏码在未来也还会反复上演。 #佳片 #观后感 #blockchain
Ps. 此片有一特色就是大量使用了 AI 绘制的素材。
周末看了部纪录片，Bloomberg 拍的关于币圈最大交易所（之一） FTX 的故事。
核心观点就是 Sam 作为一个硅谷科技天才开发了虚拟货币交易所 FTX，
然后随着 2020 年前后虚拟货币的涨价狂潮迅速崛起。
他一边对外塑造亲民朴素形象，一边在巴哈马大肆挥霍享乐。（有个投资人的评价很有意思，虽然 Sam 看上去不咋样，但是在币圈这个妖孽横行的地方，他已经是最正常的人了）
事情的转机出现在 FTX 试图获取美国证监会 SEC 的许可，而申请过程中需要大股东披露财务状况。
而币安作为持股 20% 的大股东却拒绝披露，Sam 被迫支付 20亿 美元赎回了币安的股份，
大部分是现金，还有数亿美元是代币 FTT。
币安借此掏空了 FTX 的现金流，然后宣布抛售持有的全部 FTT 从而引起市场恐慌和挤兑，
FTX 资不抵债，币安则借此机会提出收购 FTX。然而此时出问题了，币安发现 FTX 账目上存在 80 亿美元的黑洞，
将这事儿捅了出来。
事情到了这地步，美国的司法系统就介入了，最终判定 Sam 为主的管理层构成欺诈，导致了投资人 80 亿美元的巨额损失。
无数散户被套牢，而 Sam 也住进了监狱。
简而言之就是 Sam 借虚拟货币狂潮玩了一把骗局，然后因为和币安的商战而暴露。
最可怕的一点是 Sam 自己可能并没有明确的恶意，他可能就是对财富完全没有任何概念，
大肆挥霍投资人的钱，然后还自以为在改变世界。所以此片标题也很有意思，他就是搞砸（RUIN）了一切，在一个没有监管的资本市场， 这也是必然会发生的，相同的戏码在未来也还会反复上演。 #佳片 #观后感 #blockchain
Ps. 此片有一特色就是大量使用了 AI 绘制的素材。