AWS 推出 Thin Client

AWS 推出自家的 Amazon WorkSpaces Thin Client:「New Amazon WorkSpaces Thin Client provides cost-effective, secure access to virtual desktops」。

好久沒聽到這個詞彙了,翻了英文版維基百科「Thin client」,在 History 那個部分可以看到以前的各種方案,現在在網路速度比起十年前快不少的前提下,AWS 這次用雲端的基礎建設與一個便當盒搭配起來。

不過... 還是有不少挑戰?

一個主要的問題還是費用,這個機子要將近 $195 或是 $280 (如果要接第二個螢幕需要多買一個 Hub),然後還有 $6/mo 的費用,以及 Amazon WorkSpaces 的費用:

Pricing – Devices are priced at $195, or $280 with an optional hub that allows you to use a second monitor. There’s a $6 per month fee to manage, maintain, and monitor each device, and you also pay for the underlying virtual desktop service.

隨便翻了一下 Amazon 上面的商品,用 N100 當關鍵字找機器,第一個結果就可以看到這台 $199 可以接兩個 4K/60Hz 的 HDMI 的便當盒:「Beelink Mini PC, Mini S12 Pro Intel 12th N100(4C/4T, Up to 3.4GHz), 16GB DDR4 500GB M.2 SSD, Mini Desktop Computer Support 4K@60HZ Dual HDMI Display/WiFi6/BT5.2/USB3.2/1000Mbps/LAN/WOL Micro PC」。

就算先把費用的部分放到一旁,如果管理成本有下降的話,應該也會是蠻多企業願意花錢的方向,但一般商用辦公室網路的穩定度應該會使得 Thin Client 的弊端遠大於利益?

目前看起來比較像是 AWS 內某個 BU 找主題試看看...?

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 本身就很大,可以來看看後續的效應...

處理 rTorrent 會卡頓的問題

rTorrent 算是很久了,在 CLI 下的 BitTorrent client。

但 rTorrent 一直有卡頓的問題,這個週末決定還是找一下怎麼解,而在 Reddit 上面可以看到討論:「Rtorrent stalling / freezing caused by bad tracker? I fixed my problem but I'm a bit puzzled.」,其中就有提到是 libtorrent 因為 DNS 查詢 blocking 的問題。

不過這邊有些人已經提出了解法,其中一個是使用 libudns 達成 async DNS query 來解決這個問題,這個 branch 有進到官方的 git repository 裡面 (但沒有被 merge 到 master 上):「rakshasa/libtorrent at slingamn-udns.10」。

看了一下雖然最後 commit 是 2019 年,但其實不算太舊,因為 master 從 2019 年到現在 2023 年也沒幾個 commit,不過直接用 slingamn-udns.10 的 libtorrent 搭最新版的 rtorrent 是編不起來的,主要是因為 IPv6 的支援改變了一些程式的 API 介面。

最後一個可以搭 rtorrent 的版本是 2021 年六月的 582e4e40256b43d3e5322168f1e1ed71ca70ab64,也已經比目前最近的正式 release 0.9.8 (2019/07/19) 還新。

把這些組合弄起來後跑了幾個小時,看起來順不少,暫時沒有遇到卡住的問題了...

MariaDB 嘗試相容於 PostgreSQL 協定的產品

Twitter 上看到的消息,新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊:

看起來是 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.

再看看後續會不會有更多消息?

把 RabbitMQ 換成 PostgreSQL 的那篇文章...

Hacker News 上看到「SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue (prequel.co)」這篇文章,原文在「SQL Maxis: Why We Ditched RabbitMQ And Replaced It With A Postgres Queue」這邊,裡面在講他們把 RabbitMQ 換成 PostgreSQL 的前因後果。

文章裡面可以吐嘈的點其實蠻多的,而且在 Hacker News 上也有被點出來,像是有人就有提到他們遇到了 bug (或是 feature) 卻不解決 bug,而是決定直接改寫成用 PostgreSQL 來解決,其實很怪:

In summary -- their RabbitMQ consumer library and config is broken in that their consumers are fetching additional messages when they shouldn't. I've never seen this in years of dealing with RabbitMQ. This caused a cascading failure in that consumers were unable to grab messages, rightfully, when only one of the messages was manually ack'ed. Fixing this one fetch issue with their consumer would have fixed the entire problem. Switching to pg probably caused them to rewrite their message fetching code, which probably fixed the underlying issue.

另外一個吐嘈的點是量的部份,如果就這樣的量,用 PostgreSQL 降低使用的 tech stack 應該是個不錯的決定 (但另外一個問題就是,當初為什麼要導入 RabbitMQ...):

>To make all of this run smoothly, we enqueue and dequeue thousands of jobs every day.

If you your needs aren't that expensive, and you don't anticipate growing a ton, then it's probably a smart technical decision to minimize your operational stack. Assuming 10k/jobs a day, thats roughly 7 jobs per minute. Even the most unoptimized database should be able to handle this.

