這是一篇譯文,原文:http://blog.httpwatch.com/2009/01/15/https-performance-tuning/
在網絡性能優化中一個經常被忽略的問題是保障安全連接的https協議.隨着應用從桌面轉移到web,廣泛被應用的https協議中安全和隱私的可靠性越來越重要.
下面的例子展示使用https過程中常見的問題.
例1:使用有效的響應
每當瀏覽器訪問一個網站,它必須創建一個或多個tcp鏈接.既是在常見的http協議下,這也是個漫長的過程.使用tcp鏈接的有效的響應可以減少這中開銷.下面來自httpwatch的圖表顯示在訪問英國一網站時tcp連接時間大約130毫秒
使用https時,如果不是有效鏈接將會造成長時間的延遲.因爲就算tcp已經連接,ssl鏈接也需要建立請求.瀏覽器和服務端會來回通信幾次來建立加密的密鑰.使用https鏈接相應時間是http的四倍以上.
在一個重複的https鏈接裏tcp鏈接和ssl通信的開銷是應該避免的.雖然現在有些瀏覽器允許重複使用ssl鏈接,但是你不能總指望每個服務器都作了這樣的配置.
例2:避免混合內容警告
在前一篇博文中提到,如果一個https頁面使用了任何http資源,就會出現令人迷惑和煩人的警告對話框.
爲了避免這個警告提示,要確保這個頁面包含的資源都是https.
例3:使用持久緩存的靜態內容
如果你按照例子2,那麼頁面上所有的資源(圖片,css,js)都在https下面了,你應該持續地使用靜態緩存,來避免每次每個用戶再次訪問站點重複下載.
淡然你不會對所有東西緩存,賬戶信息和每月的餅圖就不用.但是大多數資源還是要安全的存儲,頁面間分享和再次使用.
這裏可能有一些混亂對於https下是否使用緩存.
例如在https下的gmail,確實訪問速度要慢一些,因爲瀏覽器不緩存這些頁面.
雖 然，37Signals公司承認，在內存中緩存是可能的，他們說 ， 持 續的緩存是不可能的 ：
但在現實中https下持續緩存在ie和firefox下是可能的.
訪問www.httpwatch.com,通過httpwatch我們可以看到,所有資源都是通過緩存來訪問的.
如果你使用firefox3.0,並不修改請求頭部,看到的是:
我們看到這裏並沒有緩存,這是因爲頭部設置的原因,firefox每次是請求的服務器.200代表靜態內容是從服務器上求情成功的.
但是我們在firefox地址輸入”about:cache”,找到這些緩存文件
這裏修改一下設置就可以了,修改Cache-Control response header to Public.
這樣我們就把https下的內容移動到了firefox的緩存空間.於是再次訪問
這個方法只有在firefox3.0纔可以(譯者音:經過試驗,3.0以後的都是可以的,也不需要該header信息)
例4:使用https警告探測器
譯者音:作者說了那麼多廣告,我這裏就不翻譯了,這段話就一個意思,使用httpwatch可以給出https下的警告.使用方法和上面截圖基本上一樣的.