Cloudflare 正式推出 ECH (Encrypted Client Hello)

Cloudflare 宣佈所有的 Plan 都支援 ECH 了：「Encrypted Client Hello - the last puzzle piece to privacy」。

要講 ECH 之前，會先提到 Domain fronting 這個避開網路審查 (censorship) 的技巧，這是利用 CDN 服務裡對 SNI 的處理與對 HTTP header 的處理分開的特性，算是一種 side effect 的搞法，不保證會動，但蠻多 CDN 的服務都會動。

實際上的作法就是在 SNI 層的 hostname 填寫一個沒有被審查的 Hostname (像是 www.akamai.com)，然後連到 www.akamai.com:443 上，也都使用 www.akamai.com 的 SSL certificate 交換。

但在 HTTP header 上面則是送出不一樣的 hostname (但也必須是在這家 CDN 的機器上有提供服務的網域)，通常是被管制的網域名稱，像是 Host: www.cnbc.com 這樣的 HTTP header；而因為這部份被 TLS 保護，無法從外部看到內容而可以穿過網路審查。

理論上 CDN 服務是可以 reject 這樣的連線的，但大多數的 CDN 廠商並沒有阻擋這麼嚴格，於是算是一種堪用的方式。而這次 ECH 算是把這個行為標準化了，就不需要再用 side effect 的方式了。

Cloudflare 本身就很大，可以來看看後續的效應...

Raspberry Pi 5 的一些細節出現了...

上一篇「Raspberry Pi 5」提到了一些來自 Raspberry Pi 官方的說明，後續各個媒體 (像是 YouTuber) 也都解禁放出不少資料可以參考了，其中電源的部分在「Answering some questions about the Raspberry Pi 5」這邊看到不認 USB PD 的 5V/5A 的問題，目前看起來是走獨規：

I also tested the Radxa USB-C PD 30W power adapter, which says it will output 5V at 5A, but the Pi only negotiates 3A with it right now. I've been in contact with Pi engineers and it seems like they have one on the way to test to see why it's not negotiating more.

另外看起來之後有機會支援 12V/2.25A (換算起來是 27W) 的充電頭，有機會透過韌體更新認得 PD？

