blog 从输入URL到页面加载的过程（上）

从输入URL到页面加载的过程（上）

Open yanyue404 opened this issue 2 years ago • 0 comments

前言

参考

从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！

大纲

从浏览器接收 url 到开启网络请求线程
- 多进程的浏览器
- 多线程的浏览器内核
- 网络请求都是单独的线程
开启网络线程到发出一个完整的 http 请求
- DNS 查询得到 IP
- tcp/ip 请求
- 五层因特网协议栈
从服务器接收到请求到对应后台接收到请求
- 负载均衡
- 后台的处理
后台和前台的 http 交互
- http 报文结构
- cookie 交互
- gzip 压缩
- 长连接与短连接
- http 2.0
- websocket
- https
- http 的缓存
解析页面流程
- 流程简述
- HTML 解析，构建 DOM
- 生成 CSS 规则
- 构建渲染树
- 渲染
- Chrome 中的调试
- 资源外链的下载
- loaded 和 domcontentloaded
JS 引擎解析过程
- 执行上下文
- 作用域链
- 事件循环机制

从浏览器接收 url 到开启网络请求线程

这一部分展开的内容是：浏览器进程/线程模型，JS 的运行机制

多进程的浏览器

浏览器是多进程的，有一个主控进程，以及每一个 tab 页面都会新开一个进程（某些情况下多个 tab 会合并进程）

进程可能包括主控进程，插件进程，GPU，tab 页（浏览器内核）等等

Browser 进程：浏览器的主进程（负责协调、主控），只有一个
第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建
GPU 进程：最多一个，用于 3D 绘制
浏览器渲染进程（内核）：默认每个 Tab 页面一个进程，互不影响，控制页面渲染，脚本执行，事件处理等（有时候会优化，如多个空白 tab 会合并成一个进程）

Shift+Esc 查看进程信息

多线程的浏览器内核

每一个 tab 页面可以看作是浏览器内核进程，然后这个进程是多线程的，它有几大类子线程

GUI 线程
JS 引擎线程
事件触发线程
定时器线程
网络请求线程

可以看到，里面的 JS 引擎是内核进程中的一个线程，这也是为什么常说 JS 引擎是单线程的

网络请求都是单独的线程

每次网络请求时都需要开辟单独的线程进行，譬如如果 URL 解析到 http 协议，就会新建一个网络线程去处理资源下载

因此浏览器会根据解析出得协议，开辟一个网络线程，前往请求资源（这里，暂时理解为是浏览器内核开辟的）

开启网络线程到发出一个完整的 http 请求

这一部分主要内容包括：dns 查询，tcp/ip 请求构建，五层因特网协议栈等等

DNS 查询得到 IP

DNS，Domain Name System/域名系统，一个面向互联网的将域名和 IP 地址相互映射的一个分布式数据库。是一个树状结构的记录、映射域名和 IP 地址的分布式系统。DNS 查询使用 UDP 协议。

为啥需要 DNS 呢，因为终端间的数据交互是通过 IP 地址来定位目标的，IP 地址如 192.168.8.8。由于人类对无规律的 IP 地址不容易记忆，因此一般使用域名地址来代替 IP 地址进行搜索使用，但实际上终端间的访问最终还是通过域名地址映射获取 IP 地址来访问的。

用户习惯使用域名地址来访问终端，当浏览器发出请求后，操作系统会使用 DNS 来查询域名地址对应的 IP 地址是什么，查询成功后操作系统会通过 IP 地址来访问终端来获取资源。

域名 DNS 名称服务器查询都是从根部.按照从右往左顺序原则进行的。

通常情况下，主机向本地名称服务器的查询一般都是采用递归查询，而本地名称服务器向 DNS(一级、二级、三级...)名称服务器采用迭代查询。

如果输入的是域名，以 www.google.com 为例，需要进行 DNS 解析成 IP，大致流程（迭代查询）：

