web 性能优化

1.影响网络通信的决定性的因素

延迟：分组从信息源发送到目的地所需要的时间。

带宽：逻辑或物理通信路径最大的吞吐量

2.延迟

=> 消息（message）或分组（packet）从起点到终点经历的时间。

影响延迟的因素：

1.传播延迟

消息从发送端到接受端需要的时间，是信号传播距离和速度的函数。

2.传输延迟

把消息中的所有比特转移到链路中所需要的时间，是消息长度和链路速率的函数。

3.处理延迟

处理分组首部，检查位错误及确定分组目标所需要的时间

4.排队延迟

到来的分组排队等待处理的时间

延迟造成的原因：

传播时间取决于距离和信号通过的媒介，另外传播速度通常不超过光速。

传输延迟由传输链路的速率决定，与客户端到服务器的距离无关.

分组到达的速度超过了路由器的处理能力，那么分组就要在入站缓冲区排队。数据在缓冲区排队等待的时间，当然就是排队延迟。

CDN（content Deliverty Network,内容分发网络）：

=> 最主要的就是通过把内容部署到全球各地，让用户从最近的服务器加载内容，大幅度降低传播分组的时间。

=> traceroute 测量延迟

IP(Internet Protocol )：负责联网主机之间的路由选址和寻址

TCP(Transmission Control Protocol 传输控制协议): 负责在不可靠的通信之上提供可靠的抽象层。

采用 TCP 数据流可以确保发送的所有字节能够完整地被接收到，而且到达客户端的顺序也一样。

三次握手

所有的TCP连接都要经历三次握手，

客户端与服务器在交换数据之前，必须就起始分组序号。

SYN

客户端选择一个伪随机序列号x,并且发送一个SYN分组， SYN x= rand()

SYN ACK

并选择自己的一个随机序列号 y，追加自己的标志和选项，然 后返回响应。

ACK

客户端给 x 和 y 加 1 并发送握手期间的最后一个ACK分组

三次握手完成后，客户端与服务器之间就可以通信了。

客户端可以在发送 ACK分组之后立即发送数据，而服务器必须等接收到ACK分组之后才能发送数据。

流量控制：是一种预防发送端过多向接收端发送数据的机制。

为了实现流量控制，TCP连接每一方都要通告自己的接收窗口(rwnd)，其中包含能够保存数据的缓冲区空间大小的信息；

第一次建立连接时，二端都会使用自身系统默认设置来发送rwnd。

浏览器页面主要是通过从服务器向客户端下载数据，因此客户端窗口可能成为瓶颈

如果是在上传图片或视频，即客户端向服务器传送大量数据时，服务器的接收窗口又可能成为制约因素。

那它可以向发送端通告一个较小的窗口。

假如窗口为零，则意味着必须由应用层先清空缓冲区，才能再接收剩余数据。

这个过程贯穿于每个TCP 连接的整个生命周期:每个ACK 分组都会携带相应的最新rwnd 值以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。

慢启动

首先，服务器通过TCP连接初始化一个新的拥塞窗口（cwnd）变量，将其值设置为一个系统设定的保守值。

.拥塞窗口大小

.发送端对从客户端接收确认(ACK)之前可以发送数据量的限制

.即客户端与服务器之 间最大可以传输(未经 ACK 确认的)数据量取 rwnd 和 cwnd 变量中的最小值

拥塞预防算法：把丢包作为网络拥塞的标志，即路径中某个连接或路由器已经拥堵了，以至于必须采取删包措施。

因此，必须调整窗口大小，以避免造成更多的包丢失， 从而保证网络畅通。

TCP的常用优点：

1.基本的分组错误检测与纠正

2.按序交付

3.丢包重发

4.以及保证网络最高效率的流量控制

5.拥塞控制和预防机制

队首阻塞：

产生的原因：因为按序交付

UDP:

无需按序交付数据

处理分组丢失

Tcp 的优化建议：

• TCP 三次握手增加了整整一次往返时间;

• TCP 慢启动将被应用到每个新连接;

• TCP 流量及拥塞控制会影响所有连接的吞吐量;

• TCP 的吞吐量由当前拥塞窗口大小控制。

UDP(User Datagram Protocol,用户数据报协议)

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

数据报和分组的区别：

数据报：只用来描述那些通过不可靠的服务传输的分组，既不保证送达，也不发送失败通知。

分组：可以用来指代任何格式化的数据块

web 性能优化，

1.延迟和带宽对web性能的影响

2.传输协议（TCP）对http 的限制

3.http协议自身的功能和缺陷

4.web应用的发展趋势以及对性能的需求

5.浏览器的局限性和优化思路

标记定义结构、样式表定义布局，

而脚本构建最终的交互式应用，响应用户输入，

并在交互期间创建样式表和标记。

性能优化的来源：计算，渲染，网络访问

web 应用主要涉及三个任务：获取资源，页面布局和渲染，JavaScript执行

渲染和脚本执行是一个线程上交错执行，不可能并发修改生成DOM。

针对浏览器的优化：

1.基于文档的优化，主要方法是有限获取资源，提前解析

2.推测性能优化

浏览器可以学习用户的导航模式，执行推测性优化，尝试预测用户的下一次操作。

