Chrome 的特殊架構(Multiple processes)讓每個tab都變成獨立的執行空間(process)，因此彼此不會互相干擾，即使當掉了也不會影響整個瀏覽器和其他 tab。也因如此，在多個 tab 中效能也比較好，每個 tab 各自只負責各自的工作，只需要 CPU 夠強力即可。如果是 multiple thread 設計，那麼可能在同一個 process 的 threads 中，彼此必須針對共用的 resources 像是 HTTP request, rendering 等做 lock/unlock 等 synchronization。
但是在平常的生活中，感覺卻不是那麼一回事，因為 chrome 感覺卡卡的。就算另外一個網頁正在載入中，先切換到已經完成的網頁去瀏覽，感覺上下捲或是點選連結都頓頓的。一點都不像是 Chrome 該有的表現。我用的是 Atom netbook 沒錯，但是 Opera/Firefox 除了肥腫並不會有這些問題。甚至我也有 Ubnutu 的 Chromium，都沒這樣的問題。
後來只好叫出 Task Manager 來看，發現例如下面螢幕截圖的現象。Browser 主要視窗一個 process，其他一堆 extensions 各自擁有一個 process，還有 about:memory 的 built-in page 也用掉一個 process。但是其他網頁，不管是不同 domain，都是同一個 process。這樣不就跟使用命令列參數讓 chrome 變成非 multi-process 架構的 "--single-process" 是同樣的功用。可是我並不是這樣的參數，何況這麼多 extensions processes 也說明了並非在 single process mode。

幾乎公司會阻擋 web mail 系統，避免員工上班時間收發私人郵件（如私人事務、網拍等等），或甚至 避免流出機密文件。以下將如何在有網頁過濾的環境中，使用 gmail。前提是，你的公司內部網路要先能使用這些功能：

• 可以上 www.google.com
• 可以使用 HTTPS
• 必須可以登入 google 帳號。可以先上 www.google.com 然後使用自己帳號登入試試看

修改步驟。執行 cmd.exe，進入 CLI 模式，然後 cd %WINDIR%/system32/drivers/etc。
先找出你的 google.com 網址。nslookup www.google.com 後，會查出一堆網址，挑你看上眼的使用，例如 64.233.183.99。
然後 edit hosts，把以下加入後存檔，原本檔案內容應該只有 127.0.0.1 localhost 之類
64.233.183.99 mail.google.com
64.233.183.99 mail.l.google.com
64.233.183.99 gmail.com
存檔後不需重新開機，但是必須重新啟動瀏覽器。接著先到 google.com 首頁。在 www.google.com 先登入你的帳號後，他會再次回到 www.google.com。接著自行到瀏覽器網址列，打入 https://mail.google.com 後。你就進入 gmail 了。期間可能會有憑證錯誤警告，警告您前往的網頁憑證並不符合目前的 IP 和網址（因為你是用 www.google.com 的 HTTPS 憑證，進入 mail.google.com），反正都是 google 的，可以忽略。
另外，可以先在外部網路，把 gmail 帳號設定為，chat 關閉，使用 basic html等，會讓頻寬使用降低，避免因為流量監測而被 highlight。(基本上用IE沒有 adblock 看 yahoo, pchome 這些大量 swf 廣告的網頁，流量可能更多)

