《Web性能权威指南》-网络技术概览-读书笔记

注：TCP/IP等知识牵涉面太广，且不说本文，哪怕是原书，限于篇幅，很多知识点都是大致介绍下。如果想深入理解，需要更一步Google相关页面资料。

延迟与带宽

WPO，Web Performance Optimization，Web性能优化。

对所有网络通信都有决定性影响的两个方面：

延迟：分组从信息源发送到目的地所需的时间；
带宽：逻辑或物理通信路径最大的吞吐量。

路由器，负责在客户端和服务器之间转发消息的设备，牵涉影响延迟的4大因素：

传播延迟：消息从发送端到接收端需要的时间，是信号传播距离和速度的函数；
传输延迟：把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速率的函数；
处理延迟：处理分组首部、检查位错误及确定分组目标所需的时间；
排队延迟：到来的分组排队等待处理的时间

以上延迟的时间总和，就是客户端到服务器的总延迟时间：

传播时间取决于距离和信号通过的媒介，另外传播速度通常不超过光速；
传输延迟由传输链路的速率决定，与客户端到服务器的距离无关；
分组(packet)到达路由器，路由器必须检测分组的首部，以确定出站路由，并且还可能对数据进行检查。这些检查通常由硬件完成，相应的延迟一般非常短，但再短也还是存在；
分组到达的速度超过路由器的处理能力，分组就要在入站缓冲区排队，即排队时间。

每个分组在通过网络时都会遇到这样或那样的延迟。发送端与接收端的距离越远，传播时间就越长。一路上经过的路由器越多，每个分组的处理和传输延迟就越多。最后，网络流量越拥挤，分组在入站缓冲区中被延迟的可能性就越大。

CDN（Content Delivery Network，内容分发网络），通过把内容部署在全球各地，让用户从最近的服务器加载内容，大幅降低传播分组的时间。

最后一公里问题：延迟中相当大的一部分往往花在最后几公里，而不是在横跨大洋或大陆时产生。

想提高上网速度，那选择延迟最短的ISP（Internet Service Provider，物流服务提供商，如电信，移动）是最关键的。

网络核心的带宽：光纤通信，通过波分复用（WDM，Wavelength-Division Multiplexing）技术，光纤可以同时传输很多不同波长（信道）的光，因而具有明显的带宽优势。一条光纤连接的总带宽，等于每个信道的数据传输速率乘以可复用的信道数。

网络边缘的带宽：用户可用带宽取决于客户端与目标服务器间最低容量连接；相比于核心光纤通信非常小。Ookla运营的speedtest，相信大家都用过。

高带宽和低延迟：宽度已经足够，性能优化重点是降低延迟。

拓展

Hibernia Express

华为与Hibernia Atlantic合作铺设的一条横跨大西洋，连接伦敦和纽约的近5000km的海底光缆。唯一目的就是减少城市间的路由，为金融交易商节省5ms延迟。只服务于金融机构，耗资预计达4亿美元。即1ms延迟成本价是8000万美元。

Bufferbloat

缓冲区爆满，Jim Gettys发明的术语，表述排队延迟影响网络整体性能。

造成这个问题的原因主要是如今市面上的路由器都会配备很大的入站缓冲区，以便不惜一切代价避免丢包（分组）。可是，这种做法破坏TCP的拥塞预防机制(Congestion Avoidance)，导致网络中产生较长且可变的延迟时间。

为解决这个问题，有人提出新的CoDel主动队列管理算法，且已经在Linux内核3.5以上版本中实现。

traceroute

Linux平台的网络诊断工具，可以列出分组经过的路由节点，以及它在IP网络中每一跳的延迟。为找到每一跳的节点，它会向目标发送一系列分组，每次发送时的跳数限制都会递增。在达到跳数限制时，中间的节点会返回ICMP Time Exceeded消息，traceroute根据这个消息可计算出每一跳的延迟。

Windows平台中对应的命令为tracert。

TCP构成

