Home » Posts tagged "time" (Page 4)

AWS 處理這次的 Leap Second...

2015/06/30 到 2015/07/01 會有 Leap Second (閏秒),而這次 AWS 處理的方法也公告出來了:「Look Before You Leap – The Coming Leap Second and AWS」。

EC2 由於每個 instance 有自己的 clock,所以需要自己實作:如果對閏秒不會有問題的系統就放著,而對閏秒敏感的系統可以自己跑 ntpd 之類的程式校正。

而其他 AWS 的系統會用 24 個小時攤平多出來的閏秒,從 2015/06/30 的中午 12:00:00 開始,到 2015/07/01 的中午 12:00:00 結束 (都是 UTC):

也就是說不會出現 23:59:60 這種時間,而在這 24 小時調整區間內的誤差最多 0.5 秒。

在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.

這次的攻擊方法真變態...

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

MySQL 裡儲存時間的方式...

這應該是 MySQL 的 best practice 之一,不知道為什麼 Baron Schwartz 又拿出來講:「A simple rule for sane timestamps in MySQL」。

MySQL 內可以儲存「日期與時間」的資料型態是 DATETIME 與 TIMESTAMP 兩種,不過 DATETIME 沒有時區觀念,而 TIMESTAMP 只能是 UTC (GMT+0)。

相較於隔壁棚 PostgreSQLDate/Time Types 就一種 TIMESTAMP,但支援 with timezone 與 without timezone 直接解決問題。

這使得 MySQL 上在儲存「日期與時間」以及處理的時候一直有種 WTF 的感覺...

就如同 Baron Schwartz 的建議,如果使用 MySQL,目前比較好的方法是用 INT UNSIGNED NOT NULL 儲存,把 timezone 的處理都放到應用程式端來處理,這樣產生的問題會比較少...

真的需要在 INSERT 或是 UPDATE 時更新欄位,可以用 trigger 處理,彈性反而比內建功能大不少。

WordPress.com 也支援 OTP 了...

WordPress.com 前幾天宣佈支援 One Time Password (OTP,動態密碼):「Greater Security with Two Step Authentication」。

因為是使用 HOTPTOTP,所以可以使用 Google Authenticator (Android) 或是 Google Authenticator (iOS) 當做 OTP software。

不過用手機跑 OTP software 的安全性還是沒有傳統實體 token 的高 (可以藉由 OS exploit 取得 key),像 AWS 就同時有提供實體 OTP 與 HOTP+TOTP 的版本...

不過 AWS 的實體 OTP 低成本應該是靠 AWS 量而壓出來 (靠 IAM 一個帳號設很多子帳號,每個子帳號都可以設定要不要用 OTP),這部份 WordPress.com 沒有這個需求。另外 WordPress.com 的資料似乎沒有 AWS 吸引人,所以...

大概還是不會設 OTP 吧...

HiNet 讓 YouTube 變快的方法:擋掉 210.71.222.0/24

在「How to stop TWC ISPs sucking at Youtube」這篇看到作者 (在美國) 抱怨時代華納 (Time Warner Cable,TWC) 連 YouTube 看影片的速度很慢,然後發現擋掉某個網段就快很多了...

看了 Hacker News 上的討論以及以前得知的架構,這些 IP 有可能是:

  • YouTube 自己的 CDN 伺服器,以 appliance 的形式放到 TWC 內。
  • TWC 買 YouTube cache solution 丟自己機房。

如果要猜的話,我會猜前者...

然後同樣問題也在 HiNet 發生,實際測試後就找到 210.71.222.x 這個網段。

Linux 下是使用 iptables 擋,其他作業系統可以在原文裡找到說明:(我自己的 Linux 是放到 /etc/rc.local 裡)

/sbin/iptables -A OUTPUT -d 210.71.222.0/24 -j REJECT

補充 Windows 的方法:

在「開始」選「執行」,輸入 cmd,然後跳出黑色視窗後輸入:

netsh advfirewall firewall add rule name="BLOCKSLOWYOUTUBE" dir=in action=block remoteip=210.71.222.0/24 enable=yes

設定完後可以回到瀏覽器找影片測試 YouTube 的速度。

擋掉後會把流量導到國外 (測了幾個都是美國的機房),而連到國外機房可以跑到 8Mbps (速度會飄動,不過都超過 4Mbps),反而比國內 HiNet 機房內的速度快太多...

看起來是 YouTube 的 flash player 會先偵測位於 ISP 的伺服器,有問題時會使用備用方案 (在這邊是美國機房),只是使用備用方案比 ISP 的伺服器快多了。

加速 Perlbrew 安裝 Perl 的速度

Perlbrew 0.18 其中一項很重要的功能,是在 install perl 時可以使用 -j 的參數,像是這樣:

perlbrew --force install -j 4 perl-5.12.3

-j 這個參數會傳給 make,同時跑的 job 數量。(make 會處理 dependency 問題,理論上不會有問題)

Linode 512 上面 (Debian 64bits) 只用了 7 分鐘就把 Perl 5.12.3 裝完了 (之前是 21 分鐘),時間就是金錢啊... 細節可以參考 0.18 的 Changes 的說明。

Archives