幹壞事是進步最大的原動力
Cloudflare 利用自家平台分析過去一年 HTTP/3 的使用率：「Examining HTTP/3 usage one year on」。
首先是整體的使用率，看起來反而沒有什麼太大的變化？一上線就已經是巔峰的感覺？
然後各種 bot (像是搜尋引擎的 bot 或是 social media 的 bot) 看起來幾乎都沒有用 HTTP/3，少數的量應該都是實驗性質居多，唯一的例外是 LinkedIn 有試著在導入，可以看到慢慢的爬升：
看起來不算太順？
在 Twitter 上看到的消息，新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊：
Hm. Did MariaDB Corporation just admit PostgreSQL is the future ? https://t.co/FCw30V0x2y #mariadb #postgres
— Peter Zaitsev (@PeterZaitsev) May 10, 2023
看起來是 SkySQL 的服務，這樣聽起來不像會 open source... 看起來賣點在於 globally distributed RDBMS 這個部分：
MariaDB is previewing a PostgreSQL-compatible front end in its SkySQL Database-as-a-Service which provides a globally distributed RDBMS on the back end.
再看看後續會不會有更多消息？
在 Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇，專案在「Measuring CPU core-to-core latency」這裡，看起來是個有趣的研究，測試許多不同 CPU 內，跨 core 之間溝通的時間花費。
依照專案的說明，測試的方式是利用 cache coherence 來來量測：
We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.
By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.
裡面已經測了很多不同的 CPU，然後可以看到一些有趣的結果。
像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組，大家還蠻好奇 CPU #8 到底是怎麼一回事，跨 core 溝通的 latency 特別低，還特別找了 CPU 的 die 圖片看看：
另外一個是 AWS 上的 c6a.metal，機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」，可以看到被分成了六個區塊：
接下來在 ARM 平台，在更多 CPU core 的 c7g.16xlarge 上，機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」，會看到更多不平均的現象：
早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」，但可以看到很不一樣的 latency pattern：
大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸，導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。
看到「RFC 9293: Transmission Control Protocol (TCP)」這篇，主要是把本來分散在各個 RFC 的文件 (從 RFC 793 開始) 全部整理成一份，另外把一些已知的勘誤表放進來：
This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.
然後淘汰掉 (obselete) 一卡車 RFC 文件 XD
翻資料發現 2014 的時候 HTTP/1.1 被幹過一次類似的事情，不過是反過來被拆開：「HTTP/1.1 的更新」，這次把 RFC 2616 幹掉分成 RFC 7230～RFC 7235。
然後今年因為 HTTP 的關係又被幹了一次，這次 HTTP/1.1 又被整回來變成一份文件，但是把裡面的一些概念拆開：「HTTP 標準的翻新」。
其中 RFC 9110 定義 HTTP Semantics，RFC 9111 定義 HTTP Caching，然後 RFC 9112 與 RFC 9113 拿來定義了 HTTP/1.1 與 HTTP/2，另外先把 HTTP/3 的號碼保留下來的 RFC 9114。
不斷 refactor 以及加新功能的文件...
看到 OxideDB 這個專案：
OxideDB is a translation layer that works as a MongoDB database server while using PostgreSQL's JSON capabilities as the underlying data store.
跟之前提到的 MangoDB 有些淵源 (參考「MangoDB：拿 PostgreSQL 當作後端的 MongoDB 相容層」)，順便提一下 MangoDB 後來被要求改名為 FerretDB：「MangoDB 改名為 FerretDB (雪貂)」。
主要的差異在於 OxideDB 只以 PostgreSQL 為底層，另外是用 Rust 寫的：
The project was heavily inspired by FerretDB and is on its early days. The main difference is that there is no intention to support any database other than PostgreSQL (FerretDB is also supporting Tigris) and it's written in Rust, as opposed to Go.
看起來大家都拿 PostgreSQL 在搞事，但這個專案裡面好像沒搜到 GIN 這個關鍵字，不知道是不是連 index 都沒下...
AWS 的 Anycast 服務 AWS Global Accelerator 宣佈支援 IPv6：「New for AWS Global Accelerator – Internet Protocol Version 6 (IPv6) Support」。
算是補功能，不過這個功能只對於「純 IPv6 環境」的使用者端有用 (沒有 DNS64 + NAT64 的轉換)，目前商轉給一般使用者用的 IPv6 環境應該都還是有掛 DNS64 + NAT64 才對...
另外使用這個功能會需要 VPC 有 IPv6 能力：
To test this new feature, I need a dual-stack application with an ALB entry point. The application must be deployed in Amazon Virtual Private Cloud (Amazon VPC) and support IPv6 traffic.
然後 IPv4 會進到 IPv4 的服務裡，IPv6 則會進到 IPv6 的服務裡：
Protocol translation is not supported, neither IPv4 to IPv6 nor IPv6 to IPv4. For example, Global Accelerator will not allow me to configure a dual-stack accelerator with an IPv4-only ALB endpoint. Also, for IPv6 ALB endpoints, client IP preservation must be enabled.
短時間還用不太到，但之後應該有機會...
看到「Goodbye Microsoft SQL Server, Hello Babelfish」這篇，AWS 對 Aurora (PostgreSQL) 推出了可以吃 Microsoft SQL Server 協定的 Babelfish：
Today, we are making Babelfish for Aurora PostgreSQL available. Babelfish allows Amazon Aurora PostgreSQL-Compatible Edition to understand the SQL Server wire protocol.
查了一下資料發現是去年年底的時候發表的：「Want more PostgreSQL? You just might like Babelfish」，不過當時沒注意到這東西，大概是因為是 preview 的關係：
We are open sourcing Babelfish in 2021. Until then, you can use Babelfish on Amazon Aurora in a preview to see how it works and to get a sense for whether this is the right approach for you.
用起來不知道怎樣，但感覺很值得注意，目前雖然沒用到 Microsoft SQL Server 的東西，但以後遇到可以考慮看看...
除了在 AWS 上用以外，也可以自己到 GitHub 上拉 patch 回來上：「babelfish-for-postgresql」。
話說回來，PostgreSQL 被 AWS 拿來用在好多地方啊，先前大家也猜是 DocumentDB 後面是 PostgreSQL (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」這篇)，不知道之後會不會想要跟 Oracle 的律師打架...
在「By default, scp(1) now uses SFTP protocol」這邊看到的，OpenSSH 的 scp 改用 SFTP 協定了，原因也有附在文章裡：
SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side.
要注意這是 BC-break change，有些之前會動的 case 在改用 SFTP 後會爛掉，但這算是前進了一大步，scp 因為 spec 的關係很難維護安全性。
在「Deprecating scp」這邊也有提到相關的問題，另外也給出了一些範例。
在 Red Hat 的 blog 上看到 SCTP over UDP 的方式，讓不支援 SCTP 的 NAT 裝置也能使用 SCTP：「An easier way to go: SCTP over UDP in the Linux kernel」。
這個方式也是個標準，在 RFC 6951：「UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication」。
Linux kernel 則是在 5.11 之後才支援，不過翻了一下 5.11 是一般版，在 2021 年二月釋出，在五月底就已經 EoL：
Stream Control Transmission Protocol over User Datagram Protocol (SCTP over UDP, also known as UDP encapsulation of SCTP) is a feature defined in RFC6951 and implemented in the Linux kernel space since 5.11.0.
上一個 LTS 版本是 5.10，下一個不知道是什麼時候了...
前幾天的新聞了，這兩天 Fastly 與 Cloudflare 也都發文章出來了，QUIC 成為標準：「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。
主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了，接下來可以等一些測試報告，看看在 web 這種已經有不少複雜的 workaround 機制下，TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。
在 QUIC 下的 https 協定會走 443/udp，如果防火牆是預設阻擋所有連線，然後逐條開放的話，需要另外開這組設定。
另外就是等 nginx 支援了，在「NGINX QUIC Preview」這邊有些資料，然後「">nginx-quic: log」裡面可以看到東西，裡面不少 commit 只是跟 nginx 本家同步而已，不過還是可以看到一些跟 QUIC 有關的...