Tag: cdn

關於 twemoji.maxcdn.com 這個網址的一些事情

在「phpBB 3.3.10 Release」這邊看到這個修正，研究了一下發現原來有些故事在後面跑：

Update the emoji CDN: PHPBB3-17071

Twitter Emoji (Twemoji) 這個計畫是 Twitter 弄出來的 open source project，最主要是讓不支援新版 Unicode 的系統上可以改用圖片顯示出來 (畢竟 Unicode 一直在加字)。

其中提供的 url 是 https://twemoji.maxcdn.com/v/latest/twemoji.min.js，可以看到裡面帶有 MaxCDN 的資訊，算是一種廣告，但後來 StackPath 在 2016 併購 MaxCDN，接下來是在去年打算要淘汰掉 MaxCDN 這個產品線：「MaxCDN and SecureCDN are Retiring; Here’s What It Means for You」。

這件事情被帶到「Clarify MaxCDN URLs now that MaxCDN is retiring #556」這邊討論，但看起來沒有太多動作，後來在「Maxcdn has shut down, cdn not working anymore. #580」這邊又被帶起來討論，其中 Twitter 前員工大概提了一下情況，主要是當年他們跟 MaxCDN 有談過讓 MaxCDN 負責頻寬的部份：

@simplexx among all the things, twemoji has always been a Twitter service for the community.

At my times in there, we had a great agreement / deal with MaxCDN so that it's hard to blame the boss this time, as MaxCDN is a completely different company/story.

What I see is some poor attention to this project, as companies don't close from a day to another (usually?) but as we all know what's going on @ twitter, I can't really blame any of my former colleagues, or new arrivals there.

Please let's not make it a wall of shame for all the people that worked on this, thanks for your understanding (I've left 7 years ago or more, as example, I've got pinged by some follower and I'm just trying to help you out anyway).

另外也有人提到目前 Twitter 的溝通管道的狀況：

For what it's worth, while I was still there we were in talks with MaxCDN to have the same deal when they migrated to be Stackpath. Everyone who had worked on the deal with MaxCDN had left and left no record of that deal, so it was taking them a bit longer to work out than expected – MaxCDN used to offer free hosting to OSS projects, but Stackpath wouldn't be doing that. They were working on an exception for us, but any emails they send to our Twitter emails now get bounced, so I guess they could've gotten this sorted out before shutting down MaxCDN... but it's not like we're there on the other end to make it happen, so it appears we'll never know.

Anyway，現在是至少讓 twemoji.maxcdn.com 恢復到「會動」了，但情況變得很特殊，twemoji.maxcdn.com 這個網址目前是指到競業的 BunnyCDN 上：

;; ANSWER SECTION:
twemoji.maxcdn.com.     229     IN      CNAME   twemoji.b-cdn.net.
twemoji.b-cdn.net.      35      IN      A       23.248.177.58

但如果你真的打過去要檔案，會是 301 到 jsDelivr 上：

$ http https://twemoji.maxcdn.com/2/svg/1f525.svg
[...]
Location: https://cdn.jsdelivr.net/npm/twemoji@11.3.0/2/svg/1f525.svg
[...]

而 jsDelivr 目前是放在 Fastly 上：

;; ANSWER SECTION:
cdn.jsdelivr.net.       180     IN      CNAME   jsdelivr.map.fastly.net.
jsdelivr.map.fastly.net. 30     IN      A       199.232.45.229

但在 GitHub 的說明上面則是建議用 UNPKG：

<script src="https://unpkg.com/twemoji@latest/dist/twemoji.min.js" crossorigin="anonymous"></script>

而 UNPKG 目前的 CDN 的部份則是 Cloudflare：

;; ANSWER SECTION:
unpkg.com.              86400   IN      NS      anirban.ns.cloudflare.com.
unpkg.com.              86400   IN      NS      aron.ns.cloudflare.com.
;; ANSWER SECTION:
unpkg.com.              300     IN      A       104.16.126.175
unpkg.com.              300     IN      A       104.16.123.175
unpkg.com.              300     IN      A       104.16.122.175
unpkg.com.              300     IN      A       104.16.124.175
unpkg.com.              300     IN      A       104.16.125.175

指到 BunnyCDN 但是 BunnyCDN 只負責 redirect，然後也不是導到 UNPKG 上...

Cloudflare 宣佈漲價

Cloudflare 寫了一篇很長的漲價公告：「Adjusting pricing, introducing annual plans, and accelerating innovation」。

25% 的漲幅，本來的 Pro Plan 從 $20/mo 漲到 $25/mo，本來的 Business Plan 從 $200/mo 漲到 $250/mo：

Cloudflare is raising prices for the first time in the last 12 years. Beginning January 15, 2023, new sign-ups will be charged $25 per month for our Pro Plan (up from $20 per month) and $250 per month for our Business Plan (up from $200 per month). Any paying customers who sign up before January 15, 2023, including any currently paying customers who signed up at any point over the last 12 years, will be grandfathered at the old monthly price until May 14, 2023.