DNS 客户端 向所配置的本地名称服务器 dns.google.com 发出解析 www.google.com 域名的 DNS 请求报文。
本地名称服务器收到请求后，先查询本地缓存。假设没有查到该域名对应记录，则本地名称服务器向所配置的根名称服务器 a.rootserver.net 发出解析请求解析www.google.com 域名的 DNS 请求报文(相当于对本地名称服务器说:“请给我 www.google.com 所对应的 IP 地址”)。
根名称服务器收到客户端的 DNS 查询请求报文后，通过查询得到.com 顶级域名所对应的顶级名称服务器，然后向本地名称服务器返回一条应答报文(相当说“我不知道www.google.com 域名所对应的 IP 地址，但我现在告诉你 .com 域名所对应的顶级名称服务器地址”)。
本地名称服务器在收到根名称服务器的 DNS 应答报文，得到.com 顶级域名所对应的顶级名称服务器地址后，再次向对应的顶级名称服务器发送一条请求解析 www.google.com 域名的 DNS 请求报文。
.com顶级名称服务器在收到 DNS 请求报文后，先查询自己的缓存，假设也没有该域名的记录项，则查询 google.com 所对应的二级名称服务器，然后也向本地名称服务返回一条 DNS 应答报文(相当于对本地名称服务器说:“我不知道 www.google.com 域名所对应的 IP 地址，但我现在告诉你 google.com 域名所对应的二级名称服务器地址”。
本地名称服务器在收到 .com 顶级名称服务器的 DNS 应答报文，得到google.com 二级域名所对应的二级名称服务器地址后，再次向对应的二级名称服务器发送一条请求解析 www.google.com 域名的 DNS 请求报文。
google.com 二级名称服务器在收到 DNS 请求报文后，也先查询自己的缓存，假设也没有该域名的记录项，则查询 www.google.com 所对应的权威名称服务器，然后也向本地名称服务器返回一条 DNS 应答报文(相当于本地名称服务器说：“我不知道 www.google.com 域名所对应的 IP 地址，但我现在告诉你 www.google.com 域名所对应的权威名称服务器地址”)。
本地名称服务器在收到 google.com 二级名称服务器的 DNS 应答报文，得到 www.google.com 三级域名所对应的权威名称服务器地址后，再次向对应的权威名称服务器发送一条请求解析 www.google.com 域名的 DNS 请求报文。
www.google.com权威名称服务器在收到 DNS 请求后，在它的 DNS 区域数据库中查找，最终得出了www.google.com 域名所对应的 IP 地址。然后向本地名称服务器返回到条 DNS 应答报文(相当于对本地名称服务器说：“www.google.com 域名的 IP 地址为 xxx.xxx.xxx.xxx”)。
本地名称服务器在收到权威名称服务器的应答报文后，向 DNS 客户端返回一条 DNS 应答报文，告诉 DNS 客户端所得到的www.google.com 域名的 IP 地址。这样 DNS 客户端就可以正常访问这个网站了。

以上流程，需要知道 dns 解析是很耗时的，因此如果解析域名过多，会让首屏加载变得过慢，可以考虑 dns-prefetch 优化（DNS 预获取，尝试在请求资源之前解析域名）

<!-- dns预加载 -->
<link rel="dns-prefetch" href="//node1.baidu.com" />
<link rel="dns-prefetch" href="//node2.baidu.com" />

参考连接

https://juejin.cn/post/7042956796020916261

tcp/ip 请求

http 的本质就是tcp/ip请求

需要了解 3 次握手规则建立连接以及断开连接时的四次挥手

tcp 将 http 长报文划分为短报文（tcp 通常将数据分成长度为 MSS 的若干段），通过三次握手与服务端建立连接，进行可靠传输

MSS（Maxitum Segment Size）最大分段大小的缩写，MSS 就是 tcp 数据包每次能够传输的最大数据分段，通讯双方会根据双方提供的 MSS 值的最小值确定为这次连接的最大 MSS 值。

三次握手

三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送 3 个包。

第一次握手([SYN], Seq = x)

客户端发送一个 SYN 标记的包，Seq 初始序列号 x，发送完成后客户端进入SYN_SEND状态。

第二次握手([SYN,ACK], Seq = y, ACK = x + 1)

服务器返回确认包(ACK)应答，同时还要发送一个 SYN 包回去。ACK = x + 1,表示确认收到(客户端发来的 Seq 值 + 1)，Seq = y, 表示让客户端确认是否能收到。发送完成后服务端进入SYN_RCVD（received 缩写，收到）状态。

第三次握手([ACK], ACK = y + 1)

客户端再次发送确认包(ACK),ACK = y + 1, 表示确认收到服务器的包（服务端发来的 Seq 值 + 1）。客户端发送完毕后，进入ESTABLISHED（建立了）状态，服务端接收到这个包，也进入ESTABLISHED状态, TCP 握手结束。

换一种抽象派的方式解释：

（1）客户端：hello，你是 server 么？

（2）服务端：hello，我是 server，你是 client 么?

（3）客户端：yes，我是 client

四次挥手

建立连接成功后，接下来就正式传输数据

然后，待到断开连接时，需要进行四次挥手（因为是全双工的，所以需要四次挥手）

TCP 连接的断开需要发送四个包，所以称为四次挥手。

第一次挥手（[FIN], Seq = x）

客户端发送一个 FIN 标记的包，告诉服务器需要关闭连接，表示自己不用发送数据了，但是还可以接收数据。发送完成后，客户端进入 FIN_WAIT_1 状态。

第二次挥手 ([ACK], ACK = x + 1)

服务端发送一个 ACK 的确认包，告诉客户端接收到关闭的请求，但是还没有准备好。发送完成后，服务端进入 CLOSE_WAIT 状态，客户端收到这个包后，进入 FIN_WAIT_2，等待服务器关闭连接。

第三次挥手 ([FIN], Seq = y)

服务端准备好关闭连接时，发送 FIN 标记的包，告诉客户端准备关闭了。发送完成后，服务端进入 LAST_ACK 状态，等待客户端确认。

第四次挥手 ([ACK], ACK = y + 1)

客户端接收到服务端的关闭请求，再发送 ACK 标记的确认包，进入 TIME_WAIT 状态，等待服务端可能请求重传的 ACK 包。

服务端接收到 ACK 包后，关闭连接，进入 CLOSED 状态。

客户端在等待固定时间(两个最大段生命周期)后，没有接收到服务的 ACK 包，认为服务器已关闭连接，自己也关闭连接，进入 CLOSED 状态。

同样换一种抽象派的方式解释：

（1）主动方：我已经关闭了向你那边的主动通道了，只能被动接收了

（2）被动方：收到通道关闭的信息

（3）被动方：那我也告诉你，我这边向你的主动通道也关闭了

（3）主动方：最后收到数据，之后双方无法通信

为什么要"三次握手，四次挥手"

三次握手

换个易于理解的视角来看为什么要 3 次握手。

客户端和服务端通信前要进行连接，“3 次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

每次都是接收到数据包的一方可以得到一些结论，发送的一方其实没有任何头绪。我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？

而从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是由于第一次的“请求”触发，因此每次握手其实是可以得到额外的结论的。比如第三次握手时，服务端收到数据包，表明看服务端只能得到客户端的发送能力、服务端的接收能力是正常的，但是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了，并且作出了响应，从而得到额外的结论：客户端的接收、服务端的发送是正常的。

四次挥手

TCP 连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个 ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个 FIN 段来关闭此方向上的连接。接收方发送 ACK 确认关闭连接。注意，接收到 FIN 报文的一方只能回复一个 ACK, 它是无法马上返回对方一个 FIN 报文段的，因为结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我无法了解“上层的意志”。

参考链接

https://zhuanlan.zhihu.com/p/53374516
https://www.jianshu.com/p/12790cea57ac

tcp/ip 的并发限制

HTTP 1.x 标准下，浏览器对同一域名下并发的 tcp 连接是有限制的（2-10 个不等，Chrome 为 6 个），因此有些网站对于一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。

在 HTTP/1 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量（Chrome 下一般是限制六个连接），当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

在 HTTP/2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

并发限制，队头阻塞（Head of line blocking）

当一个网页的图片资源在同一个域名情况下加载，如图，30 个图片总用时【1.11s】

同样的运行环境，同样的资源在多个域名（同一个 ip）情况下加载，如图，30 个图片总用时【424ms】

参考链接：

https://juejin.cn/post/6844904035628089357

五层因特网协议栈

其实这个概念挺难记全的，记不全没关系，但是要有一个整体概念

其实就是一个概念： 从客户端发出 http 请求到服务器接收，中间会经过一系列的流程。

简括就是：

从应用层的发送 http 请求，到传输层通过三次握手建立 tcp/ip 连接，再到网络层的 ip 寻址，再到数据链路层的封装成帧，最后到物理层的利用物理介质传输。

当然，服务端的接收就是反过来的步骤

五层因特网协议栈其实就是：

1.应用层(dns,http) DNS解析成IP并发送http请求

2.传输层(tcp,udp) 建立tcp连接（三次握手）

3.网络层(IP,ARP) IP寻址

4.数据链路层(PPP) 封装成帧

5.物理层(利用物理介质传输比特流) 物理传输（然后传输的时候通过双绞线，电磁波等各种介质）

当然，其实也有一个完整的 OSI 七层框架，与之相比，多了会话层、表示层。

OSI 七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

表示层：主要处理两个通信系统中交换信息的表示方式，包括数据格式交换，数据加密与解密，数据压缩与终端类型转换等

会话层：它具体管理不同用户和进程之间的对话，如控制登陆和注销过程

从服务器接收到请求到对应后台接收到请求

服务端在接收到请求时，内部会进行很多的处理

这里由于不是专业的后端分析，所以只是简单的介绍下，不深入

负载均衡

对于大型的项目，由于并发访问量很大，所以往往一台服务器是吃不消的，所以一般会有若干台服务器组成一个集群，然后配合反向代理实现负载均衡

当然了，负载均衡不止这一种实现方式，这里不深入…

简单的说：

用户发起的请求都指向调度服务器（反向代理服务器，譬如安装了 nginx 控制负载均衡），然后调度服务器根据实际的调度算法，分配不同的请求给对应集群中的服务器执行，然后调度器等待实际服务器的 HTTP 响应，并将它反馈给用户

后台的处理

一般后台都是部署到容器中的，所以一般为：

先是容器接受到请求（如 tomcat 容器）
然后对应容器中的后台程序接收到请求（如 java 程序）
然后就是后台会有自己的统一处理，处理完后响应响应结果

概括下：

一般有的后端是有统一的验证的，如安全拦截，跨域验证
如果这一步不符合规则，就直接返回了相应的 http 报文（如拒绝请求等）
然后当验证通过后，才会进入实际的后台代码，此时是程序接收到请求，然后执行（譬如查询数据库，大量计算等等）
等程序执行完毕后，就会返回一个 http 响应包（一般这一步也会经过多层封装）
然后就是将这个包从后端发送到前端，完成交互

后台和前台的 http 交互

前后端交互时，http 报文作为信息的载体, 所以 http 是一块很重要的内容。

http 报文结构

报文一般包括了：通用头部，请求/响应头部，请求/响应体

通用头部

Request URL: https://xxx.cn/tkproperty/nprd/N20210033/ 请求的web服务器地址
Request Method: GET （请求方式：Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）
Status Code: 200  请求的返回状态码
Remote Address: 10.161.163.16:443 请求的远程服务器地址（会转为IP）

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。以及几种 Additional Request Methods：PUT、DELETE、LINK、UNLINK

HTTP1.1 定义了八种请求方法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

200——表明该请求被成功地完成，所请求的资源发送回客户端
301——永久性重定向，表示资源已被分配了新的 URL
304——自从上次请求后，请求的网页未修改过，请客户端使用本地缓存
400——客户端请求有错（譬如可以是安全模块拦截）
401——请求未经授权
403——禁止访问（譬如可以是未登录时禁止）
404——资源未找到
500——服务器内部错误
503——服务不可用
...

再列举下大致不同范围状态的意义

1xx——指示信息，表示请求已接收，继续处理
2xx——成功，表示请求已被成功接收、理解、接受
3xx——重定向，要完成请求必须进行更进一步的操作
4xx——客户端错误，请求有语法错误或请求无法实现
5xx——服务器端错误，服务器未能实现合法的请求

请求/响应头部

常用的请求头部（部分）：

Accept: 接收类型，表示浏览器支持的MIME类型 （text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8））
（对标服务端返回的Content-Type）
Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收
Content-Type：客户端发送出去实体内容的类型
Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache
If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中
Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间
Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中
If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中
Cookie: 有cookie并且同域访问时会自动带上 (utm_source、RequestId 等)
Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive
Host：请求的服务器URL，如 xxx.cn
Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私
Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段)
User-Agent：用户客户端的一些必要信息，如UA头部等 （Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1）

