Home » 2014 » October (Page 2)

用 Require-Recipient-Valid-Since (RRVS) 解決帳號失效的問題

在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了:「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。

起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的:Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。

而這導致了帳號綁定問題:如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號,而他的 Yahoo! 帳號被釋出被其他人拿走後,其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。

Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理,服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since,要求這封信必須在某個時間點後有效,才能讓收信者看到這封信的內容。

Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。

Bitcoin 電子錢包的初始化加速

因為從以前到現在的歷史記錄都被累積起來,Bitcoin 電子錢包初始化所需要的時間變得很長,所以就有不少方法想要改善。

在「Bitcoin Blockchain Initial Sync Time Dramatically Reduced By Headers-First Sync」這篇文章裡面提到了一些事情。

目前的歷史記錄大約是 22GB,文章裡說平均是兩天可以跑完 (我自己是跑了五天...),但另外一個方法則是可以透過「[ANN] Bitcoin blockchain data torrent」這邊提供的 BitTorrent 方式下載記錄 import 進去,這樣就有機會縮短到 4 小時。

另外被提出來的方案是減少傳輸量先確認。而且這個方法已經被 merge 進官方的 client 了:「Headers-first synchronization」,過陣子來測看看速度如何...

Facebook 的 mcrouter

這也不知道積了多久,九月 Facebook 的文章,最近被同事提起來才又仔細看:「Introducing mcrouter: A memcached protocol router for scaling memcached deployments」。

memcached 應該當作普通的 cache layer 來用,拿來放掉了也沒關係的資料。如果掉了會很痛的資料應該丟到 Redis 或是 MySQL 這類 persistent storage。

但有些資料介於兩者之間,掉了會讓使用者用起來不太爽,但也不會死人... 於是總是想要在這上面做些改善。

Facebook 開發的 mcrouter 就可以拿來解這類問題。其中一個 scenario 是「寫的不多,但讀德很多」,寫的時候寫到所有機器上,但讀取時只挑一台:

而這個架構其實可以配合用在 memcached 的 HA 機制上。當有機器爛掉重開機變成空的 cache server 回來時可以暖機:

不過程式看起來並不好編,要先搞定 Facebook 的兩個 C++ 的套件後才能編...

CloudFront 對 POODLE 的安全性更新

CloudFront 的進一步更新出來了,剛剛看到信件通知。分成兩種 case,一種是使用 dedicated IP 服務的人,一種是使用 *.cloudfront.net 的人。

使用 dedicated IP 的人仍然可以打開 SSLv3,不過 CloudFront 建議在 use case 允許下不要開:

If you are using the Dedicated IP Custom SSL Certificates to serve SSL traffic, you may configure whether your distribution accepts SSLv3 connections. We have added an option to select this in both the console and the API. For existing distributions that use Dedicated IP Custom SSL, the default value for this new setting will be to allow SSLv3, so you will need to update your distributions if you want to disallow SSLv3. We do recommend that customers disable SSLv3 if their use case allows it.

使用 *.cloudfront.net 預定在 2014/11/03 之後就會關閉 SSLv3:

Additionally, starting on November 3rd, 2014, we will begin disabling SSLv3 for ALL customers who use SSL with the default CloudFront domain name (*.cloudfront.net). If you believe that this policy will negatively affect your website or application, please contact us as soon as possible so that we can discuss your options: https://aws.amazon.com/forms/poodle_sslv3

而使用 SNI 的人不需要管這件事情,因為這代表你已經是用 TLS 了:

If you're using Custom SSL Certificates and Server Name Indication (SNI), you don’t need to take any action because, as SNI-Only Custom SSL distributions already did not allow SSLv3 connections.

AWS 在歐洲開第二個資料中心了:德國

上次開 us-west-1 (Ireland) 是 2008 年 12 月了,離這次 eu-central-1 (Frankfurt) 開在德國差了快八年:「Now Open - AWS Germany (Frankfurt) Region - EC2, DynamoDB, S3, and Much More」。

六月的時候有人發現 eu-central-1 這個代碼:「Amazon AWS builds a data center in Germany: Nice idea!」。

比較有趣的是,公告雖然出來了,但有些地方好像還沒完全搞定:

價錢的部份比 eu-west-1 貴一點點而已,對於要符合歐盟法令將資料留在歐盟地區,並且希望有遠距離異地建設的服務來說,解決了相當多的問題 :p

剛剛踹了 ec2.eu-central-1.amazonaws.com 這個 domain,看起來目前亞洲地區都還是從美國西岸再一路過去,不知道之後會不會再最佳化這塊,走俄羅斯或是有辦法走東歐過去...

CloudFront 統計資料繼續改善...

半年多前 CloudFront 在 web console 上實做了統計資訊:「Amazon CloudFront 可以從 Web Console 上看到統計資料了」,而今天可以看到更多東西了:「CloudFront Update - Trends, Metrics, Charts, More Timely Logs」。

首先是確保收到 log 的時間差,目前可以確保一個小時內會收到 log:

With these changes, the newest log files in your bucket will reflect events that have happened as recently as an hour ago.

再來是多了 cache 分析:

以及熱門物件統計資訊:

也是其他 CDN 業者都已經有的功能,算是在補 :p

查看各家 CDN 在各地的狀態

Cedexis 的「Real time data for real time decisions」蒐集了各家 CDN 在各地的連線資訊,包括了 response time、throughput 這些資訊,能夠解讀的話對於事前分析會很有幫助。

舉個例子來說,泰國地區 2014/10/20 的數字如下圖。

先從 latency 的部份開始看,可以看到 AkamaiCDNetworks 的速度分別是 52ms 與 63ms,可以合理猜測都是在泰國當地有 PoP 直接服務。而 LimelightCloudFront 要 98ms 與 111ms,看起來最少是新加坡或是香港?

而 availability 的部份也可以看出來國內線路的優勢,只要一跨國就不好維持。

這樣就可以針對需求而決定要找哪幾家 CDN 業者來談。在找 CDN 業者實際測試前,先看看這邊的資料會是很不錯的資訊,可以省下不少白工。

Archives