Tag: cdn

Cloudflare 新增高雄節點

看到「Network Performance Issues in Kaohsiung City, Taiwan」這個發現 Cloudflare 有了高雄節點，但不確定是什麼時候，所以去 Internet Archive 上翻，發現應該就是這幾天的事情...

9/20 的 20220920130956 版本還沒有高雄，但到了 9/25 的 20220925191430 就出現了。

手上沒有高雄的機器可以測，明天來問問看高雄的朋友好了...

CloudFront 在越南開點

AWS 宣佈在越南設立 edge：「AWS announces new edge locations in Vietnam」。

新的 edge 包括了各種服務，像是標題寫到的 CloudFront：

The new locations offer edge networking services including Amazon CloudFront and AWS Global Accelerator that are integrated with security service AWS Shield that includes Distributed Denial of Service (DDoS), Web Application Firewall (WAF), and bot protection.

看起來是拓點，第一次進到越南，先前應該是會被導去泰國或是香港？

不過在 CloudFront 的「Global Edge Network」頁面上面意外的還沒看到越南的點 (參考 Internet Archive 的這邊以及 archive.today 的這邊)。

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect)：「Netflix 在單機服務 400Gbps 的影音流量」，快一年後的目前，Netflix 的人已經成功推到接近 800Gbps 了：「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片，最後衝到 720Gbps，主要是因為 NIC output drop，而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短？)，如果有看過前面的內容可以快速看一下就好，這次新的東西從 page 89 開始：

  • Asynchronous Sendfile (2014)
  • Kernel TLS (2016)
  • Network-centric NUMA (2019)
  • Inline Hardware (NIC) kTLS (2022)
  • 800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台：

  • AMD (EPYC 7713 CPUs)
  • Dell (PowerEdge R7525)
  • Mellanox/NVIDIA (ConnectX-6 Dx NICS)
  • Intel (P5316 NVME)

下個目標不知道是什麼，看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...

CloudFront 支援 HTTP/3

雖然 HTTP/3 還沒有進到 Standard Track，但看到 CloudFront 宣佈支援 HTTP/3 了：「New – HTTP/3 Support for Amazon CloudFront」。

只要在 CloudFront 的 console 上勾選起來就可以了：

看了看 RFC 9114: HTTP/3 文件裡的描述，client 可以試著建立 UDP 版本的 QUIC 連線，但要有機制在失敗時回去用 TCP 的 HTTP/2 或是 HTTP/1.1：

A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級：

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

像是這樣：

Alt-Svc: h3=":50781"

然後 client 就可以跑上 HTTP/3：

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

另外在 FAQ 裡面有提到啟用 HTTP/3 是不另外計費的，就照著本來的 request 費用算：

Q. Is there a separate charge for enabling HTTP/3?

No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.

先開起來玩看看...

今年三月的時候 Limelight Networks 買了 Edgecast，改名為 Edgio

查資料的時候才發現的新聞，Limelight Networks 買下 Edgecast，改名為 Edgio：「Limelight to Acquire Yahoo’s Edgecast, Creating Global Leader in Edge Enabled Software Solutions」，然後 NASDAQ 代碼從 LLNW 改成 EGIO。

不過本來 Edgecast 本來在台灣是有點的 (跟 HiNet 合作)，現在看起來在 network map 上面沒出現了：

不過直接抓 www.edgecast.com 還是可以看到是中華的機房：

  2.|-- 168-95-170-94.hinet-ip.hi  0.0%    10    2.0   3.0   1.5  11.4   3.0
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 220-128-24-53.hinet-ip.hi  0.0%    10    7.0   6.8   6.4   7.7   0.4
  6.|-- 211-20-238-81.hinet-ip.hi  0.0%    10    6.1   6.9   6.1   9.7   1.0
  7.|-- 152.195.35.156             0.0%    10    7.1   6.7   6.3   7.4   0.4

但 edg.io 看起來是丟去新加坡：

  2.|-- SNUH-3302.hinet.net        0.0%    10    1.8   2.6   1.2  11.4   3.1
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- pcpd-4101.hinet.net        0.0%    10    1.8   2.2   1.8   3.0   0.4
  5.|-- pcpd-4001.hinet.net        0.0%    10    2.2   2.6   2.1   3.3   0.4
  6.|-- ix-ae-17-0.tcore1.svw-sin  0.0%    10   48.6  50.7  48.6  61.7   4.0
  7.|-- if-be-45-2.ecore2.esin4-s 60.0%    10   49.1  48.7  48.1  49.1   0.4
  8.|-- if-be-10-2.ecore2.svq-sin  0.0%    10   52.3  50.7  49.3  55.1   1.8
  9.|-- 117.121.251.241            0.0%    10   49.7  50.1  49.5  50.6   0.4
 10.|-- 208.69.180.13              0.0%    10   49.6  49.9  49.0  51.8   0.8

再找機會研究看看...

Cloudflare 推出了讓你買 cache 空間的 Cache Reserve

這幾天 Cloudflare 推出了一大包東西，其中一個是 Cache Reserve：「Introducing Cache Reserve: massively extending Cloudflare’s cache」。

一般的使用情境是依照 LRU 演算法在決定 Cloudflare 的 cache 滿的時候要排除誰：

We do eviction based on an algorithm called “least recently used” or LRU. This means that the least-requested content can be evicted from cache first to make space for more popular content when storage space is full.

Cache Reserve 就是自己買 cache 空間，他的作法是你付 R2 的空間費用：

Cache Reserve is a large, persistent data store that is implemented on top of R2.

這樣就可以完全依照 Cache-Control 這類 HTTP header 內的時間保存了，你就不用擔心會被 purge 掉，首先價錢包括了 R2 的部份：

