从页面请求到渲染过程的细节

1.浏览器请求页面到渲染页面的整个过程

 

1. 浏览器从URL中解析出服务器的主机名；
2. 通过域名系统（DNS）将主机名转换成服务器的IP地址；
3. 从URL中解析出端口号（如果没有，http的默认端口号是80，https是443），有了IP地址和端口号就能建立起一条TCP连接；
4. 浏览器向服务器发送一条HTTP请求报文；
5. 服务器向浏览器回送一条HTTP响应报文（请求的资源在报文主体中）；
6. 关闭连接，浏览器开始渲染页面；
7. 浏览器将HTML文档解析为DOM树；
8. 将CSS文件解析成StyleSheet对象；
9. 为每个DOM节点附加(attach)样式，构建渲染树；
10. 布局（或重排）——遍历文档元素，计算每个节点在屏幕的位置；
11. 绘制（或重绘）——遍历渲染树，将每个节点绘制到屏幕上，页面渲染成功。

 

2.域名的解析过程

 

假定域名为m.xyz.com的主机想要访问y.abc.com，流程如下：

1. 主机m.xyz.com首先向本地域名服务器dns.xyz.com查询。若本地域名服务器不知道所查询域名的IP地址，那么本地域名服务器将以DNS客户的身份向其他根域名服务器继续发出查询请求报文（代替主机），而不是主机自己进行下一步的查询操作（称为递归查询）；
   
2. 根域名服务器并不直接把待查询的域名直接转换成IP地址（根域名服务器也没有存放这种信息），而是告诉本地域名服务器下一步应对向哪一个顶级域名服务器查询，也即告诉本地域名服务器下一次应查询的顶级域名服务器dns.com的IP地址；（注意，这里是让本地域名服务器去执行查询，而没有像前面那样，根域名服务器代替本地域名服务器去进行下一步查询，这称为迭代查询）
3. 有了这个IP地址，本地域名服务器就向该顶级域名服务器dns.com进行查询。若顶级域名服务器有y.abc.com的IP地址，则直接返回IP地址；若没有，则告诉本地域名服务器下一步应查询的权限域名服务器dns.abc.com的IP地址；（迭代查询）
4. 本地域名服务器向权限域名服务器dnx.abc.com进行查询，权限域名服务器返回所查询域名y.abc.com的IP地址；
5. 本地域名服务器将最后结果告诉主机。

 

3.TCP连接的三次握手和四次挥手

TCP三次握手建立连接

1. 最初，客户端A和服务器端B都处于 CLOSED(关闭) 状态。由服务器端B先进入 LISTEN(收听) 状态，等待客户端的连接；
2. 第一次握手：客户端A向服务器端B发出连接请求报文段，首部的同步位 SYN=1，同时选择一个初始序列 seq=x，这时客户端A进入 SYN-SENT(同步已发送) 状态；
3. 第二次握手：服务器端B收到连接请求报文段后，如同意连接则向A发送确认。确认报文段中，SYN=1，ACK=1，确认号 ack=x+1，同时为自己选择一个初始序列 seq=y，服务器端B进入 SYN-RCVD(同步收到) 状态；
4. 第三次握手：客户端A收到来自服务器端B的确认后，需要再次发送确认报文段，ACK=1，确认号 ack=y+1，序号seq=x+1。客户端A进入 ESTABLISHED(已建立连接) 状态；
5. 当服务器端B收到来自A的确认报文段时，也进入 ESTABLISHED 状态，此时可以进行数据传输。

 

三次挥手中，为什么A最后还要发送一次确认？（为什么要使用三次挥手？）

　　目的是防止已失效的连接请求报文由发送到了B，使得B误以为A发出了新的连接请求，从而向A发送确认。假设不使用三次握手，那么在B看来这里有两条TCP连接在进行，但在A看来自己并没有发出新的连接请求，故不会向新的连接传输数据，而B的第二条TCP连接则一直在等待A传输数据，造成资源浪费；

　　所谓的“已失效的连接请求”，指的是A发出的第一个连接请求报文段并没有丢失，但在某些网络节点中滞留了，此时A会进行超时重传第二个连接请求报文段。然而，过了段时间后，滞留的第一个报文段也到达了B。

　　若采用三次握手，B收到失效报文段时会发出第二次确认，但A不会对这次确认进行确认，那么B就收不到“来自A的属于失效报文段的确认的确认”，这时B就知道A没有要求新的连接请求。

 

 TCP四次挥手释放连接

1. 第一次挥手：数据传输结束后，双方仍处于 ESTABLISHED 状态。由客户端A先发出连接释放报文段，停止传输数据并主动关闭TCP连接（服务器端B也可以先释放）。连接释放报文段中，FIN=1，seq=u（等于A前面已传输数据的最后一个字节的序号加1）。这时，A进入 FIN-WAIT-1(终止等待1) 状态；
2. 第二次挥手：服务器端B收到连接释放报文段后发出确认，ACK=1，ack=u+1，seq=v（等于B前面已传输数据的最后一个字节的序号加1）。这时B进人 CLOSE-WAIT(关闭等待) 状态，由A->B这个方向的连接就释放了，但B->A方向还未关闭，故B要传输数据时A仍可接收；
3. 客户端A收到B的确认后，进人 FIN-WAIT-2(终止等待2) 状态，等待服务器端B发出连接释放报文段；
4. 第三次挥手：若B已经没有要向A发送的数据，则B向A发出连接释放报文段，FIN=1，ACK=1，seq=w，ack=u+1（需要重复上次已发送的确认号），这时B进人LAST-ACK(最后确认)状态；
5. 第四次挥手：客户端A收到B的连接释放报文段后发出确认，ACK=1，ack=w+1，seq=u+1。这时客户端进人 TIME-WAIT(时间等待) 状态，经过计时器设定的 2MSL（MSL称为最长报文段寿命）后进人 CLOSED 状态，而服务器端B收到确认后也进入CLOSED 状态。

 

为什么A在TIME-WAIT状态必须等待2MSL？

• 为了保证A发送的最后一个确认报文段能够到达B。因为确认报文段可能丢失，使得处于LAST-ACK 状态下的B收不到对FIN+ACK报文段的确认而重传FIN+ACK报文段，那么A就能在2MSL时间内收到这个重传的FIN+ACK报文段，重发一次确认，使得A和B都能进入 CLOSED 状态。如果A在TIME-WAIT状态中不等待，而是直接进人CLOSED状态，那么A就收不到B重传的FIN+ACK报文段，B也就无法收到A的确认，从而导致B无法进入CLOSED状态；
• 防止已失效的连接请求报文段。因为A发送完最后一个确认报文段后，在等待的2MSL时间内，本连接产生的所有报文段都会到达寿命，使下一次连接中不会出现旧的连接请求报文段。

标签：服务器端,渲染,报文,确认,细节,域名,服务器,连接,页面
来源： https://www.cnblogs.com/evil-shark/p/16140861.html