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

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 連線,但要有機制在失敗時回去用 TCPHTTP/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

再找機會研究看看...