TCP负责在不可靠的传输信道之上提供可靠的抽象层，向应用层隐藏大多数网络通信的复杂细节，如丢包重发、按序发送、拥塞控制及避免、数据完整等。采用TCP数据流可以确保发送的所有字节能够完整地被接收到，且到达客户端的顺序也一样。TCP的目标是精确传送，并没过多顾及时间。

三次握手

在交换应用数据之前，必须就起始分组序列号，以及其他一些连接相关的细节达成一致。
在这里插入图片描述
出于安全考虑，序列号由两端随机生成：

SYN：Synchronize Sequence Numbers，同步序列编号。客户端选择一个随机序列号x，并发送一个SYN分组，其中可能还包括其他TCP标志和选项。
SYN ACK：服务器给x加1，并选择自己的一个随机序列号y，追加自己的标志和选项，然后返回响应。
ACK：客户端给x和y加1并发送握手期间的最后一个ACK分组。

三次握手带来的延迟，影响性能，因此需要重用连接。

TFO，TCP Fast Open，TCP快速打开，致力于减少新建TCP连接带来的性能损失。Linux 3.7及之后的内核已经在客户端和服务器中支持TFO。

但是，TFO只能在某些情况下有效：

随同SYN分组一起发送的数据净荷有最大尺寸限制
只能发送某些类型的HTTP请求
由于依赖加密cookie，只能应用于重复的连接。

拥塞预防及控制

拥塞崩溃：可能是往返时间超过所有主机的最大中断间隔，于是相应的主机会在网络中制造越来越多的数据报副本，使得整个网络陷入瘫痪。最终，所有交换节点的缓冲区都将被填满，多出来的分组必须删掉。目前的分组往返时间已经设定为最大值。主机会把每个分组都发送好几次，结果每个分组的某个副本会抵达目标。

ARPANET：Advanced Research Projects Agency Network，高级研究计划局网络，是现代互联网的前身，是世界上第一个实际运行的分组交换网络。

流量控制

流量控制：一种预防发送端过多向接收端发送数据的机制。否则，接收端可能因为忙碌、负载重或缓冲区容量有限而无法处理。为实现流量控制，TCP连接的每一方都要通告自己的接收窗口(rwnd)，其中包含能够保存数据的缓冲区空间大小信息。
在这里插入图片描述
发送端和接收端的窗口都可能成为制约因素。为了缓解性能瓶颈：每个ACK分组都会携带相应的最新rwnd值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。

窗口缩放：TCP Window Scaling，RFC 1323引入，可把接收窗口大小由65535字节（16位，即 $2^{16}$ ）提高到1G字节！缩放TCP窗口是在三次握手期间完成的，其中有一个值表示在将来的ACK中左移16位窗口字段的位数。

检查和启用窗口缩放选项的命令：

sysctl net.ipv4.tcp_window_scaling
sysctl -w net.ipv4.tcp_window_scaling=1

慢启动

TODO

拥塞预防

慢启动以保守的窗口初始化连接，随后的每次往返都会成倍提高传输的数据量，直到超过接收端的流量控制窗口，即系统配置的拥塞阈值(ssthresh)窗口，或者有分组丢失为止，此时拥塞预防算法介入。

拥塞预防算法把丢包作为网络拥塞的标志，即路径中某个连接或路由器已经拥堵，以至于必须采取删包措施。因此，必须调整窗口大小，以避免造成更多的包丢失，从而保证网络畅通。

TCP比例降速
确定丢包恢复的最优方式并不容易。如果太激进，那么间歇性的丢包就会对整个连接的吞吐量造成很大影响。而如果不够快，那么还会继续造成更多分组丢失。

TCP最初使用AIMD（Multiplicative Decrease and Additive Increase，倍减加增）算法，即发生丢包时，先将拥塞窗口减半，然后每次往返再缓慢地给窗口增加一个固定的值。很多时候太过保守。