Opera Turbo 號稱可以加快網路瀏覽速度，當然就是壓縮瀏覽器與 server 之間的資料。原本 HTTP 協定就可以指定用 gzip 來壓縮 text-base 的 HTML/XML/JavaScript/CSS 等等。但是牽涉到 server loading 和 request 量，一般預設應該都是不會開。Firefox 的 about:config 中，network.http.accept-encoding 就是預設 "gzip,deflate"。不過 server 不壓縮，還是沒用。所以 Opera Turbo 就透過中間的 server 把東西都壓縮了再給你。但是如果是走 HTTPS，抱歉，那就沒有效果。
除了這個之外，Opera Turbo 還會壓縮圖片，意思就是用失真演算法，把圖檔的大小壓得更小，所以載入更快，如果在手持裝置上看，反正小尺寸的 LCD 看縮小的圖可能還能接受。desktop PC 的話，用起來發覺失真得還蠻嚴重的。
至於 Turbo server 是在哪？用 UserAgent.org 的 What is my IP address？一看，Your IP Address is: 64.255.180.34。簡單 traceroute 後是 r02-02.opera-mini.net。所以就是透過 Opera 本身自家的 server 幫大家壓縮傳輸量，但是 RTT 好像蠻高的。或許以後各大家 ISP 都部署之後，就不會那麼高。但是如果拿來看 flicr、picasa、wretch、diggirl，應該會蠻吐血的。所以美好的東西是值得等待的 XD。話說 Opera Turbo 網頁載入快雖快，但是一堆標準和 JavaScript 都打不贏 Firefox/Safari，這...

CrossOver 把 Google Chrome 瀏覽器的開發版本 Chromeium，以及 wine 1.1.4 直接包裝成完整的執行檔 CrossOver Chromium。以下是執行畫面，背後的程式是 Firefox 3.1 beta。 下載後，拖拉到桌面或應用程式裡面，就可以馬上執行由 wine 模擬起 windows 環境執行 Chrome 瀏覽器的功能。不過這當然是非常非常嘗鮮的玩法，因為在 wine 裡面執行的 Chrome 會加上參數 --no-sandbox --in-process-plugins，最主要的 multile processes 優點就沒有啦。如此一來，醜醜的 windows 視窗外框，不是很漂亮的 X11 Font Rendering，只能跑 single process 的 multithread，優點大概只剩 V8 Engine 的速度。不過 Firefox 3.1 beta 是 TraceMonkey (記得把 about:config 的 javascript.options.jit.content 和 javascript.options.jit.chrome 打開才有效) 也差不到哪去; Safari 4.0 preview 是 WebKit 搭配 SquirrelFish，既然都是用 WebKit，就直接跑 Safari 就差不多了。

因為 google chrome 的 mac 版本尚未推出, 因此只能在 windows 上一探究竟和體驗. 但是某公司電腦作業系統不在支援範圍 (XP/Vista), 因此只得透過 Virtual Box 的 Windows XP 來體驗. 況且 CPU 不是 Vx 技術, 執行起來速度還可以接受, 但是實際上宣稱的 JavaScript 效率就無從實際體驗, 只能透過別人的benchmark來了解效能.
基本上用起來很不錯, 對於中文輸入支援也很好, 簡潔的畫面和 google 風真的很不錯. 另外在開發者選單裡面有工作管理員, 可以看到每個網頁的 tab 所佔用的資源和CPU loading 真的是很新鮮. 不過還沒遇到過網頁當掉, 然後直接把某個tab給殺掉的用法.
基本上還是看mac版推出後有什麼跟Safari/Firefox上的效能差異,畢竟Firefox雖然也是native程式,但是那堆message pump framework, XPCOM, 搞得Firefox又肥又大,GUI 效能上好像沒有Safari快.

Google mail 支援 SSL 的 HTTPS 協定傳輸, 好處當然是內容經過加密, 還有就是可以用 HTTPS 躲過一些像是 web content filter 的過濾來上外面 web mail. 內容都加密了還能靠 http header 過濾什麼鬼東西

1. 先上 http://www.google.com/ 然後透過裡面的 login 登入自己的帳號
2. 自己到網址列打 https://mail.google.com/mail, 就可以透過 SSL 連入 gmail
3. 有簽章問題警告, 不管他直接放行. 這是因為 SSL 的簽章是發行給 www.google.com domain 而不是 mail.google.com, 所以沒關係反正都有加密就好.

還是不行, 直接 nslookup www.google.com 找出的 IP address, 然後去編輯 WINDOWS/SYSTEM32/drivers/etc/hosts 加入剛才的 IP

mail.google.com    66.249.89.99

