arXiv 上了 Fastly CDN

看到 arXiv 宣佈上了 FastlyCDN:「Faster arXiv with Fastly」。

翻了一下 arxiv.org 的 DNS record,可以看到現在是這樣:

;; ANSWER SECTION:
arxiv.org.              10      IN      A       151.101.131.42
arxiv.org.              10      IN      A       151.101.3.42
arxiv.org.              10      IN      A       151.101.67.42
arxiv.org.              10      IN      A       151.101.195.42

mtr 測試,看起來 HiNet 過去的 routing 還是進到新加坡。

不過 static.arxiv.org 是在 CloudFront 上:

;; ANSWER SECTION:
static.arxiv.org.       3600    IN      CNAME   daa2ks08y5ls.cloudfront.net.
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.100
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.29
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.88
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.127

依照官方的說明看起來還在換,只是不知道已經在 CloudFront 上的 (像是上面提到的 static.arxiv.org) 會不會換過去:

That includes our home page, listings, abstracts, and papers — both PDF and HTML (more on that soon).

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

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

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

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

日本囯土地理院提供的日本地圖圖資

查資料的時候發現日本的囯土地理院有開放使用日本的地圖圖資:「地理院タイル一覧」。

圖資放在 cyberjapandata.gsi.go.jp 這個網址上,前面掛 Fastly 的 CDN:

;; ANSWER SECTION:
cyberjapandata.gsi.go.jp. 300   IN      CNAME   d.sni.global.fastly.net.
d.sni.global.fastly.net. 30     IN      A       199.232.46.133

抓個鶯谷園的點出來看:

然後可以看到非常多不同的資料,像是「1928年頃」、「活断層図(都市圏活断層図)」、「明治期の低湿地」、「磁気図2010.0年値」,另外針對比較大的災難也有提供一些區域圖,像是「平成25年7月17日からの大雨 山口地方「須佐地区」正射画像(2013年7月31日撮影)」。

另外因為 url 形式是 https://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png 這種格式,可以直接用 Leaflet 這類 library 吃進去...

Fastly 服務掛掉的事件

Hacker News 上看到「Summary of June 8 outage (fastly.com)」這邊的討論,連結是 Fastly 官方先發布的說明:「Summary of June 8 outage」。

其中提到了是因為客戶的某些設定造成的:

10:27 Fastly Engineering identified the customer configuration

另外特別提到了 Fastly 的 WebAssembly 與 Compute@Edge,看起來應該就是這邊炸鍋:

Broadly, this means fully leveraging the isolation capabilities of WebAssembly and Compute@Edge to build greater resiliency from the ground up. We’ll continue to update our community as we make progress toward this goal.

我猜基本的資源保護機制應該有上 (像是在程式裡面自己 call 自己之類的,Fork bomb 之類的),可能是這兩個東西互串的某些部份沒有保護到,就一路把資源吃完炸掉。

看起來後續會有比較完整的報告,到時候再來看看會透露出多少東西...

QUIC 成為標準,從 RFC 8999 到 RFC 9002

前幾天的新聞了,這兩天 FastlyCloudflare 也都發文章出來了,QUIC 成為標準:「QUIC is now RFC 9000」、「QUIC Version 1 is live on Cloudflare」。

主要是這兩家都發稿宣傳他們的平台都支援 QUIC 了,接下來可以等一些測試報告,看看在 web 這種已經有不少複雜的 workaround 機制下,TCP BBR 環境的 HTTP/2 跟 QUIC 環境會有多少差異... 記得 QUIC 也是 BBR-based 的演算法。

在 QUIC 下的 https 協定會走 443/udp,如果防火牆是預設阻擋所有連線,然後逐條開放的話,需要另外開這組設定。

另外就是等 nginx 支援了,在「NGINX QUIC Preview」這邊有些資料,然後「">nginx-quic: log」裡面可以看到東西,裡面不少 commit 只是跟 nginx 本家同步而已,不過還是可以看到一些跟 QUIC 有關的...

Backblaze 與 Fastly 合作

Twitter 上看到的消息,BackblazeFastly,免除 Origin 到 CDN 這段的流量費用:

新聞稿是「Set Your Content Free With Fastly and Backblaze B2」這篇:

Our new collaboration with Fastly, a global edge cloud platform and CDN, offers an integrated solution that will let you store and serve rich media files seamlessly, free from the lock-in fees and functionality of closed “goliath” cloud storage platforms, and all with free egress from Backblaze B2 Cloud Storage to Fastly.

不過這不是第一家提供這樣的方案,在 2018 年的時候就有跟 Cloudflare 合作,免除了 Origin 端到 CDN 端這段費用:「Backblaze 與 Cloudflare 合作,免除傳輸費用」。

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

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

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

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

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

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

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

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?