Home » Posts tagged "akamai" (Page 2)

蘋果自家的 CDN

Apple 自家建立了 CDN 並且開始服務:「Apple’s CDN Now Live: Has Paid Deals With ISPs, Massive Capacity In Place」。

找了好久才找到 swcdn.apple.com 這個名稱,sw 不知道是不是指 switch 的意思?

從 blog 這台主機 (DigitalOcean 在 San Jose 的機房) 可以看到被指到 SFO 的 Apple CDN:

swcdn.apple.com.        3600    IN      CNAME   swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 300 IN      CNAME   ussjc1.cdn-apple.com.akadns.net.

而如果從台灣查,則會導去 Akamai

swcdn.apple.com.        3282    IN      CNAME   swcdn.apple.com.akadns.net.
swcdn.apple.com.akadns.net. 300 IN      CNAME   swcdn.apple.com.edgesuite.net.

看起來還是用 Akamai 提供的 DNS 服務。而從導的情況看起來,符合原文作者 Dan Rayburn 的說明,目前只有歐美地區是走自家的 CDN:

Recently, Apple’s CDN has gone live in the U.S. and Europe and the company is now delivering some of their own content, directly to consumers.

量夠大就會這樣玩,應該是逐步繼續做?

Akamai 與 EdgeCast 混用的效果...

EdgeCast 官網上丟出來的「The Positive Performance Impact of a Dual CDN Strategy」這篇 PR 稿引用了 Optimizely 的「The Most Misleading Measure of Response Time: Average」。

EdgeCast 官網上的 PR 稿當然不會提到 Akamai 的名字,但在 Optimizely 上有說明:

At Optimizely, we had already been using Akamai, one of the world’s fastest and most reliable CDNs, so we decided to try adding another. We tested a balanced CDN architecture, combining Akamai with EdgeCast, another leader in the CDN space.

可以看到 99 percentile response time 大幅改善:

其中改善最高的是北美:

不過看不出來是怎麼測試 CDN Balancing 這個方法啊?依照白皮書的說明:

Prior to introducing CDN Balancing, Optimizely’s experiment code was stored in a JavaScript file that sits on Akamai’s CDN, one of the fastest and most reliable CDNs in the world. The code in this file is important because it’s responsible for making client-side changes to a page and serving them to visitors according to the targeting and A/B testing criteria set up by the Optimizely customer who created the experiment.

看起來是對 js code 測試,應該是 cdn.optimizely.com 這個 hostname,而 optimizely.com 的 DNS 放在 Dyn 上。

猜測應該是對 EdgeCast 有服務的地區丟到 EdgeCast 上 (美國的部份應該可以切割到「州」),其他的則丟到 Akamai 上?不過現在怎麼查都是 EdgeCast 啊,從馬來西亞查也是丟到 EdgeCast 的 CDN 上 (然後被導到新加坡)。

不過,在北美 EdgeCast 會比 Akamai 快這麼多應該是因為 EdgeCast 有兩個平台,一個是 for large files,一個是 for small files,兩個平台最佳化時調整的參數應該不同,針對大檔案的部份會計較 thoughtput,針對小檔案的部份會計較反應時間。Akamai 可能就是輸在這邊...

也有可能是因為 EdgeCast 的反應時間比較好,然後 Akamai 合約到期就整個切過去了?(噗)

冒出很多疑問啊...

Zerigo DNS 換到 Akamai,然後漲價...

Zerigo 年底發了兩篇公告:

Zerigo 是好用在 GeoDNS 的服務上 (不用自己寫程式 & 更新 GeoDNS database,更不用自己做 HA 機制),一般的 DNS 服務到是還好... 漲了也只能接受啊,就當作換上 Akamai 後的成本調漲好了?(看了看,檯面上 GeoDNS 沒幾家好用的服務啊...)

繼續觀察看看吧...

iOS 7 的下載與 Akamai...

剛好看到「By My Estimates, Apple’s iOS7 Download Business Is Worth About $10-$12M To Akamai」這篇,講到這次蘋果 iOS 7 的下載讓 Akamai 有一筆不小的收入...

正想要下載 VirtualBox,沒遇過 HiNet 機房的 Akamai 這麼慢... XD

gslin@GSLIN-DESKTOP [~/tmp] [13:31/W3] wget http://download.virtualbox.org/virtualbox/4.2.18/virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb
--2013-09-19 13:32:17--  http://download.virtualbox.org/virtualbox/4.2.18/virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb
正在查找主機 download.virtualbox.org (download.virtualbox.org)... 137.254.120.26
正在連接 download.virtualbox.org (download.virtualbox.org)|137.254.120.26|:80... 連上了。
已送出 HTTP 要求,正在等候回應... 302 Moved Temporarily
位置:http://dlc.sun.com.edgesuite.net/virtualbox/4.2.18/virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb [跟隨連結]
--2013-09-19 13:32:18--  http://dlc.sun.com.edgesuite.net/virtualbox/4.2.18/virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb
正在查找主機 dlc.sun.com.edgesuite.net (dlc.sun.com.edgesuite.net)... 203.69.141.82, 203.69.141.10
正在連接 dlc.sun.com.edgesuite.net (dlc.sun.com.edgesuite.net)|203.69.141.82|:80... 連上了。
已送出 HTTP 要求,正在等候回應... 200 OK
長度: 64206462 (61M) [application/x-debian-package]
Saving to: `virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb'

2013-09-19 13:35:47 (301 KB/s) - `virtualbox-4.2_4.2.18-88780~Ubuntu~precise_amd64.deb' saved [64206462/64206462]

試了幾次,有些還會導到美國機房分流... 量真的太大了 :o

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...

Archives