从输入URL到页面加载发生了什么

转载：https://zhuanlan.zhihu.com/p/78677852
https://blog.csdn.net/sinat_23880167/article/details/78882766

总过程为以下几个过程：
1、输入地址
2、DNS解析
3、TCP连接
4、发送http请求
5、返回http响应
6、浏览器解析渲染页面
7、断开连接。

一、输入地址：
当在浏览器中输入地址的时候，浏览器在历史记录、书签等地方，找到已经输入的字符串可能对应的url，然后给出智能提示，补全url地址
二、DNS解析：
DNS解析的过程是寻找哪台机器上有需要资源的过程。当在浏览器中输入一个地址的时候，不是（例如百度）该网站真正意义上的地址。互联网每一台计算机的唯一标识是IP，但IP不方便记忆，用户更喜欢用方便记忆的网址去寻找互联网上的计算机。所以设计者就在用户的方便性与可用性方便过一个权衡，就是讲url转换成IP地址。这就是DNS解析。
1、查找浏览器缓存：查看浏览器的DNS缓存中是否有域名对应的IP地址
浏览器一般会缓存DNS记录一段时间，不同浏览器的时间不同，如果有缓存，则返回IP，否则进行下一步。
2、查找系统缓存：windows系统可查看本地硬盘中的hosts文件，查看其中有没有和这个域名对应的规则，如果有，就返回，否则进行下一步。
3、查找本地DNS：浏览器发送DNS请求到本地DNS服务器。本地DNS服务器查找它的缓存记录，有，就返回结果，此过程是递归过程。否则进行下一步
4、向DNS根服务器请求：本地DNS服务器向DNS根服务器（Root server域名服务器）发送查询请求，跟服务器没有记录具体的域名和IP地址对应关系，而是告诉本地DNS服务器，到域服务器上继续查询，并给出域服务器地址。这就是迭代的过程。
5、向域服务器请求。本地DNS服务器继续向域服务器发出请求（例如www。baidu.com）,此例中请求的对象是.com域服务器。.com域服务器收到请求后，不会反悔域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名解析服务器地址。
6、向域名解析服务器地址发出请求：此时能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询，可直接返回结果。

DNS在进行区域间传输的时候使用TCP协议，其他时候使用UDP协议
全球只有十三太逻辑根服务器
DNS查询的两种方式：

1、递归解析：

当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式，如图所示的是递归方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。
2、迭代解析：

当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析，如图所示。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。

三、TCP连接
通过ip寻址和arp协议，找到目标服务器地址，三次握手简历TCP连接
具体过程如下：
ip协议在第三层互联网层（网络层），arp协议在第四层网络访问层（链路层）。通过获取到的IP寻址找到IP对应的服务器，通过arp协议找到服务器的mac地址。

ip寻址的方式有两种，一种是同一网段，另一种是不同网段。判断两个IP地址是否在同一个网段下，将IP地址分别于子网掩码做运算，得到网络号，相同，在同一网段，不同在不同网段。

为什么有了ip之后还要mac地址？在最开始没有互联网的时候只有mac地址，不存在ip地址。后来互联网越来越大，发现mac地址找起来太麻烦，就发明了IP。但是一直没有分开

找到了目标IP并获得IP服务器的mac，浏览器会请求与服务器连接，进行TCP三次握手。
第一次握手：客户端将标志位SYN置为1,随机产生一个值为seq=J（J的取值范围为=1234567）的数据包到服务器，客户端进入SYN_SENT状态，等待服务端确认。简单说就是客户端给服务器发送syn，假设序列号是J。

第二次握手：服务端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务端进入SYN_RCVD状态。
简单来说就是服务端收到后，发送一个syn和ack给客户端，ack的序列号是j+1标识给syn的应答，新syn序列号是k

第三次握手：客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务端，服务端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，完成三次握手，随后客户端A与服务端B之间可以开始传输数据了。
简单说就是，客户端收到后，也回应ack 序列号是k+1标识收到了。
三次握手的目的是为了防止已经失效的连接请求报文段突然又传送到了服务端而产生错误。

