iptraf filter 用法

我用 ssh 連上 server 跑 iptraf, 但 ssh 資料一直更新 (因為畫面顯示要傳資料回來, 所以就無限循環 ...), 得濾掉 ssh 資料才行

參考資料:

• 3.0 版: IPTraf Filter Configurations « Phithak Thaenkaew
• 2.7 版官方文件: Filters

注意事項:

• 試了半天, IP filter 好像只有影響到 IP traffic monitor, 結果這句話就寫在官方文件的開頭 ...
• Filtler -> IP ... 會看到右側寫 "IP filter active" 或 "No IP filter active", 表示目前有無採用 IP filter
• Edit filter 後要再按 Apply filter 才會生效的樣子
• 可定義多組 filter, 但一次只會 apply 一組 filter
• 同一組 filter 裡, 採用 first match 的樣子
• 要濾掉 ssh, 要先寫一則 exclude port 22, 再寫一則 include all

CSS 雜項心得 (2)

重要的基本觀念如以前CSS 雜項心得所寫, 還是 box model, float, position 等, 但用熟開發工具, 寫網頁會更快。看完這篇 Modern Web Development Part 1 – The Webkit Inspector 後功力至少增加個一甲子, 才懂得怎麼運用 box model 的觀念配合 Chrome Developer Tool 的 Metrics 來看元素占用空間的情況, 遇到「破掉」或對不齊等問題, 用 Metrics 檢查一下, 就知道是 padding 還是 margin 出問題, 或是因內部的子元素往上或擠出空間等。相較以前, 除錯省了不少時間。

過了兩年, 如今不用擔心 IE 6 或著也不用擔心 IE 7 了, 不過 HTML5 和 CSS3 多了不少東西, 支援的瀏覽器變多後, 也就更值得學。所以, 要學的東西也許是不會變少吧

用 CSS 寫出多欄等高的版面

找了一下如何用 CSS 寫出多欄等高的版面, 看到這篇Equal Height Columns with Cross-Browser CSS, 是找到幾個方法裡最完備且乾淨易懂的作法。不過實際應用上會有些小地方要注意, 也難怪有人 Give Up and Use Tables的主張了 ...

使用 PIcasa 批次改圖

兩個重點

• 加入 PNG 到支援的圖檔類型裡, 預設沒有會導致 Picasa 裡看不到圖
• 使用匯出功能批次改圖

API 使用 http 做為底層 protocol 的好處

以前對 http-based 的 API 一直有疑問 (免責聲明: 我沒有弄懂 RESTful 和這點的具體差別), 為什麼要綁在 http 這個不太相關的協定上? 尤其是在試用 Solr 後, 發覺因為使用 http 提供 api 的緣故, 即使是 localhost 連線做很簡單的查詢, 也有一定的 latency 成本。

不週在多了一些 network programming 經驗後, 對此有了不同想法。

首先, network programming 很痛苦, 一開始要處理兩個問題: 第一點是在 streaming-based 的資料上, 提供 datagram 的概念, 這樣才有辦法傳遞和接受參數。streaming 不同已有完整資料的檔案一般, 資料回傳時間不一定, 每次讀回的 byte 不一定, 提供 datagram-like 的介面, 要費點心思。

第二個問題是, 要將資料 serialization, 這件事本身也很苦, 若要求效率, 要用 binary 格式, 實作苦除錯更苦; 若用 text 表示 (如 JSON), 也許有一天會有效能問題, 若需要傳 binary file, overhead 太大。

第一和第二問題在面對多種語言的 client 時 (比方 PC 上有人想用 Python 或 C++, mobile 上有 Objective C 和 Java), 實作成本更高。

解決這些基本問題後, 若幸運地服務順暢, 用戶成長個 10 倍, 有什麼方法可以擋住 10 倍的使用量? 也就是 scalability 的問題, 這又是一串的麻煩開始。10 倍擋住後, 變 100 倍怎麼辦?

反之, 使用 http-based solution, 以上統統不是問題。有成熟的 web server 包含 scalability 都解決了, http client lib 也是遍地開花, 沒有找不到套件的問題, 只有太多種版本不知選那個好的困擾 (看看 python 那票 urllib, urllib2, httplib, httplib2 以及其它各家 3rd party 實作)。更可以直接用 browser 試用 API, 連寫程式都不用。

