《web性能权威指南》读书笔记

延迟与带宽

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

影响延迟的因素

• 传播延迟：消息从发送端到接收端需要的时间，是信号传播距离和速度的函数；
• 传输延迟：把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速率的函数；
• 处理延迟：处理分组首部、检查位错误及确定分组目标所需的时间；
• 排队延迟：到来的分组排队等待处理的时间；
• 总延迟时间：传播延迟+传输延迟+处理延迟+排队延迟
• 分组到达路由器。路由器检测分组的首部，还可以对数据进行检查。如果分组到达的速度超过路由器处理能力，分组要入站缓冲区排队。发送端与接收端的距离越远，传播时间越长。一路上经过的路由器越多，每个分组的处理和传输延迟就越多。最后，网络流量越拥挤，分组在入站缓冲区被延迟的可能性就越大。
• 本地路由器的缓冲区爆满：路由器会配很大的入站缓冲区，以避免丢包（分组），但这破坏了TCP的拥塞预防机制，导致网络中产生较长且可变的延迟时间。
• CDN（Content Delivery Network，内容分发网络）：最重要的是通过把内容部署在全球各地，让用户从最近的服务器加载内容，大幅度降低传播分组的时间。
• 延迟的最后一公里：traceroute baidu.com,查看上网服务商的拓扑结构和速度；

使用traceroute 和 mtr 测量延迟

traceroute原理：

• 程序利用增加存活时间（TTL）值来实现其功能。每当数据包经过一个路由器，其存活时间就会减1。当其存活时间是0时，主机便取消数据包，并传送一个ICMP TTL数据包给原数据包的发出者。 程序发出的首3个数据包TTL值是1，之后3个是2，如此类推，它便得到一连串数据包路径。
• Traceroute通过发送小的数据包到目的设备直到其返回，来测量其需要多长时间。

-

[root@server3 ~]# traceroute baidu.com
traceroute to baidu.com (111.13.101.208), 30 hops max, 60 byte packets
 1  localhost (192.168.109.2)  0.556 ms  0.496 ms  0.446 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

C:\Users\somebody>tracert www.baidu.com

通过最多 30 个跃点跟踪
到 www.a.shifen.com [61.135.169.125] 的路由:

  1     1 ms     1 ms    47 ms  10.12.14.4
  2     5 ms     7 ms     2 ms  10.12.25.5
  3     *        *       14 ms  111.204.23.1
  4     *        *        *     请求超时。
  5   102 ms     3 ms    21 ms  61.18.4.177
  6    21 ms     *        8 ms  bt-228-189.bta.net.cn [202.106.228.189]
  7     7 ms     6 ms     6 ms  61.14.154.174
  8    10 ms    13 ms     4 ms  123.15.28.98
  9     *        *     ^C
                    My traceroute  [v0.85]
server3.example.com (0.0.0.0)        Wed Aug 16 19:47:37 2017
Keys:  Help   Display mode   Restart statistics   Order of fie
lds   quit           Packets               Pings
 Host              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. localhost       0.0%     9    0.2   0.2   0.1   0.3   0.0
 2. 10.12.140.4     0.0%     9   68.0  16.4   2.6  68.0  20.7
 3. 10.12.255.5     0.0%     8    5.7  13.8   3.9  38.5  11.3
 4. 111.204.243.1   0.0%     8   23.0  16.5   5.3  46.1  13.4
 5. ???
 6. 61.148.4.181    0.0%     8   17.4  15.2   6.6  23.9   5.7
 7. ???
 8. 124.65.59.114   0.0%     8    3.8  11.2   3.8  40.0  11.9
 9. 123.125.248.90 85.7%     8    4.8   4.8   4.8   4.8   0.0
10. ???
11. 61.135.169.121  0.0%     8   64.7  17.7   5.2  64.7  20.2

网络核心的带宽

• 波分复用（WDM）技术：光纤可以同时传输很多不同波长（信道）的光

TCP的构成

• TCP，即Transmission Control Protocol（传输 控制协议），负责在不可靠的传输信道之上提供可靠的抽象层；
• TCP快速打开：握手阶段已经成为影响网络总延迟的一个重要因素；TFO（TCP Fast Open）,致力于减少新建TCP连接带来的性能损失；
• TFO平均可以降低HTTP事务网络延迟15%，整个页面加载时间10%以上；
• Linux 3.7及以后的内核已经在客户端和服务器中支持TFO。但有局限；

为了解决网络瘫痪的解决方法