I should also note the official adapter lists 12V at 2.25A output as an option, so maybe some future Pi could take that and run with it, for increased compatibility with more USB-C PD adapters (5V at 5A is a rarely seen, though it's an option in the spec).

不過即使走 5V/3A (15W)，在一般的應用下是夠用了，到時候拿到來玩看看...

Raspberry Pi 5

Raspberry Pi 5 的消息出來了：「Introducing: Raspberry Pi 5!」。

價錢是 $60 (4GB RAM 版本) 與 $80 (8GB RAM 版本)，目前看起來是 pre-order 階段。

Today, we’re delighted to announce the launch of Raspberry Pi 5, coming at the end of October. Priced at $60 for the 4GB variant, and $80 for its 8GB sibling, virtually every aspect of the platform has been upgraded, delivering a no-compromises user experience.

其中一個大賣點應該是效能了，宣稱與 RPi4 相比，CPU/GPU 效能是以前的兩倍到三倍，記憶體與 I/O 的頻寬也加倍了，所以應該是所有應用都會變快不少：

Today, that effort bears fruit, with the launch of Raspberry Pi 5: compared to Raspberry Pi 4, we have between two and three times the CPU and GPU performance; roughly twice the memory and I/O bandwidth; and for the first time we have Raspberry Pi silicon on a flagship Raspberry Pi device.

等到後續出貨應該就會有資料可以看了，不過從時脈就可以看出一些重點，上一代還是 1.5GHz (或是後來更新的 1.8GHz)，這一代拉到 2.4GHz 了：

2.4GHz quad-core 64-bit Arm Cortex-A76 CPU

而後續也提到，在相同的 loading 吃電量比 RPi4 低，但因為 boost 的關係，瞬間最高吃電量從以前 RPi4 的 8W 變到 RPi5 的 12W：

Raspberry Pi 5 consumes significantly less power, and runs significantly cooler, than Raspberry Pi 4 when running an identical workload. However, the much higher performance ceiling means that for the most intensive workloads, and in particular for pathological “power virus” workloads, peak power consumption increases to around 12W, versus 8W for Raspberry Pi 4.

但也因為這樣，如果你拿 15W 的 USB-C 充電器時，他的 USB port 就只能提供 3W 的功率了 (剛好就是他提到的 5V/600mA)：

When using a standard 5V, 3A (15W) USB-C power adapter with Raspberry Pi 5, by default we must limit downstream USB current to 600mA to ensure that we have sufficient margin to support these workloads. This is lower than the 1.2A limit on Raspberry Pi 4, though generally still sufficient to drive mice, keyboards, and other low‑power peripherals.

如果要能夠讓 USB 可以供應足夠的功率 (像是外接的機械硬碟這種會吃比較多電的設備)，需要使用 5V/5A 的充電器。

但這邊提到 RPi5 firmware 在偵測到 5V/5A 的充電器時會提高限制，而不是提到 USB PD，所以可以預期是特規？

For users who wish to drive high-power peripherals like hard drives and SSDs while retaining margin for peak workloads, we are offering a $12 USB-C power adapter which supports a 5V, 5A (25W) operating mode. If the Raspberry Pi 5 firmware detects this supply, it increases the USB current limit to 1.6A, providing 5W of extra power for downstream USB devices and 5W of extra on-board power budget: a boon for those of you who want to experiment with overclocking your Raspberry Pi 5.

供貨的部分反而沒有聊到太多，但 RPi4 最近的供貨還算可以，所以可以預期 RPi5 應該不會太差？

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬：「Announcing 200 GB free Standard Tier internet data transfer per month」。

這類優惠應該是要給練習或是試用的人用的，吸引他們放一些量上來...

另外雖然是每個區域都有 200GB/mo 的 free bandwidth，但通常也只會用一個或兩個區域，以台灣的 asia-east1 來說，如果有量在上面跑的話，省下來的會是 $0.07/GB 這個部分，大概就是 $14/mo 左右？

ClickHouse 弄了一個 C++ 寫的 ZooKeeper drop-in replacement：ClickHouse Keeper

在 Hacker News 上看到「ClickHouse Keeper: A ZooKeeper alternative written in C++ (clickhouse.com)」，原文是「ClickHouse Keeper: A ZooKeeper alternative written in C++」。

在 distributed coordination 這個領域目前應該是 etcd 比較知名，但 Apache ZooKeeper 畢竟算是元老，還是有不少應用程式會把 ZooKeeper 當作基礎建設在用。

因此 etcd 也包了一個 zetcd，可以用 etcd 當作底層結構，但提供 ZooKeeper API 的介面讓應用程式使用：

Serve the Apache Zookeeper API but back it with an etcd cluster

這次 ClickHouse 的人搞出一個用 C++ 寫的 ClickHouse Keeper，定位是 drop-in replacement，想要解決現有的應用程式遇到的記憶體資源問題。

從開頭的說明就可以看到著重在這塊：

up to 46 times less memory than ZooKeeper ​​for the same volume of data while maintaining performance close to ZooKeeper.

而對於新的應用程式，在開發時應該就不太會選 ZooKeeper 了，畢竟連 distributed lock 都得自己操作 znode 把功能疊出來 (像是官網很貼心的還提供了「ZooKeeper Recipes and Solutions」，裡面提供了 lock 的方法)，而這種事情太累，用 etcd 方便太多...

號稱目前最強的 Mistral 7B

Hacker News 上看到「Mistral 7B (mistral.ai)」，Mistral 7B 是目前號稱最強的 7B model。

宣稱在所有項目超越 Llama 2 13B，以及在許多項目超越 Llama 1 34B：

Outperforms Llama 2 13B on all benchmarks
Outperforms Llama 1 34B on many benchmarks

很重要的是以 open source license 放出來的，選的是 Apache License, Version 2.0：

We’re releasing Mistral 7B under the Apache 2.0 license, it can be used without restrictions.

這個 model 大小是可以用 CPU 跑的，馬上就有人推 patch 進 llama.cpp 了：「Added the fact that llama.cpp supports Mistral AI release 0.1 #3362」。

我記得 Llama 2 13B 的輸出結果還有點微妙，但如果說是全部都超過的話，也許可以期待看看品質...

Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇，裡面提到了 Percona 包的 Galera Cluster，叫 Percona XtraDB Cluster。

Percona 算是把 Galera Cluster 包的比較好的 distribution，是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本，叫做 MariaDB Galera Cluster。

這篇算是很早期使用 PXC 的人的一些感想：(大概是 2012 年導入，當年雲端也還沒流行，在地端上面自己建，對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的，加上一台沒有資料，這台沒資料的只負責投票組成 quorum，不需要到三台都是大機器，而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入，但實務上會建議都集中在一台寫，這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素，將兩台有資料的機器，一台做 writer，另外一台做 reader 算是常見的架構，然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構，或是後來政治改名為 source-replica 架構)，不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題，現在有 GUID 後會好一些)

