在核輻射避難所建的資料中心

Nuclear Fallout Shelter 照字面翻是核放射塵碉堡,意思上算是可以對抗輻射塵的防空洞,用 Google Translate 翻出來是「核輻射避難所」,感覺也頗貼切的啦...

而 C14 project 則是 Online.net 在巴黎的核輻射避難所建立 data center 的玩意:「C14 story - Part 1 Meet Our Nuclear Fallout Shelter

在地下 26 公尺,如果一層樓三米的話,大約是已經是地下八樓到九樓的位置了:

Starting in October 2016, you will be able to store all your critical C14 data in our fallout shelter, located 26 meters underground in Paris, France.

整個計畫在 2012 年從法國政府買下來,然後開始重建:

In 2011, the French state, owner of the building, decided to move the Ponts et Chaussées' central laboratory in the Parisian suburb and started to dismantle the building.

The Ponts et Chaussées' central laboratory buildings were revamped and divided in multiple bundles to be sold and transformed in multi-unit housing. The main building and the shelter were sold separately via a public invitation to tender. Online landed the deal in September 2012 with the project to build a Datacenter. The project’s codename is DC4.

接近完工的照片看起來好棒啊:

看起來這是一系列的故事,到時候應該會有不少照片可以看...

Google 對於行為分析具有壓倒性的資料

The Verge 的「Google and Facebook still dominate tracking on the web」這篇文章題到了「Online tracking: A 1-million-site measurement and analysis」這個分析報告。

現在有很多會 track 使用者行為的 javascript,或是 free cdn 服務,而報告的作者想要知道「哪個公司收集到最多最完整的資料」。

不過 The Verge 給的標題很奇怪,因為 Google 能追蹤的量遠遠超越 Facebook

Google Analytics 第一名不怎麼意外,DoubleClick 是網路上最大的廣告服務也不意外... 前五名都是 Google 的服務,後面還有一堆也都還是 Google 的服務。

Square 申請 IPO

Square 丟出 IPO 申請:「Square Files Registration Statement for Proposed Initial Public Offering」,其中參與的單位包括:

Goldman, Sachs & Co., Morgan Stanley, and J.P. Morgan are acting as lead joint book-running managers for the proposed offering. Barclays, Deutsche Bank Securities, Jefferies, RBC Capital Markets, and Stifel are acting as additional book-running managers for the proposed offering, and LOYAL3 Securities, Inc. is acting as a co-manager.

維基百科上的「Square, Inc.」有整理過的歷史資料。2009 年創立,2010 年五月上線的公司,從 Series A 跑到 Series E。

Google 對 GitHub 先前遭受 GFW 的 DDoS 攻擊的分析

Google Online Security 分析了前陣子 GitHub 被 DDoS 攻擊的行為:「A Javascript-based DDoS Attack as seen by Safe Browsing」。

透過 GoogleSafe Browsing,針對 baidu.com 這個網域的 injection 情況分析:

可以看得出來分成多個不同階段攻擊。其中 AWSCloudFront 承受了不小的壓力,不過畢竟是商用水準的 CDN,沒那麼容易垮掉。後來則是攻擊 GitHub 造成影響而上了新聞。

最終還是繼續推廣 TLS,可以避免中間被 injection 攻擊:

Had the entire web already moved to encrypted traffic via TLS, such an injection attack would not have been possible.

Google Cloud 推出 Nearline Storage

Google Cloud 推出了 Nearline Storage:「Introducing Google Cloud Storage Nearline: (near)online data at an offline price」。

同樣都是 USD$0.01/GB,相較於隔壁棚 AWSAmazon Glacier 需要 3~5 小時的重新上線時間,Nearline Storage 是 3 秒鐘。

不知道這次 AWS 會多快反擊...

利用 pt-online-schema-change 同步 master 與 slave 的資料

在「Syncing MySQL slave table with pt-online-schema-change」這篇看到 master 與 slave 的資料不同步時,強制性同步的方法:

pt-online-schema-change --alter 'ENGINE=INNODB' D=dbname,t=tblname

由於 pt-online-schema-change 的作法是建一個新的表格,然後把舊表格的資料寫過去,而這些行為會被 replicate 到新機器上,於是就同步了...

這招有趣 XDDD

OCSP stapling

OCSP (Online Certificate Status Protocol) 是用來檢查 SSL certificate 是否被撤銷的方法。OCSP server 接受 HTTP POST 後,回答 client 這個 SSL certificate 是否仍然有效。

對於 client 來說,這主要有兩個問題:

  • client 需要多花時間連到 OCSP server 確認。
  • 隱私問題:OCSP server 會知道「這個使用者試著連到使用這個 SSL certificate」的資訊。

而對於 OCSP server 來說,這個方法的 scalability 很差,熱門的站台會產生大量的流量打進 OCSP server。

OCSP stapling 則是解決這個問題的方法。藉由 server 向 OCSP server 要一次 OCSP response 後,直接傳回 OCSP response 給 client (通常是 browser) 避開了上面的問題。這個方法也逐漸在普及了:(取自英文版維基百科文章內的說明)

OCSP stapling has not seen broad deployment to date, however this is changing. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, and LiteSpeed Web Server since version 4.2.4. and Microsoft's IIS since Windows Server 2008

On the browser side, OCSP stapling was implemented in Firefox 26 and in Internet Explorer since Windows Vista.

所以已經有不少 client 與 server 都支援了...

在瀏覽器內偵測連線是否正常...

在「Offline automatically displays online/offline indicators to your users」看到 Offline 這個軟體,可以偵測網路狀態,做出像 Gmail 在離線時重連的特效...

在偵測到斷線時:

然後是重連的效果:

偵測到回復時的效果:

支援 IE8+ 與其他瀏覽器...

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 速度比較快的幾家簽,對速度會有幫助...

寫 Online Judge 的題目...

早上又回頭跑去寫 UVa Online Judge 的題目,這應該是參加高中生與大學生在寫的?好久沒寫了...

這東西除了訓練資料結構與演算法外,另外還可以訓練「鑽牛角尖讀 spec」的能力:在題目裡沒保證的,就一定會炸給你看...

舉例來說,第一題的「100 - The 3n + 1 problem」上面只說要找 i 與 j 之間的範圍的最大值。於是很多人就寫了:

for (t = i; t <= j; t++) { ... }

文件上有提到保證 i <= j 嗎?沒有。

多練習這些題目後,除了資料結構與演算法外,對於實際工作的文件就會很自然而然避免過度解讀。