瀏覽器裡取得 Local IP 位置的方式

whatismybrowser.com 上看到 local IP address 時愣了一下,查了查資料後發現是 WebRTC 的功能:「Local IP discovery with HTML5 WebRTC: Security and privacy risk?」。

如果知道內網的 IP 後,再加上一堆問題設備,hmmm... 能做的事情好多啊 @_@

在「Can I use WebRTC Peer-to-peer connections?」可以看到 Google ChromeFirefox 都支援了...

看了看 chrome://flags 似乎沒解... 來想看看有沒有什麼其他反制的辦法 @_@

Firefox 可以參考「Where can I disable WebRTC and PeerConnection?」這邊提供的方法試看看,不過我沒測過,不知道到底有沒有效...

Twitter 自動轉貼 Plurk 的程式

Twitter 拿掉 RSS 支援後原來「支援新版 Plurk API (OAuth Core 1.0a) 的 Twitter To Plurk Script」這篇提到的程式就不會動了,剛好現在在東京慢慢蹭,就花點時間改寫了。

程式一樣在 Gistgslin/982195 上。

由於不想要接 Twitter API,再加上自己的帳號是公開的,所以這邊就用 Web::Query 去爬 HTML 然後生出對應的 body 貼到 Plurk 上。

不過還是有不完美的地方,像是目前讀取的順序是顛倒的,大多數的情況下應該還好,不過有關連性的 tweet 就會看起來怪怪的 :o

Amazon CloudFront 可以從 Web Console 上看到統計資料了

官方這篇「Announcing Amazon CloudFront Usage Charts for Web Distributions - Track Trends in Requests & Data Transfer」公告說明 Amazon CloudFront 可以透過 Web Console 看到統計數據了:

最近好像補了不少 log 與統計的功能,CloudFront 也趕上這波了 XD

猜測 AWS ELB 內的架構...

AWS Elastic Load Balancing (ELB) 是 AWS 在雲端上推出的 Load balancer。

在非雲端的架構上會使用 Layer 4 Switch (像是 F5Alteon),或是使用 open source 的 HAProxy

從實驗猜測 ELB 是這樣做的:

  • ELB 是 Amazon 自己開發的「軟體」,而非硬體。可能就是跑在 EC2 上,也可能為了 billing 的需求是跑在另外一個 cluster 上。
  • 在每一個有 instance 需要服務的 availability zone 上都會開一台 ELB instance 起來。
  • 每一個 ELB instance 會有一個 public IP 對外,在 ELB domain 解出來的 IP 可以查出來。

所以 ELB 的文件上會警告「每一個 AZ 的運算能力要盡可能接近」:

By default, the load balancer node routes traffic to back-end instances within the same Availability Zone.

To ensure that your back-end instances are able to handle the request load in each Availability Zone, it is important to have approximately equivalent numbers of instances in each zone.

這是因為不同 AZ 的平衡是靠 DNS round robin 處理,所以下面的例子就有建議儘量打平:

For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones.

As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a.

As a best practice, we recommend that you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones.

So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

而量大到一個 ELB instance 撐不住的時候,AWS 就會自動開出第二台:(目前都只放在同一個 zone 上)

;; ANSWER SECTION:
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.249.68.121
lb-guesschocolate-1791292202.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.238.240.61

以這樣的架構,當量夠大的時候,AWS 應該要有能力生出足夠多的 ELB instance 打散?之後再來觀察看看好了... 還有很多煩惱要處理 ~_~

網頁大小的分析...

Zite 上看到「The average web page has grown 151% in just three years」,對網頁大小提出三點分析...

直接列出這三點:

  • The average top 1,000 web page is 1575 KB.
  • More than half of this size is due to images.
  • Flash is on the decrease. Custom fonts are on the increase.

前面兩點其實不意外,網頁大小不斷成長、圖片是流量的大宗。但第三點比較有趣,使用自訂字型的網頁急速成長...

快超越 Flash 的使用率了?

Varnish 的 Super Fast Purger...

Reverse Proxy 的 Cache Infrastructure 在遇到 cache invalidate 都是很討厭的問題,不是不能做,而是效能不太好... 常見的作法是設計成不用 purge 的形式,只要是需要更新,就產生不同的 url,而舊的 url 在沒人 access 後會透過各種 Cache algorithms 自動回收掉,像是 LRU (Least Recently Used) 之類的演算法。

發展久了之後也因此衍伸出很多不同的架構,像是 groupcache 就是假設在同一個 address 的內容永遠不會變的前提。

Varnish Cache 這次發表的東西則是打算從根本問題解決,也就是想辦法讓 purge (cache invalidate) 的成本降低:「Simple scales better and faster in the real world」、「VAC 2.0.3 with high performance cache invalidation API (aka the Super Fast Purger)」。

官方的說法,在大台機器上可以到 60k reqs/sec:

Kristian nonchalantly mentioned that the Super Fast Purger did 60,000 requests per second, on a 6 core Xeon with 36GB memory, traffic over a gigabit network to a single Varnish Cache server, with httperf as test client. But we believe the Super Fast Purger can do a lot more with a little love and tuning.

Squid 效能不好,ATS 的文件很傷,是該找時間來測試看看...

GitHub 總算把使用者頁面放到新的 domain 上:github.io

剛剛看到 GitHub 公告,將使用者網站 (http://username.github.com/ 這種) 改到 http://username.github.io/ 下:「New GitHub Pages domain: github.io」。

GitHub 總算把把使用者頁面放到 subdomain 下這種對安全性問題吃力不討好的事情給搞定了...

PS:我還是對 HiNethinet.net 用在使用者 IP 上這件事情感覺到... XD

變難用的 Zite...

我很喜歡在 iPad 上用 Zite 讀文章,除了看文章以外,有些常出現的新站台我會丟到 Google Reader 訂閱...

不過最近一次改版後,操作上變得很難用...

next 的設計是希望我一直看一下去,不過我用了一陣子以後發現:

  • 大概還是有一半的文章我沒興趣。
  • 按下 next 後,如果剛好遇到 web mode 會很煩躁... (我在 Zite 裡不用 web mode 看文章)

所以後來就完全放棄 next 按鈕,我寧可點左上角的 close 按鈕... (要用左手按,很不方便)

有人要推薦其他的軟體嗎?

node.js 版的 YUICompressor...

看「Fantastic front-end performance Part 1 – Concatenate, Compress & Cache – A Node.JS Holiday Season, part 4」的時候發現 node.js 版的 YUICompressor 比起 Perl 版本更早之前就 porting 完成了:「UglifyCSS」,甚至是官方版本的「yuicompressor / ports / js / cssmin.js」也都遠早於 Perl 版本...

npm 裝 uglifycss 就可以用了...