在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？

【这是一道百分之一百会问到的题目】
一般是以下几个过程，越详细越好

• DNS解析
• TCP连接
• 发送HTTP请求
• 服务器处理HTTP请求并返回报文
• 浏览器解析渲染页面
• 连接结束

---

具体过程

输入url之后，首先需要找到这个url域名的服务器的ip，使用DNS地址解析协议。寻找的路径依次是：浏览器缓存—本地系统缓存–网络服务提供商服务器–根DNS服务器

获取到ip地址后，浏览器根据ip以及端口号等，构造一个http请求。这个请求报文会包括这次请求的信息，主要是请求方法（GET/POST/HEAD等8种），请求说明和请求附带的数据，并将这个http请求封装在一个tcp包中，这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器。

找到服务器之后，开始通过TCP协议建立传输连接，tcp连接的建立需要三次握手：
第一次：浏览器发送syn=1，sql=x，请求链接
第二次： 服务器收到信息之后发送确认信息，向浏览器发送同步请求，syn=1，ack=x+1，seq=y；
第三次：浏览器收到服务器的确认信息后，需要再次确认是否收到服务器的确认信息，发送
ack=y+1,seq=z;

服务器解析这个请求来作出响应，返回相应的html给浏览器。http响应报文包括，响应行、响应头和响应主体。返回的http状态码有其对应的规则。
1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求。
然后断开TCP连接，TCP连接的断开需要四次挥手。

浏览器解析html结构。
（1）解析与构建DOM树
首先构建DOM树,在DOM树构建的过程中，由于浏览器自上而下进行解析，如果遇到js脚本和外部js连接，就会停止构建dom树来执行和下载相应的代码，这会造成阻塞。
（2）构建渲染树
之后浏览器根据外部样式、内部样式和内联样式构建一个CSS对象模型树，CSSOM树。构建完成以后和DOM树合并为渲染树（RenderTree），这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点还会涉及到CSS层叠的问题。
（3）布局和绘制
之后进行布局，布局主要是确定各个元素的位置和尺寸，之后是渲染页面。因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载。

更详细的解释：

• 构建DOM树：
  ①Tokenizing：根据HTML规范将字符流解析为标记  
  ②Lexing：词法分析将标记转换为对象并定义属性和规则  
  ③DOM construction：根据HTML标记关系将对象组成DOM树
• 构建CSSOM树：
  ①Tokenizing：字符流转换为标记流  
  ②Node：根据标记创建节点  
  ③CSSOM：节点创建CSSOM树
• 根据DOM树和CSSOM树构建渲染树：
  ①从DOM树的根节点遍历所有可见节点，不可见节点包括：
  script,meta这样本身不可见的标签。
  被css隐藏的节点，如display: none  
  ②对每一个可见节点，找到恰当的CSSOM规则并应用
  ③发布可视节点的内容和计算样式
• 对js的解析如下：
  ①浏览器创建Document对象并解析HTML，将解析到的元素和文本节点添加到文档中，此时document.readystate为loading  
  ②HTML解析器遇到没有async和defer的script时，将他们添加到文档中，然后执行行内或外部脚本。这些脚本会同步执行，并且在脚本下载和执行时解析器会暂停。这样就可以用document.write()把文本插入到输入流中。同步脚本经常简单定义函数和注册事件处理程序，他们可以遍历和操作script和他们之前的文档内容  
  ③当解析器遇到设置了async属性的script时，开始下载脚本并继续解析文档。脚本会在它下载完成后尽快执行，但是解析器不会停下来等它下载。异步脚本禁止使用document.write()，它们可以访问自己script和之前的文档元素  
  ④当文档完成解析，document.readState变成interactive  
  ⑤所有defer脚本会按照在文档出现的顺序执行，延迟脚本能访问完整文档树，禁止使用document.write()
  ⑥浏览器在Document对象上触发DOMContentLoaded事件  
  ⑦此时文档完全解析完成，浏览器可能还在等待如图片等内容加载，等这些内容完成载入并且所有异步脚本完成载入和执行，document.readState变为complete,window触发load事件

其中还需要注意和缓存相关的，比如缓存一般通过Cache-Control、Last-Modify、Expires等首部字段控制。 Cache-Control和Expires的区别在于Cache-Control使用相对时间，Expires使用的是基于服务器 端的绝对时间，因为存在时差问题，一般采用Cache-Control，在请求这些有设置了缓存的数据时，会先 查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次 响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验 Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304

补充：
TCP为什么需要三次握手？

有这样一种情况，当A发送一个消息给B，但是由于网络原因，消息被阻塞在了某个节点，然后阻塞的时间超出设定的时间，A会认为这个消息丢失了，然后重新发送消息。

当A和B通信完成后，这个被A认为失效的消息，到达了B
对于B而言，以为这是一个新的请求链接消息，就向A发送确认，
对于A而言，它认为没有给B再次发送消息（因为上次的通话已经结束）所有A不会理睬B的这个确认，但是B则会一直等待A的消息

这就导致了B的时间被浪费（对于服务器而言，CPU等资源是一种浪费）

为什么需要四次挥手？
因为是双方彼此都建立了连接，因此双方都要释放自己的连接，A向B发出一个释放连接请求，他要释放链接表明不再向B发送数据了，此时B收到了A发送的释放链接请求之后，给A发送一个确认，A不能再向B发送数据了，它处于FIN-WAIT-2的状态，但是此时B还可以向A进行数据的传送。此时B向A 发送一个断开连接的请求，A收到之后给B发送一个确认。此时B关闭连接。A也关闭连接。
为什么要有TIME-WAIT这个状态呢，这是因为有可能最后一次确认丢失，如果B此时继续向A发送一个我要断开连接的请求等待A发送确认，但此时A已经关闭连接了，那么B永远也关不掉了，所以我们要有TIME-WAIT这个状态

参考文献

https://blog.csdn.net/My__long/article/details/82823026
https://blog.csdn.net/MiemieWan/article/details/85708052
https://blog.csdn.net/yu876876/article/details/81560122