常用的响应头部（部分）：

Access-Control-Allow-Headers: 服务器端允许的请求Headers
Access-Control-Allow-Methods: 服务器端允许的请求方法
Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*）
Content-Encoding: Type：客户端返回出去实体内容的类型，如gzip
Content-Type：服务端返回的实体内容的类型
Date：数据从服务器发送的时间
Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档
Last-Modified：请求资源的最后修改时间
Expires：应该在什么时候认为文档已经过期,从而不再缓存它
Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag：请求变量的实体标签的当前值
Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38）
Server：服务器的一些相关信息

如下图是对某请求的 http 报文结构的简要分析

get/post

get: 可缓存、请求长度受限、会被历史保存记录，无副作用(不修改资源)，幂等(请求次数与资源无关)的场景
post: 安全一点、大数据、更多编码类型

两者详细对比如下图:

post 请求的编码格式

POST 提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。实际上，开发者完全可以自己决定消息主体的格式，只要最后发送的 HTTP 请求满足上面的格式就可以。服务端通常是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。

application/x-www-form-urlencoded

这是最常见的 POST 提交数据的方式了，浏览器的原生 <form> 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。其提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。

<form action="http://localhost:8888/task/" method="POST">
  First name: <input type="text" name="firstName" value="Mickey&" /><br />
  Last name: <input type="text" name="lastName" value="Mouse " /><br />
  <input type="submit" value="提交" />
