HTTP协议之总结展望篇

HTTP/2

HTTP/2 把 TCP 协议的部分特性挪到了应用层&＃xff0c;把原来的“Header&＃43;Body”的消息“打散”为数个小片的二进制“帧”&＃xff08;Frame&＃xff09;&＃xff0c;用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。

HTTP/1、HTTPS 和 HTTP/2 的协议栈

• HTTP 协议取消了小版本号&＃xff0c;所以 HTTP/2 的正式名字不是 2.0&＃xff1b;
• HTTP/2 在“语义”上兼容 HTTP/1&＃xff0c;保留了请求方法、URI 等传统概念&＃xff1b;
• HTTP/2 使用“HPACK”算法压缩头部信息&＃xff0c;消除冗余数据节约带宽&＃xff1b;
• HTTP/2 的消息不再是“Header&＃43;Body”的形式&＃xff0c;而是分散为多个二进制“帧”&＃xff1b;
• HTTP/2 使用虚拟的“流”传输消息&＃xff0c;解决了困扰多年的“队头阻塞”问题&＃xff0c;同时实现了“多路复用”&＃xff0c;提高连接的利用率&＃xff1b;
• HTTP/2 也增强了安全性&＃xff0c;要求至少是 TLS1.2&＃xff0c;而且禁用了很多不安全的密码套件。

HTTP/2内核

“HPACK”算法是专门为压缩 HTTP 头部定制的算法&＃xff0c;与 gzip、zlib 等压缩算法不同&＃xff0c;它是一个“有状态”的算法&＃xff0c;需要客户端和服务器各自维护一份“索引表”&＃xff0c;也可以说是“字典”&＃xff08;这有点类似 brotli&＃xff09;&＃xff0c;压缩和解压缩就是查表和更新表的操作。

• HTTP/2 废除了原有的起始行概念&＃xff0c;把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式&＃xff0c;并且给这些“不是头字段的头字段”起了个特别的名字——“伪头字段”&＃xff08;pseudo-header fields&＃xff09;。而起始行里的版本号和错误原因短语因为没什么大用&＃xff0c;顺便也给废除了。为了与“真头字段”区分开来&＃xff0c;这些“伪头字段”会在名字前加一个“:”&＃xff0c;比如“:authority” “:method” “:status”&＃xff0c;分别表示的是域名、请求方法和状态码。

• 流是二进制帧的双向传输序列。

在 HTTP/2 连接上&＃xff0c;虽然帧是乱序收发的&＃xff0c;但只要它们都拥有相同的流 ID&＃xff0c;就都属于一个流&＃xff0c;而且在这个流里帧不是无序的&＃xff0c;而是有着严格的先后顺序。

HTTP/2 的流有哪些特点呢&＃xff1f;

• 流是可并发的&＃xff0c;一个 HTTP/2 连接上可以同时发出多个流传输数据&＃xff0c;也就是并发多请求&＃xff0c;实现“多路复用”&＃xff1b;
• 客户端和服务器都可以创建流&＃xff0c;双方互不干扰&＃xff1b;
• 流是双向的&＃xff0c;一个流里面客户端和服务器都可以发送或接收数据帧&＃xff0c;也就是一个“请求 - 应答”来回&＃xff1b;
• 流之间没有固定关系&＃xff0c;彼此独立&＃xff0c;但流内部的帧是有严格顺序的&＃xff1b;
• 流可以设置优先级&＃xff0c;让服务器优先处理&＃xff0c;比如先传 HTML/CSS&＃xff0c;后传图片&＃xff0c;优化用户体验&＃xff1b;
• 流 ID 不能重用&＃xff0c;只能顺序递增&＃xff0c;客户端发起的 ID 是奇数&＃xff0c;服务器端发起的 ID 是偶数&＃xff1b;
• 在流上发送“RST_STREAM”帧可以随时终止流&＃xff0c;取消接收或发送&＃xff1b;
• 第 0 号流比较特殊&＃xff0c;不能关闭&＃xff0c;也不能发送数据帧&＃xff0c;只能发送控制帧&＃xff0c;用于流量控制。
  

