Category: CDN

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.

算是補產品線...

CloudFront 支援 TLS 1.3

看到 AWS 的公告，宣佈 CloudFront 支援 TLS 1.3：「Amazon CloudFront announces support for TLSv1.3 for viewer connections」。

預設會自動啟用：

TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections.

對使用者最大的差異應該還是改善 first byte 的時間 (主要是因為 handshake 時間縮短)，這點 AWS 的人也有提到在內部測試時，美國區的改善情況：

In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

在 latency 更高的地區應該也會有大幅改善...

Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務，用客戶的 IP address 放 routing 出去：「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast，不過這邊沒明講：

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6，在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到，以 Cloudflare 的技術架構，應該是都支援？

用自己的 IP 的好處，一個明顯的方向就是 firewall 會好設不少，另外如果需要服務中國或是其他管制地區，比較不會因為 IP space 混用誤殺受到影響？

Cloudflare 降低 Workers 的 Cold Start 時間的方法...

Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。

傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：

他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：

這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好...

Amazon Lightsail 也推出 CDN 服務了...

Amazon Lightsail 也推出 CDN 服務了：「Amazon Lightsail now offers CDN distributions to accelerate content delivery」。

這個服務是用 CloudFront 為底：

This native service, called Lightsail CDN, is backed by Amazon CloudFront, Amazon Web Services’ CDN platform that uses a global network of servers in over 200 locations across 42 countries to store and deliver your content throughout the world. Lightsail CDN distributions can be created and configured with just a few clicks for a low, predictable monthly price, and you can get started for free.

看了一下價錢，免費方案可以有 50GB/month，一般自己架個 WordPress 之類的 blog 應該是可以涵蓋在內。

付費方案中，USD$10/month 可以給 200GB，但 USD$35/month 只能給 500GB？這邊是用愈多愈貴，沒看懂這個定價方式啊...

但看起來是有不少機會比 CloudFront 便宜 (如果非歐美的流量不少的話)，再來就是 Lightsail CDN 這邊沒有列出每個 request 的費用，所以應該是不算這塊？這樣小檔案很多的話應該也是個選擇？

Amazon Lightsail 一直拿 AWS 自家東西出來市場上打架，現有的 VPS 不知道會怎麼提供類似的方案，搭 Cloudflare 嗎？或是找 Fastly 這些服務搭？(不過話說回來，Fastly 的牌價好貴 XD)

拿 Cloudflare Workers 跑 Geolocation API

在 Hacker News Daily 上看到拿 Cloudflare Workers 跑 Geolocation API：「How to make simple Geolocation service」。

作者想要做一個很簡單的 Geolocation API，一開始的想法是在 AWS Lambda 上用 MaxMind 的資料，但 latency 偏高：

However, I quickly realized that the response time isn't what I've expected - on average the response took somewhere between from 200ms to 500ms. So I started looking for other options.

所以作者就想到是不是有有機會丟到 Cloudflare Workers 上，但發現 license 看起來是個問題，另外因為把 MaxMind 的資料庫丟進去，會超過 worker 的時間限制：

And for this case MaxMind offers GeoLite2 database, however you'll be in charge of hosting this database on your server and making regular updates of the database. You also need to make sure your project is compliant with MaxMind's License.

However, this solution had one really big caveat - MaxMind GeoLite2 database does not work on Cloudflare Workers due to some runtime limitations.

結果作者後來發現 Cloudflare Workers 上本身就會帶 Geoloation 資訊了，不需要另外拉 MaxMind 的資料查：

And after exploring their documentation, I realized that the Request object in function have an access to cf object, which contains some useful information about the visitor, including visitor's country!

另外我翻了一下價錢，主要是算次數的，看起來 Free Plan 就可以 100K/day (執行時間限制是 10ms)，而如果是付費方案的話則是 USD$0.5/M (50ms)，這樣對一些小專案來說，Free Plan 似乎是夠用了...

AWS 推出直播服務 Amazon Interactive Video Service (Twitch-as-a-Service)

把直播系統包在一起的服務 Amazon Interactive Video Service：「Amazon Interactive Video Service – Add Live Video to Your Apps and Websites」。

這邊先抱怨一下，這個服務的網址是 https://aws.amazon.com/ivs/，但 Elastic Load Balancer (ELB) 卻是 https://aws.amazon.com/elasticloadbalancing/，這是差別待遇啊...

回到原來的主題，這個服務做了幾件事情。收到 RTMPS stream 後，他會轉成許多格式：

If you send the maximum 8.5Mbps, 1080p60 stream, Amazon IVS will create 8.5Mbps 1080p60, 3Mbps 720p60, 2Mbps 720p30, 1.2Mbps 480p30, 800Kbps 360p30, and 400Kbps 160p30 renditions in an ABR stream.

從這份列表可以看出他目前最高只支援 1080p60，而 1440p (2K) 或是 2160p (4K) 看起來都還不支援。