</form>

application/form-data

这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让

表单的 enctype 等于 multipart/form-data。直接来看一个请求示例：

<form
  action="http://localhost:8888/task/"
  method="POST"
  enctype="multipart/form-data"
>
  First name: <input type="text" name="firstName" value="Mickey&" /><br />
  Last name: <input type="text" name="lastName" value="Mouse " /><br />
  <input type="submit" value="提交" />
</form>

可以看出 multipart/form-data 不会对参数编码，使用的 boundary(分割线)，相当于&，boundary 的值是----Web\*\*AJv3

application/json

application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。

function addUserXhr(sendData) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.onreadystatechange = () => {
      if (xhr.readyState == 4 && xhr.status == 200) {
        const res = JSON.parse(xhr.responseText);
        if (res.code === 0) {
          resolve(res.data);
        }
      }
    };
    xhr.open('POST', '/api/users/add', true);
    xhr.setRequestHeader('Content-Type', 'application/json');
    xhr.send(sendData);
  });
}

// 需要转成字符串后，再发送请求
const sendData = JSON.stringify({ username: '你好', age: 2, password: 'qww' });
addUserXhr(sendData);

cookie 交互

cookie 是浏览器的一种本地存储方式，一般用来帮助客户端和服务端通信的，常用来进行身份校验，结合服务端的 session 使用。

