第一步 URL解析

判断你输入的是的内容是否符合Url的格式，如果不符合的话按下回车会用默认的搜索引擎搜索
HSTS（是什么不知道
其他操作：比如安全检查、访问限制（之前国产浏览器限制 996.icu）。
检查缓存：

image.png

有缓存的话就会检查是否过期，没过期就读取缓存，返回缓存的（这里缓存里存的是什么？？
如果过期了，就携带相关表示向服务器请求，资源是否有更新，有更新的话返回更新的资源，没更新就返回304

第二步DNS查询

image.png

浏览器先检查是否在缓存中：
检查浏览器缓存
检查是否在本地HOSTS文件里
检查操作系统缓存
ISP DNS缓存（客户端电脑上设置的首选DNS服务器，大多数情况下都会有缓存
当上面的缓存里都没有，本地DNS服务器会把请求转发到互联网上的根域

image.png

问题来了，什么是DNS？

DNS（Domain Name System，域名系统），万维网上作为域名和IP地址相互映射的一个分布式数据库，能够使用bai户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。
IP地址太难记，因此，人们发明了域名(Domain Name)，域名可将一个IP地址关联到一组有意义的字符上去。用户访问一个网站的时候，既可以输入该网站的IP地址，也可以输入其域名，对访问而言，两者是等价的。例如：微软公司的Web服务器的IP地址是207.46.230.229，其对应的域名是www.microsoft.com，不管用户在浏览器中输入的是207.46.230.229还是www.microsoft.com，都可以访问其Web网站。

域名系统的名字空间是层次结构的，类似Windows的文件名。它可看作是一个树状结构，不同节点可以使用相同的标记。所有节点的标记只能由3类字符组成：26个英文字母(a～z)、10个阿拉伯数字(0～9)和英文连词号(-)，并且标记的长度不得超过22个字符。一个节点的域名是由从该节点到根的所有节点的标记连接组成的，中间以点分隔。
最上层节点的域名称为顶级域名(TLD，Top-Level Domain)，第二层节点的域名称为二级域名，依此类推。

早期因特网上仅有数百台主机，那时候的域名与IP地址对应只需简单地记录在一个hosts.txt文件中，这个文件由网络信息中心(NIC，Network Information Center)负责维护。任何想添加到因特网上的主机的管理员都应将其名字和地址E-mail给NIC，这个对应就会被手工加到hosts.txt文件中。每个主机管理员去NIC下载最新的hosts.txt文件放到自己的主机上，就完成了域名列表的更新。域名解析只是一个检查本机文件的本地过程。
随着因特网上主机数量的膨胀，原有的方式已经无法满足要求。现有域名系统于20世纪80年代开始投入使用。域名系统采用层次结构的名字空间，并且原来庞大的对应表被分解为不相交的、分布在因特网中的子表，这些子表称为资源文件。

回到正题 说说域名解析：
上面说到了域名系统名字空间的层次结构，下面来具体看一下这一结构是如何同域名系统的域名服务器(DNS，Domain Name Server)结合来实现域名解析的。
根据域名系统域名空间的层次结构将其按子树划分为不同的区域，每个区域可看作是负责层次结构中这一部分节点的可管理的权力实体。

例如，整个域的顶层区域由ICANN负责管理，一些国家域名及其下属的那些节点又构成了各自的区域，像.cn域就由CNNIC负责管理。而.cn域下又被划分为一些更小的区域，例如.fudan.edu.cn由复旦大学网络中心负责管理。

名服务器在接到用户发出的请求后查询自身的资源记录集合，返回用户想要得到的最终答案，或者当自身的资源记录集合中查不到所需要的答案时，返回指向另外一个域名服务器的指针，用户将继续向那个域名服务器发出请求。所以说，域名服务器不需要记录所有下属域名和主机的信息，对于其中的子域(如果存在)，只需要知道子域的域名服务器即可。

根域名服务器知道所有顶级域名的域名服务器，对应于每个顶级域名，它都有两条资源记录：一条是NS资源记录，域名字段是该顶级域名，值字段是该顶级域名解析的域名服务器的域名；另一条是A资源记录，用来指明该域名服务器的域名对应的IP地址。综合使用这两条记录，就可以知道对该域下的某个域名解析，应该继续去哪个IP地址的域名服务器寻找。第二层的域名服务器类似地存放各个第三层域名服务器的指针。第三层的域名服务器会出现A、CNAME、MX等类型的资源记录。每个域名服务器都有根域名服务器的地址记录。

