Category: CDN

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

CloudFront 在印度的第六個區域：加爾各答

查了一下資料才發現，印度應該是僅次於北美的單一國家 CloudFront 最多點的地區：「Amazon CloudFront announces its first Edge locations in Kolkata and Hamburg」。

以「Amazon CloudFront Key Features」這頁列出的資料可以看到印度有第六個區域了：

Edge locations: Bangalore, India (3); Chennai, India (2); Hong Kong, China (3); Hyderabad, India (4); Kolkata, India; Kuala Lumpur, Malaysia (2); Mumbai, India (3); Manila, Philippines; New Delhi, India (4); Osaka, Japan; Seoul, South Korea (4); Singapore (4); Taipei, Taiwan(3); Tokyo, Japan (16)

不過如果以節點總數來說的話，印度與日本都是 17 個 (德國是 16 個)，而且光東京這區就 16 個，這又更感覺得出網路重鎮的味道...

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係，可以預期網路的流量一定會大幅提昇，但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化：「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比，可以看到許多區域的流量都有大幅成長，尤其是重災區的義大利與英國，不過這邊沒有給與 2019 三月的比較 (YoY)：

另外是這些流量成長的種類，可以看到 streaming、數位媒體與教育類的流量大幅成長：

在網路速度的部份，可以看到大多數的地區是下降的，但加州沒什麼影響，而日本反而是上升的，應該可以解讀為這兩個地區平常就有夠多的容量，所以真的有爆量而用到的時候反而不會是瓶頸？

接下來幾個月應該會更嚴峻...

Cloudflare 改用自己的 CAPTCHA 服務 hCaptcha

Cloudflare 從 Google 的 reCAPTCHA 改用自家的 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 的資訊，配到的伺服器的頻寬就不會太差...

Cloudflare 的另外一個策略：不熱門的資料只放到記憶體內

前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...

Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...

AWS Global Accelerator 的 TCP 協定

AWS Global Accelerator 是讓使用者先連到最近的 AWS 節點，再透過 AWS 的骨幹網路連到服務上 (可以參考之前寫的「AWS 推出 Global Accelerator，用 AWS 的網路加速」這篇)，當時就有說支援 TCP 與 UDP，但剛剛看到「AWS Global Accelerator launches TCP Termination at the Edge」這篇的時候才注意到，本來的產品是把 TCP 封包當作 UDP 在處理，也就是 TCP 3-way handshake 還是要到服務節點本身處理。

現在這個 TCP Termination 的功能則是先在最近的節點上建立 TCP 連線，然後同時往後端的建立連線接起來：

Typically, a TCP connection is established by using a three-way handshake (that is, three messages) between the client on the internet and the application endpoint in the AWS Region. So the farther away the client is from the endpoint, the longer the initial connection setup takes. With TCP termination at the edge, Global Accelerator reduces initial setup time by establishing a TCP connection between the client and the AWS edge location closest to the client. At nearly the same time, Global Accelerator creates a second TCP connection between the edge location and the application endpoint in the AWS Region. With this process, the client gets a faster response from the Global Accelerator edge location, and the connection from the edge location to the application endpoint in the Region is optimized to run over the AWS global network.

這樣連線的速度就會更快，但有可能會有前面建起來但後面建不起來的情況需要處理，一般的應用程式應該還好，畢竟地球上有個 GFW 也常幹這種事情...

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：

另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家，差異就更大了：

另外一個好處是改善 privacy，不過好像沒特別提到...