场景如下（简述）：

在登陆页面，用户登陆了

此时，服务端会生成一个session，session中有对于用户的信息（如用户名、密码等）

然后会有一个sessionid（相当于是服务端的这个session对应的key）

然后服务端在登录页面中写入cookie，值就是:jsessionid=xxx

然后浏览器本地就有这个cookie了，以后访问同域名下的页面时，自动带上cookie，自动检验，在有效时间内无需二次登陆。

上述就是 cookie 的常用场景简述（当然了，实际情况下得考虑更多因素）

一般来说，cookie 是不允许存放敏感信息的（千万不要明文存储用户名、密码），因为非常不安全，如果一定要强行存储，首先，一定要在 cookie 中设置httponly（这样就无法通过 js 操作了），另外可以考虑 rsa 等非对称加密（因为实际上，浏览器本地也是容易被攻克的，并不安全）

另外，由于在同域名的资源请求时，浏览器会默认带上本地的 cookie，针对这种情况，在某些场景下是需要优化的。

关于 cookie 的交互，可以看下图总结

gzip 压缩

首先，明确gzip是一种压缩格式，需要浏览器支持才有效（不过一般现在浏览器都支持），而且 gzip 压缩效率很好（高达 70%左右）

然后 gzip 一般是由apache、tomcat等 web 服务器开启

当然服务器除了 gzip 外，也还会有其它压缩格式（如 deflate，没有 gzip 高效，且不流行）

所以一般只需要在服务器上开启了 gzip 压缩，然后之后的请求就都是基于 gzip 压缩格式的，非常方便。

长连接与短连接

首先看tcp/ip层面的定义：