除了 Galera Cluster 外，另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD：因為 DRBD 可以在兩台機器的 block 層做 mirror，所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純，維護成本也很低，但缺點就是 recovery 的時間會高一些：在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID)，而 Galera Cluster 因為等於是 hot-standby，蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上，Galera Cluster 也是因為 hot-standby 大勝：DRBD 這邊的情境等於是 cold start，資料庫內還有很多東西還沒進到 InnoDB buffer，對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西，但後面運作的機制複雜不少 (而且需要有人維護)，公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況，讀取速度與 random access 的效率都快很多，這使得 DRBD 切換的成本低很多了，很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定，如果這個時間是可以接受的，用 Galera Cluster 的優點可能就沒那麼高了...

scp -3：直接對兩個 remote host 複製檔案

剛剛找資料才發現的，scp 指令早就可以針對兩個遠端複製檔案了：「scp from one remote server to another remote server」。

可以加上 -3，像是這樣：

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加，因為這是 default 值：

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期，是 2014 年十月回的，所以至少 Ubuntu 16.04 就有這個功能了？(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬，然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案，沒想到隔壁棚早就給了解法...

這樣有些情境搬檔案就簡單多了...

目前最老的 BitTorrent 種子 20 年了：The Fanimatrix

The Fanimatrix 的 BitTorrent 種子是目前還活著的 BitTorrent 種子最老的，從 2003 年九月建立的種子，至今要 20 年了：「The World’s Oldest Active Torrent Turns 20 Years Old」。

在 2022 的報告裡面 BitTorrent 的流量大約是 2.91% (雖然這份報告本身有些地方很詭異，但就還是可以當個參考)：「2022 Global Internet Phenomena Report」，在「BitTorrent is Still the King of Upstream Internet Traffic, But for How Long?」這邊也在討論 BitTorrent 的占比逐漸下降。

但這就是 open protocol 的特性，你沒辦法殺掉他，而且他在對應的領域還是活的很好...

cURL 放入 ipfs:// 支援

在 Hacker News 上看到 cURL 支援 ipfs:// 的消息：「IPFS support got merged into curl (twitter.com/bmann)」。

Hacker News 上有人提到這包支援的特性與問題：

This patch makes curl utilize a gateway for ipfs:// addresses. It prefers a local one but can also use public gateways. It makes no effort to verify that the final product's cryptographic hash corresponds to the one in the address.

依照說明是透過 gateway 處理，如果本地端有的話就用本地端的 gateway，不然就用 public gateway。另外就是沒有驗證 hash...

不算是原生支援，但還行...？