渐变好难调啊，调了半天感觉我已经成了色盲了，分不清红绿蓝了，红里透着绿，绿里透着蓝emm

HTTP/2 可能没 HTTP/1.1 快

HTTP/2 最大变化是引入单独的成帧层，支持了多路复用，允许交错接收多个资源。如 a.js 与 b.css，HTTP/1.1 只能顺序的 aaaabbb 接收，而 HTTP/2 允许 abababa。

但这种交错对浏览器来说，不一定是好事，因为浏览器必须完整接收整个文件，才能开始执行它，abababa 意味着直到最后才能开始执行 a.js，直到最后第二个才能开始执行 b.css。

其它方式呢，如 aaababb，确实可以，但面对一众突发请求，很难有效控制，HTTP/2 确实出现过流优先级系统，但在 HTTP/3 中被彻底删除，当然很大一部分归因于 QUIC 流之间无序。

将多个文件相互交错，还更容易受到丢包影响，而被阻塞。丢包由网络路径中的路由缓冲区暂时溢出导致，一般发生在相邻几个流之间，aXXXbbb 和 aXXXaba（X 表示丢失），当然前者更好，因为 b.css 未受到丢包影响。

结果就是，对浏览器而言，某些情况 HTTP/1.1 会更快，即使存在 HOL blocking 问题（HTTP/2 也仍存在 TCP 层的 HOL blocking），但 HTTP/1.1 将这些请求分摊到 6 个连接，可以很大程度避免它。

与 HTTP/2 的单一连接不同，HTTP/1.1 是真正意义上的并行请求，每个连接都有自己的拥塞控制，对于 HTTP/2 即使是单个数据包丢失，也会导致整体变慢，而 HTTP/1.1 其中一个连接丢包，只会减慢该连接的速度。同时 6 个连接的初始拥塞窗口也会更大 6*14K=84KB，而非单一连接的 14KB。

#learning

Source map 原理

Source map 本身是一个 JSON，如 {"version":3, "mappings":";;;MADF,cAtBF;mBAAkB", "sources":["~/code/Cat.tsx"], ...}

mappings 是 source map 关键，它记录了源码与转换后代码的映射关系。每个 ; 表示新的一行，因此其后的 MADF 在第 4 行，表示该行的列映射关系，多个使用 , 隔开，它的每个字符基于 Base64 编码，解码后正好是 6 bits。

如对 cAtBF 解码，c:011100 A:000000 t:101101 B:000001 F:000101，解码后的数据以 VLQ(variable-length quantity) 形式表示，每组的最高位是 continuation(C)，表示是否连续，最低位是 sign(S)，1 为负。

首先 c:011100，C、S 都是 0，表示“非连续正数”，因此可以直接拿中间的位 1110=14。其后 A:000000 按照同样方式，0000=0。

之后是 t:101101，C、S 均为 1，表示“连续负数”，“连续”指其后的 B:000001 也是它的一部分，为了更加充分利用空间，后面每组都省去了 S，因此最终是 t:0110（除去 C、S），B:00001（除去 C），连起来 00001 0110=22，补上符号 -22。

最后的 F:000101，C=0，S=1，表示“非连续负数”，因此 0010=2，补上符号后 -2。最终 cAtBF 得到 [14,0,-22,-2] 四个数，分别表示 output column、input filename index、input line、input column，所有数字都是相对于当前的偏移量，input filename index 对应于上面 JSON 中的 sources。

如果得到 5 个数，则在上面 4 个基础上，再追加一个 name index，对应于 JSON 中的 names（未列出）。如果只有 1 个数，那么仅表示 output column，无其它更多信息。

#learning

Golang 并发缓存实践
https://sxyz.blog/go-concurrent-cache/

#blog 头一次写这么长的博客（

原来还有 DoQ
https://adguard.com/en/blog/dns-over-quic-official-standard.html

GitHub 的 Tab 支持真是差强人意

- GitHub Actions 的 yaml 只能用 Space
- Markdown 会把 Tab 渲染成 8-width，即使用户设置了 Tab size preference，也不会遵照

在看到 GitHub 改善之前，我决定 Markdown 先用 space 作为替代。

推荐一个 MS Edge theme
https://microsoftedge.microsoft.com/addons/detail/pride/gpahbdchbfofplfeaeipcphhbdhdpnae

非常漂亮！inspired by the many flags of the LGBTQI+ community

利用 CDN 规避流量审查

Domain Fronting：SNI 是一个存在于 CDN 的域名，Host 目标域名。原理 CDN 没检查 SNI == Host

Domain Hiding：SNI 任意域名，ESNI/ECH 包含加密的目标域名

Domain Borrowing：域名所有者 Alice 添加一个 *.example.com cert，攻击者 Bob 添加一个不存在的 a.example.com，CDN 错误地将其关联到 *.example.com wildcard cert

#learning

https://xsleaks.dev

里面写了好多跨源攻击方式，有些第一次见，还挺全的。

#learning #tools

Ezno，一个新的 JavaScript 类型检查器

https://kaleidawave.github.io/posts/introducing-ezno/

两篇 TCP 性能优化文章

- https://www.rfc-editor.org/rfc/rfc1323
- https://datatracker.ietf.org/doc/html/draft-stenberg-httpbis-tcp

#learning

：你冷静点，不要过来啊

https://sxyz.blog/aes-from-scratch/

写了一篇关于 AES 的博客。业余密码学爱好者，如有错误还请指出（

#blog

CSS Nesting Module

CSS 终于支持选择器嵌套了，https://drafts.csswg.org/css-nesting/

过了一遍，和 Sass 语法基本差不多，浏览器目前仍在实现，或将在 Chrome 109 中可用（with a flag）。

另外刚刚查资料时，发现了 postcss-nesting 这个插件，它允许你提前体验该语法，原理是将 nesting selector 编译为 :is()。

如 div{+span#my-id{}} 编译为 :is(div)+span#my-id{}。

其它几个还能用的域名
https://www.ooopn.com/tool/zlibrary/

试了下已经支持了欸，不过 DevTools 显示还有问题。

Chrome 版本 Version 109.0.5402.0 (Official Build) canary (arm64)

flag 参数 --enable-blink-features=CSSNesting

是 nil，但不是 nil
https://go.dev/doc/faq#nil_error

#golang

https://sxyz.blog/functors-applicatives-and-monads-in-pictures/

把 Aditya Bhargava 的这篇经典文章重新翻译了一版。

它是了解函数式编程非常棒的一篇文章，但现存的中文译文却都不可用了。

#blog