Tag: cdn

Cloudflare 弄了 time.cloudflare.com，不過 latency 沒有很好...

Cloudflare 提供的 NTP service，使用 time.cloudflare.com：「Introducing time.cloudflare.com」。

官方是號稱所有的機房 (應該就包括台北的點)：

Now, anyone can get time securely from all our datacenters in 180 cities around the world.

但在 HiNet 下測試可以看到是從東京的點服務：

  2.|-- snuh-3302.hinet.net        0.0%    10    9.5  10.5   9.5  12.7   0.8
  3.|-- tpdt-3022.hinet.net        0.0%    10   11.1  10.8  10.1  11.8   0.3
  4.|-- r4103-s2.tp.hinet.net      0.0%    10   27.2  11.9   9.3  27.2   5.4
  5.|-- r4003-s2.tp.hinet.net      0.0%    10   11.3  10.7   9.5  11.6   0.3
  6.|-- xe-0-0-0-3-6.r02.osakjp02  0.0%    10   47.9  48.7  47.6  49.9   0.6
  7.|-- ae-2.a00.osakjp02.jp.bb.g  0.0%    10   44.9  47.3  42.8  66.4   6.9
  8.|-- ae-20.r03.osakjp02.jp.bb.  0.0%    10   43.7  43.2  42.5  44.7   0.3
  9.|-- 61.120.144.46              0.0%    10   69.6  52.4  48.0  69.6   6.8
 10.|-- 162.159.200.123            0.0%    10   48.3  48.8  47.9  49.3   0.0

如果從 APOL (有線電視) 的點則是透過台灣的機房連線：

  3.|-- 10.251.11.6                0.0%    10   19.8  29.6  11.1  80.2  21.7
  4.|-- 10.251.231.5               0.0%    10   25.3  24.9  16.4  43.6   8.0
  5.|-- 10.251.231.1               0.0%    10    8.7   6.3   3.4   9.1   1.9
  6.|-- 10.251.230.34              0.0%    10    4.6   7.4   2.6  14.5   3.2
  7.|-- 10.251.230.29              0.0%    10    3.0   6.6   3.0  11.9   2.8
  8.|-- 202-178-245-162.cm.static  0.0%    10    4.8   7.3   4.8   9.9   1.4
  9.|-- 192.168.100.14             0.0%    10    7.3   8.0   5.4  11.1   2.0
 10.|-- 192.168.100.9              0.0%    10    8.2   8.0   4.9  11.1   1.7
 11.|-- 203-79-250-65.static.apol  0.0%    10    9.1   9.0   6.4  11.3   1.5
 12.|-- 211.76.96.92               0.0%    10    7.8   8.1   4.3  15.8   3.3
 13.|-- 39-222-163-203-static.tpi  0.0%    10    9.9   9.1   6.7  12.4   1.8
 14.|-- 162.159.200.1              0.0%    10    5.0   7.2   5.0   9.7   1.4

看起來又是有東西沒搞定了...

Cloudflare 提供 IPFS 的 HTTPS Gateway

IPFS Gateway 基本上就是個 Proxy，這次 Cloudflare 直接提供 *.cf-ipfs.com 服務：「Continuing to Improve our IPFS Gateway」。

用把 hash 放進 subdomain 的方式讓我想起當年的 Coral CDN 計畫...

Anyway，我覺得對 IPFS 的幫助還是有限，畢竟本來 IPFS 官方就有提供 Gateway，現在只是一個比較快的 Gateway，能做的功能還是那些...

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時，CDN 這端會先取得 exclusive lock，然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案，就會先卡住，避免同時間對 origin server 產生大量連線：

這個架構在一般的情況下其實還 ok，就算是 Windows Update 這種等級的量，畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說，因為檔案一直產生，這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲，所以在使用者端就需要多抓一些緩衝時間才能確保品質，這增加了直播的互動延遲，所以 Cloudflare 改善了這個部分，讓所有人都可以同時下載，而非等到發起的使用者下載完才能下載：

沒有太多意外的，從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降，對於使用者來說也大幅降低了 TTFB (time to first byte)：

不確定其他家的情況...

靜態網頁服務的選擇

在 Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇，除了文章連結外，留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務，或是透過 Netlify，需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後，其他人把真正有用的工具整理了出來...

CloudFront 開始提供中國大陸的服務

Amazon CloudFront 開始提供中國大陸上的節點：「Amazon CloudFront is now Available in Mainland China」。看起來是綁在 AWS China 上面，而且需要 ICP 才能使用：

To start using CloudFront in China, customers must setup a CloudFront distribution using the AWS Management Console or API in China and also obtain a valid ICP (Internet Content Provider) recordal.

不過第一波提供的節點不多，只有北京、上海與寧夏：

Amazon CloudFront announces the launch of CloudFront in China with three new Edge locations (POPs) located in Beijing, Shanghai, and Zhongwei, operated by Ningxia Western Cloud Data Co. Ltd. (NWCD).

