Home » Computer » Network » Archive by category "CDN"

CloudFront 在東京又擴點了...

Twitter 上看到 CloudFront 又擴點的消息了:

點進去一看發現亞洲的點又是擴東京:

And in Asia, one Edge location is being added in Tokyo, Japan, our ninth in the city.

同樣是日本,不考慮擴一下大阪的點嗎... 或是加開名古屋的點?(蠻多海纜從志摩跟豐橋拉上去的)

CloudFront 在台北增加第三個點...

Twitter 上看到 AWS 宣佈 CloudFront 加了四個點:

點進去後發現這四個點包括了台北:

Amazon CloudFront announces four new Edge locations: Cape Town, South Africa; Denver, Colorado; Frankfurt, Germany; and Taipei, Taiwan.

在 CloudFront 的列表裡也增加到三個點:

Bangalore, India; Chennai, India (2); Hong Kong, China (3); Kuala Lumpur, Malaysia; Mumbai, India (2); Manila, Philippines; New Delhi, India; Osaka, Japan; Seoul, South Korea (4); Singapore (3); Taipei, Taiwan(3); Tokyo, Japan (8)

這樣應該可以再減少被導去海外節點的機會 (通常是香港或日本),不過狀況會怎麼樣還要再觀察... 先前加第二個點後,觀察到的現象是有減少,但還是會發生。現在加到第三個後不知道會不會解決...

CloudFront 在東京開到第八個點了...

看到 Amazon CloudFront 宣佈在東京開到第八個點了:「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。

Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.

這個成長速度有點驚人,一月才加了兩個,現在又要再加一個... 不過大阪還是維持一個。

Bootstrap 的 CDN 從 MaxCDN 換到 StackPath (Highwinds) 了...

最近在寫網頁時發現 Bootstrap 的網站上給的 CDN 網址改了,從本來用的 maxcdn.bootstrapcdn.com (MaxCDN) 變成 stackpath.bootstrapcdn.com (StackPath,本來的 Highwinds)。

而且看起來跟 MaxCDN 的合作已經全部停了,現在 maxcdn.bootstrapcdn.com 也是指到 StackPath 上。

翻了 Wayback Machine 上的記錄,看起來是在 2018040904501720180410051321 這之間換的,也就是大約是在 2018/04/10 前後換的。不知道後面的交易是什麼...

可以參考 K 社的 SmokePing 資料「SmokePing Latency Page for netdna.bootstrapcdn.com (NetDNA, Bootstrap)」:

可以看到 HiNet 走的點的latency 比之前好不少...

Microsoft 啟用自己的 CDN 了...

在朋友的 tweet 裡看到微軟啟用自己的 Azure CDN 了,先前應該是提供 AkamaiEdgeCast 的服務:「Announcing Microsoft's own Content Delivery Network」。

看圖似乎是有台灣的點,不過我找不到可以測試 traceroute 的 endpoint,頁面上用的圖還是 EdgeCast 的啊 XDDD

;; ANSWER SECTION:
azurecomcdn.azureedge.net. 1604 IN      CNAME   azurecomcdn.ec.azureedge.net.
azurecomcdn.ec.azureedge.net. 3404 IN   CNAME   cs9.wpc.v0cdn.net.
cs9.wpc.v0cdn.net.      3404    IN      A       117.18.232.200

然後公測期間優惠價 50%:

Azure Content Delivery Network Standard from Verizon (S1) and Akamai (S2) and Microsoft (S3)*
*S3 is currently in public preview. CDN rates will be 50% of the stated price during this period.

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

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?

CloudFront 在台北的第二個 PoP

Twitter 上看到了 Amazon CloudFront 宣佈了台北的第二個 PoP:

這個也是喊好久了,從去年就有消息一直到現在... 這樣台灣多了一個 backup,比較不會導去香港或是日本了。不過新 PoP 的代碼找不到,試著找 tsatpe 以及後面接數字,還是只有找到 tpe50,不知道是不是後來不露出代碼了...

Cloudflare 的 jpegtran 在 ARM 上面的表現

Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」,或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇),最近在 ARM 上發現 jpegtran 的效能不是太好,花了不少力氣最佳化,發現有意外收穫:「NEON is the new black: fast JPEG optimization on ARM server」。

他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%,但發現只有 26% 左右的效能:

Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.

In this case, however, I was disappointed to discover an almost 4X slowdown.

而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速,於是作者就想到,把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助:

Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?

而 porting 完後重新測試發現達到了 66% 的效能,已經超過本來的目標... 另外在批次處理中,也比 Xeon 快了:

繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能),也許能提供更進一步的加速:

While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.

如果再把這些指令實做出來,會發現單 core 的效能已經到 Xeon 的 83%,而批次的速度又提昇了不少:

最後是整台伺服器都跑滿時的測試,會發現整台的效能差不多 (其實 ARM 的版本還贏一些),但吃電量不到一半,而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題),用電效率來到 6.5 倍:

With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.

這篇在提醒之後在 ARM 上寫最佳化時,不要只從 SSE porting 到 NEON,要多看一下有沒有其他指令集是有幫助的...

Archives