Category Archives: CDN

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

Leave a reply

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 要增加自訂網域名稱需要先過認證...

Leave a reply

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

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 認證可能是一個方法，但流程上就多了不少步驟。

PHP 終止 mirror 站台計畫

Leave a reply

Twitter 上看到的公告：

本來 PHP 開放讓各地區的自願者提供頻寬，使用 PHP 的網域名稱 (像是 tw.php.net 這樣)，現在則是全部都收回，由官方統一提供有 HTTPS 的網頁版本 https://www.php.net/。

目前看起來 latency 頗高，都是到美東的伺服器上？下載也都還是指在 https://www.php.net/ 上，不知道 CDN 是用在哪裡...

Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

Leave a reply

這邊講的應該是在 client 端裝了 root certificate 後，網路上的 middle box 就有能力解開 HTTPS 連線看內容，再 proxy 連出去的方式：「Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception」，對於有設定 Pinning 的 HTTPS 應該會因為偵測到 certificate 被換掉而不會被監聽，但大多數的應用程式應該沒做這個保護。

對應的公開網站是 MALCOLM，為「Measuring Active Listeners, Connection Observers, and Legitimate Monitors」的縮寫。

Cloudflare 用了幾個方法去分析，像是 User-agent 與 OS 跟支援的 cipher 對不起來的情況就可以猜測是 middle box 的監聽。另外也可以看到 Cloudflare 分析了 middle box 的廠牌，可以看到 Blue Coat 應該是目前的大品牌 (但這邊有統計偏差，限制在可以被偵測出來的品牌)。

其實整體看起來不算低耶... 光是可以確認的部分，整個 Cloudflare 網路上有 10%～20% 的流量其實是有被過濾的？

Cloudflare 發表 Logpush，把 log 傳出來

1 Reply

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 的使用情況...

Leave a reply

在 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 在北美增加了一堆節點...

Leave a reply

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.

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

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Leave a reply

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft，但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響，所以就找了方法讓兩者並存：「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS，可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料，如果裡面有看到想要使用 TLS 1.3 的訊息，就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑：

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼，將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑，就比較不用擔心本來的 stack 會有狀況了。

AWS 推出 Global Accelerator，用 AWS 的網路加速

Leave a reply

AWS 推出了 Global Accelerator，利用 AWS 的網路加速：「New – AWS Global Accelerator for Availability and Performance」。

這個產品有點像是 GCP 的 Premium Network 的概念，從名稱叫做 Data Transfer-Premium (DT-Premium) 也可以看出來這點。另外 Cloudflare 也有類似的產品，叫做 Spectrum。

使用者的連線會先進入最接近使用者的 AWS Edge，然後走 AWS 自己的網路到真正服務所在的 AWS 區域：

AWS 自家的 CloudFront 可以做類似的事情，但是 CloudFront 是 DNS-based service，而且只吃 HTTP 類的連線；這次推出的 Global Accelerator 則是 Anycast-based service，同時支援 TCP 與 UDP。

目前的 edge 只有北美、歐洲與亞洲：

AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).

這類服務通常也都可以擋下一些 DDoS 攻擊，畢竟是拿大水管在擋...

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

Leave a reply

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 支援許久的功能... 算是補產品線與進度？