Netflix 與 Comcast 的恩怨

其實就是商業公司之間的勾心鬥角,在包裝後搬到檯面上 :p

Netflix 在美國固網裡吃的流量比 YouTube 還多,可想而知當然就變成各 ISP 找麻煩的對象...


出自 Sandvine 的「Global Internet Phenomena Report 2H 2013」。

Netflix 有多種方式將影片傳遞給使用者。除了早期自建機房外,後來跟不少 CDN 有業務往來 (包括了 AkamaiLimelightLevel3),另外也有 Netflix Open Connect Content Delivery Network 計畫,直接在 ISP 內部機房放設備提供服務。

使用 CDN 的作法成本太高,而 ISP 又不一定會接受 Open Connect 方案 (因為不一定收的到錢),在這種情況下,如果走 transit 線路的速度通常都不會太好。而 Netflix 與 Comcast 之間的狀況就是如此:

在付給 Comcast 錢後速度都都解決了...

除了付錢解決外,上個禮拜 Netflix 就丟出一篇說明的文章發難了:「The Case Against ISP Tolls」,這篇文章除了提到上面的事情外,另外還極力反對 Comcast 與 Time Warner Cable 的併購案 XDDD

然後最近又炒熱的網路中立問題,看起來也這件案子應該會很熱鬧 XDDD

CloudFlare 的速度...

CloudFlare 是一種 CDN 服務,相較於其他 CDN 會被歸類到 AkamaiDynamic Site AcceleratorLimelight NetworksDynamic Site Platform,或是 EdgeCastApplication Delivery Network

這類型的 CDN 加速服務,如果用在完全沒有考慮最佳化的網站上,效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上,反而會因為軟體已經做了不少處理,上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢?有人跳下去測試寫報告了:「Cloudflare Showdown」,如果懶得看中間的數據,可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上,用 CloudFlare 會慢不少,如果是 WordPress 及其他 open source 軟體,最好的情況是快一點點,但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多,動態資料的加速基本上是個商業包裝而已,真正需要加速還是得自己把可以 cache 的部份切割出來。