作者【加】Ilya Grigorik
如果想做Web性能优化，这本书绝对值得一读。里面讲述了TCP UDP TLS HTTP1 HTTP2怎么优化，有需求的话绝对不要错过。不过这些内容，大部分太过底层，优化和验证相对麻烦一些。后面会针对里面阐述的优化做一些测试，看看效果。
第一部分 网络技术概览
第1章延迟与带宽
1.1 速度是关键
延迟: 分组从信息源发送到目的地所需的时间。
带宽: 逻辑或物理通信路径最大的吞吐量。
1.2 延迟的构成
- 延迟的时间总和:
- 传播延迟:消息从发送端到接收端需要的时间，是信号传播距离和速度的函数
- 传输延迟:把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速率的函数
- 处理延迟:处理分组首部、检查位错误及确定分组目标所需的时间
- 排队延迟:到来的分组排队等待处理的时间
1.3 光速与传播延迟
- 光速与分组在介质中传播速度之比，叫做该介质的折射率。这个值越大，光在该介质中传播的速度就越慢。
- 研究表明：在软件交互中，哪怕100~200 ms左右的延迟，我们中的大多数人就会感觉到“拖拉”；如果超过了300 ms的门槛，那就会说“反应迟钝”；而要是延迟达到1000 ms（1s）这个界限，很多用户就会在等待响应的时候分神，有人会想入非非，有人恨不得忙点别的什么事儿。
1.4 延迟的最后一公里
- 最后一公里的延迟却是世界任何一个角落的互联网提供商共同面临的问题。如果你好奇，那只要一条简单的traceroute命令，就能知道上网服务商的拓扑结构和速度
1.5 网络核心的带宽
- 一条光纤连接的总带宽，等于每个信道的数据传输速率乘以可复用的信道数。
1.6 网络边缘的带宽
- 推荐一个在线服务：Ookla运营的http://speedtest.net（图1-2），可以测试客户端到某个本地服务器的上传和下载速度。
1.7 目标：高带宽和低延迟
第2章TCP的构成
2.1 三次握手
2.2 拥塞预防及控制
- 流量控制：通告接收窗口（rwnd）
- 慢启动：慢启动以保守的窗口初始化连接，随后的每次往返都会成倍提高传输的数据量，直到超过接收端的流量控制窗口，即系统配置的拥塞阈值（ssthresh）窗口，或者有分组丢失为止，此时拥塞预防算法介入
- 拥塞预防：拥塞预防算法把丢包作为网络拥塞的标志，即路径中某个连接或路由器已经拥堵了，以至于必须采取删包措施。因此，必须调整窗口大小，以避免造成更多的包丢失，从而保证网络畅通
2.3 带宽延迟积
- 发送端和接收端之间在途未确认的最大数据量，取决于拥塞窗口（cwnd）和接收窗口（rwnd）的最小值。接收窗口会随每次ACK一起发送，而拥塞窗口则由发送端根据拥塞控制和预防算法动态调整。
- BDP（Bandwidth-delay product，带宽延迟积）数据链路的容量与其端到端延迟的乘积。这个结果就是任意时刻处于在途未确认状态的最大数据量。
2.4 队首阻塞
- TCP在不可靠的信道上实现了可靠的网络传输。基本的分组错误检测与纠正、按序交付、丢包重发，以及保证网络最高效率的流量控制、拥塞控制和预防机制，让TCP成为大多数网络应用中最常见的传输协议。
- 如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端的TCP缓冲区，等待丢失的分组重发并到达接收端。这一切都发生在TCP层，应用程序对TCP重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。这种效应称为TCP的队首（HOL，Head of Line）阻塞。
2.5 针对TCP的优化建议
1.服务器配置调优
- 服务器使用最新版本
- 增大TCP的初始拥塞窗口
- 慢启动重启
- 窗口缩放（RFC 1323）
- TCP快速打开
- 可用ss命令查看相关配置
2.应用程序行为调优
- 再快也快不过什么也不用发送，能少发就少发
- 我们不能让数据传输得更快，但可以让它们传输的距离更短
- 重用TCP连接是提升性能的关键
3.性能检查清单
- 把服务器内核升级到最新版本（Linux：3.2+）；
- 确保cwnd大小为10；
- 禁用空闲后的慢启动；
- 确保启动窗口缩放；
- 减少传输冗余数据；
- 压缩要传输的数据；
- 把服务器放到离用户近的地方以减少往返时间；
- 尽最大可能重用已经建立的TCP连接。
第3章 UDP的构成
3.1 无协议服务
- 说到底，UDP仅仅是在IP层之上通过嵌入应用程序的源端口和目标端口，提供了一个“应用程序多路复用”机制。
3.2 UDP与网络地址转换器
- 建议的IP重用方案就是在网络边缘加入NAT设备，每个NAT设备负责维护一个表，表中包含本地IP和端口到全球唯一（外网）IP和端口的映射（图3-3）。
3.3 针对UDP的优化建议
- •应用程序必须容忍各种因特网路径条件； •应用程序应该控制传输速度； •应用程序应该对所有流量进行拥塞控制； •应用程序应该使用与TCP相近的带宽； •应用程序应该准备基于丢包的重发计数器； •应用程序应该不发送大于路径MTU的数据报； •应用程序应该处理数据报丢失、重复和重排； •应用程序应该足够稳定以支持2分钟以上的交付延迟； •应用程序应该支持IPv4 UDP校验和，必须支持IPv6校验和； •应用程序可以在需要时使用keep-alive（最小间隔15秒）。
第4章传输层安全（TLS）
SSL协议在直接位于TCP上一层的应用层被实现
IETF后来在标准化SSL协议时，将其改名为Transport Layer Security（TLS，传输层安全）。很多人会混用TLS和SSL，但严格来讲它们并不相同，因为它们指代的协议版本不同。
4.1 加密、身份验证与完整性
- TLS协议的目标是为在它之上运行的应用提供三个基本服务：加密、身份验证和数据完整性。
4.2 TLS握手
- 每一个TLS连接在TCP握手基础上最多还需要两次额外的往返
4.3 TLS会话恢复
- TLS提供了恢复功能，即在多个连接间共享协商后的安全密钥。
- 简短TLS握手协议
4.4 信任链与证书颁发机构
4.5 证书撤销
- CRL（Certificate Revocation List，证书撤销名单）
- 为解决CRL机制的上述问题，RFC 2560定义了OCSP（Online Certificate Status Protocol，在线证书状态协议），提供了一种实时检查证书状态的机制。
4.6 TLS记录协议
4.7 针对TLS的优化建议
4.8 性能检查清单
- 要最大限制提升TCP性能，请参考2.5节“针对TCP的优化建议”；
- 把TLS库升级到最新版本，在此基础上构建（或重新构建）服务器；
- 启用并配置会话缓存和无状态恢复；
- 监控会话缓存的使用情况并作出相应调整；
- 在接近用户的地方完成TLS会话，尽量减少往返延迟；
- 配置TLS记录大小，使其恰好能封装在一个TCP段内；
- 确保证书链不会超过拥塞窗口的大小；
- 从信任链中去掉不必要的证书，减少链条层次；
- 禁用服务器的TLS压缩功能；
- 启用服务器对SNI的支持；
- 启用服务器的OCSP封套功能；
- 追加HTTP严格传输安全首部。
4.9 测试与验证
- 最后，要验证和测试你的配置，可以使用Qualys SSL Server Test（https://www.ss-llabs.com/ssltest/）等在线服务来扫描你的服务器，以发现常见的配置和安全漏洞。 这个网址已经没有办法使用了