PRR：Proportional Rate Reduction，比例降速，RFC 6937规定的新算法，其目标就是改进丢包后的恢复速度。Linux 3.2+内核默认的拥塞预防算法。

带宽延迟积

发送端和接收端之间在途未确认的最大数据量，取决于拥塞窗口(cwnd)和接收窗口(rwnd)的最小值。rwnd会随每次ACK一起发送，而cwnd则由发送端根据拥塞控制和预防算法动态调整。

BDP：Bandwidth Delay Product，带宽延迟积，数据链路的容量与其端到端延迟的乘积。这个结果就是任意时刻处于在途未确认状态的最大数据量。

窗口大小的协商与调节由网络栈自动控制，应该会自动调整。但事实上，窗口大小有时候仍然是TCP性能的限制因素。

队首阻塞

TCP的HOL（Head of Line，队首）阻塞：每个TCP分组都会带着一个唯一的序列号被发出，而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端，那后续分组必须保存在接收端的TCP缓冲区，等待丢失的分组重发并到达接收端。这一切都发生在TCP层，应用程序对TCP重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。
在这里插入图片描述
问题：分组到达时间会存在无法预知的延迟变化，被称为抖动。

无需按序交付数据或能够处理分组丢失的应用程序，以及对延迟或抖动要求很高的应用程序，最好选择UDP等协议。

丢包不一定是坏事。反而是让TCP达到最佳性能的关键。被删除的包恰恰是一种反馈机制，能够让接收端和发送端各自调整速度，以避免网络拥堵，同时保持延迟最短。

很多应用程序可以容忍丢失一定数量的包。

TCP优化建议

TCP调优非常复杂，但核心原理不变：

TCP三次握手增加整整一次往返时间；
TCP慢启动将被应用到每个新连接；
TCP流量及拥塞控制会影响所有连接的吞吐量；
TCP的吞吐量由当前拥塞窗口大小控制。

服务器配置调优

升级服务器内核到最新版，服务器配置最佳实践：

增大TCP的初始拥塞窗口：加大起始拥塞窗口可以让TCP在第一次往返就传输较多数据，而随后的速度提升也会很明显。
慢启动重启：在连接空闲时禁用慢启动可以改善瞬时发送数据的长TCP连接的性能。
窗口缩放：RFC 1323，启用窗口缩放可以增大最大接收窗口大小，可以让高延迟的连接达到更好吞吐量。
TFO：在某些条件下，允许在第一个SYN分组中发送应用程序数据。TFO是一种新的优化选项，需要客户端和服务器共同支持。

应用程序行为调优

三点：

再快也快不过什么也不用发送，能少发就少发。启用压缩。
不能让数据传输得更快，但可以让它们传输的距离更短。
重用TCP连接是提升性能的关键。

性能检查清单

包括但不限于：

把服务器内核升级到最新版本（Linux：3.2+）；
确保cwnd大小为10；
禁用空闲后的慢启动；
确保启动窗口缩放；
减少传输冗余数据；
压缩要传输的数据；
把服务器放到离用户近的地方以减少往返时间；
尽最大可能重用已经建立的TCP连接。

UDP构成

User Datagram Protocol，用户数据报协议。UDP的主要功能和亮点并不在于它引入什么特性，而在于它忽略的那些特性，因此也叫无（Null）协议。

数据报：一个完整、独立的数据实体，携带着从源节点到目的地节点的足够信息，对这些节点间之前的数据交换和传输网络没有任何依赖

数据报(datagram)和分组(packet)：

分组可以用来指代任何格式化的数据块
数据报则通常只用来描述那些通过不可靠的服务传输的分组，既不保证送达，也不发送失败通知

无协议服务

IP层的主要任务就是按照地址从源主机向目标主机发送数据报。
在这里插入图片描述
IP层不保证消息可靠的交付，也不发送失败通知，实际上是把底层网络的不可靠性直接暴露给上一层。

上图是IPv4首部，多大20字节，作为对比，看一下仅8字节的UDP首部：

