从输入链接到浏览器呈现页面的过程中,浏览器所经历的过程。
首先浏览器将输入的链接进行DNS
解析,也就是将域名转换为IP
地址的过程,得到了服务器具体的IP
地址,才可以进行TCP
链接以及数据的传输。
具体DNS
解析的过程,浏览器首先检查自身的DNS
缓存是否对于此域名有IP
地址,chrome
对于域名解析的缓存时间为60s
,可以通过地址栏输入chrome://net-internals/#dns
清除DNS
缓存。若浏览器解析缓存未命中,则到操作系统中hosts
文件检查域名与IP
对应关系。若hosts
文件未命中,则向本地域名服务器请求解析,本地域名服务器一般是运营商ISP
提供的,一般是通过53
端口发送UDP
报文请求服务器解析DNS
。若本地服务器解析未命中则会有两种解析方案:迭代解析与递归解析,一般来说,主机向本地域名服务器的查询一般都是采用递归查询,本地域名服务器向根域名服务器的查询通常是采用迭代查询,依次向根域名服务器、顶级域名服务器、主域名服务器等一级一级查询查询直到查询到IP
地址。
HTTP
协议是使用TCP
协议作为其传输层协议的,在拿到服务器的IP
地址后,客户端浏览器会与服务器建立TCP
连接,该过程包括三次握手。
client server
主动打开 → SYN=1,seq=x → 被动打开,接收
(同步已发送) (同步收到)
接收 ← SYN=1,ACK=1,seq=y,ack=x+1 ← 发送
(已建立链接) (同步收到)
发送 → ACK=1,seq=x+1,ack=y+1 → 接收
(已建立链接) (已建立链接)
- 第一次握手:客户端主动链接服务器,发送初始序列号
seq=x
与SYN=1
同步请求标志,并进入同步已发送SYN_SENT
状态,等待服务器确认。 - 第二次握手:服务端收到消息后发送确认标志
ACK=1
与同步请求标志SYN=1
,发送自己的序列号seq=y
以及客户端确认序号ack=x+1
,此时服务器进入同步收到SYN_RECV
状态。 - 第三次握手:客户端收到消息后发送确认标志
ACK=1
,发送自己的序列号seq=x+1
与服务器确认号ack=y+1
,发送过后即确认链接已建立状态ESTABLISHED
,服务端接收确认信息后进入链接已建立状态ESTABLISHED
。
SSL
的建立是为了HTTPS
加密传输,HTTPS
在HTTP
的基础下加入SSL
层,HTTPS
的安全基础是SSL
,因此加密的详细内容就需要SSL
。
- 首先
TCP
三次握手建立链接,这是数据传输基础,在此之上开始SSL
。 - 客户端首先发送
Client Hello
开始SSL
通信,报文中包含客户端支持的SSL
版本、随机值Random1
、加密算法以及密钥长度等。 - 服务器发送
Server Hello
,和客户端一样,在报文中包含SSL
版本、随机值Random2
以及加密组件,此后服务端将证书也发送到客户端。 - 此时客户端需要对服务端发送的证书进行验证,通过操作系统内置的
CA
证书,将服务器发送的证书的数字签名进行解密,并将证书的公钥进行相同算法的HASH
与解密的数字签名解密的内容进行对比,验证证书是否合法有效,是否被劫持更换。 - 客户端验证证书合法,然后生成一个随机值
Random3
,用公钥对Random3
进行加密,生成Pre-Master Key
,客户端以Client Key Exchange
报文将Pre-Master Key
发送到服务端,此后发送Change Cipher Spec
报文表示此后数据传输进行加密传输。 - 服务端将
Pre-Master Key
用自己的私钥解密为Random3
,服务端发送Change Cipher Spec
报文表示此后数据传输进行加密传输。 - 此时客户端与服务端都拥有三个随机字符串,且
Random3
是密文传输的,是安全状态的,此时则可以使用这三个字符串进行对称加密传输。由于非对称加密慢,不能每次传输数据都进行非对称加密,所以使用非对称加密将密钥协商好然后使用对称加密进行数据传输。 - 此时便正常进行
HTTP
数据传输,但是由于SSL
加密的作用,此时的HTTP
传输便是安全的,此为HTTPS
的传输过程,其中2
、3
、5
、6
也被称为SSL
四次握手。
浏览器构建HTTP
请求报文,并通过TCP
协议传送到服务器的指定端口,HTTP
请求报文一共有三个部分,报文首部,通常包含请求行与各种请求头字段等;空行,告诉服务器请求头部到此为止),报文主体,即发送的数据信息,通常并不一定要有报文主体。
<!-- 报文首部 -->
GET / HTTP/1.1 <!-- 请求行 -->
accept: text/html
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
... <!-- 请求头 -->
<!-- 空行 -->
<!-- 报文主体 -->
u=1&t=1587699008
服务端响应HTTP
请求,返回响应报文,HTTP
响应报文由四部分组成:响应行、响应头、空行、响应体。
HTTP/1.1 200 OK <!-- 响应行 -->
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Fri, 24 Apr 2020 03:34:50 GMT
... <!-- 响应头 -->
<!-- 空行 -->
<!-- 响应体 -->
{"status":1, "msg": "success"}
- 自上而下,首先解析
HTML
标签,生成DOM Tree
- 在解析到
<link>
或者<style>
标签时,开始解析CSS
,生成CSSOM
,值的注意的是此时解析HTML
标签与解析CSS
是并行执行的 - 当遇到
<script>
标签后,浏览器会立即开始解析脚本,并停止解析文档,因为脚本有可能会改动DOM
与CSS
,继续解析会浪费资源,所以应当将<script>
标签放于<body></body>
后 - 当
DOM Tree
与CSSOM
生成后,将两者结合进行布局,计算它们的大小位置等布局信息,形成一个能够表示这所有信息的内部表示模型,可称为渲染树render tree
- 根据计算好的信息绘制整个页面,系统会遍历渲染树,并调用
paint
方法,将内容显示在屏幕上。
client server
主动关闭 → FIN=1,seq=u → 被动关闭,接收
(终止等待1) (关闭等待)
接收 ← ACK=1,seq=v,ack=u+1 ← 发送
(终止等待2) (关闭等待)
接收 ← FIN=1,ACK=1,seq=w,ack=u+1 ← 发送
(时间等待) (最后确认)
发送 → ACK=1,seq=u+1,ack=w+1 → 接收
(时间等待 2MSL 关闭) (关闭)
- 第一次挥手:客户端发出释放标识
FIN=1
,自己的序列号seq=u
,进入终止等待FIN-WAIT-1
状态 - 第二次挥手:服务端收到消息后发出
ACK=1
确认标志和客户端的确认号ack=u+1
,自己的序列号seq=v
,进入关闭等待CLOSE-WAIT
状态,客户端收到消息后进入终止等待FIN-WAIT-2
状态 - 第三次挥手:服务器发送释放标识
FIN=1
信号,确认标志ACK=1
,确认序号ack=u+1
,自己的序列号seq=w
,服务器进入最后确认LAST-ACK
状态 - 第四次挥手:客户端收到回复后,发送确认标志
ACK=1
,确认序号ack=w+1
,自己的序列号seq=u+1
,客户端进入时间等待TIME-WAIT
状态,经过2
个最长报文段寿命后,客户端CLOSE
。服务器收到确认后,立刻进入CLOSE
状态。
TCP三次握手四次挥手 https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/TCP%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B.md
HTTP协议概述 https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/HTTP%E5%8D%8F%E8%AE%AE%E6%A6%82%E8%BF%B0.md
HTTPS加密传输过程 https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/HTTPS%E5%8A%A0%E5%AF%86%E4%BC%A0%E8%BE%93%E8%BF%87%E7%A8%8B.md
浏览器渲染与内核 https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/%E6%B5%8F%E8%A7%88%E5%99%A8%E6%B8%B2%E6%9F%93%E4%B8%8E%E5%86%85%E6%A0%B8.md
对称加密与非对称加密 https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86%E4%B8%8E%E9%9D%9E%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86.md
https://www.jianshu.com/p/d616d887953a
https://www.cnblogs.com/lhh520/p/10232738.html
https://blog.csdn.net/bjweimengshu/article/details/78978314
https://blog.csdn.net/wlk2064819994/article/details/79756669
https://blog.csdn.net/weixin_40659167/article/details/86510745