这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
前端页面的生命周期
- 浏览器收到URL，开启网络线程去请求对方的服务器
- 一个完整的http请求并发出请求
- 服务器接收到请求，一般服务器都有个代理服务，这个代理就会转发具体的处理后台，处理完后再转给代理服务器
- 前后台之间的HTTP交互和涉及的缓存机制，例如强缓存和协商缓存嘛，然后就去进行内容的响应
- 浏览器接收到数据包的关键渲染路径
- JS引擎的解析过程
网络请求线程的开启
首先对URL的解析
| 标题 | 名称 | 备注 |
|---|---|---|
| Protocol | 协议头 | |
| Host | 主机域名/IP地址 | |
| Port | 端口号 | |
| Path | 目录路径 | |
| Query | 查询参数 | |
| Fragment | 片段 |
URL结构：Protocol://Host:Port/Path?Query#Fragment，例如 example.com/users/1?foo…
解析 URL后，如果是 HTTP 协议，则浏览器会新建一个网络请求线程去下载所需的资源，要明白这个过 程需要先了解进程和线程之间的区别，以及目前主流的多进程浏览器结构。
进程与线程
区别：
- 只要某个线程执行出错，将会导致整个进程崩溃。
- 进程与进程之间相互隔离。这保证了当一个进程挂起或崩溃的情况发生时，并不会影响其他进程的 正常运行，虽然每个进程只能访问系统分配给自己的资源，但可以通过IPC 机制进行进程间通信。
- 进程所占用的资源会在其关闭后由操作系统回收。即使进程中存在某个线程产生的内存泄漏，当进 程退出时，相关的内存资源也会被回收。
- 线程之间可以共享所属进程的数据。
建立HTTP请求
这个阶段的主要工作分为两部分
- DNS解析（根据域名找IP地址）
- 通信链路的建立
简单来说
- 首先发起请求的客户端浏览器要明确知道所要访问的服务器地址
- 然后建立通往该服务器地址的路径
TCP连接
- 三次握手
- 这里可以查询关于TCP连接的教程，这里不多赘述
前后端的交互
当TCP 连接建立好之后，便可通过 HTTP 等协议进行前后端的通信，但在实际的网络访问中，并非浏览 器与确定IP 地址的服务器之间直接通信，往往会在中间加入反向代理服务器。
反向代理服务器
对需要提供复杂功能的网站来说，通常单一的服务器资源是很难满足期望的。一般采用的方式是将多个应 用服务器组成的集群由反向代理服务器提供给客户端用户使用，这些功能服务器可能具有不同类型，比如 文件服务器、邮件服务器及 Web 应用服务器，同时也可能是相同的Web服务部署到多个服务器上，以实 现负载均衡的效果，反向代理服务器的作用如图所示。
反向代理服务器根据客户的请求，从后端服务器上获取资源后提供给客户端。反向代理服务器通常的作用 如下：
- 负载均衡
- 安全防火墙
- 加密及SSL加速
- 数据压缩
- 解决跨域
- 对静态资源缓存
- 常用作反向代理服务器的有 Nginx、 IIS、 Apache
后端处理流程
经反向代理收到请求后，具体的服务器后台处理流程大致如下。
- 首先会有一层统一的验证环节，如跨域验证、安全校验拦截等。如果发现是不符合规则的请求，则 直接返回相应的拒绝报文。
- 通过验证后才会进入具体的后台程序代码执行阶段，如具体的计算、数据库查询等。
- 完成计算后，后台会以一个HTTP响应数据包的形式发送回请求的前端，结束本次请求。
HTTP相关协议特性
HTTP 是建立在传输层 TCP 协议之上的应用层协议，在TCP 层面上存在长连接和短连接的区别。所谓长 连接，就是在客户端与服务器端建立的 TCP 连接上，可以连续发送多个数据包，但需要双方发送心跳检 查包来维持这个连接。
短连接就是当客户端需要向服务器端发送请求时，会在网络层1P 协议之上建立一个 TCP 连接，当请求发 送并收到响应后，则断开此连接。根据前面关于 TCP 连接建立过程的描述，我们知道如果这个过程频繁 发生，就是个很大的性能耗费，所以从 HTTP 的1.0 版本开始对于连接的优化一直在进行。
在HTTP 1.0 时，默认使用短连接，浏览器的每一次 HTTP 操作就会建立一个连接，任务结束则断开连 接。
在HTTP 1.1 时，默认使用长连接，在此情况下，当一个网页的打开操作完成时，其中所建立用于传输 HTTP 的TCP 连接并不会断开关闭，客户端后续的请求操作便会继续使用这个已经建立的连接。如果我们 对浏览器的开发者工具留心，在查看请求头时会发现一行 Connection: keep-alive。长连接并非永久 保持，它有一个持续时间，可在服务器中进行配置。
而在 HTTP 2.0 到来之前，每一个资源的请求都需要开启一个 TCP 连接，由于 TCP 本身有并发数的限制， 这样的结果就是，当请求的资源变多时，速度性能就会明显下降。为此，经常会采用的优化策略包括，将 静态资源的请求进行多域名拆分，对于小图标或图片使用雪碧图等。
HTTP 2.0 除了一个连接可请求多个资源这种多路复用的特性，还有如下一些新特性。
- 二进制分帧：在应用层和传输层之间，新加入了一个二进制分帧层，以实现低延迟和高吞吐量。
- 服务器端推送：以往是一个请求带来一个响应，现在服务器可以向客户端的一个请求发出多个响应，这样便可以实现服务器端主动向客户端推送的功能。
- 设置请求优先级：服务器会根据请求所设置的优先级，来决定需要多少资源处理该请求。
- HTTP头部压缩：减少报文传输体积。
优化手段
DNS解析
- 减少DNS对请求次数
- 进行DNS预获取
HTTP优化
- 减少请求次数
- 减少单次请求所花费的时间
Gzip压缩
如何开启？只需要在你的 request headers 中加上
accept-encoding:gzip
图片优化
时下应用较为广泛的 Web 图片格式有 JPEG/JPG、PNG、WebP、Base64、SVG 等
JPEG/JPG
关键字：有损压缩、体积小、加载快、不支持透明
适合：色彩丰富的图片，一般为大大背景图、轮播图或者Banner
PNG-8 与 PNG-24
关键字：无损压缩、质量高、体积大、支持透明
适合：小logo，颜色简单
SVG
关键字：文本文件、体积小、不失真、兼容性好
适合：可以像写代码一样定义 SVG，把它写在 HTML 里
Base64
关键字：文本文件、依赖编码、小图标解决方案
Base64 是作为雪碧图的补充而存在的，主要是为了减少加载图片对服务器的请求次数
既然 Base64 这么棒，我们何不把大图也换成 Base64 呢？
因为Base64 编码后，图片大小会膨胀为原文件的 4/3，大图使用base64可能会得不偿失
WebP
关键字：年轻的全能型选手
WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。
