从URL输入到页面展现到底发生什么？（笔记）

从开发角度来说，总分为以下几个过程

1. 浏览器的地址栏输入URL并按下回车
2. DNS解析URL对应的IP
3. 根据IP建立TCP链接(三次握手)
4. HTTP发送请求
5. 服务器处理请求，浏览器接收HTTP响应
6. 渲染页面，构建DOM树
7. 关闭TCP(四次挥手)

一、输入网站并解析

1.URL主要由四个部分组成：协议、域名、端口、路径；
2.输入URL后浏览器会解析出协议、域名、端口、路径等信息，并构建一个HTTP请求
3.缓存

1. 浏览器请求前会根据请求头的expires和cache-control判断是否存在强缓存，如果存在直接从缓存中获取资源，并直接返回资源给浏览器进程；如果没有存在，进入下一步判断是否存在协议缓存
2. 不存在强缓存，浏览器会发送请求根据请求头中的If-Modified-Since和If-None-Match判断是否存在协议缓存，如果存在直接返回资源给浏览器进程；如果强缓存和协议缓存都不存在 那么直接进入网络请求流程

缓存

强缓存
强缓存不和服务器交互，请求时间为0ms
客户端设置请求头Cache-Control，只有为：’no-store’ | ‘no-cache’ |‘max-age=0’才会生效; no-cache意思是不走强缓存，走协商缓存；no-store意思是不使用缓存; ax-age=0 的意思是告知客户端响应从一开始就已经过时因此需要重新验证；
POST请求不能设置缓存，只有GET请求可以设置

协议缓存
总结：协议缓存第一次发送请求的时候 服务器会返回状态码200和资源数据以及标识； 当下次请求时会对比资源标识 如果一致返回304状态码不返回资源数据；如果不一致则返回状态码200以及新的资源数据和新的标识；

协议缓存第一次发送请求的时候 服务器返回的状态码为200 内容是请求的资源 同时有一个Last-Modified/ETag的属性标记此文件在服务期端最后被修改的时间

当客户端第二次请求此URL链接的时候 根据HTTP协议，浏览器会向服务器传送 If-Modified-Since 报头，询问改时间之后文件有没有被修改过；

如果服务器的资源没有变化 则时间一样，自动返回状态码304且不返回资源，这样就能减少传输的数据量

如果服务器资源发送了改变或者重新启动了服务器 时间不一致，返回200状态码返回资源，客户端接受到后，会丢弃旧文件把新文件缓存起来显示在浏览器中；

DNS 域名解析

在浏览器输入URl后，首先要经过域名解析；因为浏览器并不能直接通过URL找到对应的服务器，而是要通过域名；所以浏览器会向DNS服务器发送域名，DNS服务器查询到与域名相对于的IP地址，然后返回给浏览器，浏览器在将IP地址打在协议上，同时请求参数也会在协议搭建，然后一并发送给对应的服务器。

DNS域名解析分为递归查询和迭代查询两种方式，现在一般为迭代方式

递归查询
浏览器、操作系统、路由器、都会缓存一些URL对应的IP地址，统称为DNS高速缓存。这是为了加快DNS的解析速度，使得不必每次都到根域名服务器中去查询
所谓递归查询：就是客户端主机查询的域名地址无法在本地域名服务器中找到，因此本地域名服务器就以DNS客户端的身份向其他根域名服务器发起请求，进行查询，而不是让客户端主机去一直查询；
递归过程：主机→本地DNS服务器→其他服务器 （如：我想要吃奶油蛋糕，找到了小红蛋糕店，问小红有没有奶油蛋糕，小红说没有但是可以帮你找小明蛋糕店它可能会有，问完后小明还真有，然后小明把蛋糕给了小红，小红在把蛋糕给我，这就是递归查询）

迭代查询
本地DNS服务器向其他服务器进行查询，如果没有查到就会给一个没有查到的信息，并将下一个阶段的其他服务器地址告知本地DNS服务器，本地域名服务器接收到后会继续进行请求查询，直到找到IP地址或者找不到IP返回报错信息，然后信息返回给客户端主机；迭代查询只会帮你找到相关的服务器，然后说我现在比较忙，你自己去找吧。
迭代过程：本地DNS服务器→根服务器，本地DNS服务器→顶级域名服务器，本地DNS服务器→权限域名服务器；（如：我想吃奶油蛋糕，找到了小红蛋糕店，小红说我没有你去找小明蛋糕店它可能有，我又去小明蛋糕店，小明说我也没有 你可以去小非蛋糕店，找到了小菲终于找到了奶油蛋糕，这就是迭代查询的过程）

DNS负载均衡
DNS负载均衡起到的作用是，现在很多网站有多个服务器，当一个网站的访问量过大时，如果请求都在一个服务器上就会崩溃，这时就可以用负载均衡的技术，在应答DNS查询的时候，会返回不同的解析结构，也就是返回不同IP地址，从而进行分流到不同服务器。

DNS预解析
在有多个不同服务器资源的情况下，都可采取DNS预解析，提前解析，减少页面卡顿。