流状态转换

• 最开始的时候流都是“空闲”&＃xff08;idle&＃xff09;状态&＃xff0c;也就是“不存在”&＃xff0c;可以理解成是待分配的“号段资源”。
• 当客户端发送 HEADERS 帧后&＃xff0c;有了流 ID&＃xff0c;流就进入了“打开”状态&＃xff0c;两端都可以收发数据&＃xff0c;然后客户端发送一个带“END_STREAM”标志位的帧&＃xff0c;流就进入了“半关闭”状态。
• 这个“半关闭”状态很重要&＃xff0c;意味着客户端的请求数据已经发送完了&＃xff0c;需要接受响应数据&＃xff0c;而服务器端也知道请求数据接收完毕&＃xff0c;之后就要内部处理&＃xff0c;再发送响应数据。
• 响应数据发完了之后&＃xff0c;也要带上“END_STREAM”标志位&＃xff0c;表示数据发送完毕&＃xff0c;这样流两端就都进入了“关闭”状态&＃xff0c;流就结束了。
• 流 ID 不能重用&＃xff0c;所以流的生命周期就是 HTTP/1 里的一次完整的“请求 - 应答”&＃xff0c;流关闭就是一次通信结束。
• 下一次再发请求就要开一个新流&＃xff08;而不是新连接&＃xff09;&＃xff0c;流 ID 不断增加&＃xff0c;直到到达上限&＃xff0c;发送“GOAWAY”帧开一个新的 TCP 连接&＃xff0c;流 ID 就又可以重头计数。
  

小结

• HTTP/2 必须先发送一个“连接前言”字符串&＃xff0c;然后才能建立正式连接&＃xff1b;
• HTTP/2 废除了起始行&＃xff0c;统一使用头字段&＃xff0c;在两端维护字段“Key-Value”的索引表&＃xff0c;使用“HPACK”算法压缩头部&＃xff1b;
• HTTP/2 把报文切分为多种类型的二进制帧&＃xff0c;报头里最重要的字段是流标识符&＃xff0c;标记帧属于哪个流&＃xff1b;
• 流是 HTTP/2 虚拟的概念&＃xff0c;是帧的双向传输序列&＃xff0c;相当于 HTTP/1 里的一次“请求 - 应答”&＃xff1b;
• 在一个 HTTP/2 连接上可以并发多个流&＃xff0c;也就是多个“请求 - 响应”报文&＃xff0c;这就是“多路复用”。

HTTP/3

• HTTP/3 基于 QUIC 协议&＃xff0c;完全解决了“队头阻塞”问题&＃xff0c;弱网环境下的表现会优于 HTTP/2&＃xff1b;
• QUIC 是一个新的传输层协议&＃xff0c;建立在 UDP 之上&＃xff0c;实现了可靠传输&＃xff1b;
• QUIC 内含了 TLS1.3&＃xff0c;只能加密通信&＃xff0c;支持 0-RTT 快速建连&＃xff1b;
• QUIC 的连接使用“不透明”的连接 ID&＃xff0c;不绑定在“IP 地址 &＃43; 端口”上&＃xff0c;支持“连接迁移”&＃xff1b;
• QUIC 的流与 HTTP/2 的流很相似&＃xff0c;但分为双向流和单向流&＃xff1b;
• HTTP/3 没有指定默认端口号&＃xff0c;需要用 HTTP/2 的扩展帧“Alt-Svc”来发现。

Nginx&＃xff1a;高性能的Web服务器

Nginx 是个“轻量级”的 Web 服务器。