在这里插入图片描述
如上图，UDP协议会用自己的分组结构封装用户消息，只增加4个字段：源端口、目标端口、分组长度和校验和。事实上，UDP数据报中的源端口和校验和字段都是可选的。

UDP的无服务：

不保证消息交付：不确认，不重传，无超时。
不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞。
不跟踪连接状态：不必建立连接或重启状态机。
不需要拥塞控制：不内置客户端或网络反馈机制。

UDP与网络地址转换器

NAT：Network Address Translator，网络地址转换器，RFC 1631规范提出的解决IPv4地址即将耗尽的临时性方案。在网络边缘加入NAT设备，每个NAT设备负责维护一个表，表中包含本地IP和端口到全球唯一（外网）IP和端口的映射。NAT设备背后的IP地址空间就可以在各种不同的网络中得到重用，从而解决地址耗尽问题。

IANA：Internet Assigned Numbers Authority，因特网号码分配机构，作为监管全球IP地址分配的机构，为私有网络保留三段IP地址，这些IP地址经常可以在NAT设备后面的内网中看到。为防止路由错误和引起不必要的麻烦，不允许给外网计算机分配这些保留的私有IP地址。
在这里插入图片描述

连接状态超时

NAT转换的问题在于必须维护一份精确的路由表才能保证数据转发。NAT设备还被赋予删除转换记录的责任。为解决这个问题，UDP路由记录会定时过期。引入一个双向keep-alive分组，周期性地重置传输路径上所有NAT设备中转换记录的计时器。

NAT穿透

NAT问题：内部客户端不知道外网IP地址，只知道内网IP地址。NAT负责重写每个UDP分组中的源端口、地址，以及IP分组中的源IP地址。如果客户端在应用数据中以其内网IP地址与外网主机通信，连接必然失败。

为解决UDP与NAT的这种不搭配，发明很多穿透技术(TURN、STUN、ICE)，用于在UDP主机之间建立端到端的连接。

STUN、TURN与ICE

TODO

UDP优化建议

UDP省略的功能：连接状态、握手、重发、重组、重排、拥塞控制、拥塞预防、流量控制，甚至可选的错误检测。

如果要使用UDP协议，则开发者需要按需增加功能。

RFC 5405文档，对设计单播UDP应用程序给出的设计建议：

必须容忍各种因特网路径条件；
应该控制传输速度；
应该对所有流量进行拥塞控制；
应该使用与TCP相近的带宽；
应该准备基于丢包的重发计数器；
应该不发送大于路径MTU的数据报；
应该处理数据报丢失、重复和重排；
应该足够稳定以支持2分钟以上的交付延迟；
应该支持IPv4 UDP校验和，必须支持IPv6校验和；
可以在需要时使用keep-alive（最小间隔15秒）。

传输层安全

两个容易混淆的概念：

SSL，Secure Sockets Layer，安全套接字层；
TLS，Transport Layer Security，传输层安全。

SSL 2.0是该协议第一个公开发布的版本，但由于存在很多安全缺陷很快就被SSL 3.0取代。

IETF成立一个小组负责标准化SSL协议时，将其改名为TLS；其中RFC 2246诞生TLS 1.0，是SSL 3.0的升级版。TLS 1.0和SSL 3.0的区别并不特别明显，但这些区别会严重妨碍TLS 1.0与SSL 3.0之间的互操作性。IETF随后又发布TLS 1.1，TLS 1.2版本。

RFC 6347引入的DTLS（Datagram Transport Layer Security，数据报传输层安全）协议旨在给UDP增加TLS安全保障。

加密、身份验证与完整性

TLS协议的目标是为在它之上运行的应用提供三个基本服务：

加密：混淆数据的机制
身份验证：验证身份标识有效性的机制
数据完整性：检测消息是否被篡改或伪造的机制

TLS握手

在这里插入图片描述
TLS握手协议

TLS会话恢复

完整TLS握手会带来额外的延迟和计算量，从而给所有依赖安全通信的应用造成严重的性能损失。为了挽回某些损失，TLS提供恢复功能，即在多个连接间共享协商后的安全密钥。

