文章目录
一、解析URL
1. 合法性
-
如果输入的 URL 中的协议或者主机名不合法,将会把地址栏中输入的内容传递给搜索引擎。
-
如果没有问题,浏览器会检查 URL 中是否出现了非法字符,如果存在非法字符,则对非法字符进行转义后再进行下一过程。
2. 解析
- 首先会对 URL 进行解析,分析所需要使用的协议版本和请求的资源的路径。
二、缓存判断
- 浏览器会判断所请求的资源是否在缓存里。
- 如果请求的资源在缓存里并且没有过期,那么就直接使用,否则向服务器发起新的请求。
- 这里可以使用的是强制缓存,协商缓存也需要在建立连接后发出http请求。
三、DNS域名解析
1. 原因
- 这一步首先需要获取的是输入的 URL 中的域名的 IP 地址。(IP用来判断是否在同一个子网络)
- 网络层会将本机地址作为源地址,获取目标服务器的 IP 地址作为目的地址。
2. 过程
先查看缓存
- 先查看本地缓存(host文件) ,再查看本地DNS服务器缓存。
如果没有,就需要访问多个服务器(根域名服务器、顶级域名服务器、权威域名服务器),获取到IP
- 本地DNS服务器 ⇒ 根域名服务器 = 顶级域名服务器
- 本地DNS服务器 ⇒ 顶级域名服务器 ⇒ 权威域名服务器
- 本地DNS服务器 ⇒ 权威域名服务器 = IP(返回给用户)
四、获取MAC地址
1. 原因
- 当浏览器得到 IP 地址后,还需要知道目的主机 MAC 地址。
- 因为应用层下发数据给传输层,TCP 协议会指定源端口号和目的端口号,然后下发给网络层。网络层会将本机IP地址作为源地址,获取的 IP 地址作为目的地址。
- 然后将下发给数据链路层,数据链路层的发送需要加入通信双方的 MAC 地址,本机的 MAC 地址作为源 MAC 地址,目的 MAC 地址需要分情况处理。
2. 过程
- 查看缓存:先查看本地的ARP缓存表,检查是否有IP与MAC地址的映射,如果有直接获取MAC地址。
- 是否同一个子网络:通过将 IP 地址与本机的子网掩码相比,可以判断是否与请求主机在同一个子网里,
- 在同一个子网里,可以使用 APR 协议获取到目的主机的 MAC 地址,
- 不在一个子网里,那么请求应该转发给网关,由它代为转发,此时同样可以通过 ARP 协议来获取网关的 MAC 地址,此时目的主机的 MAC 地址应该为网关的地址。
五、TCP三次握手
1. 目的
- 同步序列号,需要两边都需要发送自己的初始序列号,还需要进行应答。
- 比如:客户端发送一个初始序列号x,服务端回应一个x+1进行确认应答。服务端同样也会发送初始序列号,客户端进行确认应答。
2. 回答为什么三次握手
同步序列号(目的)
- TCP 三次握手的建立连接的过程就是相互确认初始序号的过程,告诉对方,什么样序号的报文段能够被正确接收。
- 第三次握手的作用是客户端对服务器端的初始序号的确认。
如果只有两次
- 只要服务端发出确认,就建立新的连接了。
- 那么服务器就没有办法知道自己的序号是否已被确认。
- 如果第二次握手时的数据包丢失,那么客户端会重新建立连接,而服务器保留了无效连接。如果建立过多无效连接会造成资源浪费。
六、HTTPS握手
1. 原因
如果使用的是 HTTPS 协议,在通信前还存在 TLS 的四次握手过程。
2. TLS
主要涉及:公钥私钥、密钥、数字证书、数字签名
非对称加密
这种算法加密和解密的密码不一样,一个是公钥,另一个是私钥。
- 公钥和私钥成对出现
- 公开的密钥叫公钥,只有自己知道的叫私钥
- 用公钥加密的数据只有对应的私钥可以解密
- 用私钥加密的数据只有对应的公钥可以解密
- 如果可以用公钥解密,则必然是对应的私钥加的密
- 如果可以用私钥解密,则必然是对应的公钥加的密
公钥和私钥是相对的,两者本身并没有规定哪一个必须是公钥或私钥。
(1) 客户端向服务器端索要并验证公钥。
(2) 客户端用公钥加密数据,服务端用私钥解密。
对称加密+非对称加密
非对称加密计算量大,怎么减少计算时间?
- 每一次对话(session),客户端和服务器端都生成一个"对话密钥"(session key),用它来加密信息。
- 由于"对话密钥"是对称加密,所以运算速度非常快。
- 而服务器公钥只用于加密"对话密钥"本身,这样就减少了加密运算的消耗时间。
数字证书保证是目标服务器。(证明身份)
- 将公钥放在数字证书中。只要数字证书是可信的,公钥就是可信的。
数字签名保证数字证书没有被篡改。
- 数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要,再用CA的私钥加密,最终组成数字签名。
- 当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要,然后用CA的公钥对数字签名解密,得到CA创建的消息摘要,两者一比较,就知道中间有没有被⼈篡改了。
七、返回数据
- 当页面请求发送到服务器端后,服务器端会返回一个
html
文件作为响应。 - 浏览器接收到响应后,开始对
html
文件进行解析,开始页面的渲染过程。
八、页面渲染
1. 渲染树
- 首先解析
html
文件和CSS
文件构建渲染树。 - 如果遇到
script
标签,则判端是否含有defer
或者async
属性。- 如果没有这两个属性, JS的加载和执行会造成页面的渲染的阻塞。
defer
属性:立即下载,但是脚本延迟到整个页面都解析完毕后再执行async
属性:立即下载,下载完成后,停止页面解析,先执行脚本
2. 布局
- 当浏览器生成渲染树以后,就会根据渲染树来进行布局。
- 这一阶段浏览器要做的事情是要弄清楚各个节点在页面中的确切位置和大小。通常这一行为也被称为“自动重排”。
- (回流指的是这个阶段)
3. 绘制
- 布局完成后,最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。
- (重绘指的是这个阶段)
九、TCP四次挥手
1. 目的
- 若客户端认为数据发送完成,则它需要向服务端发送连接释放请求。
2. 为什么四次
- 挥手跟握手的报文信息区别在于把SYN改为FIN,同样一个SYN或FIN需要一个ACK,但是SYN和ACK可以合并,但是FIN和ACK只能分开。也就是请求和应答分开。
- 如果像握手一样,服务端FIN和ACK一起发送,那么就只需要三次挥手。
- 但是,客户端数据发送完的时候,服务端可能还有数据需要发送,所以不能FIN和ACK一起发送,只能先发送ACK释放客户端到服务端的连接。等到服务端数据发送完了,再发送FIN报文,释放服务端到客户端的连接。
3. 为什么等待2MSL
-
最长报文寿命:
MSL=2min
-
2MSL
足够所有报文过期,也就是4min
(1)确保数据接收(为什么不能立刻关闭)
-
确保第四次挥手能被客户端接收。
-
假如客户端立刻关闭连接,这时候第四次挥手失败,服务端就永远无法知道客户端是否收到了断开连接的请求。所以客户端需要保持等待状态。
-
如果客户端没有立刻关闭,当第四次挥手报文段丢失,服务端就会超时重传第三次挥手时请求,客户端就会重新给服务端发送第四次挥手的报文。
(2)保证老连接的数据消失(为什么是2MSL)
-
如果客户端直接关闭连接,然后又再次向服务器发起一个新连接,新发起的连接和刚关闭的连接两者的端口号可能是相同的。如果这时候老连接的一些数据还滞留在网络中,这些滞留数据在新连接建立后才到达服务器。就会对新数据造成混乱。
-
等待2MSL时间后,老连接中的数据都在网络中消失了。
4. 长连接
http1.1
协议以后默认开启TCP长连接,就是一个TCP连接可以发送多次http请求。