长连接：一个 tcp/ip 连接上可以连续发送多个数据包，在 tcp 连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（类似于心跳包）
短连接：通信双方有数据交互时，就建立一个 tcp 连接，数据发送完成后，则断开此 tcp 连接（连接 -> 传输数据 -> 断开连接）

然后在 http 层面：

http1.0中，默认使用的是短连接，也就是说，浏览器每进行一次 http 操作，就建立一次连接，任务结束就中断连接，譬如每一个静态资源请求时都是一个单独的连接，
- 无法复用链接，完成即断开，重新慢启动和 TCP 3 次握手
- head of line blocking: 线头阻塞，导致请求之间互相影响
http1.1 起，默认使用长连接，使用长连接会有这一行Connection: keep-alive，在长连接的情况下，当一个网页打开完成后，客户端和服务端之间用于传输 http 的 tcp 连接不会关闭，如果客户端再次访问这个服务器的页面，会继续使用这一条已经建立的连接
- host 字段指定对应的虚拟站点
- 新增功能:
  - 断点续传
  - 身份认证
  - 状态管理
  - cache 缓存
    - Cache-Control
    - Expires
    - Last-Modified
    - Etag

注意： keep-alive 不会永远保持，它有一个持续时间，一般在服务器中配置（如 apache），另外长连接需要客户端和服务器都支持时才有效

http 2.0

http 2.0 不是 https，它相当于是 http 的下一代规范（譬如 https 的请求可以是 http2.0 规范的）

然后简述下 http2.0 与 http1.1 的显著不同点：

http 2.0 把所有请求和响应的消息采用二进制格式封装而非 http1.1 的纯文本格式，显著提高传输灵活性
http 1.1 支持长连接和请求的流水线（Pipeling 管道）处理，在一个 tcp 连接上可以传送多个 http 请求和响应，减少了建立和关闭连接的消耗和延迟。
http 2.0 中，一个 tcp/ip 请求可以请求多个资源，也就是说，只要一次 tcp/ip 请求，就可以请求若干个资源，分割成更小的帧请求，速度明显提升。
http 2.0 使用报头压缩，降低开销
http 2.0 让服务器可以将响应主动推送给客户端

队头阻塞（Head of line blocking）由于 tcp/ip 本身有并发数限制（浏览器限制了同一个域名下的请求数量，Chrome 下一般是限制六个连接），当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

所以，如果 http 2.0 全面应用，很多 http1.1 中的优化方案就无需用到了（譬如打包成精灵图，静态资源多域名拆分等）

然后简述下 http 2.0 的一些特性：

多路复用（即一个 tcp/ip 连接可以请求多个资源）
首部压缩（http header 编码压缩，减少体积）
二进制分帧（在应用层跟传送层之间增加了一个二进制分帧层，改进传输性能，实现低延迟和高吞吐量）
服务器端推送（服务端可以对客户端的一个请求发出多个响应，可以主动通知客户端）
请求优先级（如果流被赋予了优先级，它就会基于这个优先级来处理，由服务器对请求的响应设置优先级权重，决定需要多少资源来处理该请求。）

扩展链接

关于队头阻塞（Head-of-Line blocking），看这一篇就足够了

websocket

TODO:

https

https 就是较为安全的 http，譬如一些支付等操作基本都是基于 https 的，因为 http 请求的安全系数太低了。

简单来看，https 与 http 的区别就是： 在请求前，会建立 ssl 链接，确保接下来的通信都是加密的，无法被轻易截取分析

一般来说，如果要将网站升级成 https，需要后端支持（后端需要申请证书等），然后 https 的开销也比 http 要大（因为需要额外建立安全链接以及加密等），所以一般来说 http2.0 配合 https 的体验更佳（因为 http2.0 更快了）

一般来说，主要关注的就是 SSL/TLS 的握手流程，开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手。

在 TLS 中使用了两种加密技术，分别为：对称加密和非对称加密。

对称加密：

对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。

这种加密方式固然很好，但是问题就在于如何让双方知道秘钥。因为传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。

非对称加密：

有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。

这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。

简单流程如下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个秘钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。

假定客户端叫做爱丽丝，服务器叫做鲍勃，整个握手过程分成五步：

第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。

第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。

第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。

第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

http 缓存

强缓存与弱缓存

缓存可以简单的划分成两种类型：强缓存（200 from cache）与协商缓存（304）

区别简述如下：

