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

整理之前的笔记时，发现之前的掌握的东西尚差的太远，就仔细查询了这个问题。

总体来说，可以分为一下几个部分：
1. DNS解析
2. TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

DNS解析

DNS解析是将域名转换成IP的过程,从用户在浏览器地址栏输入url开始

• 第1步：查找浏览器缓存
  

  浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就将结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等。这个缓存时间太长和太短都不好，如果缓存时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有可能会有一部分用户无法访问网站。如果时间设置太短，会导致用户每次访问网站都要重新解析一次域名。

chrome查看浏览器dns缓存: chrome://net-internals/#dns

• 第2步：查找系统缓存

  如果用户的浏览器缓存中没有，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。读取操作系统里的hosts文件，这是很多翻墙推荐的最简单的方法，如果有软件恶意的修改了hosts文件，则会导致域名劫持。

• 第3步：查找路由器缓存

  如果系统缓存中也找不到，那么查询请求就会发向路由器，它一般会有自己的DNS缓存。

• 第4步：查找ISP DNS缓存

  网络配置有DNS服务器地址这一项，操作系统会把域名发送给这个服务器，通常是本地区的域名的服务器，80%的域名解析到这里就结束了，也会缓存对应的源码的IP地址。

• 第5步：递归搜索

  逐级查询各级域名服务器，直到找到对应的IP的地址.

4、5步借用网上的图片来说明：

关于dns的相关知识有:
1. 减少dns查询,各级缓存的使用，使用Keep-Alive特性来减少查询。
2. dns预解析:

• 可以通过用meta信息来告知浏览器, 我这页面要做DNS预解析
  <meta http-equiv="x-dns-prefetch-control" content="on" />
• 可以使用link标签来强制对DNS做预解析：
  <link rel="dns-prefetch" href="https://www.google.com/" />

TCP连接

HTTP协议是使用TCP作为其传输层协议的，当TCP出现瓶颈时，HTTP也会受到影响。

1. TCP3次握手
2. TCP4次挥手

TCP协议：TCP是主机对主机层的传输控制协议，提供可靠的连接服务。
简单的说一下5层网络协议：

• 物理层
• 链路层
• 网络层：IP
• 传输层：TCP/UDP
• 应用层：HTTP/Telnet/FTP
  在7层网络协议中，将上面的应用层划分为会话层，表示层，应用层，其中dns属于会话层。

关于TCP/UDP协议的区别，这应该属于网络的知识。
先简单说明一下TCP的标志位（位码），有6种表示：

SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)

常用的有：SYN，ACK，FIN。

各个状态的意义：

LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED -在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；

在我们分析3次握手和4次挥手的过程中，我们困惑的地方可能是因为我们不清楚发送的位码的意义和对应状。

TCP3次握手

1. 第1次握手：建立连接时，客户端A发送SYN包到服务器B，并进入SYN_SEND状态，等待服务器B确认。
2. 第2次握手：服务器B收到SYN包，必须确认客户A的SYN，同时自己也发送一个SYN包，即SYN+ACK包，此时服务器B进入SYN_RECV状态。
3. 第3次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

TCP4次挥手

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
客户端和服务器都可以发起挥手

1. 第1次挥手：客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
2. 第2次挥手：服务器B收到这个FIN，它发回一个ACK。
3. 第3次挥手：服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
4. 第4次挥手：客户端A发回ACK报文确认。

简单分析：
1. TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。
2. 每个方向都必须单独进行关闭。
3. 先关读，后关写。
4. 以服务器发起的关闭为例：

• 服务器读通道关闭
• 客户端写通道关闭
• 客户端读通道关闭
• 服务器写通道关闭

可以对应4次挥手分析，每次挥手关闭了哪个通道，就会清晰。这样我们可以对TCP协议在前端的应用有了清晰的理解。

发送HTTP请求

主要发生在客户端，是构造http请求报文并通过TCP发送到服务器指定的端口。
HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。
关于http请求头和响应头我会单独在写一篇博文的。

服务器处理请求并返回HTTP报文

服务器从接收到TCP报文开始，对http协议进行解析，并按照报文的格式进一步封装成HTTP request对象供上层使用。

http响应报文是由3部分组成的：状态码，响应报头，请求报头。
状态码取值说明：
1. 1xx：指示信息–表示请求已接收，继续处理。
2. 2xx：成功–表示请求已被成功接收、理解、接受。
3. 3xx：重定向–要完成请求必须进行更进一步的操作。
4. 4xx：客户端错误–请求有语法错误或请求无法实现。
5. 5xx：服务器端错误–服务器未能实现合法的请求。

要理解常见的状态码的含义，http缓存。

浏览器解析渲染页面

浏览器在收到HTML,CSS,JS文件后，它是如何把页面呈现到屏幕上的？下图对应的就是WebKit渲染的过程。

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

JS的解析是由浏览器中的JS解析引擎完成的。参见我的另一篇文章js线程

浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等。浏览器将重复1-6过程下载该资源。请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

请求结束

连接是否关闭，还要看Connection字段是否设置为长连接。

关于http报文，可以说的地方很多，要搞懂http缓存必须先懂这些，对报文的字段都要清晰的理解。请求是https时，有何差异，这些我会陆续更新https，http协议报文等博文意义说明，这是我前端知识体系化必走之路，我会对遇见的知识点，逐一写博客，demo，来理清他们。