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.针对不同的协议版本进行优化处理

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180926G11X1T00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券