Go 的 net/http 在 1.22 的 routing 新功能

Gonet/http 在 1.22 引入了更方便的 pattern matching:「Routing Enhancements for Go 1.22」。

用官方的範例,現在可以處理路徑裡的參數了:

http.Handle("GET /posts/{id}", handlePost2)

後續可以透過 PathValue() 取出來:

idString := req.PathValue("id")

而優先順序則是依照吻合度定義:

The precedence rule is simple: the most specific pattern wins. This rule matches our intuition that posts/latests should be preferred to posts/{id}, and /users/{u}/posts/latest should be preferred to /users/{u}/posts/{id}. It also makes sense for methods. For example, GET /posts/{id} takes precedence over /posts/{id} because the first only matches GET and HEAD requests, while the second matches requests with any method.

但是當有重疊卻無法判斷相對吻合度的 rule 被加進去時,會直接 panic()

What if two patterns overlap but neither is more specific? For example, /posts/{id} and /{resource}/latest both match /posts/latest. There is no obvious answer to which takes precedence, so we consider these patterns to conflict with each other. Registering both of them (in either order!) will panic.

這的確是種方法啦... 而且留有之後處理的空間,真的有好的方法就可以把 panic() 的邏輯改成新的共識。

透過無線 WiFi 的監視器的問題

在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries (tomshardware.com)」這邊看到的,原報導在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries -- smart security systems vulnerable as tech becomes cheaper and easier to acquire」。

這個手法是把無線網路的頻寬塞爆 (或是放出干擾),這樣 security camera 就算拍到東西也不會有記錄:

這個應該是已知的問題?從以前 security camera 都是建議走有線 (以及 isolated VLAN),無線的主要還是娛樂用途,而不是 security camera...

以前還有印象有看過防 EMP 的型號,不過那個是軍用...

nginx 分家:freenginx

Hacker News 上看到 Maxim Dounin 決定分家到 freenginx 的消息:「Freenginx: Core Nginx developer announces fork (nginx.org)」,原文在 mailing list 上:「announcing freenginx.org」,這邊提到分家的原因:

Unfortunately, some new non-technical management at F5 recently decided that they know better how to run open source projects. In particular, they decided to interfere with security policy nginx uses for years, ignoring both the policy and developers’ position.

在 freenginx 的 mailing list 上有提到更多,在 2024-February/000007.html 這篇:

The most recent "security advisory" was released despite the fact that the particular bug in the experimental HTTP/3 code is expected to be fixed as a normal bug as per the existing security policy, and all the developers, including me, agree on this.

And, while the particular action isn't exactly very bad, the approach in general is quite problematic.

這邊提到的 security advisory 是「[nginx-announce] nginx security advisory (CVE-2024-24989, CVE-2024-24990)」這個,看起來是個沒有 enabled by default 的功能:

Two security issues were identified in nginx HTTP/3 implementation,
which might allow an attacker that uses a specially crafted QUIC session
to cause a worker process crash (CVE-2024-24989, CVE-2024-24990) or
might have potential other impact (CVE-2024-24990).

The issues affect nginx compiled with the ngx_http_v3_module (not
compiled by default) if the "quic" option of the "listen" directive
is used in a configuration file.

The issue affects nginx 1.25.0 - 1.25.3.
The issue is fixed in nginx 1.25.4.

id=39373804 這邊有些目前 nginx 組成的資訊可以讀,目前 nginx 的 core devs 應該就三位 (在 Insights/Contributors 這邊看起來只有兩位,這是因為 GitHub 上面的 mirror 看起來是從 Mercurial 同步過去的,而 Sergey Kandaurov 沒有 GitHub 帳號):

Worth noting that there are only two active "core" devs, Maxim Dounin (the OP) and Roman Arutyunyan. Maxim is the biggest contributor that is still active. Maxim and Roman account for basically 99% of current development.

So this is a pretty impactful fork. It's not like one of 8 core devs or something. This is 50% of the team.

