浏览器开发者工具_Network模块-Timing

失心疯_2023

已于 2024-08-30 17:24:32 修改

阅读量190

点赞数

分类专栏：乱七八糟文章标签： Chrome 浏览器开发者工具 Network Timing

于 2024-01-25 11:06:34 首次发布

原文链接：https://blog.csdn.net/lgq2016/article/details/132481921

版权

乱七八糟专栏收录该内容

2 篇文章 0 订阅

订阅专栏

本文介绍了浏览器开发者工具Network面板中的Timing特性，详细解释了HTTP请求的全过程，包括DNS查找、TCP连接、SSL握手、TTFB等阶段，并提供了优化策略，如域名分片和HTTP2以提升性能。

摘要由CSDN通过智能技术生成

无奋斗不青春

我的个人主页：👉👉 失心疯的个人主页 👈👈
入门教程推荐：👉👉 Python零基础入门教程合集 👈👈
虚拟环境搭建：👉👉 Python项目虚拟环境(超详细讲解) 👈👈
PyQt5 系列教程：👉👉 Python GUI(PyQt5)文章合集 👈👈
Oracle数据库教程：👉👉 Oracle数据库文章合集 👈👈
优质资源下载：👉👉 资源下载合集 👈👈
优质教程推荐：👉👉 Python爬虫从入门到入狱系列合集👈👈

分隔线

Network模块-Timing

- 浏览器端功能模块简介
- - 浏览器开发者工具
  - - - Network 中的Timing

文章转载自： https://blog.csdn.net/lgq2016/article/details/132481921

浏览器端功能模块简介

浏览器开发者工具

Network 中的Timing

浏览器中 HTTP 请求流程:
发起一个HTTP请求之后，浏览器首先查找缓存
如果缓存没有命中，那么继续发起 DNS 请求获取 IP 地址
然后利用 IP 地址和服务器端建立 TCP 连接，再发送 HTTP 请求，等待服务器响应；
不过，如果服务器响应头中包含了重定向的信息，那么整个流程就需要重新再走一遍。
这就是在浏览器中一个 HTTP 请求的基础流程。
那详细列表中是如何表示出这个流程的呢？
这就要重点看下时间线面板了：
单个文件的时间线：
那面板中这各项到底是什么含义呢？
Queuing
- 也就是排队的意思，当浏览器发起一个请求的时候，会有很多原因导致该请求不能被立即执行，而是需要排队等待。导致请求处于排队状态的原因有很多。
- 首先，页面中的资源是有优先级的
  - CSS、HTML、JavaScript等都是页面中的核心文件，所以优先级最高；
  - 图片、视频、音频这类资源就不是核心资源，优先级就比较低。
  - 通常当后者遇到前者时，就需要“让路”，进入待排队状态
- 其次，浏览器会为每个域名最多维护 6 个 TCP 连接，如果发起一个 HTTP 请求时，这 6 个 TCP 连接都处于忙碌状态，那么这个请求就会处于排队状态。
- 最后，网络进程在为数据分配磁盘空间时，新的 HTTP 请求也需要短暂地等待磁盘分配结束。等待排队完成之后，就要进入发起连接的状态了。不过在发起连接之前，还有一些原因可能导致连接过程被推迟，这个推迟就表现在面板中的 Stalled 上，它表示停滞的意思。
- 这里需要额外说明的是，如果你使用了代理服务器，还会增加一个 Proxy Negotiation 阶段，也就是代理协商阶段，它表示代理服务器连接协商所用的时间，不过在上图中没有体现出来，因为这里我们没有使用代理服务器。
Initial connection/SSL
- 也就是和服务器建立连接的阶段，这包括了建立 TCP 连接所花费的时间；不过如果你使用了 HTTPS 协议，那么还需要一个额外的 SSL 握手时间，这个过程主要是用来协商一些加密信息的。（关于 SSL 协商的详细过程，我们会在 Web 安全模块中介绍。）和服务器建立好连接之后，网络进程会准备请求数据，并将其发送给网络，这就是 Request sent 阶段。通常这个阶段非常快，因为只需要把浏览器缓冲区的数据发送出去就结束了，并不需要判断服务器是否接收到了，所以这个时间通常不到 1 毫秒。
Waiting (TTFB)
- 数据发送出去了，接下来就是等待接收服务器第一个字节的数据，这个阶段称为 Waiting (TTFB)，通常也称为“第一字节时间”。 TTFB 是反映服务端响应速度的重要指标，对服务器来说，TTFB 时间越短，就说明服务器响应越快。接收到第一个字节之后，进入陆续接收完整数据的阶段，也就是 Content Download 阶段，这意味着从第一字节时间到接收到全部响应数据所用的时间。
优化时间线上耗时项了解了时间线面板上的各项含义之后，我们就可以根据这个请求的时间线来实现相关的优化操作了。

排队（Queuing）时间过久排队时间过久，大概率是由浏览器为每个域名最多维护 6 个连接导致的。那么基于这个原因，你就可以让 1 个站点下面的资源放在多个域名下面，比如放到 3 个域名下面，这样就可以同时支持 18 个连接了，这种方案称为域名分片技术。除了域名分片技术外，我个人还建议你把站点升级到 HTTP2，因为 HTTP2 已经没有每个域名最多维护 6 个 TCP 连接的限制了。
第一字节时间（TTFB）时间过久这可能的原因有如下：服务器生成页面数据的时间过久。对于动态网页来说，服务器收到用户打开一个页面的请求时，首先要从数据库中读取该页面需要的数据，然后把这些数据传入到模板中，模板渲染后，再返回给用户。服务器在处理这个数据的过程中，可能某个环节会出问题。网络的原因。比如使用了低带宽的服务器，或者本来用的是电信的服务器，可联通的网络用户要来访问你的服务器，这样也会拖慢网速。发送请求头时带上了多余的用户信息。比如一些不必要的 Cookie 信息，服务器接收到这些 Cookie 信息之后可能需要对每一项都做处理，这样就加大了服务器的处理时长。对于这三种问题，你要有针对性地出一些解决方案。面对第一种服务器的问题，你可以想办法去提高服务器的处理速度，比如通过增加各种缓存的技术；针对第二种网络问题，你可以使用 CDN 来缓存一些静态文件；至于第三种，你在发送请求时就去尽可能地减少一些不必要的 Cookie 数据信息。
Content Download 时间过久如果单个请求的 Content Download 花费了大量时间，有可能是字节数太多的原因导致的。这时候你就需要减少文件大小，比如压缩、去掉源码中不必要的注释等方法。

参数解析

Queued at 20.30s        # 表示该请求加入到请求队列中的时刻，请求队列在打开F12后第一次发送请求的时候创建，直到关闭控制台的时候销毁。
Started at 20.30s       # 表示请求开始处理的时刻。
Queueing                # 表示请求从加入到请求队列中到请求开始处理经过的时间。
Stalled                 # 请求在可以被发送出去之前的等待时间（阻塞时间），一般是等待可复用的TCP连接释放的时间。浏览器对于单个域名只能同时建立4~6个TCP连接（不同浏览器实现有差异）。
Proxy Negotiation       # 浏览器和代理服务器连接的协商时间。
DNS Lookup              # 域名解析花费的时间。
Initial Connection      # 建立TCP连接花费的的时间，包括TCP握手/重试和协商SSL。
Request sent            # 发送请求花费的时间。
Waiting (TTFB)          # 从发出请求到接收到响应第一个字节经过的时间，包括网络延迟时间。
Content Download        # 接收响应花费的时间。