在同一個 thread 下面也有人提到這個量真的很小,甚至直接不講武德提到可以用 Jenkins 解 XD:

Years of being bullshitted have taught me to instantly distrust anyone who is telling me about how many things they do per day. Jobs or customers per day is something to tell you banker, or investors. For tech people it’s per second, per minute, maybe per hour, or self aggrandizement.

A million requests a day sounds really impressive, but it’s 12req/s which is not a lot. I had a project that needed 100 req/s ages ago. That was considered a reasonably complex problem but not world class, and only because C10k was an open problem. Now you could do that with a single 8xlarge. You don’t even need a cluster.

10k tasks a day is 7 per minute. You could do that with Jenkins.

然後意外看到 Simon Willison 提到了一個重點,就是 RabbitMQ 到現在還是不支援 ACID 等級的 job queuing (尤其是 Durability 的部份),也就是希望 MQ 系統回報成功收到的 task 一定會被處理:

The best thing about using PostgreSQL for a queue is that you can benefit from transactions: only queue a job if the related data is 100% guaranteed to have been written to the database, in such a way that it's not possible for the queue entry not to be written.

Brandur wrote a great piece about a related pattern here: https://brandur.org/job-drain

He recommends using a transactional "staging" queue in your database which is then written out to your actual queue by a separate process.

這也是當年為什麼用 MySQL 幹類似的事情,要 ACID 的特性來確保內容不會掉。

這也是目前我覺得唯一還需要用 RDBMS 當 queue backend 的地方,但原文公司的想法就很迷,遇到 library bug 後決定換架構,而不是想辦法解 bug,還很開心的寫一篇文章來宣傳...

npm 裡的 redis 與 ioredis

前幾天在噗浪的偷偷說上看到有人提到 npmtrends 上的 redis (官方的) 與 ioredis:「https://www.plurk.com/p/p6wdc9」。

意外發現以下載量來看,ioredis 已經超越官方的 redis 了:

找了一下差異,看起來的確有些團隊在 loading 很高的情況下會考慮用 ioredis 取代 redis:「Migrating from Node Redis to Ioredis: a slightly bumpy but faster road」。

但沒有特別需求的話應該還是會用官方版本?

AWS 官方推出了自己的 Amazon S3 FUSE 套件

看到「Mountpoint for Amazon S3」這個專案,AWS 自己推出了自己的 Amazon S3 FUSE 套件。Hacker News 上也有一些討論:「Mountpoint – file client for S3 written in Rust, from AWS (github.com/awslabs)」。

Amazon S3 的價錢比其他 AWS 提供的 storage 都便宜不少。以美東第一區 us-east-1 來說,S3 是 $0.023/GB,而 EBS (gp3) 要 $0.08/GB,即使是 EBS (st1) 也要 $0.045/GB。

S3 相較於 EBS 來說,多了 API call 的費用,所以對於不會產生大量 API call 的應用來說 (像是常常會寫很大包的資料到檔案裡),透過 FUSE 操作 Amazon S3 可以讓現有的套裝軟體或是程式直接跑上去。

另外一個常見的應用是讓套裝軟體或是現成的程式可以讀取 S3 的資料。

之前這類應用馬上會想到的專案是 s3fs-fuse,這個專案很久了,大家也都知道多人寫入的部份會是痛點。

這次 AWS 自己出來做的事情有點重工,看起來他想做的事情 s3fs-fuse 都解的差不多了,目前看起來唯一的賣點應該只有 Rust-based,但 s3fs-fuse 主要是 C++,其實也沒差到哪裡:

Mountpoint for Amazon S3 is optimized for read-heavy workloads that need high throughput. It intentionally does not implement the full POSIX specification for file systems.

目前專案還是 alpha release,不確定專案的方向到底是什麼...

CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)

看到 CloudFront 宣佈支援帶入 JA3 資訊了:「Amazon CloudFront now supports JA3 fingerprint headers」:

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

JA3 的頁面上可以看到說明,針對 SSL/TLS 這個複雜的 handshake 過程中,就可以從中得知不同的 client 實做,比起容易偽造的 User-agent 有效:

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測:

JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865

先前在「修正 Curl 的 TLS handshake,避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。

透過 SOCKS5 界面連進 WireGuard 網段的軟體 wireproxy

Hacker News 上看到「A userspace WireGuard client that exposes itself as a proxy (github.com/octeep)」看到這個有趣的東西,可以把自己當作是一個 WireGuard client,然後透過 SOCKS5 界面讓使用者使用... 專案則是在 GitHub 上的「Wireguard client that exposes itself as a socks5 proxy」這邊可以看到。

除了軟體本身有支援 SOCKS5 的可以用以外,另外可以搭配透過 LD_PRELOAD 把 TCP 連線都轉進 SOCKS5 服務的套件來用,像是 tsocks 或是 redsocks 這種工具。

然後這包東西是用 Golang 寫的,好像剛好可以拿來練手包 Ubuntu PPA...