後續不知道還有機會展到哪些地區...

Amazon CloudFront 要增加自訂網域名稱需要先過認證...

大概猜得到原因，總算是把這塊做下去了...

AWS 宣佈 CloudFront 增加自訂網域名稱需要先過認證才能啟用：「Amazon CloudFront enhances the security for adding alternate domain names to a distribution」，也就是把自己的 domain name 掛到 CloudFront 上需要先認證過。

這邊的認證需要用公開被信任的 SSL Certificate，而大多數人應該會直接拿 AWS 提供的 ACM 來用：

With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free.

申請 ACM 也需要確認身分，印象中沒記錯的話是透過 DNS 或是 e-mail 認證。

會有這個改變是因為有一個 DDoS 的攻擊手法可以「造成困擾」。在沒有認證就可以增加網域名稱的情況下 (假設是 assets.gslin.com)，AWS 需要把不同帳號設定同一組 domain name (assets.gslin.com) 的 IP address 分開，這樣才能確保安全性。而 IPv4 address 是有限的，用很多帳號申請就有機會讓真正的 assets.gslin.com 擁有人想要用的時候沒有資源可以用。

其實在 Route53 也有類似的問題，但因為是個雞生蛋蛋生雞的問題，就更不好解決了，在 DNS 還沒設定好之前要怎麼確認身分是一個更頭痛的問題... e-mail 認證可能是一個方法，但流程上就多了不少步驟。

Cloudflare 發表 Logpush，把 log 傳出來

Cloudflare 推出了 Logpush，可以把 log 傳到 Amazon S3 或是 Google Cloud Storage 上 (目前就支援這兩個)：「Logpush: the Easy Way to Get Your Logs to Your Cloud Storage」，目前是 enterprise 方案可以用：

Today, we’re excited to announce a new way to get your logs: Logpush, a tool for uploading your logs to your cloud storage provider, such as Amazon S3 or Google Cloud Storage. It’s now available in Early Access for Enterprise domains.

Logpush currently works with Amazon S3 and Google Cloud Storage, two of the most popular cloud storage providers.

以往是自己拉，需要考慮 HA 問題 (兩台小機器就可以了，機器成本是還好，但維護成本頗高)，現在則是可以讓 Cloudflare 主動推上來...

我大多數的建議是 log 儘量留 (包括各種系統的 log 與 http access log)。主要是因為儲存成本一直下降 (S3 的 1TB 才 USD$23/month，如果使用 Glacier 會低到 USD$4/month)，而且 log 在壓縮後會變小很多 (經常會有重複的字)。

最傳統的 AWStats 就可以看到不少資訊，如果是透過 IP address 與 User-agent，交叉配合其他 event data 就可以讓很多 machine learning 演算法取得的資訊更豐富。

HTTP Archive 分析 CDN 的使用情況...

在 Twitter 上看到 HTTP Archive 分析各家 CDN 的使用情況，給了一個蠻意外的結果，可以看到 Cloudflare 的佔比相當高：

進去看一下分析的方式，是拿 Google Chrome 提供的資料來再進一步分析：

As of December 15th 2018, the HTTP Archive is crawling the full list of desktop origins from the Chrome User Experience (CrUX) Report for the desktop crawls (mobile will be added as of January 1, 2019). The URL list used is the latest available at the time of the crawl (November 2018 in this case).

這應該是出自「Chrome User Experience Report」這邊：

The Chrome User Experience Report is powered by real user measurement of key user experience metrics across the public web, aggregated from users who have opted-in to syncing their browsing history, have not set up a Sync passphrase, and have usage statistic reporting enabled.

由於有條件限制，可以預期會有偏差，不過以目前 Google Chrome 的市占率來說，應該是有意義的資料。而這份資料跑出來的數據看到 Cloudflare 的影響力遠遠超過其他 CDN 讓人頗意外...

CloudFront 在北美增加了一堆節點...

CloudFront 在北美增加了一堆節點：「Amazon CloudFront announces ten new Edge locations in North America, Europe, and Asia」。

北美一口氣增開了八個，提升了 40% 的 capacity：

Amazon CloudFront announces ten new Edge locations, adding to our global presence. Eight of the new Edge locations are in North America: Houston, Texas (our first location in this city), Chicago, Illinois, Newark, New Jersey, Los Angeles, California, and Ashburn, Virginia. We also added an Edge location in Berlin, Germany, as well as one in Tokyo, Japan.

With this launch, CloudFront will increase its request processing capacity by up to 40%, on average, in the North American cities.

另外不怎麼意外的又增加了東京...

CloudFront 十週年、在東京的第十個 PoP，以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了，另外這次在東京又加節點了，變成 10 個：「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket：「Amazon CloudFront announces support for the WebSocket protocol」，以及支援 Origin Failover：「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能，大家主要是希望利用 CloudFront 擋 DDoS，正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin，當主要的掛掉時可以切到備用的，對於支援多節點的架構算是第一步 (目前看起來只能設兩個)：

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度？