Edit: Just noticed Sergey Kandaurov isn't listed on GitHub "contributors" because he doesn't have a GitHub account (my bad). So it's more like 33% of the team. Previous releases have been tagged by Maxim, but the latest (today's 1.25.4) was tagged by Sergey

現在就是單方面的說法,可以再讓子彈多飛一點時間... 看 F5 要不要回應,以及 F5 的說法 (如果要回應的話)。

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡,兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet,這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet,但我希望 VM 是走社區網路,所以用 bridge mode 設定到網卡上,用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到,前幾天用 Line 傳照片的時候很慢 (之前就有發生了,一直忘記去追問題),花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢,這點可以從 Speedtest 的測試結果看到:

先講最後的結論,在交叉測了很多組合後,我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled

回到當時抓問題的情況,當時先用筆電與 host 測試都沒看到問題,所以看起來應該是 VM 裡面的狀況,但不確定是什麼情況,畢竟不是斷掉...

由於下載速度正常,只有上傳速度卡住,一開始想到的是跟 MTU 相關的問題,所以找了指令降到 1400 後測試,還是一樣...

後來先把 VM 的網路改成 NAT,再測試上傳速度就正常了...

接著想要換個網路卡類型看看,結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了,但想說先去看看 Windows 10 網卡設定裡面的設定,結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗?)。

然後一關就正常了,交叉再開關兩次確認這個參數有影響,就肯定這個 workaround 應該是有效了...

另外在自己找完問題後,在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

雲端的流量費用

在「Cloud Egress Costs (getdeploying.com)」這邊看到的文章,原文在「Cloud Egress Costs」這邊,主要是整理了表格出來可以快速了解不同雲端的流量費用差異,裡面不是單純 VPS 比較,而是各類的服務都拿出來比,像是 storage 類的以及 CDN 類的都有放進來...

Backblaze 的頻寬費用算法頗有趣,每個月給資料量的三倍大小當作免費頻寬,沒記錯的話因為 Cloudflare 是 Backblaze 的 partner,兩邊的傳輸費用不計費,如果資料是可以公開的,可以透過這個方式接出來;如果真的得走一般的流量輸出,收費是 US$0.01/GB (所以換算後是 US$10/TB)。

三家常被擺在一起的 VPS (LinodeDigitalOceanVultr) 的頻寬也都是 US$10/TB。

以前沒注意到的是 OVH CloudScaleway 的頻寬費用居然是免費的?另外 Hetzner 雖然要收費但也很低?有機會好像該玩看看,看一下品質如何?

停止使用 Spamhaus DNSBL

剛剛看到「If you query Spamhaus Projects’ legacy DNSBLs via DigitalOcean move to the free Data Query Service」這篇,覺得愈來愈詭異了,研究了目前的情況後決定停用 Spamhaus

現在已經愈來愈少自己架設 mail server 了,不過我自己還是留了幾個 domain 跑在自己架設的 Postfix 上面,最主要是 command line 下面用 Mutt 讀信還是蠻方便的,另外一方面是確保一個信箱是不受到大企業的管制。

如果不是拿套裝軟體直接架設的話,自己架設 mail server 會有不少東西要設定:在 MTA 這端通常會使用 DNSBL 擋掉已知會發 spam 的 IP address。

DNSBL 的原理不難,就是拿 IPv4 address 組合一個 hostname,透過 DNS 查詢就會知道這個 IPv4 address 是否在清單;換句話說,就是拿 DNS protocol 當作 API,當作資料庫查詢。

舉個例子來說,假設我要查 188.235.18.134 這個位置的情況 (從「Worst /24 blocks based on total spam count」這邊翻出來的),這邊使用 SpamCop 的清單,我先把 IPv4 address 反過來變成 134.18.235.188,然後再加上 SpamCop 所指定的 bl.spamcop.net,變成 134.18.235.188.bl.spamcop.net,接下來查詢就可以查到:

134.18.235.188.bl.spamcop.net has address 127.0.0.2

