浏览器从输入url到页面加载完成发生了什么?

浏览器的地址输入URL并按下回车 可以分为以下步骤

1、解析URL，判断URL是否合法，然后浏览器查找当前的URL是否存在缓存，并比较缓存是否过期。

2、DNS解析URL对应的IP。

3、根据IP建立TCP连接。（三次握手）

4、HTTP发起请求。

5、服务器处理请求，浏览器接收HTTP响应。

6、渲染页面，构建DOM树。

7、关闭TCP连接。（四次挥手）

URL，统一资源定位符，用于定位互联网上的资源，我们俗称“网址”。

URL遵循以下的语法规则：scheme://host.domain:port/path/filename

scheme - 定义因特网服务的类型。常见的协议有 http、https、ftp、file，其中最常见的类型是 http，而 https 则是进行加密的网络传输。
host - 定义域主机（http 的默认主机是 www）。
domain - 定义因特网域名，比如 w3school.com.cn。
port - 定义主机上的端口号（http 的默认端口号是 80）。
path - 定义服务器上的路径（如果省略，则文档必须位于网站的根目录中）。
filename - 定义文档/资源的名。

1、 解析URL，查找当前URLDNS缓存记录，并比较缓存是否过期。

首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

像 / ? : 等这样的字符，已经被url当做特殊意义理解了， 因此这些字符不能随意出现。
比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义。

转义的规则：将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式。

HSTS 是 HTTP 严格传输安全（HTTP Strict Transport Security） 的缩写。 这是一种网站用来声明他们只能使用安全连接（HTTPS）访问的方法。 如果一个网站声明了 HSTS 策略，浏览器必须拒绝所有的 HTTP 连接并阻止用户接受不安全的 SSL 证书。 目前大多数主流浏览器都支持 HSTS。

浏览器还会进行一些额外的操作，比如安全检查、访问限制等。

浏览器检查缓存：

 

2、DNS域名解析，得到对应IP。

假设输入的URL是包含域名的，那肯定会涉及到DNS解析。当然，如果URL仅仅是IP，那就不会涉及到DNS的。域名的出现是为了方便记忆，因为域名比IP好记。我们这里假设URL包含域名。DNS域名解析，采用的是递归查询的方式。

• 浏览器缓存：　　

        首先会在自己的浏览器缓存中查找是否有该域名对应的IP地址（若曾经访问过该域名且没有清空缓存便存在）；

• 系统缓存：

        当浏览器缓存中无域名对应IP则会自动检查用户计算机系统Hosts文件DNS缓存是否有该域名对应IP；但是这种操作系统级别的域名解析规程也被很多黑客利用，通过修改你的hosts文件里的内容把特定的域名解析到他指定的ip地址上，造成所谓的域名劫持。所以在windows7中将hosts文件设置成了readonly，防止被恶意篡改。

• 路由器缓存：

        当浏览器及系统缓存中均找不到时则进入路由器缓存中检查，以上三步均为客服端的DNS缓存；

• ISP（互联网服务提供商）DNS缓存：

        当在用户客服端查找不到域名对应IP地址，则将进入ISP DNS缓存中进行查询。比如你用的是电信的网络，则会进入电信的DNS缓存服务器中进行查找；

• 根域名服务器

        当以上均未完成，则进入根服务器进行查询。全球仅有13台根域名服务器，1个主根域名服务器，其余12为辅根域名服务器。根域名收到请求后会查看区域文件记录，若无则将其管辖范围内顶级域名（如.com）服务器IP告诉本地DNS服务器；

• 顶级域名服务器

        顶级域名服务器收到请求后查看区域文件记录，若无则将其管辖范围内主域名服务器的IP地址告诉本地DNS服务器；

• 主域名服务器

        主域名服务器接受到请求后查询自己的缓存，如果没有则进入下一级域名服务器进行查找，并重复该步骤直至找到正确纪录；

• 保存结果至缓存

        本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时将该结果反馈给客户端，客户端通过这个IP地址与web服务器

最后再将找到的ip返回给用户，并将其缓存在本地，方便下次使用，而且，需要知道DNS的解析时很耗时的，因此，如果解析域名过多的话，会让首屏加载速度变得很慢（一个优化首批速度的点），可以考虑一下dns-prefetch优化

3.根据IP建立TCP连接。（三次握手）

TCP是可靠的面向链接的协议
所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。在 socket 编程中，客户端执行 connect() 时。将触发三次握手。

第一次握手 客户端发送一个 TCP 的 SYN=1(synchronous建立联机)的包，指明客户端打算连接的服务器的端口，随机产生seq number=1234567的数据包到服务器，发送完毕后，客户端进入 SYN_SEND 状态。

第二次握手：服务器收到请求后要确认联机信息，向A发送syn=1，ack=1(acknowledgement 确认)，ack number=(主机A的seq+1)，随机产生seq=7654321的包；发送完毕后服务器端进入 SYN_RCVD 状态 

第三次握手客户端收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
客户端发送完毕后，会进入 ESTABLISHED 状态，当服务器端接收到这个包确认后，也进入 ESTABLISHED状态，TCP 握手结束。