• “轻量级”是相对于“重量级”而言的。“重量级”就是指服务器进程很“重”&＃xff0c;占用很多资源&＃xff0c;当处理 HTTP 请求时会消耗大量的 CPU 和内存&＃xff0c;受到这些资源的限制很难提高性能。而 Nginx 作为“轻量级”的服务器&＃xff0c;它的 CPU、内存占用都非常少&＃xff0c;同样的资源配置下就能够为更多的用户提供服务&＃xff0c;其奥秘在于它独特的工作模式。

Nginx “一反惯例”地没有使用多线程&＃xff0c;而是使用了“进程池 &＃43; 单线程”的工作模式

• Nginx 在启动的时候会预先创建好固定数量的 worker 进程&＃xff0c;在之后的运行过程中不会再 fork 出新进程&＃xff0c;这就是进程池&＃xff0c;而且可以自动把进程“绑定”到独立的 CPU 上&＃xff0c;这样就完全消除了进程创建和切换的成本&＃xff0c;能够充分利用多核 CPU 的计算能力。

• 在进程池之上&＃xff0c;还有一个“master”进程&＃xff0c;专门用来管理进程池。它的作用有点像是 supervisor&＃xff08;一个用 Python 编写的进程管理工具&＃xff09;&＃xff0c;用来监控进程&＃xff0c;自动恢复发生异常的 worker&＃xff0c;保持进程池的稳定和服务能力。

• 不过 master 进程完全是 Nginx 自行用 C 语言实现的&＃xff0c;这就摆脱了外部的依赖&＃xff0c;简化了 Nginx 的部署和配置。
  

• Nginx 是一个高性能的 Web 服务器&＃xff0c;它非常的轻量级&＃xff0c;消耗的 CPU、内存很少&＃xff1b;

• Nginx 采用“master/workers”进程池架构&＃xff0c;不使用多线程&＃xff0c;消除了进程、线程切换的成本&＃xff1b;

• Nginx 基于 epoll 实现了“I/O 多路复用”&＃xff0c;不会阻塞&＃xff0c;所以性能很高&＃xff1b;

• Nginx 使用了“职责链”模式&＃xff0c;多个模块分工合作&＃xff0c;自由组合&＃xff0c;以流水线的方式处理 HTTP 请求。

Web 服务器从根本上来说是“I/O 密集型”而不是“CPU 密集型”&＃xff0c;处理能力的关键在于网络收发而不是 CPU 计算&＃xff08;不考虑 HTTPS 的加解密&＃xff09;&＃xff0c;而网络 I/O 会因为各式各样的原因不得不等待&＃xff0c;比如数据还没到达、对端没有响应、缓冲区满发不出去等等。

I/O 多路复用

• Nginx 里使用的 epoll&＃xff0c;就好像是 HTTP/2 里的“多路复用”技术&＃xff0c;它把多个 HTTP 请求处理打散成碎片&＃xff0c;都“复用”到一个单线程里&＃xff0c;不按照先来后到的顺序处理&＃xff0c;而是只当连接上真正可读、可写的时候才处理&＃xff0c;如果可能发生阻塞就立刻切换出去&＃xff0c;处理其他的请求。
• 通过这种方式&＃xff0c;Nginx 就完全消除了 I/O 阻塞&＃xff0c;把 CPU 利用得“满满当当”&＃xff0c;又因为网络收发并不会消耗太多 CPU 计算能力&＃xff0c;也不需要切换进程、线程&＃xff0c;所以整体的 CPU 负载是相当低的。

Nginx“I/O 多路复用”的示意图

• epoll 还有一个特点&＃xff0c;大量的连接管理工作都是在操作系统内核里做的&＃xff0c;这就减轻了应用程序的负担&＃xff0c;所以 Nginx 可以为每个连接只分配很小的内存维护状态&＃xff0c;即使有几万、几十万的并发连接也只会消耗几百 M 内存&＃xff0c;而其他的 Web 服务器这个时候早就“Memory not enough”了。

Nginx 使用了“职责链”模式&＃xff0c;多个模块分工合作&＃xff0c;自由组合&＃xff0c;以流水线的方式处理 HTTP 请求。