二、TCP/IP连接：三次握手

在客户端发送数据之前会发起 TCP 三次握手用以同步客户端和服务端的序列号和确认号，并交换 TCP 窗口大小信息。

第一次握手：客户端A发送位码为SYN＝1，随机产生一个值为seq=X(X的取值范围为=1234567)的数据包到服务器，服务端B由SYN=1知道，A要求建立联机；（第一次握手，由浏览器发起，告诉服务器我要发送请求了）

第二·次握手：服务端B收到请求后要确认联机信息，服务端B将标志位SYN和ACK都置为1，ack=X+1，随机产生一个值seq=Y，并将该数据包发送给客户端A以确认连接请求（第二次握手，由服务器发起，告诉浏览器我准备接受了，你赶紧发送吧）

第三次握手：：客户端A收到确认后，检查ack是否为X+1，ACK是否为1，如果正确，客户端A会在发送ack =(Y+1 注：服务端B的seq +1),服务端B检查ack是否为Y+1，ACK是否为1，如果正确则连接建立成功；（第三次握手，由浏览器发送，告诉服务器，我马上就发了，准备接受吧）

为什么需要三次握手
1.其实这是由TCP的自身特点可靠传输决定的
客户端和服务端要进行可靠传输，那么就需要确认双方的接收和发送能力。
第一次握手可以确认客服端的发送能力
第二次握手，服务端确认了发送能力和接受能力
第三次握手才可以确认客户端的接收能力
三次握手的主要目的是：为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误
其次三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据。

改成两次握手可以不？
三次握手可以理解为了客户端和服务器互相确认对方的发送和接收能力。如果是两次握手，可以确定服务器的发送和接收能力，但只能确定客户端的发送能力，无法确认其接收能力。另外，如果是两次握手的话，可能会因为网络阻塞等原因会发送多个请求报文，延时到达的请求又会与服务器建立连接，浪费服务器的资源。

三、 HTTP请求

TCP三次握手之后，开始发送HTTP请求报文至服务器

请求报文
HTTP请求报文由：请求行、请求头部、空行和请求数据四个部分组成。

响应报文
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

HTTP协议特点

1. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于 HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2. 灵活：HTTP允许传输任意类型的数据对象。
3. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
4. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

各协议与HTTP协议关系

1. DNS 服务：解析域名至对应的IP地址
2. TCP 协议：将请求报文按序号分割成多个报文段
3. IP 协议：搜索对方的地址，一边中转一边传送

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

服务器收到请求后会发出应答，即响应数据。HTTP响应与HTTP请求相似， HTTP响应报文格式：状态行+响应头+空行+消息体，状态行包括HTTP版本号、状态码、状态说明。

五、浏览器解析渲染页面

浏览器拿到响应文本后，解析HTML代码，请求js，css等资源，最后进行页面渲染，呈现给用户；
分为以下几个步骤：

1. 根据HTML文件解析出DOM树；
2. 根据CSS解析出 CSSOM 树(CSS规则树)
3. 将 DOM树和 CSSOM树合并，构建Render树(渲染树)
4. 根据Render树进行节点信息计算（Layout–重排,回流）
5. 根据计算好的信息绘制整个页面（Paint–重绘）

回流和重绘

重绘
当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility等），浏览器会将新样式赋予给元素并重新绘制它，这个过程称为重绘。

回流
当Render树中部分或全部元素的尺寸、结构、或某些属性发生改变时，浏览器重新渲染部分或全部文档的过程称为回流。
引起回流例如：1.页面首次渲染，2.浏览器窗口大小发生改变，3.元素尺寸或位置发生改变，4.元素字体大小变化等;
减少回流例如：1.避免设置多层内联样式，2.避免使用CSS表达式等；
回流必将引起重绘，而重绘不一定会引起回流。

六、断开连接：TCP 四次挥手

1. 刚开始双方都处于链接状态，假如是客户端先发起关闭请求
2. 第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态 (由浏览器告诉服务器，我请求报文发送完了，你准备关闭吧)
3. 第二次挥手：服务端收到FIN之后，会发送ACK报文，且把客户端的序列号值+1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态 (由服务器告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧)
4. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发送FIN报文，且指定一个序列号。此时服务端处于LAST_ACK的状态 (由服务器告诉浏览器，我响应报文发送完了，你准备关闭吧)
5. 客户端向服务端发送报文段，Ack、Seq；然后进入等待 TIME_WAIT 状态；被动方收到发起方的报文段以后关闭连接。发起方等待一定时间未收到回复，则正常关闭。(由浏览器告诉服务器，我响应报文接收完了，我准备关闭了，你也准备吧)

简单点说就是：
1、客户端→服务端：客户端告诉服务端：“我发完了”
2、服务端→客户端：服务端告诉客户端：“好的，我知道你发完了”
3、服务端→客户端：服务端告诉客户端：“我收完了”；
4、客户端→服务端：客户端告诉服务端：“好的，我知道你发完也收完了”