然後丟出年費方案，就跟原來的月費方案寄算十二個月一樣的價錢 ($240/y 與 $2400/y)：

We are also introducing an option to pay annually, rather than monthly, that we hope most customers will choose to switch to. Annual plans are available today and discounted from the new monthly rate to $240 per year for the Pro Plan (the equivalent of $20 per month, saving $60 per year) and $2,400 per year for the Business Plan (the equivalent of $200 per month, saving $600 per year). In other words, if you choose to pay annually for Cloudflare you can lock in our old monthly prices.

後面就是很長的解釋...

CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)

看到 CloudFront 宣佈支援帶入 JA3 資訊了：「Amazon CloudFront now supports JA3 fingerprint headers」：

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

JA3 的頁面上可以看到說明，針對 SSL/TLS 這個複雜的 handshake 過程中，就可以從中得知不同的 client 實做，比起容易偽造的 User-agent 有效：

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測：

JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。

Netflix 單機 800Gbps 伺服器所使用的最佳化技巧

在 Hacker News 上看到 Netflix 的人丟出來的投影片，試著了解 Netflix 的 Open Connect Appliances 裡與 FreeBSD 相關的最佳化技巧對於效能的影響：「The “other” FreeBSD optimizations used by Netflix to serve video at 800Gb/s from a single server」。

看起來這邊的分析是先基於 400Gbps 的版本，可以跑到 375Gbps (53% CPU)，接著在上面拔掉各種最佳化的設定，看看會掉多少流量。這邊可以參考先前在「Netflix 在單機服務 400Gbps 的影音流量」提到的資料。

投影片上的第一章是 sendfile 與 kTLS 相關的最佳化，這邊可以看出來都是重要的項目，隨便關掉一個就會掉很多 capacity：

  • Disable kTLS (and async sendfile) + nginx aio：40Gbps (100% CPU)
  • Disable kTLS (and async sendfile) + nginx thread pools：90Gbps (90% CPU)
  • Disable sendfile (but use kTLS)：75Gbps (80% CPU)
  • Disable sendfile (but use NIC kTLS)：95Gbps (80% CPU)
  • Enable Sendfile & kTLS, but disable ISA-L crypto：180Gbps (80% CPU)
  • Enable Sendfile & kTLS：240Gbps (80% CPU)

第二章是 virtual memory，UMA VM Page Cache 這邊看起來最明顯，SF_NOCACHE 也是個重要的項目：

  • Disable UMA VM Page Cache：60Gbps (95% CPU)
  • Disable VM Batch Queues：280Gbps (95% CPU)
  • Disable SF_NOCACHE：120Gbps (55% CPU)

另外第二章特別提到了一個之前沒有用到的 optimization，是把 arm64 上面的 4KB Pages 變成 16KB Pages，這帶動了些許的效能提昇，並且降低了 CPU 使用率：

345Gb/s @ 80% CPU -> 368Gb/s @ 66% CPU

第三章是 network stack，看起來 TSO 帶來的效益也是很高：

  • Disable TCP Large Receive Offload：330Gbps (65% CPU)
  • Disable RSS accelerated LRO：365Gbps (70% CPU)
  • TSO Disabled：180Gbps (85% CPU)
  • Disable TSO and LRO：170Gbps (85% CPU)

最後面則是有提到從 400Gbps 到 800Gbps 還多做了那些事情，最後是達到 731Gbps。

用的機器是 Dell PowerEdge R7525，這是一台 2U 的機器啊...

AWS 台北區的網路狀況 (Routing & CDN 的情況)

在「目前 AWS 台北區只能開 *.2xlarge 的機器」這邊把機器開起來了，所以先測一下 AWS 台北區對台灣各家的 ISP 的網路狀況。

先看台灣內的點，看起來都有 peering，用 IP 測可以看到 latency 都很低：

再來試看海外 internet 的部份，美國蠻多點是從東京 AWS 過去，但測了香港的部份 www.three.com.hk，是從 TPIX 換出去，看起來台灣這邊也有一些出口，peering 與 transit 目前沒看到大問題。

但幾乎所有透過 GeoDNS-based 的查詢都會被丟到東京：

走 anycast 的 Cloudflare 就好不少，像是付費版本的 www.plurk.com 就是台北的 PoP，而免費版本的 wiki.gslin.org 也會丟到亞洲的某個點上？(看不出來是不是東京，出現 jtha 這個有點像是日本，但也有可能是泰國的點？)

這應該主要還是因為這段 IP 目前還是被認到東京的 ap-northeast-1 上，得等各家調整才有機會放到台灣的 PoP 上，不然就是要故意用沒有 EDNS Client Subnet 的 DNS resolver 了。

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

再找機會研究看看...