看《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。
图片来源: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权威指南》一书的测试结果:
建议:优先选择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等内容。