照這樣來看, 因為綁定 http, 而「稍微」多些 latency, 似乎不是什麼不得了的負擔。

ps.

• kcwu 補充說明使用 http 還有減少被阻擋的機率, 有許多地方會擋 port 80、443 以外的 port。此外, http 有許多現成工具提供 encryption, compression, cache, proxy, load balance, authentication 等功能。
• Socket Programming HOWTO 值得一讀, 簡要地描述 network programming 的基本知識以及實作會遇到的問題。

在 iPad/iPhone 上連續抓 screenshot

雖然 iPad 可以按 sleep button + home button 抓一次 screenshot, 但要抓第二次 screenshot 卻要等個數秒以上, 不夠應付我的需求。於是改查如何錄下 iPad 上的畫面, 得知有 AirPlay 這個好東西, 可以將 iPad 畫面轉到 Mac 或 PC 上。詳細介紹見 How To Record Your iPhone Screen or Record Your iPad Screen, 作法複製到這裡:

1. Install AirServer on your PC or Mac.
2. Make sure your PC/Mac is on the same wireless network as your iPhone or iPad.
3. Start AirPlay on your iPhone or iPad
4. Record your computer screen using Camtasia, Screenflow, etc.

裝 AirServer 時, 會要求裝 DirectX 和 Bonjour, AirServer 試用期有七天。之後參考 FAQ 說明, iPad 進 Airplane Mode 一陣子, 再取消, 然後雙擊 home button, 將下方畫面移到最左側, 就會看到 AirPlay 的 icon (進出 Airplane Mode 前, 我沒看到這個 icon)。

再來就找套可以一按 PrintScreen 就直接存下圖片的軟體, 就差不多達到目的了。

cookie 雜記

讀完這兩篇就差不多通了

• HowStuffWorks "How Internet Cookies Work"
• HTTP cookie - Wikipedia, the free encyclopedia

做實驗的話, 配合 Firefox View Cookies 很方便。

基本知識

• http 本身是 stateless, 理由大概是利於實作, server overhead 也小。若 server 想維持使用者登入狀態、個人偏好、追蹤瀏覽過程等有狀態的功能, 得透過別的方式, 也就是 cookie
• cookie 是 http header 裡的其中一個欄位, server 透過 http response header 裡的 Set-Cookie 要求 client 記下資訊; client 之後看到 URI 符合 domain + path 時, 會在 request header 裡加上 Cookie 傳送當初用 Set-Cookie 存下的 key-value 回去
• cookie 裡有個 expire 欄位表示什麼時候失效。有設這個欄位稱作 persistent cookie, 沒設的話稱作 session cookie, 表示關掉 browser 時, browser 要自行清除它

restore session 會一併回復 session cookie

• Chrome 和 Firefox 在使用 "restore session" 的功能時, 不只會回復關閉時的頁面, session cookie 也會一併復原, 這是符合此項需求的設計, 不是 bug, 要 100% 重現關閉時的狀態
• facebook 登入框下面有個 "keep me logged in", 還有 Google account 登入有個 "stay signed in", 有勾的時候會用 persistent cookie 記錄登入資訊, 沒勾時會用 session cookie。但若平時用 Chrome / Firefox 有開啟回復關閉時的頁面, 勾不勾都沒差

third-party cookie 和廣告商

• 對於 domain A 來說, 可能嵌入其它網站的圖片、iframe 等, 這些物件也會有 cookie, 同時送出 http request 取得這些物件時, 會帶有 Referer 欄位指向目前網址 (即 domain A 下的某一 URL)。這類非 domain A 的 cookie, 稱為 third-party cookie
• 因此, 網站加速技巧之一, 是將圖片放到另一個 domain, 不只可以增加 browser 同時取得檔案的連線數, 也可以避免不必要的 cookie 傳送
• 反過來說, 如 Facebook、DoubleClick 這類會在很多網站嵌入他們物件的網站, 可故意放 cookie 來得知使用者更多資料, 因為使用者每到一個有嵌入網站 B 物件的網站, 都會送出目前所有搜集到網站 B 的 Cookie 資訊出去, 同時帶有目前網站網址 (透過 Referer 欄位)