然后，预先解析 DNS、预先连接可能的目标。

3.资源获取和排定的优先顺序

文档、CSS 和 JavaScript 解析器可以与网络协议层沟通，声明每种资源的优先 级:初始渲染必需的阻塞资源具有最高优先级，

而低优先级的请求可能会被临时 保存在队列中。

4.DNS预解析

对可能的域名进行提前解析，避免将来 HTTP 请求时的 DNS 延迟。预解析可以 通过学习导航历史、用户的鼠标悬停，或其他页面信号来触发。

5.TCP预链接

DNS 解析之后，浏览器可以根据预测的 HTTP 请求，推测性地打开 TCP 连接。 如果猜对的话，则可以节省一次完整的往返(TCP 握手)时间。

6.页面预渲染

某些浏览器可以让我们提示下一个可能的目标，从而在隐藏的标签页中预先渲染 整个页面。这样，当用户真的触发导航时，就能立即切换过来。

利用浏览器达到性能优化：

1.css 和 javascript等重要资源应该尽早出现在文档中

2.应该尽早交付css ,从而解除渲染并让javascript 执行

3.非关键性的JavaScript应该推迟，从而避免阻塞DOM 和 CSSDOM构建

4.HTML文档由解析器递增，从而保证可以间隙性的发送，以求得最佳性能。

除了优化页面结构，还可以在文档中嵌入提示，以触发浏览器为我们采用其他优化 机制:

➊

Firefox Chrome Safari IE

3.5+ N/A 1.0+ 1.0+ 5.01+ N/A 9+(预获取) N/A

3.5+ N/A 1.0+ 13+ N/A N/A 10+ 11+

href="/javascript/myapp.js">

➋ href="/images/big.jpeg">

➌ href="//example.org/next_page.html">

➊ 预解析特定的域名

➋ 预取得页面后面要用到的关键性资源

➌ 预取得将来导航要用的资源

➍ 根据对用户下一个目标的预测，预渲染特定页面

HTTP1.1 工作的重要目标：

1.持久化链接以支持连接重用

2.分块传输以支持流失响应

3.请求管道以支持并发请求

4.字节服务以支持基于范围的资源请求

5.改进的更好的缓存机制

针对网络优化 14条规则

1.减少DNS 查询

2.减少HTTP请求

常用的做法:

1.连接，把多个javascript 或者css 文件合并成一个文件

2.拼合，把多张图组合成一个更大的复合的图片

3.减少协议开销

4.应用层管道

3.使用CDN => 显著地减少每次TCP连接的网络延迟，增加吞吐量

4.添加Expires 首部并配置ETag 标签 => 利用缓存

5.GZip 资源 => 所以的文本资源应该使用Gzip 资源压缩，然后在客户端和服务器之间传输

6.避免HTTP重定向

做这些 主要是为了 消除和减少不必要的网络延迟，把传输的字节数降到最少

非文本性资源则必须通过 base64 编码

• 如果文件很小，而且只有个别页面使用，可以考虑嵌入;

• 如果文件很小，但需要在多个页面中重用，应该考虑集中打包;

• 如果小文件经常需要更新，就不要嵌入了;

• 通过减少 HTTP cookie 的大小将协议开销最小化。

HTTP 2.0 性能增强的核心，全在于新增二进制分层，它定义了如何封装HTTP消息并在客户端和服务器之间传输

二进制分针层

1.http 请求头被包装为 HEADERS 帧

内容被 包装为 DATA 帧

• 流已建立的连接上的双向字节流。

• 消息 与逻辑消息对应的完整的一系列数据帧。

• 帧 HTTP 2.0 通信的最小单位，每个帧包含帧首部，至少也会标识出当前帧所属的流。

HTTP 2.0 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。

相应地，每个数据流以消息的形式发送，而消息由一或多个帧组成，这些帧可 以乱序发送，然后再根据每个帧首部的流标识符重新组装。

HTTP 2.0 的所有帧都采用二进制编码，所有首部数据都会被压缩。

HTTP 2.0 中新的二进制分帧层突破了这些限制，

实现了多向请求和响应:客户端和 服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，

最后再 在另一端把它们重新组合起来。

请求优先级

• 0 表示最高优先级;

• 231-1 表示最低优先级

服务器推送

就是服务器可以对一个客户端请求发送多个

响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。

首部压缩

描述传输的资源及其属性

经典优化的最佳实践（目的在于减少延迟）

1 减少 DNS 查找

2 重用 TCP 连接

3 减少HTTP 重定向

4 使用CDN（内容分发）

5 去掉不必要的资源

6.在客户端使用缓存

cache-control 首部指定缓存时间

last-Modified 和 Etag 提供验证机制

7.传输压缩的内容

HTML、CSS 和 JavaScript 等文本资源的大小经过 gzip 压缩平均可以减少 60%~80%。

• 图片一般会占到一个网页需要传输的总字节数的一半;

• 通过去掉不必要的元数据可以把图片文件变小;

• 要调整大小就在服务器上调整，避免传输不必要的字节;

• 应该根据图像选择最优的图片格式;

• 尽可能使用有损压缩。

8.减少不必要的请求开销

9.并行处理请求和响应

10.针对不同的协议版本进行优化处理