最后，一个需要域名解析的用户先将该解析请求发往本地的域名服务器。如果本地的域名服务器能够解析，则直接得到结果，否则本地的域名服务器将向根域名服务器发送请求。依据根域名服务器返回的指针再查询下一层的域名服务器，依此类推，最后得到所要解析域名的IP地址。
拿到IP地址后 就可以正式的发送网络请求啦~
值得注意的是，浏览器提供了DNS数据缓存功能。即如果一个域名已经解析过，那会把解析的结果缓存下来，下次处理直接走缓存，不需要经过 DNS解析。

另外，如果不指定端口的话，默认采用对应的 IP 的 80 端口。

第三步 建立TCP连接

什么是TCP？
TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

• 通过三次握手(即总共发送3个数据包确认已经建立连接)建立客户端和服务器之间的连接。
• 进行数据传输。这里有一个重要的机制，就是接收方接收到数据包后必须要向发送方确认, 如果发送方没有接到这个确认的消息，就判定为数据包丢失，并重新发送该数据包。当然，发送的过程中还有一个优化策略，就是把大的数据包拆成一个个小包，依次传输到接收方，接收方按照这个小包的顺序把它们组装成完整数据包。
• 断开连接的阶段。数据传输完成，现在要断开连接了，通过四次挥手来断开连接。

既然提到这里了，那不得不说一下三次握手和四次挥手了

三次握手和四次挥手

三次握手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

image.png

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号seq。此时客户端处于 SYN_SEND 状态。
  首部的同步位SYN=1，初始序号seq=x
• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号seq。同时会把客户端的seq + 1 (TCP 协议规定SYN报文虽然不携带数据， 但是也要消耗1个序列号， 所以前两次握手客户端和服务端都需要向对方回复 x+1 或 y+1 。)作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
  在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的seq + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

重要字段

过程了解之后，就应该知道其传输的字段是什么意思了。如下是其中重要的字段。

序号(sequence number)**：seq序号（动态生成的），占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

确认号（acknowledgement number）：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。

标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

URG：紧急指针（urgent pointer）有效。

ACK：确认序号有效。（为了与确认号ack区分开，我们用大写表示）

PSH：接收方应该尽快将这个报文交给应用层。

RST：重置连接。

SYN：发起一个新连接。

FIN：释放一个连接。

那么这些字段有什么作用呢？

seq序号、ack序号：用于确认数据是否准确，是否正常通信。

标志位：用于确认/更改连接状态。
放个好懂的图：

image.png

两次握手不行吗？

第一次握手：客户端发送网络包，服务端收到了。

这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。

这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。

这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

四次挥手

image.png

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

好了 现在三次握手建立起了链接，就可以发送HTTP请求啦！

发送HTTP请求：

现在TCP连接建立完毕，浏览器可以和服务器开始通信，即开始发送 HTTP 请求。浏览器发 HTTP 请求要携带三样东西:请求行、请求头和请求体。

首先，浏览器会向服务器发送请求行,关于请求行， 我们在这一部分的第一步就构建完了

// 请求方法是GET，路径为根路径，HTTP协议版本为1.1
GET / HTTP/1.1

结构很简单，由请求方法、请求URI和HTTP版本协议组成。

同时也要带上请求头，比如我们之前说的Cache-Control、If-Modified-Since、If-None-Match都由可能被放入请求头中作为缓存的标识信息。当然了还有一些其他的属性，列举如下:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: /* 省略cookie信息 */
Host: www.baidu.com
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1

最后是请求体，请求体只有在POST方法下存在，常见的场景是表单提交。

网络请求

HTTP 请求到达服务器，服务器进行对应的处理。最后要把数据传给浏览器，也就是返回网络响应。

跟请求部分类似，网络响应具有三个部分:响应行、响应头和响应体。

响应行类似下面这样:

HTTP/1.1 200 OK

由HTTP协议版本、状态码和状态描述组成。

响应头包含了服务器及其返回数据的一些信息, 服务器生成数据的时间、返回的数据类型以及对即将写入的Cookie信息。

举例如下:

Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Wed, 04 Dec 2019 12:29:13 GMT
Server: apache
Set-Cookie: rsv_i=f9a0SIItKqzv7kqgAAgphbGyRts3RwTg%2FLyU3Y5Eh5LwyfOOrAsvdezbay0QqkDqFZ0DfQXby4wXKT8Au8O7ZT9UuMsBq2k; path=/; domain=.baidu.com

响应完成之后怎么办？TCP 连接就断开了吗？

不一定。这时候要判断Connection字段, 如果请求头或响应头中包含Connection: Keep-Alive，表示建立了持久连接，这样TCP连接会一直保持，之后请求统一站点的资源会复用这个连接。

否则断开TCP连接, 请求-响应流程结束。总结一下上面的过程：

image.png