Home » Posts tagged "content" (Page 2)

Linode 的被攻擊報告

Linode 這陣子一直被 DDoS 攻擊,前幾天放出報告:「The Twelve Days of Crisis – A Retrospective on Linode’s Holiday DDoS Attacks」。

其中這段提到了一些數字,Linode 有個小機房有 40Gbps 的能力,但以現在的 DDoS 規模會馬上爆掉:

Linode’s capacity management strategy for IP transit has been simple: when our peak daily utilization starts approaching 50% of our overall capacity, then it’s time to get more links.

This strategy is standard for carrier networks, but we now understand that it is inadequate for content networks like ours. To put some real numbers on this, our smaller datacenter networks have a total IP transit capacity of 40Gbps. This may seem like a lot of capacity to many of you, but in the context of an 80Gbps DDoS that can’t be blackholed, having only 20Gbps worth of headroom leaves us with crippling packet loss for the duration of the attack.

另外把 DNS 整個放上 CloudFlare 讓他們來擋:

Our nameservers are now protected by Cloudflare, and our websites are now protected by powerful commercial traffic scrubbing appliances.

後續的改善應該還要幾個月?完成後應該會再看到 blog post...

把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content,瀏覽器預設值不會直接全部擋掉,而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換,讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後,接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了,接下來要不要進 HSTS Preload List 就看大家自己的想法了。

CloudFlare 對 Brotli 的測試

之前有提過這件事情,由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法),所以 CloudFlare 的人整理了目前的效能比較:「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率,對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率,從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%):

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助,但對於 on-the-fly 的壓縮反而會比較慢。

Google Chrome 46 修改 Mixed Content 的 HTTPS Icon

剛剛出的 Google Chrome 46 除了安全性更新外,還修改了在 Mixed Content 時的 HTTPS icon:「Simplifying the Page Security Icon in Chrome」。

官方的這張圖就給了不錯的解釋:

本來是用黃色三角形表示,現在直接變成跟 HTTP 一樣沒有 Secure Icon,這樣減少了使用者要了解的情況:

This change will reduce the number of page security states in Chrome from four to three.

而接下來還打算再減少:

In the long term, we hope that most sites on the internet will become secure, and we plan to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.

在 iOS 9 裡安裝 Crystal 擋掉全版廣告

蘋果的 iOS 9 在今天放出來了,更新完以後可以用 Content Blocking 擋廣告,剛剛測過可以擋下全頁式的廣告。

這篇要介紹了的是「Crystal」這個目前限時免費的 app,你可以在「Crystal - Block Ads, Browse Faster.」這邊下載安裝。

