Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology:「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題,透過 Cloudflare 自家的骨幹網路,最佳化 latency & bandwidth & packet loss 產生的問題:「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了,主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料,而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server,就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好:就算是 Windows Update 或是 iOS 更新這種基數超大的量,一開始也許會慢一點,但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm,讓 edge server 都有 cache 後再上線,這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了,因為會一直產出新的內容 (之前玩的是走 HLS,所以會一直有新的 .ts 檔生出來),沒辦法先 pre-warm,這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務,所以需要 CDN 系統在中間疊一層 cache server,這個功能在各家 CDN 業者都有,只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate,這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1),而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+,相對於後端的壓力可以降到 50:1 到 100+:1。

AWSCloudFront 也有類似的架構,叫做 Regional Edge Caches:

不過這兩種架構都有一些缺點,像 Akamai 需要自己指定 cache server 的節點,這樣就不容易動態調整,或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的,就會遇到像是 origin server 與 edge server 都在台灣,但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡),產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache),看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier,不需要使用者額外設定。

不過一般網站應該還好,主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

PinePower 120W 充電器

在「PinePower 120W desktop power supply features display, USB PD, QC 3.0 and wireless charging」這邊看到 PinePower 120W 這個充電器:

提供了一個 Type-A QC 3.0 (18W) + 三個 Type-A 5V/3A (15W) + 一個 Type-C PD (65W),然後還有一個 Qi (10W),算了一下這些組合全部都跑滿要 138W,然後機器的上限提供 120W,這個集縮比超低,看起來也是頗猛的...

目前 out of stock,剛好可以等其他用過的人的評價...

LastPass 開始進入「殺」的階段,免費使用者只能在一個平台上使用

LastPass 進入了「套養殺」最後一個階段「殺」,宣佈縮減 LastPass Free 的可用範圍。在 2021/03/16 開始 (一個月後),LastPass Free 的使用者只能選擇一個平台使用,像是「桌機平台」,或是「行動平台」:「LastPass’ free tier will become a lot less useful next month」,官方的新聞稿則是在「Changes to LastPass Free」這邊。

官方有提供第一年的限時優惠 (換算起來應該是一年 USD$27),但不給既有用戶,現有的用戶如果要的話得自己換帳號 export & import,不然就是用原價殺 (一年 USD$36):

If you’d like unlimited device type access and email support, you can upgrade from Free to LastPass Premium for a limited time, for $2.25 per month (billed annually). *

*Additional Terms and Conditions: Advertised price valid for new users on their first year of LastPass Premium. Price not valid for renewals or existing customers and cannot be used for other LastPass plans, products or services.

不過這個優惠連結發現點下去是爛的:

話說回來,這種東西我自己還是偏好用 open source 方案,然後自己搭同步機制,不過目前看到的方案在跨桌機平台與行動平台的確是痛點... 有需求的人應該還是會選 LastPass 或是 1Password 這樣的方案。

把 AWS 的 Billing 資料接進 Grafana 上...

Twitter 上看到 Grafana 的帳號提到了一篇把 AWS Billing 資料接進 Grafana 上的文章:

這個想法還頗不賴的,有些東西剛好可以交叉比對拉出來...

Google Groups 把 comp.lang.c 給禁了...

Hacker News Daily 上看到的,Google Groupscomp.lang.c 給禁了,連到 https://groups.google.com/g/comp.lang.c 可以看到無法使用的訊息:

警告:內容已遭禁止
comp.lang.c 已被認定為包含垃圾內容、惡意軟體或其他惡意內容。

如要進一步瞭解 Google 網路論壇的內容政策,請參閱這篇關於濫用本服務的說明中心文章,以及我們的《服務條款》。

這樣連歷史資料都看不到了...

在 HTTP Header 裡面傳結構性資料

忘了在哪邊看到的,好像是 Twitter 上看到的,mnotphk 兩個人弄了一個新的 RFC 標準,可以在 HTTP header 裡面傳結構性資料:「Structured Field Values for HTTP」。

第一個最直接的問題就在「A.1. Why Not JSON?」這個章節說明,考慮了既有的限制,包括 JSON spec,以及市場上既有的 JSON library 的實做。

但也因為自己定義了資料結構,Serializing & Parsing 就得另外再開發 library 處理,這樣會有多少 framework 支援就是個問題了,而且對於開發者來說,直接塞 JSON 很好理解,這個標準的前景不知道會怎麼樣...

Dehydrated 取得憑證的預設演算法改成 secp384r1

這兩天弄 dehydrated,結果發現 v0.7.0 取得憑證的預設演算法改成 ECCsecp384r1 了:

Using EC secp384r1 as default certificate type

這會導致很多「稍微舊一點」的 client 失效 (瀏覽器與 library),不知道為什麼要預設... 目前避開的方法是強制在 /etc/dehydrated/config 內設定使用 rsa

KEY_ALGO=rsa

剛剛把公司一堆機器改上去,然後把自己的 server 也加一加...

Google Chrome 88 的 Search Engine Keyword 功能失效恢復的方法

升級到 Google Chrome 88 以後又再次被 Google 姦了,這次是 Search Engine Keyword 的功能預設被關掉:「Chrome 88 disables space bar shortcut for custom search engines, but there's a fix」,在「Google Chrome keyword search is no longer working」這邊也有類似的問題冒出來。

文章裡面有提到解法,在 chrome://flags 裡面挑一個設為 Disabled 就可以了,我是用 #omnibox-keyword-search-button 這組:

設定完成後要重開瀏覽器才會生效。

Wikimedia Commons 發現的印度異常流量

Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個,維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片,而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量:

由於 User-AgentReferer 都沒有資訊,可以確認這不是瀏覽器造成的流量,但也因為沒有有用的資訊,變得很難查。

接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關,因為在被 ban 後有很多使用者會去找替代的服務,而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。

所以他們把熱門的替代服務都看了一輪,也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上,所以開始交叉測試:在開 app 後就去 Hive 掃 HTTP log,然後找到一個 app。

後來為了要確認是不是這個 app,他們架了一組 DNS server 記錄查詢的網域名稱,看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱,而不出所料的確認了,而且真的就是在啟動時有抓,但是沒有顯示在畫面上。

接下來就是想辦法聯絡開發團隊,而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。

另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣,有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛,而且反應了很多次都沒用,然後他就把圖片換成「Netscape Now」,然後十五分鐘內就被解決了:

At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.

Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.

找了一下圖片,看起來應該是類似這種的圖:

要直接反擊讓人會痛... XD

Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD