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。

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

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 的部份,應該是還好...

拿 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 似乎是夠用了...

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 等級才能用)。

Cloudflare 改用自己的 CAPTCHA 服務 hCaptcha

CloudflareGooglereCAPTCHA 改用自家的 hCaptcha:「Moving from reCAPTCHA to hCaptcha」。

看起來其實就是錢的問題,reCAPTCHA 要收費了,而以 Cloudflare 的量會太貴:

Earlier this year, Google informed us that they were going to begin charging for reCAPTCHA. That is entirely within their right. Cloudflare, given our volume, no doubt imposed significant costs on the reCAPTCHA service, even for Google.

另外 hCaptcha 有提供免費版本給一般網站用,剛出來這幾天等白老鼠寫心得後,再決定要不要跳進去測試...

關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...