怎么理解进程、线程上下文切换时的成本的&＃xff0c;为什么 Nginx 要尽量避免&＃xff1f;

• 一个线程的时间片没用完就系统调用被系统调度切换出去&＃xff0c;浪费了剩余的时间片。当从一个任务切换到另一个任务&＃xff0c;当前任务的上下文&＃xff0c;如堆栈&＃xff0c;指令指针等都要保存起来&＃xff0c;以便下次任务时恢复&＃xff0c;然后再把另一个任务的堆栈加载进来&＃xff0c;如果有大量的上下文切换&＃xff0c;就会影响性能。nginx通过epoll和注册回调&＃xff0c;和非阻塞io自己在用户态主动切换上下文&＃xff0c;充分利用了系统分配给进程或者线程的时间片&＃xff0c;所以对系统资源利用很充分。
• 多线程就好比一条流水线有多个机械手&＃xff0c;把一件事情中途交给其他线程处理&＃xff0c;要交接处理中间状态信息。单进程就好比一条流水线只有一个机械手&＃xff0c;切换时间片时暂停状态就可以&＃xff0c;不用交接信息&＃xff0c;减少无用功&＃xff0c;所以效率高。

一个人很难超越时代&＃xff0c;而时代却可以轻易超越所有人。

OpenResty&＃xff1a;更灵活的Web服务器

• OpenResty 并不是一个全新的 Web 服务器&＃xff0c;而是基于 Nginx&＃xff0c;它利用了 Nginx 模块化、可扩展的特性&＃xff0c;开发了一系列的增强模块&＃xff0c;并把它们打包整合&＃xff0c;形成了一个“一站式”的 Web 开发平台。OpenResty 的核心是 Nginx&＃xff0c;但它又超越了 Nginx&＃xff0c;关键就在于其中的 ngx_lua 模块&＃xff0c;把小巧灵活的 Lua 语言嵌入了 Nginx&＃xff0c;可以用脚本的方式操作 Nginx 内部的进程、多路复用、阶段式处理等各种构件。

Lua

• Lua 的设计目标是嵌入到其他应用程序里运行&＃xff0c;为其他编程语言带来“脚本化”能力&＃xff0c;所以它的“个头”比较小&＃xff0c;功能集有限&＃xff0c;不追求“大而全”&＃xff0c;而是“小而美”&＃xff0c;大多数时间都“隐匿”在其他应用程序的后面&＃xff0c;是“无名英雄”。
• Lua 作为“最快的脚本语言”恰好可以成为 Nginx 的完美搭档&＃xff0c;既可以简化开发&＃xff0c;性能上又不会有太多的损耗。作为脚本语言&＃xff0c;Lua 还有一个重要的“代码热加载”特性&＃xff0c;不需要重启进程&＃xff0c;就能够从磁盘、Redis 或者任何其他地方加载数据&＃xff0c;随时替换内存里的代码片段。这就带来了“动态配置”&＃xff0c;让 OpenResty 能够永不停机&＃xff0c;在微秒、毫秒级别实现配置和业务逻辑的实时更新&＃xff0c;比起 Nginx 秒级的重启是一个极大的进步。

epoll 是操作系统级别的“多路复用”&＃xff0c;运行在内核空间。而 OpenResty 的“同步非阻塞”则是基于 Lua 内建的“协程”&＃xff0c;是应用程序级别的“多路复用”&＃xff0c;运行在用户空间&＃xff0c;所以它的资源消耗要更少。

• Nginx 依赖于磁盘上的静态配置文件&＃xff0c;修改后必须重启才能生效&＃xff0c;缺乏灵活性&＃xff1b;
• OpenResty 基于 Nginx&＃xff0c;打包了很多有用的模块和库&＃xff0c;是一个高性能的 Web 开发平台&＃xff1b;
• OpenResty 的工作语言是 Lua&＃xff0c;它小巧灵活&＃xff0c;执行效率高&＃xff0c;支持“代码热加载”&＃xff1b;
• OpenResty 的核心编程范式是“同步非阻塞”&＃xff0c;使用协程&＃xff0c;不需要异步回调函数&＃xff1b;
• OpenResty 也使用“阶段式处理”的工作模式&＃xff0c;但因为在阶段里执行的都是 Lua 代码&＃xff0c;所以非常灵活&＃xff0c;配合 Redis 等外部数据库能够实现各种动态配置。