会话标识符

RFC 5246最早在SSL 2.0中引入Session Identifier（会话标识符，SI），支持服务器创建32字节的SI，并作为ServerHello消息的一部分发送。

如果客户端和服务器都可在各自缓存中找到共享的会话ID参数，就能进行如下图所示的简短握手；否则就要重新启动一次全新的会话协商，生成新的会话ID。
在这里插入图片描述
借助SI可节省一次往返，还可省去用于协商共享加密密钥的公钥加密计算。因为重用之前协商过的会话数据，故连接是加密的且安全的。

每个打开的TLS连接都要占用内存，对会话ID的缓存和清除策略，需要精心设计。

会话记录单

RFC 5077提出Session Ticket（会话记录单，ST）机制，用于解决上述服务器会话缓存问题。

ST：不用服务器保存每个客户端的会话状态。如果客户端表明其支持会话记录单，则服务器可以在完整TLS握手的最后一次交换中添加一条新会话记录单(New Session Ticket)记录，包含只有服务器知道的安全密钥加密过的所有会话数据。客户端将此ST保存起来，在后续会话的ClientHello消息中，包含在SessionTicket扩展中。所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。

上面两个RFC机制，也被称为会话缓存或无状态恢复机制。优点是消除服务器端的缓存负担，通过要求客户端在与服务器建立新连接时提供会话记录单简化部署（除非记录单过期）。

信任链与证书颁发机构

信任链：信任的传递性。

证书颁发机构：Certificate Authority，CA，被证书接受者（拥有者）和依赖证书的一方共同信任的第三方。

每个浏览器（操作系统也是，但不在本书讨论范围内）都会内置一个可信任的CA（根机构）名单。通过浏览器到浏览器开发商，再到CA的信任链传递，可以把信任扩展至目标站点。

证书撤销

证书撤销：证书更新或删除。

CRL：Certificate Revocation List，证书撤销名单，RFC 5280规定的一种检查所有证书状态的机制，即每个CA维护并定期发布已撤销证书的序列号名单。

CRL以文件形式分发，定期更新，可通过URL形式访问，可缓存，存在的问题：

名单长，文件大；
实时性不好。

OCSP：Online Certificate Status Protocol，在线证书状态协议，RFC 2560为解决CRL上述问题，而提供的一种实时检查证书状态的机制。占用带宽更少，支持实时验证。

OCSP的问题：

CA，作为一个服务，必须保证高可用，且能接受并处理客户端的实时查询；
客户端在进一步协商之前阻塞OCSP请求；
CA知道客户端要访问哪个站点，OCSP请求可能会泄露客户端的隐私。

实践中，两者结合，CRL+OCSP。

TLS记录协议

TLS会话中交换的所有数据同样使用规格明确的协议进行分帧：
在这里插入图片描述
TLS记录协议负责识别不同的消息类型（握手、警告或数据，通过内容类型字段），以及每条消息的安全和完整性验证。

发送端交付应用数据的典型流程：

记录协议接收应用数据；
接收到的数据被切分为块：最大为每条记录214字节，即16KB；
压缩应用数据（可选）；
添加MAC（Message Authentication Code）或HMAC；
使用商定的加密套件加密数据。

接收端的流程相同，顺序相反。

记录协议的限制：

TLS记录最大为16KB；
每条记录包含5字节的首部、MAC（不同版本字节数不一样，最多32字节），如果使用块加密则还有填充；
必须接收到整条记录才能开始解密和验证。

小记录会因记录分帧而产生较大开销，大记录在被TLS层处理并交付应用前，必须通过TCP传输和重新组装。

TLS优化建议

计算成本

建立和维护加密信道给两端带来额外的计算复杂度，公钥（非对称）加密与对称加密相比，在握手期间确定共享密钥，作为对后续TLS记录加密的对称密钥，因此需要更大的计算工作量。

