Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能,並且向更多地區提供 AWS Import/Export Snowball 服務:「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了,他會透過 CloudFront 的節點做 proxy,並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務,而實際測試後也確認不會有 cache:他的目的在於降低 latency 而加速,而不是 cache 加速,所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多,第一筆要收的是 CloudFront 的費用,再來才是計算 Transfer Acceleration 的費用:

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份,USD$0.04/GB。如果是傳到其他 AWS region 的話,也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己),AWS 會持續監控有沒有比較快,如果沒有的話系統會 bypass 回原來的 Amazon S3:

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region,結果發現是 307 redirect 重導回 Amazon S3 上,效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份,而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置),因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速),但由於沒有 cache,除非有特殊需求,不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體,以及新區域。

新硬體是 80TB 的版本,本來只有 50TB 的版本:

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區:

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效,其他區可以選擇 50TB 或是 80TB 版本:

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...

HTTPS 因為安全性而不能使用 Referrer 的問題

Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量,而不能帶出 Referrer 的問題:「Where did all the HTTP referrers go?」。

原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer,也就是 W3C 的「Referrer Policy」,問題是到現在還是 Draft 啊...

也因為過了三年,其實 draft 裡面多了不少參數可以用:

  • neverno-referrer 表示不傳。
  • origin 表示只傳 protocol + host 的部份,後面 path 的部份不要傳。
  • defaultno-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。
  • origin-when-cross-origin 表示當跨站時用 origin 的邏輯,但本站還是用完整的路徑。
  • always 或是 unsafe-url 則是永遠都傳。

其中刪節號表示 W3C 不建議再使用,應該用後者比較新的。

不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些),所以還是可以考慮先用舊的關鍵字,讓 Microsoft Edge 也可以被保護到:「Referrer Policy」。

北都數位 (TaipeiNet) 的網路

在住的地方拉了北都數位的 cable 與網路來用,首先是速度,30M 有跑滿,不知道用的人多了之後會如何:

線路 IP 反解看起來是走遠傳 SEEDNet,而實際 traceroute 也都是走遠傳的骨幹。

首先是 DHCP 的 DNS 設定頗糟糕,居然配出 HiNet 的 168.95.1.1:

螢幕快照 2016-01-22 15.11.18

然後測了老半天,遠傳看起來完全沒有 Akamai Edge?查了一堆站台,不是走香港、日本,不然就是 HiNet 的 Akamai Edge (即使我把 DNS 硬設為 SEEDNet 自己的 DNS resolver),這樣吃國際頻寬不會吃很兇嗎?

之後找時間來看看遠傳的行動網路如何好了,固網這塊感覺好慘...