网络应用防火墙(WAF)

Web 服务遇到的威胁

• “DDoS”攻击&＃xff08;distributed denial-of-service attack&＃xff09;&＃xff0c;有时候也叫“洪水攻击”。黑客会控制许多“僵尸”计算机&＃xff0c;向目标服务器发起大量无效请求。因为服务器无法区分正常用户和黑客&＃xff0c;只能“照单全收”&＃xff0c;这样就挤占了正常用户所应有的资源。如果黑客的攻击强度很大&＃xff0c;就会像“洪水”一样对网站的服务能力造成冲击&＃xff0c;耗尽带宽、CPU 和内存&＃xff0c;导致网站完全无法提供正常服务。
• “SQL 注入”&＃xff08;SQL injection&＃xff09;应该算是最著名的一种“代码注入”攻击了&＃xff0c;它利用了服务器字符串拼接形成 SQL 语句的漏洞&＃xff0c;构造出非正常的 SQL 语句&＃xff0c;获取数据库内部的敏感信息。
• HTTP 头注入”攻击的方式也是类似的原理&＃xff0c;它在“Host”“User-Agent”“X-Forwarded-For”等字段里加入了恶意数据或代码&＃xff0c;服务端程序如果解析不当&＃xff0c;就会执行预设的恶意代码。
• COOKIE 的攻击手段&＃xff0c;“跨站脚本”&＃xff08;XSS&＃xff09;攻击&＃xff0c;它属于“JS 代码注入”&＃xff0c;利用 Javascript 脚本获取未设防的 COOKIE。

“网络应用防火墙”&＃xff0c;也就是 WAF&＃xff0c;使用它可以加固 Web 服务

• Web 服务通常都运行在公网上&＃xff0c;容易受到“DDoS”、“代码注入”等各种黑客攻击&＃xff0c;影响正常的服务&＃xff0c;所以必须要采取措施加以保护&＃xff1b;
• WAF 是一种“HTTP 入侵检测和防御系统”&＃xff0c;工作在七层&＃xff0c;为 Web 服务提供全面的防护&＃xff1b;
• ModSecurity 是一个开源的、生产级的 WAF 产品&＃xff0c;核心组成部分是“规则引擎”和“规则集”&＃xff0c;两者的关系有点像杀毒引擎和病毒特征库
• WAF 实质上是模式匹配与数据过滤&＃xff0c;所以会消耗 CPU&＃xff0c;增加一些计算成本&＃xff0c;降低服务能力&＃xff0c;使用时需要在安全与性能之间找到一个“平衡点”。

网络安全领域必须时刻记得“木桶效应”&＃xff08;也叫“短板效应”&＃xff09;。网站的整体安全不在于你加固的最强的那个方向&＃xff0c;而是在于你可能都没有意识到的“短板”。黑客往往会“避重就轻”&＃xff0c;只要发现了网站的一个弱点&＃xff0c;就可以“一点突破”&＃xff0c;其他方面的安全措施也就都成了“无用功”。

CDN&＃xff1a;加速我们的网络服务

CDN :它就是专门为解决“长距离”上网络访问速度慢而诞生的一种网络应用服务。

CDN 有三个关键词&＃xff1a;“内容”“分发”和“网络”