强缓存（200 from cache）时，浏览器如果判断本地缓存未过期，就直接使用，无需发起 http 请求
协商缓存（304）时，浏览器再次请求时会向服务端发起 http 请求（携带上次服务端返回的文件信息，时间或文件指纹），然后服务端告诉浏览器文件未改变，让浏览器使用本地缓存，这种情况下网络请求对应的状态码是 304（如下图）

协商缓存依赖于服务端与浏览器之间的通信，对于协商缓存，使用Ctrl + F5 强制刷新可以使得缓存无效（因为会刷新变成首次请求服务器，不会带有协商缓存的标识）

但是对于强缓存，在未过期时，必须更新资源路径才能发起新的请求（更改了路径相当于是另一个资源了，这也是前端工程化中常用到的技巧）

缓存控制发展

首先明确，http 的发展是从 http1.0 到 http1.1

而在 http1.1 中，出了一些新内容，弥补了 http1.0 的不足。

http1.0 中的缓存控制：

Expires

过去我们一直使用 Expires 来实现强缓存：当服务器返回响应时，在 Response Headers 中将过期时间写入 Expires 字段（服务器端时间）。例如：

从上图我们可以看到 Expires 是一个时间戳，接下来如果我们试图再次向服务器请求资源，浏览器就会先对比本地时间和 expires 的时间戳，如果本地时间小于 expires 设定的过期时间，就直接从缓存中获取这个资源。

到这里聪明的你可能已经发现了下面这个问题：由于 expires 的时间戳是服务器定义的，而本地时间的取值来自客户端，因此 expires 的工作机制对于客户端时间和服务器时间的一致性要求极高，如果两者的时间存在时差，会带来意料之外的结果。

由于上面的原因，加上 expires 是 http1.0 的产物，现在实现强缓存大多数是使用 http 1.1 的 Cache-Control。

If-Modified-Since/Last-Modified

Last-Modified（Response Header）和 If-Modified-Since（Request Header）是一对报文头，属于 HTTP1.0。

Last-Modified 表示资源的最后修改时间，是一个时间戳，如果启用了协商缓存，它会在客户端首次请求时随着 Response Headers 返回。

Last-Modified: Sat, 09 May 2020 09:33:56 GMT

If-Modified-Since 是一个请求首部字段，并且只能用在 GET 或 HEAD 请求中。客户端再次请求服务器时，请求头会包含这个字段，后面跟着在缓存中获取的资源的最后修改时间。

If-Modified-Since: Sat, 09 May 2020 09:33:56 GMT

服务端收到请求发现此请求头中有 If-Modified-Since 字段，会与被请求资源的最后修改时间进行对比，如果一致则会返回 304 和响应报文头，浏览器从缓存中获取数据即可。从字面上看，就是说从某个时间节点开始看，是否被修改了，如果被修改了，就返回整个数据和 200 OK，如果没有被修改，服务端只要返回响应头报文，304 Not Modified，Response Headers 不会再添加 Last-Modified 字段。

使用 Last-Modified 是有一定缺陷的：

如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为 If-Modified-Since 只能检查到以秒为最小计量单位的时间差。
如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。
我们编辑了文件，但文件的内容没有改变。服务端并不清楚我们是否真正改变了文件，它仍然通过最后编辑时间进行判断。因此这个资源在再次被请求时，会被当做新资源，进而引发一次完整的响应——不该重新请求的时候，也会重新请求。

为了解决上面服务器没有正确感知文件变化的问题，http 1.1 中的 Etag 作为 Last-Modified 的补充出现了。

http1.1 中的缓存控制：

Cache-Control

Cache-Control 是 HTTP1.1 提出的特性，为了弥补Expires缺陷提出的，提供了更精确细致的缓存功能。

Cache-Control 包含的值很多：

public：表明响应可以被任何对象（包括：发送请求的客户端、代理服务器等等）缓存。
private：表明响应只能被客户端缓存。
no-cache：跳过强缓存，直接进入协商缓存阶段。
no-store：表示当前请求资源禁用缓存
max-age=：设置缓存存储的最大周期，超过这个时间缓存被认为过期（单位秒）
s-maxage=：覆盖 max-age 或者 Expires 头。如果 s-maxage 未过期，则向代理服务器请求其缓存内容。