三、HTTP请求
1、建立TCP连接后，发送一个http请求，等待响应。
浏览器会对请求进行包装，包装成请求报文，请求报文的格式如下：
起始行：GET/HTTP/1.0(请求的方法，请求的URL，请求所使用的的协议）
请求的方法包含get，post，put，delete，head，option，trace等
头部信息：User-Agent Host等成对出现的值
主体：请求头部和主体之间有一个回车换行。如果是get请求，则没有主体部分，post请求有主体部分

2、服务器处理请求
浏览器请求报文到达服务器之后，服务器接口会对请求报文进行处理，执行接口对应的代码，处理完后响应客户端。由于http是无状态的，正常情况下，客户端收到响应后就会直接断开连接，然后依次http事务就完成了。但是http1.0有个keep-alive的请求字段，可在一段时间内不断开连接。http1.1默认打开keep-alive的选项，导致服务器已经处理完了请求，客户端不会自己断开，导致服务端资源被占用。服务器需要自动主动断开连接，而主动断开连接的一方会出现time_wait，占用连接池，这就是产生syn flood攻击的原因

四、返回http响应
服务器接受并处理完请求，返回 HTTP 响应，一个响应报文格式基本等同于请求报文，由响应行、响应头、空行、实体组成。

需要关注一个报文头–accept。accept代表发送端（客户端）希望接受的数据类型，这是浏览器自动封装的请求头。如果服务器返回的content-type是accept中的任何一个，浏览器都能解析，并直接展示在网页上。如果服务器返回的content-type是其他类型，此时浏览器有三种处理状态：
1、正常显示。例如返回类型为text/javascript，浏览器能直接处理并展示。
2、下载。例如返回类型为application/octet-stream（二进制流，不知道下载文件类型），这种浏览器不能直接处理的，会被下载。
3、报错。当我们返回一个字符串hello world，却使用text/xml，格式时，浏览器不能正确解析，就会报错，并把报错信息呈现在网页中。

浏览器能直接处理很多种格式，并直接呈现在网页中，并不限于accept中规定的字段。
常用的响应报错：
200：请求成功，请求方法为get或post或head或者trace。

201：请求成功并创建一个资源，请求方法为post或put。

202：请求收到但未响应。

204：服务成功处理了请求但是不返回实体内容。

205：服务成功处理了请求但是不返回实体内容且要求请求者重置请求视图。

207：返回消息体为XML。

400：语义错误，服务器无法理解此次请求。无效请求，服务器还没接到该请求，由于前端封装的字段类型有误导致。

401：当前请求需要验证， 即需要类似Authorization 头信息。

403：服务理解请求但是拒绝执行。通常是无权限、黑名单、ip过于频繁访问等原因导致。

404：请求失败，请求资源找不到。类似于脚本未被定义.

405：请求方法不被接受，比如某个接口只能用post请求，但是用了get请求，则会报405。

407：当前请求需要验证，代理服务器必须以Proxy-Authorization 信息头验证。

408：请求超时。表示客户端取消了请求或未能发送一个完整的请求。

413：请求提交的实体数据过大。

414：uri请求过长，这种情况可将get请求改为post请求。
　　　　415：请求提交的实体格式不对，比如某个接口只支持XML，提交格式为JSON则会报错。

423：资源被锁定。

429：请求次数过多。

431：请求头字段过大。

451：非法资源。

500：服务器遇到了不知如何处理的情况。主要错误是服务器内部错误，主要为用户权限的问题导致，或者是数据库连接出现了错误。

501：服务器还是不具有请求功能的，而且是没有实施的，可以用来HttpWebRequest指定一个UserAgent来试试的，可以换电脑来测试一下，可以换不同类型浏览器测试。

502：网关错误。可能原因：链接超时、服务器请求链接过多导致服务器无法正常响应。

503：服务器正在维护或者暂停了，或者是cpu占用的频率大导致的。

504：请求超时，表示服务器一直在等请求响应回来但是等不到了。

505：http的版本是不受支持的，需升级浏览器。

507：服务器有内部配置错误

六、浏览器解析渲染页面：
浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

浏览器会根据相应的content-type字段对响应字符串进行解析。能够解析并成功解析就显示，能够解析但解析错误就报错，不能解析就下载。由于浏览器采用至上而下的方式解析，所以会先解析html，直到遇到外部样式和外部脚本。这时会阻塞浏览器的解析，外部样式和外部脚本（在没有async、defer属性下）会并行加载，但是外部样式会阻塞外部脚本的执行，dom加载完毕，js脚本执行成功后dom树构建完成（DOMContentLoaded），之后就加载dom中引用的图片等静态资源。
html解析->外部样式、脚本加载->外部样式执行->外部脚本执行->html继续解析->dom树构建完成->加载图片->页面加载完成

七、断开连接：

TCP四次挥手：

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
上述可理解成：
客户端：“兄弟，我这边没数据要传了，咱关闭连接吧。”
服务端：“收到，我看看我这边有木有数据了。”
服务端：“兄弟，我这边也没数据要传你了，咱可以关闭连接了。”
客户端：“好嘞。”