FPs

《Web 性能權威指南》讀書筆記

bookcover

《Web 性能權威指南》的起因是在看《HTTPS 權威指南》的時候,看到優化相關的,然後就延伸到想看一下這本書。
這本書,作者提供了免費的在線英文版,建議還是看英文的,中文翻譯版有些地方略生硬。

TCP 優化

這部分從協議出發,講解了優化的要點。

三次握手帶來的延遲使得創建每創建一個新的TCP連接都要付出很大的代價。而這也決定了提高TCP應用性能的關鍵,在於想辦法重用連接。

可以看到重用連接在後續的HTTP 優化都是重點。
第二章分內容和《HTTPS 權威指南》的9.1 有重合,可以都看下。

把服務器內核升級到最新版本(Linux: 3.2+)

新內核能獲得更好的性能,例如採用了PRR,比例降速算法。

確保cwnd 大小爲10;

增大擁塞窗口,10表示10個MSS,以太網標准的MSS 是1460。
前面提到內核升級也可以帶來好處,Linux 3.2+ 的內核,cwnd都是默認10。
OS_CWND
圖片來源:cdnplanet.com

關於更改initcwnd、查看系統的initcwnd,可以參考:
Tuning initcwnd for optimum performance

這一部分可以再看看火丁筆記的《淺談TCP優化》

禁用空閒後的慢啓動

主要是存在長連接的時候,要確保把這個給關了。

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

確保啓動窗口縮放

sysctl -w net.ipv4.tcp_windows_scaling=1

減少傳輸冗餘數據

應用程序注意能少發數據就少發,這在後面的移動設備App優化上也是重點,移動網絡的啓動更加耗時和耗電。

壓縮要傳輸的數據

例如web server 開啓gzip,對js、css 做壓縮。

把服務器放到離用戶近的地方減少往返的時間

部署CDN,一方面邊緣節點能夠緩存文件,直接返回給用戶。如果是需要回源的話,邊緣節點如果能和回源保持長連接,這樣可以降低用戶訪問整個耗時,因爲用戶只需要和邊緣節點三次握手,距離近,耗時更短。
另外在部署HTTPS 的時候,除了TCP握手,還需要TLS握手,如果讓邊緣節點提供HTTPS,然後以HTTP向後反代,也是一種優化吧。現在CDN 廠商都支持HTTPS了,配置回源的時候選擇HTTP 相比HTTPS 會更快,給源站的壓力也更小一些,而且在IDC之間,運營商那臺噁心的劫持問題應該少很多吧。

盡最大可能重用已經建立的TCP 連接

UDP 優化

UDP 這部分,在工作中遇到的少,沒太多體會。

Application must tolerate a wide range of Internet path conditions.
Application should control rate of transmission.
Application should perform congestion control over all traffic.
Application should use bandwidth similar to TCP.
Application should back off retransmission counters following loss.
Application should not send datagrams that exceed path MTU.
Application should handle datagram loss, duplication, and reordering.
Application should be robust to delivery delays up to 2 minutes.
Application should enable IPv4 UDP checksum, and must enable IPv6 checksum.
Application may use keepalives when needed (minimum interval 15 seconds).

TLS 優化

關於TLS 優化還可以看《HTTPS 權威指南》的9.2:TLS協議優化。
另外淘寶的這份分析非常不錯:《淘宝HTTPS探索》

SSL卸載

在保證兼容性的情況下,升級到新版的openSSL,可以有更好的性能。
HPBN的在這一章的建議是用物理機,純CPU計算卸載,舉了Google和Facebook爲例。不過如果是使用的雲服務的話,部分雲廠商在負載均衡上都提供了SSL卸載的功能,不過感覺對ALPN這些協議的支持不知如何,所以還沒試用過。雲服務虛機+Nginx 來做卸載還是有少許壓力的,高峯期的時候。Intel之類的硬件,甚至F5 這種,感覺成本有點高,不過性能確實非常好,如果有條件的話,可以上這類設備。不過使用了這些設備之後,算法升級、調優的自由度可能就不大了,需要綜合考慮。

爲了降低壓力,可以對加密套件的選擇進行優化,參考《HTTPS權威指南》一書的測試結果:
TLS_Speed

TLS_Speed_taobao

建議:優先選擇ECDHE,禁用DHE。

儘早握手

類似TCP的三次握手,TLS的握手過程也可以通過類似CDN的網絡進行優化。在距離用戶較近的地方搭建代理服務器,然後和後端保持長連接,這樣降低用戶到服務整個的握手時間。

證書優化

《HTTPS權威指南》提到的幾點:

  • 使用儘可能少的證書
  • 只包含必須的證書
  • 提供完整的證書鏈
  • 使用橢圓曲線證書鏈
  • 小心同一張證書綁定過多域名

一個常見的錯誤是在證書鏈裏面包含根證書,毫無意義,還加大了傳輸開銷。

優化TLS 記錄大小

TLS 太小會造成浪費,頭信息的比例過大。如果太大,會造成延遲,如果萬一丟包,會非常糟糕。參考TLS Record Size 优化笔记

其他

  • 禁用服務器的TLS壓縮,安全性問題,Nginx的話默認是不支持的;
  • 確保證書鏈不會超過擁塞窗口大小;
  • 啓用會話緩存和無狀態恢復,參考nginx 的 ssl_session_cache,ssl_session_timeout等。
  • 配置ssl_stapling
  • 配置ssl_session_tickets
  • 開啓HSTS,這個開啓得非常小心

無線網絡優化

這部分內容介紹了很多關於移動網絡的基礎知識,也是爲後面的HTTP優化做鋪墊,畢竟現在移動App 非常發達。總的來說,移動設備上一次請求的代價更大,時間上和耗電上,所以減少請求和重用連接非常重要。

HTTP 優化

  • HTTP 1.0 升級到HTTP1.1
  • 減少DNS查詢
  • 減少HTTP請求
  • 使用CDN
  • 添加Expires 頭部並配置ETag標籤
  • Gzip 壓縮資源
  • 避免HTTP 重定向

使用持久連接

HTTP管道

消除部分等待時間。

域名分區

這個使用要適量,不讓會適得其反。

拼接、壓縮靜態資源

直接參考ngxpagespeed.com 就可以了。

升級到HTTP 2.0

要注意不要把在HTTP 1.1 上的優化手段用到HTTP 2.0 上,會適得其反。

其他

書中還有大量其他內容,一些關於TCP、HTTP的基礎介紹,以及移動網絡、XMLHttpRequest、WebSocket、WebRTC等內容。

This article is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
If you reprint it, please indicate the source: http://fangpeishi.com/hpbn_notes.html