这里需要注意的是：s-maxage 仅在代理服务器中生效，客户端只需要考虑 max-age。

下面我们来看个例子：

从上面的例子我们可以看到，HTTP 响应报文中同时有 Cache-Control和Expires两个字段，由于Cache-Control优先级较高，那么直接根据 Cache-Control 的值进行缓存，也就是说在 315360000 秒内重新发起该请求，会直接使用缓存结果，强制缓存生效。

在 HTTP1.1 标准试图将缓存相关配置收敛进 Cache-Control 这样的大背景下， max-age 可以视作是对 expires 能力的补位/替换。在当下的前端实践里，我们普遍会倾向于使用 max-age。但如果你的应用对向下兼容有强诉求，那么 expires 仍然是不可缺少的。

If-None-Match/E-tag

Etag 和 If-None-Match 是一对报文头，属于 HTTP1.1。

Etag 是一个响应首部字段，是根据实体内容生成的一段 hash 字符串，标识资源的状态，由服务端产生。

ETag: W/"324023994867772d0dd9fac01f1420bd"

If-None-Match 是一个条件式的请求首部，如果客户端请求资源时在请求首部加上这个字段，值为之前服务器返回的 Etag，则当且仅当服务器上没有任务资源的 Etag 属性值与这个值相符，服务器才会返回带有请求资源实体的 200 响应，否正服务器会返回不带实体的 304 响应。

If-None-Match: W/"324023994867772d0dd9fac01f1420bd"

Etag 的生成过程需要服务器额外付出开销，会影响服务端的性能，这是它的弊端。因此启用 Etag 需要我们审时度势。正如我们刚刚所提到的：Etag 并不能替代 Last-Modified，它只能作为 Last-Modified 的补充和强化存在。 Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。

Max-Age VS Expires

Expires使用的是服务器端的时间

但是有时候会有这样一种情况-客户端时间和服务端不同步

那这样，可能就会出问题了，造成了浏览器本地的缓存无用或者一直无法过期

所以一般 http1.1 后不推荐使用Expires

而Max-Age使用的是客户端本地时间的计算，因此不会有这个问题

因此推荐使用Max-Age。

注意，如果同时启用了Cache-Control与Expires，Cache-Control优先级高。

E-tag VS Last-Modified

Last-Modified：

表明服务端的文件最后何时改变的
它有一个缺陷就是只能精确到 1s，
然后还有一个问题就是有的服务端的文件会周期性的改变，导致缓存失效

而E-tag：

是一种指纹机制，代表文件相关指纹
只有文件变才会变，也只要文件变就会变，
也没有精确时间的限制，只要文件一变，立马 E-tag 就不一样了

注意，如果同时带有E-tag和Last-Modified，服务端会优先检查E-tag。

完整的缓存规则

但是如何设置一个可靠的缓存规则，需要根据实际需求决定，绝大部分需求的缓存规则都可以根据 Chrome 官方提供的流程图来进行设置。

我们一起来看上面这张流程图：

如果资源不可复用，直接为 Cache-Control 设置 no-store，拒绝一切形式的缓存；
如果资源可复用，考虑是否每次都需要向服务器进行缓存确认，如果是，设置 Cache-Control 的值为 no-cache；
如果不需要每次都向服务器确认，考虑资源是否可以被代理服务器缓存，根据其结果决定是设置为 private 还是 public；
接下来考虑资源的过期时间，设置对应的 max-age；
最后，配置协商缓存需要用到的 Etag、Last-Modified 等参数。

后续根据这个流程，我们就可以设计出可靠的缓存规则了。

参考链接

https://zhuanlan.zhihu.com/p/342774826

Mar 20 '22 13:03 yanyue404

blog blog copied to clipboard

从输入URL到页面加载的过程（上）

前言

参考

大纲

从浏览器接收 url 到开启网络请求线程

多进程的浏览器

多线程的浏览器内核

网络请求都是单独的线程

开启网络线程到发出一个完整的 http 请求

DNS 查询得到 IP

tcp/ip 请求

五层因特网协议栈

从服务器接收到请求到对应后台接收到请求

负载均衡

后台的处理

后台和前台的 http 交互

http 报文结构

cookie 交互

gzip 压缩

长连接与短连接

http 2.0

websocket

https

http 缓存

强缓存与弱缓存

缓存控制发展

blog
blog copied to clipboard