在Web发展早期，通常都需要专门的硬件来进行SSL卸载。如今，通过CPU就能完成。

另外，升级OpenSSL库到最新版，系统自带的默认OpenSSL库大概率已经过时。

尽早完成（握手）

会话缓存与无状态恢复

TLS记录大小

TLS压缩

TLS内置支持对记录协议传输的数据进行无损压缩。压缩算法在TLS握手期间商定，压缩操作在对记录加密之前执行。

但是，实践中往往需要禁用服务器上的TLS压缩功能：

CRIME攻击会利用TLS压缩恢复加密认证cookie，让攻击者实施会话劫持；
传输级的TLS压缩不关心内容，可能会再次压缩已经压缩过的数据（图像、视频等）。

双重压缩会浪费服务器和客户端的CPU时间，而且暴露的安全漏洞也很严重，因此请禁用TLS压缩。实践中，大多数浏览器会禁用TLS压缩，但即便如此你也应该在服务器的配置中明确禁用它，以保护用户的利益。

虽然不能使用TLS压缩，但应该使用服务器的Gzip设置压缩所有文本资源，同时对图像、音频、视频等采用最合适的压缩格式。

证书链长度

验证信任链需要浏览器遍历链条中的每个节点，从站点证书开始递归验证父证书，直至信任的根证书。

如果包含未验证的中间证书，浏览器会暂停验证并获取中间证书，验证后再继续。此时很可能需要进行新DNS查找、建立TCP连接、发送HTTP GET请求，导致握手多花几百毫秒时间。

切记：确保信任链中仅包含必要的证书，即确保证书链的长度最小。

服务器证书是在握手期间发送的，而发送证书使用的很可能是一个处于慢启动算法初始阶段的新TCP连接。如果证书链长度超过TCP的初始拥塞窗口，则无意间就会让握手多一次往返：证书长度超过拥塞窗口，从而导致服务器停下来等待客户端的ACK消息。增大拥塞窗口或减小证书大小。

优化思路：

尽量减少中间CA的数量。理想情况下，发送的证书链应该只包含两个证书：站点证书和中间CA的证书。把这一条作为选择CA的标准。第三个证书，根CA的证书，已经包含在浏览器内置的信任名单中，不用发送。
很多站点会在证书链中包含根CA的证书，这是完全没有必要的。如果浏览器的信任名单中没有该根证书，那说明它是不被信任的，即便发送它也无济于事。
理想的证书链应该在2~3KB左右，同时还能给浏览器提供所有必要的信息，避免不必要的往返或者对证书本身额外的请求。优化TLS握手可以消除关键的性能瓶颈，因为每个新TLS连接都要经历同样的延迟。

OCSP封套

每个新TLS连接都要求浏览器至少验证两样东西：证书链签名，证书没有被撤销。此时，浏览器行为差别很大：

使用自己的更新机制推送更新的CRL名单，而不会按需发送请求；
只会针对扩展验证证书（EV证书）进行实时OCSP和CRL检查。
在上述任何一种方式下阻塞TLS握手，有些则不会，具体情况取决于开发商、平台和浏览器版本。

OCSP封套，OCSP Stapling：某些浏览器采用的优化措施，服务器可在证书链中包含（封套）CA的OCSP响应，让浏览器跳过在线查询。把查询OCSP操作转移到服务器，让服务器缓存签名的OCSP响应，从而节省很多客户端请求：

需服务器（NginX、Apache和IIS等）支持；
OCSP响应约400~4000字节，把这么大的响应封套在证书链里可能会造成TCP拥塞窗口溢出；
只能包含一个OCSP响应，在没有缓存时，浏览器对其他中间证书可能仍然需要发送OCSP请求。

HSTS

HTTP Strict Transport Security，HTTP严格传输安全，一种安全策略机制，它能让服务器通过简单的HTTP首部（如Strict-Transport-Security: max-age=31536000）对适用的浏览器声明访问规则。具体来讲，它可以让用户代理遵从如下规则：