Category: CDN

Cloudflare 可以針對不同 Hostname 給不同的 TLS 設定了

Cloudflare 總算是提供付費方案 (包在 Advanced Certificate Manager 裡面)，可以針對不同的 hostname 給不同的 TLS 設定了：「Introducing per hostname TLS settings — security fit to your needs」。

本來的限制是整個 domain 都是一樣的 TLS 設定，這點對免費仔來說還好，但對於企業客戶來說就不太好用了。

遇到客戶端 (甚至是客戶) 是 Java 6 這種不支援 TLS 1.2 的情況 (參考「Qualys SSL Labs - Projects / User Agent Capabilities: Java 6u45」這邊)，你還是得想辦法生一組 TLS 1.0 服務出來，但整個 domain 都開又有可能會死在 PCI-DSS 之類的規範。

以前遇到的時候有兩種解法，第一種是在客戶端自己解決，像是在內網架 SSL proxy (通常會搭配 self-signed CA) 讓 Java 6 的 client 還是可以透過 TLS 1.0 通訊，但是連到 internet 上面會是比較新的 TLS 1.2 或是 TLS 1.3，這種算是比較安全的。

另外一種就是在 Cloudflare 上另外開一個 domain，這樣就可以用 TLS 1.0 半裸奔。

現在這樣等於是讓第二個方案更簡單一點，不用另外開 domain，只需要在 hostname 上設定...

CloudFront 支援 3072 bit RSA 憑證

看到 CloudFront 支援 3072 bit RSA certificate 的消息：「Amazon CloudFront announces support for 3072-bit RSA certificates」。

2048 bit 在一般情況算是夠用，畢竟現在的紀錄也才到 829 bit (參考「RSA Factoring Challenge」)：

1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys, 3072-bit RSA keys to 128-bit symmetric keys, and 15360-bit RSA keys to 256-bit symmetric keys. In 2003, RSA Security claimed that 1024-bit keys were likely to become crackable some time between 2006 and 2010, while 2048-bit keys are sufficient until 2030. As of 2020 the largest RSA key publicly known to be cracked is RSA-250 with 829 bits.

但如果哪天突然又有新的演算法出來威脅到 2048 bit 的話，會多一點緩衝的空間？

Cloudflare 看 HTTP/3 的使用率

Cloudflare 利用自家平台分析過去一年 HTTP/3 的使用率：「Examining HTTP/3 usage one year on」。

首先是整體的使用率，看起來反而沒有什麼太大的變化？一上線就已經是巔峰的感覺？

然後各種 bot (像是搜尋引擎的 bot 或是 social media 的 bot) 看起來幾乎都沒有用 HTTP/3，少數的量應該都是實驗性質居多，唯一的例外是 LinkedIn 有試著在導入，可以看到慢慢的爬升：

看起來不算太順？

關於 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 的機器啊...

Netflix 在 2013 年 Open Connect Appliances

Reddit 上的原文在「So I got a Netflix cache server...」這邊，但看起來作者自己刪掉內容了 (可能是被接觸要求刪掉？)，可以看 Internet Archive 上的「20221026080226」，以及報導「How a Redditor Ended Up With an Industrial-Grade Netflix Server」。

所以是 Netflix 退役的機器，看起來適合法取得的？

I work for a large ISP, and we are retiring/replacing quite a few 2013 era Netflix OCA caches, and I was offered one. Of course, I couldn't say no 😅

資料當然是被清過的：

I knew that Netflix had wiped them all in the decommissioning process, that they ran FreeBSD, that they were crammed full of drives, and that's about it.

然後這台 2013 年的機器以現在的角度來看也算很大台，尤其是看到硬碟的部份是 36 顆 HGST 的 7.2TB 硬碟：

36x 7.2TB 7200RPM HGST's

再加上 4 個 10Gbps 的界面可以接：

One 4x 10G SFP+ NIC

作者後來裝了 TrueNAS 來用，就這些規格資料看起來的確是個很適合當 NAS：

I expected some resistance when trying to install an OS, but it was already set to boot from USB and took a TrueNAS install like a champ!

但不確定會吃多少電，放在家裡用還是得考慮這點... 不然就是當紀念品收起來。

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 了。