幹壞事是進步最大的原動力
看到 Cloudflare 在講他們打算在巴西佈 25 個點：「Expanding Cloudflare to 25+ Cities in Brazil」，目前可以看出來是八個點：
比較了領土的大小，跟美國扣掉阿拉斯加差不多等級：
人口的話美國是 328M 左右 (阿拉斯加不到 1M，不太影響感覺)，巴西 215M，依照 Cloudflare 在美國目前有 39 個 PoP 來說，的確是可以拉上去，不過看起來應該是因為有大的 ISP 合作的關係：
Today, we are excited to announce an expansion we’ve been working on behind the scenes for the last two years: a 25+ city partnership with one of the largest ISPs in Brazil.
不過沒提到是哪個 ISP，之後看看有沒有消息...
Amazon CloudFront 宣佈支援 ECDSA 的 certificate：「Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers」。
用主要是讓 certificate 更小，讓 HTTPS 建立時的過程更快 (包括了傳輸的速度與計算的速度)：
As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.
很久以前好像有看到資料說 256 bits 的 EC 運算量跟 768～1024 bits 的 RSA 差不多，但一時間找不到資料...
目前 CloudFront 只支援 NIST P-256 (secp256r1，或稱作 prime256v1)：
Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront.
但 NIST P-256 一直為人詬病，在「SafeCurves: choosing safe curves for elliptic-curve cryptography」這邊可以看到 NIST 宣稱的效率設計實際上都不是真的：
Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.
但目前標準是往 NIST P-256、NIST P-384 與 NIST P-521 靠攏 (主要是受到 CA/Browser Forum 的限制)，要其他 curve 的 certificate 也沒辦法生，目前可能還是繼續觀望...
在 Hacker News 上看到「Summary of June 8 outage (fastly.com)」這邊的討論，連結是 Fastly 官方先發布的說明：「Summary of June 8 outage」。
其中提到了是因為客戶的某些設定造成的：
10:27 Fastly Engineering identified the customer configuration
另外特別提到了 Fastly 的 WebAssembly 與 Compute@Edge，看起來應該就是這邊炸鍋：
Broadly, this means fully leveraging the isolation capabilities of WebAssembly and Compute@Edge to build greater resiliency from the ground up. We’ll continue to update our community as we make progress toward this goal.
我猜基本的資源保護機制應該有上 (像是在程式裡面自己 call 自己之類的，Fork bomb 之類的)，可能是這兩個東西互串的某些部份沒有保護到，就一路把資源吃完炸掉。
看起來後續會有比較完整的報告，到時候再來看看會透露出多少東西...
前幾天的新聞了，這兩天 Fastly 與 Cloudflare 也都發文章出來了，QUIC 成為標準：「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。
主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了，接下來可以等一些測試報告，看看在 web 這種已經有不少複雜的 workaround 機制下，TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。
在 QUIC 下的 https 協定會走 443/udp，如果防火牆是預設阻擋所有連線，然後逐條開放的話，需要另外開這組設定。
另外就是等 nginx 支援了，在「NGINX QUIC Preview」這邊有些資料，然後「">nginx-quic: log」裡面可以看到東西，裡面不少 commit 只是跟 nginx 本家同步而已，不過還是可以看到一些跟 QUIC 有關的...
AWS 宣佈 CloudFront 在印度與亞太區降價：「Amazon CloudFront announces price cuts in India and Asia Pacific regions」，回朔至這個月月初生效：
Amazon CloudFront announces price cuts of up to 36% in India and up to 20% in the Asia Pacific region (Hong Kong, Indonesia, Philippines, Singapore, South Korea, Taiwan, & Thailand) for Regional Data Transfer Out to Internet rates. The new CloudFront prices in these regions are effective May 1st, 2021.
比了一下現在的「Amazon CloudFront Pricing」與 Internet Archive 上的「Amazon CloudFront Pricing」，看起來 First 10TB、Next 40TB、Next 100TB 與 Next 350TB 的部份都有降，更多的部份則是維持原價。
對一般簡單用的人來說，主要是落在 First 10TB 這個區間，亞太區的每 GB 單價從 USD$0.14 降到 USD$0.12，不無小補，而有夠大的量的單位應該都去談 commit & discount 了...
Amazon CloudFront 本來的 Lambda@Edge 產品線拆細，多出一個 CloudFront Functions：「Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale」。
就產品面的角度就是限制比 Lambda@Edge 多，但價錢變便宜很多。
先看價錢的部份，CloudFront Functions 的價錢只有 request：
Invocation pricing is $0.10 per 1 million invocations ($0.0000001 per request).
而 Lambda@Edge 則是兩筆費用，光是 request 費用就是六倍：
Request pricing is $0.60 per 1 million requests ($0.0000006 per request).
Duration is calculated from the time your code begins executing until it returns or otherwise terminates. You are charged $0.00005001 for every GB-second used.
當然，CloudFront Functions 便宜帶來的限制也不少，最主要的限制可以從最大執行時間只有 1ms，以及記憶體只能用 2MB 就可以看出來：
但這對於輕量的操作來說已經夠用了，主要就是對 HTTP header 的操作...
另外比較表上看到個有趣的點「JavaScript (ECMAScript 5.1 compliant)」，這樣應該就不會是 Node.js (V8 engine)，而是其他的 JS engine？
2018 年的時候寫過一篇 Cloudflare 在嘗試 ARM 伺服器的進展：「Cloudflare 用 ARM 當伺服器的進展...」，後來就沒有太多公開的消息，直到這幾天看到「ARMs Race: Ampere Altra takes on the AWS Graviton2」才看到原因：
By the time we completed porting our software stack to be compatible with ARM, Qualcomm decided to exit the server business.
所以是都測差不多，也都把 Cloudflare 自家的軟體搬上去了，但 Qualcomm 也決定收手，沒機器可以用...
這次再次踏入 ARM 領域讓人想到前陣子 Apple 的 M1，讓大家看到 ARM 踏入桌機與筆電領域可以是什麼樣貌...
這次 Cloudflare 選擇了 Ampere Altra，這是基於 Neoverse N1 的平台，而這個平台的另外一個知名公司就是 AWS 的 Graviton2，所以就拿來比較：
可以看到 Ampere Altra 的核心數多了 25% (64 vs. 80)，運作頻率多了 20% (2.5Ghz vs. 3.0Ghz)。測試的結果也都有高有低，落在 10%～40% 都有。
不過其中比較特別的是 Brotli - 9 的測試特別差 (而且是 8 與 10 都正常的情況下)：
依照 Cloudflare 的說法，他們其實不會用到 Brotli - 7 以及更高的等級，不過畢竟有測出來，還是花了時間找一下根本原因：
Although we do not use Brotli level 7 and above when performing dynamic compression, we decided to investigate further.
反追問題後發現跟 Page Faults 以及 Pipeline Backend Stalls 有關，不過是可以改寫避開，在避開後可以達到跟 Graviton2 類似的水準：
By analyzing our dataset further, we found the common underlying cause appeared to be the high number of page faults incurred at level 9. Ampere has demonstrated that by increasing the page size from 4K to 64K bytes, we can alleviate the bottleneck and bring the Ampere Altra at parity with the AWS Graviton2. We plan to experiment with large page sizes in the future as we continue to evaluate Altra.
但目前看起來應該都還算正向，看起來供貨如果穩定的話，應該有機會換過去？畢竟 ARM 平台可以省下來的電力太多了，現在因為 M1 對 ARM 的公關效果太驚人的關係，解釋起來會更輕鬆...
沒介紹過 Akamai 的一些架構，先講到 Akamai 的 Edge 端 Serverless 架構是 EdgeWorkers，跑的是 JavaScript：
EdgeWorkers lets developers just code — integrating into existing CI/CD workflows and enabling multiple teams to work in parallel using JavaScript. EdgeWorkers eliminates the hassle of managing compute resources and building for scale.
然後這次推出的是 EdgeKV，目前還在 Beta 版：「Serverless Storage at the Edge (EdgeKV Beta)」。
如同名字所說的，架構上 Key-Value 架構，放棄了 CAP theorem 裡面的 C，改走 Eventual Consistency：
EdgeKV uses what is known in distributing computing as an eventual consistency model to perform writes and updates. This model achieves high availability with low read latency by propagating data writes globally. The period of time it takes the system to distribute data globally is called the “inconsistency window”.
隔壁 Cloudflare Workers KV 也是 Eventual Consistency (出自「How KV works」這邊)：
KV achieves this performance by being eventually-consistent. Changes are immediately visible in the edge location at which they're made, but may take up to 60 seconds to propagate to all other edge locations.
看起來算是補上競爭對手的產品線...
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. 操作起來要很流暢)...
看到 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.
然後最近都至少是兩個點在開了，對服務穩定性比較好，維修的影響也比較小...