• 流量控制：预防发送端过多向接收端发送数据的机制；为实现流量控制，TCP 连接的每一方都要 通告自己的接收窗口（rwnd），其中包含能够保存数据的缓冲区空间大小 信息。
• 存在客户端向服务器（瓶颈）上传，客户端（瓶颈）从服务器下载；
• 假如窗口为零，则意味着必须由应用层先清空缓冲区，才能再接收剩余数据。这个过 程贯穿于每个TCP 连接的整个生命周期：每个ACK 分组都会携带相应的最新rwnd 值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。
• 窗口放缩：在三次握手期间完成的；在所有主要平台上是默认启用的。不过，中间节点和路由器可以重写，甚至完全去掉这个选项。 [root@server3 ~]# sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_window_scaling = 1

设置窗口缩放

sysctl -w net.ipv4.tcp_window_scaling=1 - 慢启动： cwnd大小达到N所需的时间： 时间=往返时间*[log2Restar(N/初始cwnd)] - 慢启动重启（SSR，Slow-Start Restart）：SSR - 拥塞控制： - 拥塞预防机制：

流量控制

• TCP连接的每一方都要通告主机的接收窗口（rwnd），包含能够保存数据的缓冲区空间大小。
• 假如窗口为零，则意味着必须由应用层先清空缓冲区，才能再接收剩余数据。这个过程贯穿于每个TCP 连接的整个生命周期：每个ACK 分组都会携带相应的最新rwnd 值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。
• 流量控制确实可以防止发送端向接收端多发送数据，但却没有机制预防任何一端向潜在网络过多发送数据

慢启动

• 发送端和接收端在连接建立之初，谁也不知 道可用带宽是多少，因此需要一个估算机制，然后还要根据网络中不断变化的条件而动态改变速度。
• TCP规范：慢启动、拥塞预防、快速重发、快速恢复
• 慢启动思想：根据交换数据来估算客户端与服务器之间的可用带宽是唯一的方法。
• 首先，服务器通过TCP 连接初始化一个新的拥塞窗口（cwnd）变量，将其值设置为一个系统设定的保守值（在Linux 中就是initcwnd）。
• 慢启动限制了可用的吞吐量
• 慢启动重启：这种机制会在连接空闲一定时间后重置连接的拥塞窗口；SSR 对于那些会出现突发空闲的长周期TCP连接有很大的影响

-

[root@server5 ~]# sysctl net.ipv4.tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 1
[root@server5 ~]# sysctl  -w net.ipv4.tcp_window_scaling=0
net.ipv4.tcp_window_scaling = 0

• 增大TCP的初始拥塞窗口，RFC6928 10段

拥塞预防

• 拥塞预防算法把丢包作为网络拥塞的标志，即路径中某个连接或路由器已经拥堵了，以至于必须采取删包措施。因此，必须调整窗口大小，以避免造成更多的包丢失，从而保证网络畅通。
• TCP版本：：TCP Tahoe 和Reno（最早的实现）、TCP Vegas、TCP New Reno、TCP BIC、TCP CUBIC（Linux 的默认实现）或Compound TCP（Windows 的默认实现）
• TCP比例降速；PRR

带宽延迟积

• BDP（Bandwidth-delay product，带宽延迟积），数据链路的容量与其端到端延迟的乘积；
• 只有传输不中断，才能保证最大吞吐量。而最优窗口大小取决于往返时间！无论实际或通告的带宽是多大，窗口过小都会限制连接的吞吐量

队首阻塞

• tcp实现可靠的网络传输:分组错误检测与纠正、按序交付、丢包重发、流量控制、拥塞控制和预防机制。队首阻塞:每个TCP 分组都会带着一个唯一的序列号被发出，而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端的TCP 缓冲区，等待丢失的分组重发并到达接收端。这一切都发生在TCP 层，应用程序对TCP 重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。
• 队首阻塞造成的延迟可以让我们的应用程序不用关心分组重排和重组，从而让代码保持简洁。然而，代码简洁也要付出代价，那就是分组到达时间会存在无法预知的延迟变化。这个时间变化通常被称为抖动;
• 大多数情况下，TCP 的瓶颈都是延迟，而非带宽

tcp优化

• 内核升级到最新
• 增大TCP的初始拥塞窗口
• 慢启动重启
• 窗口放缩
• TCP快速打开（某些条件，允许在第一个SYN分组中发送应用程序数据）
• ss查看当前打开的套接字的各种统计信息

日程表

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

HTTP1.1

• 性能优化：持久连接、分块编码传输、字节范围请求、增强的缓存机制、传输编码及请求管道。