在 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 欄位)

CLOSE_WAIT 與 TIME_WAIT

《TIME_WAIT and its design implications for protocols and scalable client server systems》 這篇真是不可思議的詳細易懂, 讀完後大概理解 TCP 結束時的前因後果了。

首先要理解的前提是, 無論 process 如何結束, 只要網路連線正常, TCP 會保證另一端得知連線結束。

接著問題要視主動 close 和被動 close 兩個方向來看。被動 close 比較單純, 會進入 CLOSE_WAIT, 程式要記得呼叫 close() 然後就沒事了。由 man page 得知, recv() 回傳 0 bytes 表示另一端結束連線。在 blocking IO 的情況下很單純, 不太會忘了 close。 non-blocking 的情況有可能寫出 bug, 而一直沒呼叫 close(), 這時用 netstat 可看到這類的連線狀態一直卡在 CLOSE_WAIT。

主動 close 的時候, 一切順利最後會進入 TIME_WAIT, 然後就是等一段時間才真的釋放使用的 port。對於同時需要主動連線出去 (做為別人的 client) 的 server 來說, 短時間內大量累加的 TIME_WAIT 有可能造成 port 不足而無法連線出去, 所以這篇的作者建議在設計 protocol 時, 盡量讓 client 主動結束連線。

綜合以上的訊息, 我理解的架構是: 盡可能讓 client 關掉連線, 再加上一個合理的長時間 timeout, 只有在 timeout 的情況下 server 才會主動關掉連線。發生 timeout 有兩種可能: client 其實「還在線上」, 只是很久沒傳資料; 或是 client 斷網後, 長於 timeout 的時間沒有連上網路。但不論何者, 為了減省 server 資源 (# of fd, memory, thread, etc), timeout 仍是必要的。

我之前在理解 TCP 斷線議題時, 一直卡在程式要怎麼知道對方斷線了? 搞清楚 kernel 實作 TCP 這點並做了些實驗後, 加上讀完這篇, 才恍然大悟。

TCP 與斷線

這件事困擾我一陣子, 一直搞不懂「網路斷線」是怎麼一回事。看了些資料做些實驗, 才發覺我搞錯斷線的意思。

TCP 是 kernel 實作的, 不管程式是自己掛掉還是被 SIGKILL 掛掉, 只要網路是通的, TCP 會如預期做結束連線的動作。即使中途 client 網路斷線, 接著 client 掛了, 待網路接通時, client 還是會送出結束連線的訊息給 server。偉哉! TCP!!

反過來說, 若網路真的不通, 在網路另一端的程式, 沒有方式可以得知這裡已經「斷線」, 挺多只能在接收或傳送資料時設個 timeout, 時間到沒回應就視對方為斷線。

總結來說, 只要另一端有辦法能連回網路, 無論發生什麼事, 都會通知對方結束網路連線, 這是由 kernel 保證的, 和 process 怎麼結束無關。但在網路不通的情況下, 雙方都無法得知對方是否真的結束了, 只能設個 timeout, 時間到就自己結束連線。

Btw, VM 真是測試網路斷線的好幫手, 方便在一台機器上做網路中斷的測試