Home » Computer » Network » Archive by category "CDN" (Page 19)

AWS 進入北京!

早上的時候就有看到消息了,而剛剛在 AWS 老大 Werner VogelsTwitter 上看到他宣佈 AWS 北京區的成立:

官方公告在「Coming Soon - New China (Beijing) Region」這邊。中國大陸的官方網站在「亚马逊 AWS | Cloud Computing in China on Amazon Web Services (Simplified Chinese)」這邊。

一如往常的,有中國政府規範的但書:

This Region will allow China-based and multinational companies to make use of a broad collection of AWS services while remaining in compliance with China's legal and regulatory requirements.

要注意的是,目前列出來的服務並沒有 CloudFrontRoute53,只有看到這樣的說明:

We have been working with a number of local data center, bandwidth, and content delivery partners to bring this Region to life. Companies such as China Net Center and SINNET will provide the infrastructure, network services, and CDN services that are required to support the launch and operation of AWS technology services in China.

繼續觀望看看接下來如何...

Amazon CloudFront 與 Route53 又多了三個 PoP...

AWS 機房多了三個 PoP,分別是菲律賓的馬尼拉、法國的馬賽、波蘭的華沙:「Three More CloudFront / Route 53 Locations - Manila, Marseille, and Warsaw」,所以 Amazon CloudFrontAmazon Route53 也多了這三個機房。

馬尼拉的頻寬費用以及 request 費用與香港相同,實際用 pinger.unimas.my 測發現好像不是連到菲律賓的機房:

Executing exec(ping, -c 5 -s 56, 54.230.158.85)
PING 54.230.158.85 (54.230.158.85) 56(84) bytes of data.
64 bytes from 54.230.158.85: icmp_req=1 ttl=53 time=44.3 ms
64 bytes from 54.230.158.85: icmp_req=2 ttl=53 time=60.5 ms
64 bytes from 54.230.158.85: icmp_req=3 ttl=53 time=60.6 ms
64 bytes from 54.230.158.85: icmp_req=4 ttl=53 time=54.2 ms
64 bytes from 54.230.158.85: icmp_req=5 ttl=53 time=57.2 ms

--- 54.230.158.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 44.345/55.416/60.666/6.026 ms

然後:

;; ANSWER SECTION:
85.158.230.54.in-addr.arpa. 86413 IN    PTR     server-54-230-158-85.sin3.r.cloudfront.net.

看起來好像剛上線而已,還有一些 routing 沒調整好?從 pinger.unimas.my 過去是到新加坡的 server...

用機車方法硬找 code name 結果只找到 maa3 (*.maa3.cloudfront.net) 是印度孟買機房,看起來還是要用其他方式找找看 :o

EdgeCast 在台灣有 PoP 了...

這是從中華機房內對 Adobe 字體服務 use.edgefonts.netSmokePing 資料 (Adobe 用 EdgeCast 的 CDN 服務),可以發現十一月底的時候 latency 從 20ms+ 降到 10ms 以下 (大約是 8ms,應該是南部的機房):

對於北部使用者,8ms 還是比 Akamai 高一些,不過比起以前香港機房的 20ms+ 好多了...

4chan 前端頁面的調校... (cookie-free domain 的重要性)

Chris Poole (4chan 的創辦人) 寫了一篇「Small things add up」,說明針對前端頁面的調整帶來的效能改善...

YSlowPageSpeed 都反應靜態內容 (像是圖片) 是從帶有 cookie 的 domain (4chan.org) 提供服務。

所以 Chris Poole 打算把靜態內容換到一個新的網域下。

首先是選擇新的 cookie-free domain 名稱,由於不需要好記 (因為是程式在用),所以在選擇時愈短愈好,這可以讓 html 內的大小會少一些 (即使是 gzip 後還是有差),所以 Chris Poole 選擇了 4cdn.org

而更大的改善其實是在 cookie 這塊。4chan 平均的 cookie 大小大約是 1KB,這表示每一個到 4chan.org 的 request 都要送出 1KB 的 cookie 資訊。對於行動用戶來說,上傳的頻寬就這樣被浪費掉了,在搬移到新的 4cdn.org 後可以省下大量的上傳頻寬:

