一次完整的http请求

1.域名解析

域名解析，解析出对应的IP地址。

那是如何解析的呢？

1. 首先会搜索浏览器自身的DNS缓存

   为了加快访问速度，Google Chrome浏览器采用了预提DNS记录，在本地建立DNS缓存的方法，加快网站的连接速度。

   chrome://net-internals/#dns，这里可以看各域名的DNS 缓存时间。chrome对每个域名会默认缓存60s。，firefox是进入about:config，搜索DNS。就可以看到缓存。

2. 再寻找本机自身的DNS缓存

   如果浏览器自身的缓存里面没有找到，那么浏览器会搜索操作系统自身的DNS缓存，其实操作系统也会有一个域名解析的过程，在Windows中可以通过C:\Windows\System32\drivers\etc\hosts文件来设置，你可以将任何域名解析到任何能够访问的IP地址。如果你在这里指定了一个域名对应的IP地址，那么浏览器会首先使用这个IP地址。 在Linux中这个配置文件是/etc/hosts,修改这个文件可以达到同样的目的。操作系统会在缓存中缓存这个解析结果，缓存的时间同样是受这个域名的失效时间和缓存的空间大小控制的。

3. 查询本地DNS服务器

   在我们的网络配置中都会有“DNS服务器地址”这一项，这个就是在我们上面这两种没查到时使用的，此时我们的电脑会把网址发送到 Local DNS本地区的域名服务器，然后去解析。（这里的服务器就是提供给你上网的供应商，例如联通，电信等。）

4. 查询根服务器

   如果LDNS仍然没有命中，就直接到RootServer域名服务器请求解析。

5. 此时根域名服务器返回给本地域名服务器一个所查询域的主域名服务器(gTLdServer)地址，然后本地域名服务器(Local DNS Server) 再向上一步返回的gTLDNS服务器发送请求。gTLD是国际顶级域名服务器，如.com、 .cn、.org、.edu 等

6. 接受请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server通常就是你注册的域名服务器，例如你在某个域名服务提供商申请的域名，那么这个域名解析任务就由这个域名提供商的服务器来完成。

7. NameServer域名服务器会查询存储的域名和IP的映射关系表，在正常情况下都根据域名得到目标IP记录，连同一个TTl值返回给DNS Server域名服务器。(TTI它表示一条域名解析记录在DNS服务器上缓存时间.当各地的DNS服务器接受到解析请求时，就会向域名指定的DNS服务器发出解析请求从而获得解析记录；在获得这个记录之后，记录会在DNS服务器中保存一段时间，这段时间内如果再接到这个域名的解析请求，DNS服务器将不再向DNS服务器发出请求，而是直接返回刚才获得的记录；而这个记录在DNS服务器上保留的时间，就是TTL值。)

8. 此时本地域名服务器先会缓存这个域名和IP的对应关系，缓存的时间由TTL值控制，然后把解析的结果返回给用户，用户根据TTL值缓存在本地系统缓存中，域名解析过程结束

递归解析

“递归解析”（或叫“递归查询”，其实意思是一样的）是最常见，也是默认的解析方式。在这种解析方式中，如果客户端配置的本地名称服务器，（又称Local DNS， 可以是默认的运营商提供的Local DNS 或者自己设置的DNS） 不能解析的话，则后面的查询全由本地名称服务器代替DNS客户端进行查询，直到本地名称服务器从权威名称服务器得到了正确的解析结果，然后由本地名称服务器告诉DNS客户端查询的结果。

在递归解析中，本地名称服务(Local DNS)是主体。

迭代解析

迭代查询的所有查询工作全部是DNS客户端自己进行（以“DNS客户端”自己为中心）。在条件之一满足时就会采用迭代名称解析方式：

• 在查询本地名称服务器时，如果客户端的请求报文中没有申请使用递归查询，即在DNS请求报头部的RD(表示期望递归)字段没有置1.
• 本地名称服务器不支持递归解析(一般是支持的)，也就是说客户的机器RD字段置为1，但是本地名称服务器不支持，所以在应答DNS报文头部的RA(表示支持递归)字段置0。

2.TCP建立连接

三次握手

第一次握手

​ 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手

​ 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手

​ 客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

四次挥手

1. 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
2. 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
3. 服务器-关闭与客户端的连接，发送一个FIN给客户端
4. 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

为什么要三次握手？二次会有什么问题

三次握手与后面的四次挥手，都是建立在网络不可靠的情况。

如果用户发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达服务器的。本来这是一个早已失效的报文段。但服务器收到此失效的连接请求报文段后，就误认为是用户再次发出的一个新的连接请求。于是就向用户发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要服务器发出确认，新的连接就建立了。由于现在用户并没有发出建立连接的请求，因此不会理睬服务器的确认，也不会向服务器发送数据。但服务器却以为新的运输连接已经建立，并一直等待客户端发来数据。这样，服务器的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

为什么需要四次挥手，三次会出现什么问题

四次挥手，由客户端发起一个FIN包，告诉服务器自己的信息发送完毕，不在需要发送信息，此时服务器接到消息，但是服务器的信息可能未发送完，所以它需要给客户端一个ACK包，告诉客户端我信息没发完，在发完之后，服务器会在给客户端一个关闭的请求，发送FIN包。如果此时就已经关闭了，而因为网络问题，这个消息没到客户端，那么客户端就会一直等待这个FIN包，造成资源浪费，所以此时需要客户端发送一个ACK包告诉服务器，它收到了，双方才可以断开连接。

新问题，如果最后的ACK包滞后了怎么办？？？

在最后的一次服务器发送FIN后，此时服务器是没断开的，它会等待客户端发送ACK包，如果客户端没发过来，它会一直再发FIN包，以保证客户端收的到这个包，而客户端并不是发送ACK之后就直接关闭的，他会进入TIME_WAIT 状态（一般为 2分钟），如果此时再接受到FIN 包说明服务器没接到，它会再发送ACK包。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

3.发起http请求

HTTP请求报文由三部分组成：请求行，请求头和请求正文

1. 请求行：用于描述客户端的请求方式，请求的资源名称以及使用的HTTP协议的版本号
2. 请求头：用于描述客户端请求哪台主机，以及客户端的一些环境信息等
3. 请求正文：当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中（GET方式是保存在url地址后面）

4.服务器端响应http请求，浏览器得到html代码

HTTP响应也由三部分组成：状态码，响应头和实体内容

　　1.状态码：状态码用于表示服务器对请求的处理结果

　　2.响应头：响应头用于描述服务器的基本信息，以及客户端如何处理数据

　　3.实体内容：服务器返回给客户端的数据

5.浏览器解析html代码

浏览器拿到html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载。

6.浏览器对页面进行渲染呈现给用户

浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。

赏

谢谢你请我吃糖果