• 网络&＃xff1a;CDN 的最核心原则是“就近访问”&＃xff0c;如果用户能够在本地几十公里的距离之内获取到数据&＃xff0c;那么时延就基本上变成 0 了。
• 分发&＃xff1a;“分发”源站的“内容”&＃xff0c;用到的就是“缓存代理”技术。使用“推”或者“拉”的手段&＃xff0c;把源站的内容逐级缓存到网络的每一个节点上。于是&＃xff0c;用户在上网的时候就不直接访问源站&＃xff0c;而是访问离他“最近的”一个 CDN 节点&＃xff0c;术语叫“边缘节点”&＃xff08;edge node&＃xff09;&＃xff0c;其实就是缓存了源站内容的代理服务器&＃xff0c;这样一来就省去了“长途跋涉”的时间成本&＃xff0c;实现了“网络加速”。
• 内容&＃xff1a;其实就是 HTTP 协议里的“资源”&＃xff0c;比如超文本、图片、视频、应用程序安装包等等。
  

CDN 有两个关键组成部分&＃xff1a;全局负载均衡和缓存系统&＃xff0c;对应的是 DNS和缓存代理技术。

• 全局负载均衡&＃xff08;Global Sever Load Balance&＃xff09;一般简称为 GSLB&＃xff0c;它是 CDN 的“大脑”&＃xff0c;主要的职责是当用户接入网络的时候在 CDN 专网中挑选出一个“最佳”节点提供服务&＃xff0c;解决的是用户如何找到“最近的”边缘节点&＃xff0c;对整个 CDN 网络进行“负载均衡”。
  
• 缓存系统是 CDN 的另一个关键组成部分&＃xff0c;相当于 CDN 的“心脏”。如果缓存系统的服务能力不够&＃xff0c;不能很好地满足用户的需求&＃xff0c;那 GSLB 调度算法再优秀也没有用。两个衡量 CDN 服务质量的指标&＃xff1a;“命中率”和“回源率”。

现在cdn有种叫“边缘计算”的技术&＃xff0c;就是把计算动态资源的代码和数据也放在cdn的节点上&＃xff0c;这样就可以在cdn里获取动态资源不用回源站了。

WebSocket&＃xff1a;沙盒里的TCP

• WebSocket 针对的是“请求 - 应答”通信模式。“请求 - 应答”是一种“半双工”的通信模式&＃xff0c;虽然可以双向收发数据&＃xff0c;但同一时刻只能一个方向上有动作&＃xff0c;传输效率低。更关键的一点&＃xff0c;它是一种“被动”通信模式&＃xff0c;服务器只能“被动”响应客户端的请求&＃xff0c;无法主动向客户端发送数据。

“WebSocket”是一种基于 TCP 的轻量级网络通信协议&＃xff0c;在地位上是与 HTTP“平级”的。

• HTTP 的“请求 - 应答”模式不适合开发“实时通信”应用&＃xff0c;效率低&＃xff0c;难以实现动态页面&＃xff0c;所以出现了 WebSocket&＃xff1b;
• WebSocket 是一个“全双工”的通信协议&＃xff0c;相当于对 TCP 做了一层“薄薄的包装”&＃xff0c;让它运行在浏览器环境里&＃xff1b;
• WebSocket 使用兼容 HTTP 的 URI 来发现服务&＃xff0c;但定义了新的协议名“ws”和“wss”&＃xff0c;端口号也沿用了 80 和 443&＃xff1b;
• WebSocket 使用二进制帧&＃xff0c;结构比较简单&＃xff0c;特殊的地方是有个“掩码”操作&＃xff0c;客户端发数据必须掩码&＃xff0c;服务器则不用&＃xff1b;
• WebSocket 利用 HTTP 协议实现连接握手&＃xff0c;发送 GET 请求要求“协议升级”&＃xff0c;握手过程中有个非常简单的认证机制&＃xff0c;目的是防止误连接。

总结

衡量服务器性能的主要指标有三个&＃xff1a;吞吐量&＃xff08;requests per second&＃xff09;、并发数&＃xff08;concurrency&＃xff09;和响应时间&＃xff08;time per request&＃xff09;。

