Category: CDN

Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破，雖然到對於攻擊現有的密碼學看起來還有一段時間，但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品，兩個團隊合作測試的結果在學界與業界都還蠻重視的：「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel，有控制組與兩個新的演算法：

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小，但運算起來比較慢 (SIKE，CECPQ2b)；另外一個是 key 比較大，但是運算比較快 (HRSS，CECPQ2)：

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試，因為這兩個演算法的缺點都還是有點致命...

AWS 官方推出 WordPress 整合套件

AWS 自己推出了跟 WordPress 的整合套件：「Accelerating WordPress with CloudFront using the AWS for WordPress Plugin」、「AWS for WordPress plugin now available and with new Amazon CloudFront workflow」。

這次的套件主要是將 Amazon CloudFront 整合進 WordPress：

Amazon Web Services announces the general availability of the AWS for WordPress plugin. Previously known as the Amazon Polly and Amazon AI plugin, the new AWS for WordPress plugin now provides a workflow to configure an Amazon CloudFront distribution that is highly optimized for WordPress websites.

如果想要都控制在自己手上，AWS 算是提供了一個官方的方案，也應該有一定的支援。不過大多數人還是會拿 Cloudflare 的免費方案吧...

Amazon CloudFront 在南美大降價...

Amazon CloudFront 宣佈了第 200 個點，同時也宣佈了南美的價錢從 11 月開始降價 56%：「200 Amazon CloudFront Points of Presence + Price Reduction」。

這次的降價幅度相當驚人，南美的頻寬本來是全 CloudFront 裡最高的，現次一降就降到比整個亞洲區的價錢都還低了，不知道是弄到什麼新合約：

We are also reducing the pricing for on-demand data transfer from CloudFront by 56% for all Points of Presence in South America, effective November 1, 2019.

不過這個比較不包括 AWS 中國區的價錢 (獨立的系統)，在中國的價錢是 CNY$0.30866/GB，換算成美金大約是 USD$0.04/GB。

這次加的三個點也都是在南美的新的點：

Today I am happy to announce that our global network continues to grow, and now includes 200 Points of Presence, including new locations in Argentina (198), Chile (199), and Colombia (200):

Cloudflare 遞出 S-1

Cloudflare 遞出 Form S-1：「S-1」。TechCrunch 有些整理：「Cloudflare files for initial public offering」。

一樣是燒錢狀態上市，不過相較於其他家燒的速度算是慢的，但成長速度很驚人：

As far as money goes, Cloudflare is — like other early-stage technology companies — losing money. But it’s not losing that much money, and its growth is impressive.

預定在 NYSE 上使用代碼「NET」：

The company will trade on the New York Stock Exchange under the ticker symbol “NET.”

不知道為什麼有種泡沫感...

Cloudflare 因為 Regular Expression 炸掉的問題

先前 Cloudflare 就有先說明七月二日的 outage 是因為 regular expression 造成的 (ReDoS)，不過昨天發的文章更完整了，導致爆炸的 regular expression 都給出來了：「Details of the Cloudflare outage on July 2, 2019」。

ReDoS 不算是新的問題，但卻是不太好避免的問題，因為需要有經驗的工程師 (中過獎的工程師) 才比較容易知道哪些 regular expression 是有問題的... 另外就是有花時間研究 regular expression 演算法的工程師也比較容易避開。

也因次，ReDoS 算是這十年來大家在還的債，各家 framework 都因為這個問題改寫了不少 regular expression。

這次的重點在這串式子導致了 ReDoS：

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

通常容易中獎的地方就是無限制字元與 * & + 連發的地方，後面這塊 )*.*(?:.*=.*))) 看起來就不太妙，果然在後面的分析也有提到：

The critical part is .*(?:.*=.*).

以前應該是在 Formal language 裡學到的，在課堂裡面其實會學到不少業界常用工具的基礎理論...

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).

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