iOS 9 的 Content Blocking 功能必須要應用程式支援,而目前只有 Safari 有支援,所以以下的測試是用 Safari 打開行動版的 Facebook (https://m.facebook.com/) 測試的,就拿這篇先來測試:(這張圖片是後來抓的,所以時間是 06:20)

直接打開會先出現全版廣告 (第一張圖),關掉後還會有大量的廣告 (第二張圖):

接著我們打開 Crystal,可以看到什麼都沒得設,因為這套軟體已經做完了:(這張圖片是剛裝完就裝的,所以是 06:00)

接著到「設定」裡面打開 Safari 的阻擋功能:

改完後就會是乾淨而且沒有廣告的版本了:

關於各家 CDN 的選擇...

在使用 CDN 前,先考慮上 SPDYHTTP/2 (i.e. 全站 HTTPS),改善的效果跟 CDN latency 帶來的效益有得拼。尤其是 server 放在美國機房的情況,SPDY 與 HTTP/2 帶來的效能提昇是相當明顯的。

會寫這篇是因為這兩個禮拜意外被問到好幾次,所以來整理幾家如果讓我來選,我會選擇的 CDN。至少再被問到的時候可以直接從這邊開始說明。

下面的圖是從我家裡 HiNet 光世代測試的結果 (最後是走兩條電話線),所以會有個 10ms 的 latency 基底,如果要計算 latency 的效能影響請考慮進去。

Akamai

先講 Akamai

Akamai 的歷史很久了,再加上併購了不少公司,所以產品成熟度很夠,你要什麼產品都有提供,只要拿的出錢就可以。

KKBOX (敝公司) 用過 PMD、DSDDSA 三個產品,其中 PMD 與 DSD 只有保障服務可靠度 (availability),DSA 還有保障效能提昇 (performance)。早期是用 PMD + DSD,現在改用 PMD + DSA。

在功能面上,雖然 Akamai 是大公司,但各種新功能跟的蠻快的。主要就是為了 SPDY 以及之後預期會有的 HTTP/2 而選了 DSA,另外也剛好有效能提昇 SLA 需求而一併升級。

品質上來說,Akamai 在全球的點 (PoP) 夠密集 (差不多是有 ISP 機房就會放),當初會選擇 Akamai 是為了敝公司在泰國與馬來西亞兩個地區的用戶,而 PMD 在這兩個地區的品質都還不錯。

在台灣也有好幾個點,但除非你買的產品線等級夠高 (i.e. 合約有保證 performance,像是 DSA),不然平常不會分到台灣的點,以最近的情況來說是深夜才有機會指回台灣。

這是 Akamai DSD 的圖:

而這是 DSA 的圖:

可以看得出來 latency 的差異。

在 SLA 的部份,是目前少數有提供保證 100% availability SLA 的 CDN。

成本考量上,價錢是最硬的,但由於 CDN 這個領域競爭得很激烈,只要超過某一個 commit level 後有機會壓到跟 CloudFront 拼的價錢,也就是說,有經濟規模就有機會在台灣變成重點客戶而坐下來談價錢 (不確定多少,但 CloudFront 的第一個級距 10TB/month 應該是基本吧)。

另一方面,因為透過業務談價錢,會需要開會討論,所以對使用方的人力成本偏高。不過因為如此,台灣有 Akamai 辦公室與經銷商,稅務會比較好處理。(參考:「零壹科技正式代理Akamai 推展雲端優化服務解決方案」)

總結來說,適合已經有量,而且台灣是重要客群的公司。

EdgeCast

再來講 EdgeCast

EdgeCast 的功能比 Akamai 少很多,自從被 Verizon 買進去後就沒推出什麼比較有趣的產品了 (參考「Verizon 打算買下 EdgeCast...」),感覺上是電信公司買來補產品線的啦,所以也不用太期待之後會有什麼新產品推出來...

比較特別的是 EdgeCast 跟 HiNet 有合作 (參考「EdgeCast 與 HiNet 合作...」),所以也是少數在台灣有機房的 CDN 業者。在台灣的 PoP 據說是在高雄 HiNet 機房內:

另外 EdgeCast 有 Network Map 可以看在全球有哪些 PoP。

價錢上聽朋友說比 Akamai 低了不少,不過自己沒經手過無法確認。同樣是透過業務談,所以也有類似的人力與稅務優缺點。不過據說也可以直接 bypass 國內的業務,直接跟國外談,不過這樣搞境外稅務的問題就要自己解決了。

綜合來說,也是適合已經有量,由於沒有 SPDY 與 HTTP/2,就看 PoP 的點決定合不合用。

CloudFront

Amazon CloudFront 算是很多 startup 的第一嘗試,no commit 以及帳單在同一張可以省下不少功夫。

在 CloudFront 上分成三個不同等級的產品,通常下載用可以拿 Price Class 100 (只有北美與歐洲的 PoP),而真正要加速用的再拿 Price Class All 用。

而功能面上,CloudFront 的功能說不定還比 EdgeCast 多,不過還是沒支援 SPDY 或 HTTP/2,所以基本上是靠台灣的 PoP 在撐 latency 的。而台灣的 PoP 據說在內湖:

價錢在官網上就擺出來給大家看了,比較大的缺點是不同區域是分開算錢的,不過是可以找台灣的經銷商談 commit level 包價錢啦,不過價錢還是很難談。

綜合來說,適合 startup 用。

CloudFlare

CloudFlare 也是很多人問的一個選擇,不看流量價錢固定是賣點之一。

功能非常多,SSL certificate 涵蓋在所有產品內,另外也是目前少數支援 SPDY 的 CDN。技術上是走 Anycast 而非 GeoDNS dispatch。

HiNet 過去的品質爛到爆炸 (重點在於會 packet loss),也常常是被 DDoS 的目標。台灣其他的 ISP 過去大多都是到日本機房,但 HiNet 會到香港機房,而 HiNet 的這條線路相當壅塞:

主要還是靠 SPDY 的能耐硬是把效能撐到「堪用」的程度,而 CloudFlare 遇到 DDoS 時就慘了。

價錢也是公開的,但以商用水準的品質來說,已經低到及格線以下了...

綜合來說,自己玩玩的東西還可以啦,任何商業性質的網站都不應該單獨用 (與其他 CDN 服務動態偵測服務搭配著用還加減可以用用)。所以目前看到用最多的服務就是內容農場 (Content Farm) 在用,為了節省頻寬與伺服器的負荷,不太在意品質。

補充

最後補充在台灣有機房的 CDN 業者:(按照字母排,可能有漏)

關於 iOS 9 的 Content Blocker

在「An hour with Safari Content Blocker in iOS 9」這邊提到了「An hour with Safari Content Blocker in iOS 9」這篇文章。

文章裡提到:

They have super tiny 'close' buttons that are near impossible to hit, they follow you as you scroll and there is a slow loading full page interstitial that loads on every page refresh. Urgh! Anyway...

在這兩張圖 (Before & After) 說明了很多效果:

而網頁讀取速度從 11 秒變成 2 秒...

蘋果在 WWDC 2015 上的說明則可以在「Safari Extensibility: Content Blocking and Shared Links」這邊看影片。

Google 發表計算網頁真實性的演算法 (Knowledge-Based Trust)

Slashdot 上看到 Google 發表了計算網頁真實性的演算法,Knowledge-Based Trust (KBT):「Google Wants To Rank Websites Based On Facts Not Links」,原始的論文 PDF 檔案可以在「Knowledge-Based Trust: Estimating the Trustworthiness of Web Sources」這邊取得。

論文本身的原理不難懂 (其實方法相當有趣),主要是給出了三個貢獻。

首先是能夠區分是取出資訊的方法有問題 (extract 的演算法不夠好),或是網站本身就給出錯誤的資訊:

Our main contribution is a more sophisticated probabilistic model, which can distinguish between two main sources of error: incorrect facts on a page, and incorrect extractions made by an extraction system.

第二個則是在效能上的改善:

Our second contribution is a new method to adaptively decide the granularity of sources to work with: if a specific webpage yields too few triples, we may aggregate it with other webpages from the same website. Conversely, if a website has too many triples, we may split it into smaller ones, to avoid computational bottlenecks (Section 4).

第三個則是提出好的分散式演算法,可以螞蟻雄兵計算出來:

The third contribution of this paper is a detailed, large-scale evaluation of the performance of our model.

KBT 並不是要取代 PageRank,而是跟 PageRank 互相配合,可以有效打擊內容農場 (Content farm) 這類網站,畢竟 PageRank 的假設在一般的狀況下是有邏輯的。

在「High PageRank but low KBT (top-left corner)」這段講到了這件事情:

We consider the 15 gossip websites listed in [16]. Among them, 14 have a PageRank among top 15% of the websites, since such websites are often popular. However, for all of them the KBT are in the bottom 50%; in other words, they are considered less trustworthy than half of the websites. Another kind of websites that often get low KBT are forum websites.

再找時間細讀其他類似的演算法...

Archives