• 吞吐量就是我们常说的 RPS&＃xff0c;每秒的请求次数&＃xff0c;也有叫 TPS、QPS&＃xff0c;它是服务器最基本的性能指标&＃xff0c;RPS 越高就说明服务器的性能越好。
• 并发数反映的是服务器的负载能力&＃xff0c;也就是服务器能够同时支持的客户端数量&＃xff0c;当然也是越多越好&＃xff0c;能够服务更多的用户。
• 响应时间反映的是服务器的处理能力&＃xff0c;也就是快慢程度&＃xff0c;响应时间越短&＃xff0c;单位时间内服务器就能够给越多的用户提供服务&＃xff0c;提高吞吐量和并发数。
• 除了上面的三个基本性能指标&＃xff0c;服务器还要考虑 CPU、内存、硬盘和网卡等系统资源的占用程度&＃xff0c;利用率过高或者过低都可能有问题。

服务器的性能优化方向&＃xff1a;合理利用系统资源&＃xff0c;提高服务器的吞吐量和并发数&＃xff0c;降低响应时间。

• Chrome 等浏览器自带的开发者工具也可以很好地观察客户端延迟指标&＃xff0c;面板左边有每个 URI 具体消耗的时间&＃xff0c;面板的右边也是类似的瀑布图。
• 点击某个 URI&＃xff0c;在 Timing 页里会显示出一个小型的“瀑布图”&＃xff0c;是这个资源消耗时间的详细分解&＃xff0c;延迟的原因都列的清清楚楚&＃xff0c;比如下面的这张图&＃xff1a;

图里面的这些指标都是什么含义呢&＃xff1f;

• 因为有“队头阻塞”&＃xff0c;浏览器对每个域名最多开 6 个并发连接&＃xff08;HTTP/1.1&＃xff09;&＃xff0c;当页面里链接很多的时候就必须排队等待&＃xff08;Queued、Queueing&＃xff09;&＃xff0c;这里它就等待了 1.62 秒&＃xff0c;然后才被浏览器正式处理&＃xff1b;
• 浏览器要预先分配资源&＃xff0c;调度连接&＃xff0c;花费了 11.56 毫秒&＃xff08;Stalled&＃xff09;;
• 连接前必须要解析域名&＃xff0c;这里因为有本地缓存&＃xff0c;所以只消耗了 0.41 毫秒&＃xff08;DNS Lookup&＃xff09;&＃xff1b;
• 与网站服务器建立连接的成本很高&＃xff0c;总共花费了 270.87 毫秒&＃xff0c;其中有 134.89 毫秒用于 TLS 握手&＃xff0c;那么 TCP 握手的时间就是 135.98 毫秒&＃xff08;Initial connection、SSL&＃xff09;&＃xff1b;
• 实际发送数据非常快&＃xff0c;只用了 0.11 毫秒&＃xff08;Request sent&＃xff09;&＃xff1b;
• 之后就是等待服务器的响应&＃xff0c;专有名词叫 TTFB&＃xff08;Time To First Byte&＃xff09;&＃xff0c;也就是“首字节响应时间”&＃xff0c;里面包括了服务器的处理时间和网络传输时间&＃xff0c;花了 124.2 毫秒&＃xff1b;
• 接收数据也是非常快的&＃xff0c;用了 3.58 毫秒&＃xff08;Content Dowload&＃xff09;。

从这张图你可以看到&＃xff0c;一次 HTTP“请求 - 响应”的过程中延迟的时间是非常惊人的&＃xff0c;总时间 415.04 毫秒里占了差不多 99%。所以&＃xff0c;客户端 HTTP 性能优化的关键就是&＃xff1a;降低延迟。

你知道的越多&＃xff0c;你不知道的越多。
有道无术&＃xff0c;术尚可求&＃xff0c;有术无道&＃xff0c;止于术。
如有其它问题&＃xff0c;欢迎大家留言&＃xff0c;我们一起讨论&＃xff0c;一起学习&＃xff0c;一起进步