Category: CDN

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。

在 AWS 的 CloudFront 也有類似的架構，叫做 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. 操作起來要很流暢)...

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了：「Good-bye ESNI, hello ECH!」。

上面這張圖是 ESNI，下面這張是 ECH：

可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了，伺服器會先試著解內層的 ClientHelloInner，失敗的時候會用外層的 ClientHelloOuter：

The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣，這樣就能順便解掉 censorship 的問題...

其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI：

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.

In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.

不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis)，目前看起來只處理了 ClientHello 本身，現在還是有機會分析 handshake 過程來擋，必須繼續改善 ECH 的協定，讓整個流程看起來都跟一般的 TLS 一樣...

可以等著看，到時候在中國的效果如何了，會不會讓國外的各大服務直接打進去呢...

Cloudflare 拔掉使用 Cookie 分析的功能

這兩則應該可以一起看，雖然相差了兩個多月。

首先是今年九月底的時候提供隱私優先的分析系統：「Free, Privacy-First Analytics for a Better Web」，接下來是最近 (十二月) 宣佈要把 __cfduid 這組 cookie 拔掉：「Deprecating the __cfduid cookie」。

文章裡面沒有提到現在是怎麼偵測的，但我猜是瀏覽器的 fingerprint 資料已經足夠辨識了，不需要用到 cookie，這點可以參考 EFF 的「Cover Your Tracks」。

所以 privacy-first 這件事情也只是程度上而已，為了要防禦 bot，還是得正確辨識出不同的使用者，也就是說，現在不用 cookie 不代表 privacy 就高很多。不過這的確是試著在技術上努力降低疑慮就是了...

真的想要在 internet 上隱藏身份的人還是用 Tor 吧，基本上最少應該拿 Tor Browser，更小心一點應該用 Tails 這類軟體。

CloudFront 新增泰國節點

看到 Amazon CloudFront 新增了泰國曼谷節點的消息：「Amazon CloudFront launches in Thailand」，原來泰國之前沒開啊...

Amazon CloudFront announces its first two edge locations in Thailand.

另外依照網路架構，先前泰國的流量應該是往新加坡或是香港跑 (我覺得新加坡可能比較像？)，不過也不是那麼確定... 畢竟地理位置比較近的馬來西亞可以透過陸地就拉過去，不需要走海纜，只是不確定馬來西亞的點有沒有買 transit：

These new edge locations in Bangkok will provide viewers as much as a 30% reduction in p90 latency measures.

然後最近都至少是兩個點在開了，對服務穩定性比較好，維修的影響也比較小...

Backblaze 與 Fastly 合作

Twitter 上看到的消息，Backblaze 與 Fastly，免除 Origin 到 CDN 這段的流量費用：

新聞稿是「Set Your Content Free With Fastly and Backblaze B2」這篇：

Our new collaboration with Fastly, a global edge cloud platform and CDN, offers an integrated solution that will let you store and serve rich media files seamlessly, free from the lock-in fees and functionality of closed “goliath” cloud storage platforms, and all with free egress from Backblaze B2 Cloud Storage to Fastly.

不過這不是第一家提供這樣的方案，在 2018 年的時候就有跟 Cloudflare 合作，免除了 Origin 端到 CDN 端這段費用：「Backblaze 與 Cloudflare 合作，免除傳輸費用」。

Cloudflare 也要支援 AVIF

Cloudflare 針對 Image Resizing 增加了 AVIF 的支援：「Introducing support for the AVIF image format」。

We've added support for the new AVIF image format in Image Resizing.

照 comment 的地方看起來是 Business 功能，之後有機會下放到 Pro，但免費版應該不會出現：

Kornel Ian K Homan • 15 hours ago
This is part of the Image Resizing feature, which is currently available for Business plans. It's coming to Polish in the near future, which is a Pro plan feature.

這跟「Chrome 85 支援 AVIF」應該有些關係，加上其他瀏覽器也陸陸續續打算要支援，是個先做不虧的感覺...

Cloudflare 推出 Cron Triggers

Cloudflare 推出了 Cron Triggers，有兩篇說明：「Introducing Cron Triggers for Cloudflare Workers」、「Making Time for Cron Triggers: A Look Inside」。

底層架構上是用 Nomad 做的：

To consume the schedules and actually trigger the Worker, we built a new service in Rust and deployed to our edge using HashiCorp Nomad. Nomad ensures that the schedule runner remains running in the edge node and can move it between machines as necessary.

多了定時跑程式的能力後，整個 serverless 平台的拼圖又多了一塊，現在看起來應該是要發展 storage 與 database-like 系統...

Cloudflare 推出 Workers Durable Objects

這幾天 Cloudflare 丟出蠻多東西的，挑一些比較想寫下來的來寫，其中一個是他們的 serverless platform 又提供另外一種 database 了：「Workers Durable Objects Beta: A New Approach to Stateful Serverless」。

先前的產品是 eventually-consistent database (放掉 CAP theorem 裡面的 C)，也就是 Workers KV，這次提供的是 strong consisteny 版本的 database，叫做 Workers Durable Objects。

目前還沒看到文件，網站上的 Products 裡只放了 Workers KV 的，目前只能就敘述上猜。

以 blog 文章的敘述看起來是保護了 C 的部份，但不知道是放掉 AP 裡面哪個，也許是 A 的部份，因為文章裡一直都沒提到 high availability。

看起來是個有趣的產品，之後等更多文件出來的時候再研究。

Amazon CloudFront 增加墨西哥與紐西蘭的點

Amazon CloudFront 新增加了四個點，兩個在墨西哥，兩個在紐西蘭：「Amazon CloudFront launches in two new countries - Mexico and New Zealand」。

比較特別的是墨西哥的點仍然是被併入北美區的價錢，也就是 CloudFront 裡面最低的那組價錢：

In Mexico, our two new edge locations in Querétaro will provide viewers as much as a 30% reduction in p90 latency measures. These new edge locations are priced within CloudFront’s North America geographic region.

所以這代表在墨西哥當地的網路成本跟美國是一樣低？

CloudFront 宣佈支援 Brotli

CloudFront 宣佈支援 Brotli：「Amazon CloudFront announces support for Brotli compression」。

官方的說明發現 Gzip 可以好 24%：

CloudFront's Brotli edge compression delivers up to 24% smaller file sizes as compared to Gzip.

Akamai 在「Understanding Brotli's Potential」這邊提到的測試數字稍微做了分類，可以看到在 html 下 Brotli 帶來的改善是最多的。

以前在 CloudFront 上還是可以支援 Brotli，主要是透過後端支援 Brotli 的方式傳回不同的資料，再加上 Vary: Accept-Encoding 的設定讓 CloudFront 針對不同的 Accept-Encoding 分開 cache。

這次的支援等於是讓 CloudFront 理解 Brotli，就可以提昇 hit rate 並且降低後端的壓力：

Prior to today, you could enable Brotli compression at the origin by whitelisting the 'Accept-Encoding' header. Now CloudFront includes 'br' in the normalized 'Accept-Encoding' header before forwarding it to your origin. You no longer need to whitelist the 'Accept-Encoding' header to enable Brotli origin compression, improving your overall cache hit ratio. Additionally, if your origin sends uncompressed content to CloudFront, CloudFront can now automatically compress cacheable responses at the edge using Brotli.

算是補產品線...