The Cache Reserve Plan will mimic the low cost of R2. Storage will be $0.015 per GB per month and operations will be $0.36 per million reads, and $4.50 per million writes.

另外還有還沒公告的 Cache Reserve 的部份：

(Cache Reserve pricing page will be out soon)

對於很極致想要拼 hit rate 的使用者來說是個選擇就是了，另外可以想到直播相關的協定 (像是 HLS) 好像可以這樣搞來壓低對 origin server 的壓力？

Akamai Shared Domains 加入 PSL (Public Suffix List)

Akamai 把自家的 shared domains 申請加入 PSL (Public Suffix List)：「Adding Akamai Shared Domains to the Public Suffix List」。

提到 PSL，常被拿來舉例的應該就是 supercookie 了，也就是把 cookie 的有效網域設到 .com 或是 .org 這種 top level domain，這樣就可以跨很多站台追蹤使用者了 (所以被稱為 supercookie)，而 PSL 則可以被拿來限制這些網域名稱。

而在 Akamai 的例子來說，edgekey.net 下面的使用者都會共用 cookie，對於安全與隱私的考量其實不太好。這次把這些網域加到 PSL 之後，變成 edgekey.net 這層無法設定 cookie，而 one.edgekey.net 與 two.edgekey.net 各自有自己的 cookie namespace，這樣就好一些了...

順帶一提，除了瀏覽器會引入 PSL 來過濾外，使用者端可以靠 Privacy Badge 來過濾掉這類的 cookie，因為 Privacy Badge 會針對這類網域清掉 cookie 再送出 HTTP request。

Akamai 的文章裡面也有提到這件事情：

The PSL contains multi-party domain suffixes and is used by a wide range of client software (for example, web browsers) to implement policy decisions, such as to prevent cookies from being set on public or multi-party domains.

Cloudflare 在那霸設點

Cloudflare 宣佈增加了一堆 PoP：「New cities on the Cloudflare global network: March 2022 edition」。

日本在這波加了兩個：

  • Fukuoka, Japan
  • Naha, Japan

福岡不算太意外，畢竟東京與大阪都已經有 PoP 了，以距離來說，開在福岡算是去吃九州的人口，而且以流量來說應該也夠大，是可以投資的點。

而沖繩那霸就真的比較意外了，如果要猜的話，也許就是談福岡的時候順便一起談？

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

168.95.1.1 與 168.95.192.1 對 CloudFront 的差異

tl;dr 版本：目前先用 PPPoE 發出來的 DNS resolver 設定，如果要自己設定的話，用 168.95.192.1 (主) + 168.95.1.1 (次) 然後關掉 round-robin 模式。

剛剛看 SmokePing 時發現的奇怪現象，同樣都是在 HiNet 下面的機器與 DNS resolver，但 CloudFront 會給出不同的機房提供服務。

講的更仔細的是，168.95.192.1 這組會給出 tpe 系列的機房，所以 latency 會比較低，但如果你用的是 168.95.1.1 的話，就會到處丟，包括日本的 nrt 系列，與香港的 hkg 系列。

這邊拿 d36cz9buwru1tt.cloudfront.net 這組網域觀察，這是 AWS 官網用的資源，從官網的 html 原始碼裡面可以看到。

以第四台網路上面的機器上面來看 (北都，我分配到的線路是走台灣智慧光網的線路)，可以看到這邊 latency 會飄：「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

看了一下 DNS 設定，第四台的 ISP 給了兩組 DNS resolver 設定給分享器，分別是 168.95.1.1 與 8.8.8.8，然後分享器的 DNS resolver 是 round-robin，所以有時候會在台灣，有時候就連出國...

不過這組不能直接說是 AWS 的問題，因為 ISP 自己不架 DNS server，還跑去用 HiNet 的，有 sub-optimal 的問題也是很正常...

另外就是確認放在 HiNet 線路上的機器，這邊 ISP 透過 PPPoE 給了 168.95.192.1 與 168.95.1.1，但因為是直接進到 /etc/resolv.conf，所以只有在第一組爛掉的時候才會導去第二組 (預設值)，所以看起來就很穩：「d36cz9buwru1tt.cloudfront.net (CloudFront)」。

實際分析從 HiNet 去 168.95.1.1 與 168.95.192.1 查時，也可以看到類似的情況，像是用這樣的 command 去看 168.95.1.1 的情況：

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.1.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

可以看到給出來的點都是日本 (nrt 與 kix)：

server-13-225-178-1.nrt57.r.cloudfront.net.
server-143-204-74-1.nrt12.r.cloudfront.net.
server-18-65-171-1.nrt57.r.cloudfront.net.
server-18-65-99-1.kix50.r.cloudfront.net.
server-54-192-254-1.nrt51.r.cloudfront.net.
server-54-230-123-1.kix56.r.cloudfront.net.
server-99-84-55-1.nrt20.r.cloudfront.net.

如果改掃 168.95.192.1 的話：

( repeat 1000 host d36cz9buwru1tt.cloudfront.net 168.95.192.1 ) | grep 'has address' | awk '{print $NF}' | awk -F. '{print $1 "." $2 "." $3}' | sort -u | awk '{print $1 "." 1}' | xargs -n1 host | awk '{print $NF}'

就會完全在台灣機房：

server-13-35-163-1.tpe50.r.cloudfront.net.
server-13-35-36-1.tpe51.r.cloudfront.net.

用先前提到的「用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊」看起來 ECS 相關資訊都被拔掉了，但不確定關聯性是怎麼樣，但可以確定的是如果你設到 168.95.1.1 的話會是 sub-optimal experience...

有人吃飯工具用 CloudFront 的 (像是公司的服務)，而且手上有 bussiness support 或是 enterprise support 的，可以自己測過確認後去開 ticket 跟 AWS 看看怎麼弄，我這邊沒這些管道 XD