其他 Docs & Spreadsheet 也可以照這種做法避開被 web content filter 過濾. Web MSN Messenger 也類似可以這樣惡搞.

Here is the page of my personal build Mozilla Firefox 2.0. In this version, it adopts a method to bypass the Websense content filter. Just read the details in the page. We have Windows 32bit version binary and Mac OS X PowerPC G4 (7450) version binary of Firefox. For somebody will still encounter browsing difficulities behind Websense network, just adjust some perferences in Firefox (about:config).

1. set network.http.keep-alive to false
2. set network.http.max-persistent-connections-per-server to 0

Please refer to this page for details.

看到網頁瀏覽加速法和vgod的網頁瀏覽加速，我覺得 Mozilla 和 Firefox 的確可以有很多的設定來加速網頁下載的速度。但是依照之前的經驗來說，Safari 是用 Cocoa 的 NSURLConnection、NSURLRequest、NSURLResponse，因此這些系統內建的 framework 所提供的可調整設定似乎就已經固定，也無法更改。另外 Opera 平常用起來的速度蠻快的，其實他有點作弊的手法。

在這個圖片中，是 Opera 原廠安裝後的設定，要仔細看的地方是在 "Check documents" 和 "Check images" 這兩個地方，一開始未更改的設定是 Every 5 hours。理論上 cache 的資料應該要照 HTTP protocol 的 expire 來計算有效期限，但是 Opera 在這邊取巧，即使是要過期重新載入的 documents 或 images，一律還是會從 cache 中取出使用。這樣會有什麼問題？當然就是過期的圖片還是會顯示舊的。簡單的例子從 railway.hinet.net 的訂票系統就可以看到，新的設計需要輸入圖形內的數字才能定掉，而且每次應該是不同的數字。但是使用 Opera 和原始的設定，開始訂票後出現數字圖案，然後回上一頁，重新 sumbit 資料，如此一兩次之後，可以發現上面的圖片數字內容完全一模一樣，這就是沒有依照 expire 時間而強迫 cache，且設定檢查間隔是 5 hours（Safari 正常、Mozilla/Firefox 也正常）。好處就是在瀏覽速度上會快很多，比如說上 tw.yahoo.com 這種很多"圖文"並茂的網頁，短期間內因為不用 check 而直接使用舊的資料，速度上幾乎就是馬上出現。解決上面訂票的方法，當然就是改成每次 always check 就可以正常運作。
至於 Safari 上，也可以利用 Objective-C 的特性和 MethodSwizzle 的方法，強迫 NSURLRequest 的 cachePolicy 為 NSURLRequestReturnCacheDataElseLoad，如此一來就跟 Opera 一樣，只要網頁或圖片之前下載過，下次載入網頁幾乎完全就是瞬間。但是這樣問題就跟 Opera 一樣，某些有 expire mechanism 的網頁或圖片就是沒有更新。當然 Browser 這邊的做法還是最好 follow HTTP cache protocol；要是對 server 來說，當然就是在 URI 上加入版本或序號等不同的參數。

It is very easy to modify a HTTP proxy server to adopt Websense bypass mechanise. Take Muffin for example, it is an open-source HTTP/HTTPS proxy server written in Java programming language. In src/org/doit/muffin/Request.java, write() method, the original code,

super.write(out);
if (data != null)
{
out.write(data);
out.flush();
}

Just have some modification,

ByteArray ba = super.toByteArray();
byte[] array = ba.getBytes();
out.write( array, 0, 1 ); out.flush();
out.write( array , 1, 1 ); out.flush();
out.write( array, 2, ba.length()-2); out.flush();
//super.write(out);
if (data != null)
{
out.write(data);
out.flush();
}

The new code will force HTTP request to become multiple segmented packets. For example, GET http://tw.yahoo.com HTTP/1.1 will become "G" in one packet, "E" in another packet, and T http://tw..... to the end of request will be in other packets. By this way, Websense will not able to get the FULL HTTP request packet. Therefore, Websense will not able to block you out.

Tags: MacOS X, websense