另外因為是包裝 AWS Elemental Media Services，所以有蠻多東西都一起可以拿進來用，像是廣告機制與 DRM，然後看起來可以選擇 CDN：

With AWS Elemental Media Services, you have a high level of control over all workflow components: transcoding and packaging configurations; levels of resilience; personalized ad insertion; and features like content protection for digital rights management (DRM). You also get to choose which video players and CDNs are used.

區域上只開了三區 (us-east-1、us-west-2 與 eu-west-1)，但我在看 AWS 上的標價時整個搞混：

一開始看的時候在找單位但發現沒標，後來研究了一下看起來應該是 per hour？這樣標看起來很像是前面一萬個小時只要 USD$0.32 啊？

另外一個比較有趣的事情是，看起來不像是用 CloudFront 做，因為收費區域的區分跟 CloudFront 不太一樣，實際開下去後發現似乎是用 Twitch 的架構？

我試著開了一個，給了 a9a09e285166.us-east-1.playback.live-video.net 這樣的 endpoint，實際測試發現的確是某種 CDN，指到台灣的機房：

;; ANSWER SECTION:
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 23.160.0.254
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 192.108.239.254

實際 traceroute 後發現不是 CloudFront，但反解後發現 dig 拋出了 Justin.tv 的資訊：

;; AUTHORITY SECTION:
0.160.23.in-addr.arpa.  300     IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 44 10800 3600 604800 300

;; AUTHORITY SECTION:
239.108.192.in-addr.arpa. 300   IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 49 10800 3600 604800 300

然後 traceroute 可以發現跟 video-edge-6ab612.tpe03.abs.hls.ttvnw.net (在 Twitch 上隨便找個實況抓的 hostname) 進到同一個機房 (在 router 還沒有擋下來的範圍)，看起來就是拿 Twitch 的頻寬做事 XDDD

Twitch-as-a-service XDDD

這包會不會是 Twitch 掛 AWS 牌推出的服務啊 XDDD

回頭來看一下 Limelight Networks

是因為看到「How Limelight Networks speeds up sales deals with Slack Connect」這篇，才想到 Limelight Networks 這家 CDN 之前也是這個產業很大的 vendor，在很多大型網站可以看到 llnw 的蹤跡 (當時 Microsoft 的 Windows Updates 與 Apple 的軟體下載還會用他的服務)，但這十年看起來就被 Cloudflare 與 CloudFront 以及 Fastly 這些後起之秀超越過去了... (至少在聲量上面是這樣)

翻到 Global Private Network 這頁，意外發現現在有把節點列出來了，記得以前是不公開的...

在裡面可以看到台灣也有節點，不過拿 HiNet 與 APOL (家裡的 cable) 實際測官網 www.limelight.com，發現都是導去香港的點，可能是有需要的客戶才會導過去，之後有機會也許問問看...

Cloudflare 也推出自己的 Speed Test 服務

Cloudflare 推出了自己的 Speed Test 服務：「Test your home network performance」。

這個服務跟 Netflix 推出的 fast.com 類似，測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度，主要的目的還是公關 (PR)，所以看看就好，實際上用 Speedtest 測出來會比較有參考價值，而且可以選擇不同的點測試...

不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇)，然後就有各種定時去打 Speedtest 觸發開放速限的方法...

目前好像只剩下這篇活著，內文提到的是 Android 上的方法，另外推文有人提到 iOS 下的方法：「[心得] 在Android破解遠X限速」，如果有遇到的可以用看看...

Cloudflare 的 Enterprise 客戶可以用 Secondary DNS 服務了

Cloudflare 宣佈了新，提供 Enterprise 客戶使用 Secondary DNS：「Secondary DNS — A faster, more resilient way to serve your DNS records」。

先前 Cloudflare 的客戶只能透過網頁或是 Cloudflare 提供的 API 管理 DNS，現在則是可以透過標準協定直接建出 Secondary DNS：

Starting today, enterprise customers who are entitled to secondary DNS will be able to configure their zone in the Cloudflare Dashboard.

這樣對於自己在管理 DNS 的客戶會方便不少 (像是用 BIND 的單位)，不過因為安全性的考量，需要啟用 TSIG 確保資料不會被竄改：

Zone transfers between a primary and secondary server are unauthenticated on their own. TSIGs (Transactional Signatures) were developed as a means to add authentication to the DNS protocol, and have mostly been used for zone transfers.

另外就會想到 StackOverflow (「StackOverflow 對於多 DNS 商的同步方式...」) 與 GitHub (「GitHub 也自己搞了一套管理多家 DNS 的程式...」) 的方式，是直接在不同的系統之間疊管理抽象層，這種搞法應該會更穩定，畢竟是直接丟到兩個不同系統管理。

然後我記得市場上有一些 Secondary DNS 的服務可以選，Cloudflare 目前看起來算是補產品線而不是進來殺市場 (畢竟是掛在 Enterprise 等級才能用)。