为什么不能用两次握手进行连接？
        3次握手完成了两个重要的功能，既要双方做好发送数据的准备工作，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

      如果把三次握手改成仅需要两次握手，死锁是可能发生的。如下图所示，如果计算机Client和Server之间的通信，假定Client给Server发送一个连接请求分组，Server收到了这个分组，并发送了确认应答分组。按照两次握手的协定，Server认为连接已经成功地建立了，可以开始发送数据分组。可是，Client在Server的应答分组在传输中被丢失的情况下，将不知道Server是否已准备好，不知道Server建立什么样的序列号，Client甚至怀疑Server是否收到自己的连接请求分组。在这种情况下，Client认为连接还未建立成功，将忽略Server发来的任何数据分组，Client只等待连接确认应答分组。而Server在发出的数据分组超时后，重复发送同样的数据分组。这样就形成了死锁。     

另外三次握手可以防止已失效的连接请求报文段突然又传到了Server，因而产生错误。假定出现一种异常情况，即Client发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达Server，本来这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后，就误认为是Client又发出一次 新的连接请求，于是就向Client发出确认报文段，同意建立连接。假定不采用三次握手，那么只要Server发出确认，新的连接就建立了，这样一直等待Client发来数据，Server的许多资源就这样白白浪费了。

TCP/IP的分层管理
        TCP/IP协议族包含了很多协议，按层次分有四层：应用层、传输层、网络层、数据链路层。

应用层：包含了各种通用的应用服务，比如 FTP（File Transfer Protocol，文件传输协议）、DNS、HTTP等。
传输层：提供网络中两台计算机之间的数据传输，比如TCP、UDP。
网络层：处理在网络上流动的数据包，该层规定了传输路线，数据包通过怎样的路径传送到对方的计算机中。比如 IP。
数据链路层：连接网络的硬件部分，包括网卡，光纤等等硬件设备

4.建立链接后发起HTTP请求。

 完整的HTTP请求包含请求起始行、请求头部、请求主体三部分  

标题

 

5、服务器响应HTTP请求，浏览器得到响应。

服务器在收到浏览器发送的HTTP请求之后，会将收到的HTTP报文封装成HTTP的Request对象，并通过不同的Web服务器进行处理，处理完的结果以HTTP的Response对象返回，主要包括状态码，响应头，响应报文三个部分。

状态码主要包括以下部分

1xx：指示信息–表示请求已接收，继续处理。

2xx：成功–表示请求已被成功接收、理解、接受。

3xx：重定向–要完成请求必须进行更进一步的操作。

4xx：客户端错误–请求有语法错误或请求无法实现。

5xx：服务器端错误–服务器未能实现合法的请求。

响应头主要由Cache-Control、 Connection、Date、Pragma等组成。

响应体为服务器返回给浏览器的信息，主要由HTML，css，js，图片文件组成。

 

6、浏览器解析HTML代码，页面渲染。

解析下载js、css、图片

1.解析html标签创建DOM树
2.解析css创建CSSOM树
3.将DOM和CSSOM合并生成reander树
4.布局reader树，计算各个节点的位置与大小
5.渲染，呈现页面

 

在这一过程中可能会触发页面的重绘或重排。这里就涉及了两个重要概念：Reflow和Repaint。

Reflow，也称作Layout，中文叫回流，一般意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树，这个过程称为Reflow。

Repaint，重绘，意味着元素发生的改变只是影响了元素的一些外观之类的时候（例如，背景色，边框颜色，文字颜色等）

重绘回流的代价是会导致卡慢，不过浏览器有自己的优化，它会维护一个队列，把所有引发重绘回流的操作都放入这个队列中，等队列到了一定的数量或者是到了一定的时间，浏览器会flush队列，进行一次批处理，这样子就会让多次的重绘回流，变成一次重绘回流了

优化：

• 直接改变className
• display：none 先将元素设置为display：none，然后再对元素进行操作，然后操作完成后再将元素设置为display：block，这样子就只触发两次重绘和回流
• 使用replaceChild 直接替换需要改变的dom，只粗发一次重绘回流
• 将需要多次回流的元素设置为position:absolute/fixed 使其脱离文档流
• createDocumentFragment，创建一个虚拟节点，集中一次性添加

 7、服务器关闭TCP链接。

 TCP四次挥手关闭TCP链接

第一次挥手(FIN=1，seq=x)：假设客户端想要关闭连接，客户端发送一个 FIN=1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。发送完毕后，客户端进入 FIN_WAIT_1 状态。(第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧)

第二次挥手(ACK=1，ACKnum=x+1)：服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。 发送完毕后，服务器端进入 CLOSE_WAIT
状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。(第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧)

第三次挥手(FIN=1，seq=y)： 服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。 发送完毕后，服务器端进入LAST_ACK 状态，等待来自客户端的最后一个ACK。 (第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧)

第四次挥手(ACK=1，ACKnum=y+1)：客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。 客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入CLOSED 状态。(第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧)

为什么连接时是三次握手却是四次挥手？
        建立连接时：当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

        关闭连接时：当Server端收到FIN报文后，TCP在系统内核实现时，自动响应的ACK；再次发送FIN是应用程序手动的调用close()来关闭连接。程序在关闭连接前，可能需要执行释放资源等前置操作，所以两次不能进行合并，在断开连接的时候就需要四次挥手。