By migrating to the new domain, end users now save roughly 100 KB upstream per page load, which at 500 million pageviews per month adds up to 46 terabytes per month in savings for our users. I find this unreal.

EdgeCast 提供的 DNS 服務:EdgeCast Route

Zite 上看到 EdgeCast 也要進入 DNS 服務這個市場了:「CDN Provider EdgeCast Gets Into The DNS Market With Launch Of EdgeCast Route」。

服務的頁面已經公開,並且公開價錢:「Managed DNS Provider | Outsourced DNS Service | Route | EdgeCast」,服務分成三種:

Standard Routing

利用 EdgeCast 的 IP Anycast Network 服務。每百萬個 query 是 USD$0.4 (超過十億個 query 的部份降到半價 USD$0.2)。

Adaptive Availability

除了 IP Anycast Network 外,還可以設定 health check 與 ratio (以達到 load sharing 的功能)。每百萬個 query 是 USD$0.6 (超過十億個 query 的部份降到半價 USD$0.3)。

Advanced Policy Routing

可以依照這些條件分析:GeoIP、GeoCountry、GeoCity、ASN、IP Group、Network Groups、Anycast PoPs 或是 IP Type。每百萬個 query 是 USD$1.5 (超過十億個 query 的部份降到 USD$1)。

另外價錢還有 zone 的部份。前面 50 個 zone 是 USD$50/month (算是低消吧?),後面每 50 個 zone 是 USD$35/month。而 health check 的部份是每個 USD$0.5/month。

可以設這麼細,而且又取這個名字,算是跟 Amazon Route 53 打對台?不過那個 Geo 系列以及 ASN 的部份看起來不賴啊,以前是自己寫 DNS resolver 處理這部份,把國外流量指到 CDN 上,然後台灣流量放在台灣的機房 (因為 CDN 不一定有台灣機房的 PoP)。

找機會來看看效果如何...

Amazon CloudFront 上 Protected Content 的 URL Sign...

Amazon CloudFront 也可以設定要簽名才能抓檔案,只是 URL Sign 設計的觀念跟 Amazon S3 完全不一樣,這不一致的調調很... 詭異...

大致上有這些差異:

  • Amazon S3 用的是 HMAC-SHA1 的機制簽名 (shared secret,也就是 Amazon S3 與你都有同一把 key),而 Amazon CloudFront 則是用 RSA key 簽名 (public key,也就是 Amazon CloudFront 存放 public key,你自己存放 private key)。
  • 也因為是使用 RSA key,有人會誤解跟 Amazon EC2 用的 RSA key 相同。但實際上需要在 Security Credentials 頁裡設,有專門對 Amazon CloudFront 用的 RSA key 的段落。
  • 自己對 Base64 編碼再處理,避開使用 += 以及 /。但不是有標準可以用嗎,為什麼要自己發明呢...
  • 引入 Policy 的彈性機制,不僅可以對時間控制,也可以對 IP address 控制,但 Policy 這是帶在 URL 裡傳進去的... 你可以看到我的程式碼內產生出 $json_str 後簽完名帶到 URL 內了。

官方的 CloudFront Signed URLs in PHP 這篇的範例程式碼其實很清楚了,要直接拿去用其實也沒麼問題。我自己整理後是這樣:

<?php

$key_pair_id = 'APKA...';
$pem_file = '';
$resource = 'http://test2-cdn.gslin.org/test.txt';

$expires = time() + 3600;

$json_str = json_encode(
    array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array(
                        'AWS:EpochTime' => $expires
                    )
                )
            )
        )
    ),
    JSON_UNESCAPED_SLASHES
);

$buf = file_get_contents($pem_file);
$key = openssl_get_privatekey($buf);

openssl_sign($json_str, $signed_policy, $key, OPENSSL_ALGO_SHA1);

openssl_free_key($key);

$signature = str_replace(
    array('+', '=', '/'),
    array('-', '_', '~'),
    base64_encode($signed_policy)
);

echo "${resource}?",
    "Expires=${expires}&",
    "Signature=${signature}&",
    "Key-Pair-Id=${key_pair_id}\n";

反正你搞不太懂 Amazon 為什麼要這樣設計的... =_=

Archives