如果是 168.95.1.1 的話,同樣方法組合成 1.1.95.168.bl.spamcop.net 可以看到沒有在 SpamCop 清單內:

Host 1.1.95.168.bl.spamcop.net not found: 3(NXDOMAIN)

這邊選擇用 DNS 的好處包括了 DNS resolver 及 DNS library 自然的 cache,不需要 Postfix 這類 MTA 再自己實作 cache 層,對於有大量信件 (無論是正常的或是 spam) 進來的時候也不會造成提供清單的服務大量的負載。

回頭來說 Spamhaus 的情況,他們公告要擋 DigitalOcean 的理由很奇怪,因為 DigitalOcean 架設了自己的 mirror 所以他們不知道使用的量,要使用者去 Spamhaus 上註冊申請後拿到一個自己的 your_DQS_key.zen.dq.spamhaus.net 使用。

有了 unique key 在 query,這樣就給了 Spamhaus 很清晰追蹤資料,加上 Privacy Policy 裡面的資訊:

We may have to share your personal data with the parties set out below for the purposes set out in the table in paragraph 4.
[...]
– Third parties to whom we may choose to sell, transfer, or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy notice.

這樣就知道他們想要做什麼了...

另外一方面,查資料的時候發現他們已經擋掉 Google Public DNS 以及 Cloudflare DNS

這是我自己架設 Unbound 的查詢:

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2

這是 Google Public DNS (8.8.8.8):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

這是 Cloudflare DNS (1.1.1.1):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

在 Spamhaus 的「Frequently Asked Questions (FAQ)」這篇裡面有提到 127.255.255.254 的回應是「Query via public/open resolver」:

127.255.255.252	Any	Typing error in DNSBL name
127.255.255.254	Any	Query via public/open resolver
127.255.255.255	Any	Excessive number of queries

所以還蠻清楚這家的東西已經不能碰了...

看 Hacker News 上面文章變化的網站:Quality News

在『蒐集 Hacker News 上被不合理條件「消失」的連結』這篇看到的網站,定時去抓 Hacker News 上新的連結與首頁上的連結後整理出來的網站:「Quality News」。

像是現在在 top 1 的「John Walker, founder of Autodesk, has died (fourmilab.ch)」這篇,對應的資訊頁就在「Hacker News Story Stats: John Walker, founder of Autodesk, has died」這邊,抓個截圖:

這樣有些文章覺得奇怪時可以交叉看一下資料,就會對 Hacker News 上面的「操作」有些「感覺」了...

IFTTT 將原本的 Legacy Pro 漲價一倍

收到 IFTTT 的通知信件,本來的 Legacy Pro (US$1.99/mo) 要變成 Pro+ 變成 US$3.99/mo:

翻了一下 Hacker News,看起來前幾天有提到:「IFTTT is killing its pay-what-you-want Legacy Pro plan (2023) (techhive.com)」,原文看起來是去年六月的文章:「IFTTT is killing its pay-what-you-want Legacy Pro plan」,當時 IFTTT 的公告則是在「Important Update to the Legacy Pro Plan」這邊。

這看起來不是什麼好消息... 不是因為對 Legacy Pro 動手這件事情,而是這次的動作代表 (i.e. 我的解讀) 沒有足夠的新進用戶去「忽略」掉 Legacy Pro 的成本。

接下來應該是要思考拆出來的事情?畢竟手上有 VPS instance 可以跑...

換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

Vultr 推出了自己的 CDN

Vultr 推出了自己的 CDN:「Vultr CDN: Revolutionizing Content Delivery with Global Reach and Unbeatable Price-to-Performance」。

畢竟手上也有很多機房了,這算是弄個加值服務賣... 不過對於量小的人就不太划算了,有基本開銷 US$10/mo (看起來不可抵使用的量),然後再加上頻寬費:

亞洲區的點主要還是比較傳統的點... 其中日本的東京與大阪以及新加坡都是 US$0.03/GB,韓國的首爾則是 US$0.05/GB;歐美看起來是 US$0.01/GB。

目前還在 beta,可以觀望看看...