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

Amazon S3 的改善

其實老牌的 Amazon S3 也改了不少東西:「Revolutionizing S3 Storage Management with 4 new features」。

其中的「S3 Object Tagging」讓管理可以透過 tag 處理,管理上會多一些選擇。而「S3 Analytics, Storage Class Analysis」則是可以分析存取的 pattern,藉此重新規劃 policy。

看到之前的同事說 CloudFront 要支援 2-tier cache,但卻還沒看到公告,不知道是怎麼樣的實作方式... 這對大型的 live streaming 幫助很大啊,後面的壓力會小很多。

CloudFront 持續擴建:香港

Amazon CloudFront 在香港又增加機房了,這樣就是香港的第三個機房... 畢竟還是亞洲區頻寬成本相較起來比較低的地方 (也是很多東南亞國家會交換的地區),有對應的需求就可以擴充:「Announcing Third Edge Location in Hong Kong for Amazon CloudFront」。

不過話說回來,台灣 PoP 其實主要還是卡中華的頻寬,像這樣三個圖可以理解為那個瞬間 HiNet 與 CloudFront 之間的頻寬滿了 (分別是從 HiNet、TFNFET 去 ping AWS 官網自己用的 d36cz9buwru1tt.cloudfront.net,取自 smokeping.kkbox.com.tw 這邊):

不過還是有時候可以看到全部導走,是 capacity 突然滿掉嗎?這就有點奇怪了...

Akamai 阻擋 DDoS 能力的上限

這應該是最近在看 DDoS 事件中比較重要的新聞了,從這次的事件知道 Akamai 沒有能力擋下某種 620Gbps 以上的 DDoS 攻擊,而這是攻擊者已經有能力「示範」出來的量:「Akamai kicked journalist Brian Krebs' site off its servers after he was hit by a 'record' cyberattack」。

The assault has flooded Krebs' site with more than 620 gigabits per second of traffic — nearly double what Akamai has seen in the past.

然後現在 Krebs on Security 的整個站台都轉移到 GoogleProject Shield 計畫上了,接下來就是時間的考驗了:「The Democratization of Censorship」。

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.


  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

Netflix 的 Open Connect 架構

在「研究人员绘制Netflix CDN服务器位置图」這邊看到在討論 NetflixOpen Connect 架構,也就是 Netflix 自己的 CDN 架構。引用的論文是「Open Connect Everywhere: A Glimpse at the Internet Ecosystem through the Lens of the Netflix CDN」這篇。

翻了一下論文,看起來還是頗傳統的方法,從一堆伺服器去 query 找出來:

Indeed, Netflix server domain names are too specific, i.e., including details on the physical location of the server. This makes it unlikely that redirection takes place based on these domain names. Additionally, we ran a distributed DNS lookup campaign from Planetlab nodes to verify our assumption that Netflix DNS names always resolve to a single IP address, independently of the client location.


We implemented a crawler, which generated DNS names following the pattern outlined above and attempted to resolve those generated domains names to IP addresses. The crawler was fed with lists of known countries, airport codes and ISPs. We curated these lists manually, consulting publicly available lists of countries and airport codes. For the ISPs, we conducted an extensive search on the Internet, including but not limited to the Netflix ISP Speed Index, Wikipedia, various ISP rankings or recommendation lists and discussions in web forums.

所以總共列了 243 個國家地區,3468 個機場編號 (IATA) 與 1728 個 ISP 去搜尋:

In total, our curated lists contained 243 countries, 3,468 airport codes and 1,728 ISP names. In total we tested 16 different network connection types.


The DNS names actually include a typo, the Carrasco International Airport in Uruguay is abbreviated MDV instead of MVD. We used the ISP names found to verify that what was really meant is the airport in Uruguay.


不過事實上因為 Netflix 已經規劃全面走 HTTPS:「Netflix 對 sendfile() 在 TLS 情況下的加速」、「Protecting Netflix Viewing Privacy at Scale」,所以在 Certificate Transparency%.nflxvideo.net 會有完整的列表,看起來遠超過這篇論文所給的數字:

gslin@home [~/tmp] [14:55/W5] grep isp.nflxvideo nflxvideo.html | sort | uniq | wc
   1311    1311   65827
gslin@home [~/tmp] [14:55/W5] grep ix.nflxvideo nflxvideo.html | sort | uniq | wc
     77      77    3230


CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了:「Announcing Query String Whitelisting for Amazon CloudFront」,對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string,或是把整個 query string 當作 cache key 的一部分,現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上,針對 v=\d+ 當作 cache key 的一部分,而其他的參數可以忽略,不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用,像是 Slack 把整個網站放上 CloudFront 後,應該會有很多 API 是透過 query string 傳遞參數,而這次的改變讓 CloudFront 可以細部調整。