标签：服务器端 渲染 报文 确认 细节 域名 服务器 连接 页面

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。