在浏览器输入URL后发生了什么？

在浏览器输入URL并获取响应的过程，其实就是浏览器和该url对应的服务器的网络通信过程。

从封装的角度来讲，浏览器和web服务器执行以下动作：（简单流程）

1、浏览器先分析超链接中的URL:分析域名是否规范

2、浏览器向DNS请求解析请求解析http://www.sxtyu.com/index.html中的ip地址

3、DNS将解析出的ip地址返回浏览器

4、浏览器与服务器建立TCP连接（80端口，三次握手）

5、浏览器请求文档（GET/index.html）

6、服务器给出响应，将文档index.html发送给浏览器，浏览器进行解封装。

7、浏览器显示index.html中的内容（渲染页面）

8、释放TCP连接（四次挥手）

新版是这个流程，老版是先7后8

一、浏览器线分析超链接中的URL

1、URL是由协议、主机和端口（默认为80）以及文件名三部门构成

URL请求的目标服务器上的文件路径就是

1. 浏览器做的第一步就是会解析URL得到里面的参数，分析域名是否规范，并将域名和需要的请求的资源分离开来，从而了解需要请求的是哪个服务器，请求的是服务器上的什么资源等等。

2. 浏览器对URL进行解析之后，浏览器确定了目标服务器和文件名，接下来就是需要根据这些消息封装成一个HTTP请求报文发送出去。HTTP请求报文的例子为：

3. 对于这个封装，其中涉及到计算机网络中的知识。就是说发送端在层与层之间传输数据的时候，每经过一层必定会被打上一个该层所属的首部信息。反之，接收端在层与层之间传输数据的时候，没经过一层就会把该层对应的首部消息消除。

二、浏览器向DNS请求解析IP地址

封装好HTTP请求报文之后，就需要获取目标服务器的ip地址（ip包里面有ip地址），虽然解析得到了域名，按理浏览器应该已经知道了目标服务器是谁了。但是实际上，域名并不是目标服务器真正意义上的地址，互联网上每一台计算机都被全世界唯一IP地址标识着，但是IP地址并不方便记忆，所以才设计出了域名。但是虽然域名容易被用户所接受和使用，但是计算机只能识别纯数字构成的IP地址，不能直接读取域名。所以如果只是知道域名也不知道这个请求会被发送到哪里去。那么就需要解析域名获取目标服务器的IP地址。

DNS域名解析IP地址的过程：

1.客户端首先查看浏览器缓存，看有没有该域名对应的IP地址

2.如果没有的话，查看本地host文件，看有没有该域名对应的IP地址

3.如果没有的话，客户端向本地域名服务器进行递归查询，查询该域名对应的IP地址

4.如果还是没有的话，本地域名服务器向根域名服务器进行迭代查询，根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器

5.本地域名服务器再向顶级域名服务器查询，顶级域名服务器要么给出所要查询的IP地址，要么告诉本地服务器下一步应该向哪一个权限域名服务器进行查询

6.本地域名服务器向权限域名服务器进行查询，然后得到了所要解析的IP地址

7.本地域名服务器将该域名和对应的IP地址写入自身缓存，然后将解析的IP地址返回给客户端

1、首先本地电脑会检查浏览器DNS缓存中有没有这个域名对应的解析过的IP地址。

如果缓存的中有，这个解析过程就结束。缓存中维护着一张域名与 IP 地址的对应表。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下，缓存时间为几分钟到几个小时或者更长。域名被缓存的时间限制可以通过TTL属性来设置，这个缓存时间太长、太短都不太好。如果时间太长，一旦域名被解析到的ip发生变化，就会导致客户端缓存的域名无法解析到变化后的ip地址，导致该域名不能正常解析，这段时间内会有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都需要重新解析一次域名，都会影响到用户的使用。

2、如果浏览器缓存中没有数据，浏览器会查找hosts文件（操作系统缓存中：hosts文件）看有没有该域名对应的IP地址。

其中的操作系统也有一个域名解析的过程，在Linux中可以通过/etc/hosts文件中来设置，Windows中可以通过配置C:\Windows\System32\drivers\etc\hosts文件来设置，用户可以将任何域名解析到任何能够访问到的ip地址。

如：我们可以在测试的时候将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地DNS解析的规程，所以就可能有黑客通过修改用户的域名来把特定的域名解析到他指定的ip地址上，导致域名被劫持。

3、如果本地缓存文件中也没有的话，就需要使用到网络配置中的“DNS服务器地址”。

操作系统会把这个域名发送给本地DNS服务器。每个完整的内网通常都会配置本地DNS服务器，例如用户是在学校或者单位接入互联网，那么用户的本地DNS服务器肯定是在学校或者工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。后面的DNS迭代和递归也是由本地DNS服务器负责的。

Windows的配置在：控制面板-网络共享中心-更改适配器-选择目标适配器右键选择属性-Internet协议版本4(TCP/IPv4)-》配置DNS地址。

Linux中的配置在：/etc/resolv.conf

[root@nginx-kafka01 etc]# cat /etc/resolv.conf

# Generated by NetworkManager

nameserver 114.114.114.114

nameserver 192.168.2.1

本地域名服务器记录的解析如果有就会直接返回，如果没有解析，就会去根域名服务器（www顶级域.baidu：二级域.com）找全球13台，依次迭代查询得到最后的ip解析地址 ，通过迭代去查询的。（注意：主机和本地域名服务器之间的查询方式是递归查询）

4、如果DNS服务器中还是没有，本地域名服务器向根域名服务器进行迭代查询

（注意：本地域名服务器和其他域名服务器之间的查询方式是迭代查询，防止根域名服务器压力过大）

通过以下方式进行迭代查询：

首先本地域名服务器向根域名服务器发起请求，根域名服务器是最高层次的，它并不会直接指明这个域名对应的 IP 地址，而是返回顶级域名服务器的地址，也就是说给本地域名服务器指明一条道路，让他去这里寻找答案。

本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址

本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的IP地址

5、本地域名服务器将得到的IP地址返回给操作系统，同时自己将IP地址缓存起来

6、操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来

7、至此，浏览器就得到了域名对应的 IP地址，并将IP地址缓存起来

递归查询和迭代查询的区别：

DNS客户端和本地名称服务器是递归查询，而本地名称服务器和其他名称服务器之间是迭代查询。

DNS递归名称解析：

在DNS递归解析中，当所配置的本地名称服务器解析不了时，后面的查询工作是由本地名称服务器替代DNS客户端进行的（以“本地名称服务器”为中心），只需要本地名称服务器向DNS客户端返回最终的查询结果即可。

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

在查询本地名称服务器时，如果客户端的请求报文中没有申请使用递归查询，即在DNS请求报头部的RD字段没有置1。相当于说“你都没有主动要求我为你进行递归查询，我当然不会为你工作了”。

客户端在DNS请求报文中申请使用的是递归查询（也就是RD字段置1了），但在所配置的本地名称服务器上是禁用递归查询（DNS服务器一般默认支持递归查询的），即在应答DNS报文头部的RA字段置0。

其中，DNS 使用的是 UDP 协议，也就是说上面各种请求的转发，都是基于 UDP 这个无连接协议的。

三、DNS将解析出的地址返回给浏览器

四、浏览器与服务器建立TCP连接（三次握手）

三次握手的流程：

第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

五、浏览器请求文档

TCP三次握手完成之后，浏览器与服务器之间就会建立起一个可靠的虚拟通道，于是浏览器就可以发送自己的HTTP请求了。

HTTP 请求报文或者响应报文在 TCP 连接通道上进行传输的时候，由于这些报文比较大，为了更容易和准确可靠的传输，TCP 会将 HTTP 报文按序号分割成若干报文段并加上 TCP 首部，分别进行传输。接收方在收到这些报文段后，按照序号以原来的顺序重组 HTTP 报文

HTTP中的请求报文：

请求报文：客户端（浏览器）向web服务器发送的请求报文。报文的所有字段都是ASCII码。

请求报文中可以携带数据，也可以不携带数据。 请求报文由请求行、请求头部、空行和请求包体 4 个部分组成。

首部行：用来说明浏览器、服务器或报文主体是一些信息。

首部字段：请求报文里。请求的时候需要携带数据告诉服务器自己需要访问的东西。携带的数据是通过头部字段(header)去访问。

请求报文里面的字段：提问 requests: 请求报文

①Host:表示访问的主机。表示访问的那个网址---》URL（通过域名dns或者ip地址）

②connection：close或者keepalive 表示当前是连接还是断开的状态。

③user-agent ：表示使用的是什么用户代理---》浏览器（本质上使用的是什么浏览器）：请求字段，用来描述发起请求的客户端，比如是Chrome、Mozilla、Safari，或者是spider。

④Accept-language.cn ：客户端可接受的自然语言。

⑤Accept-encode.cn：客户端可接受的编码压缩格式;接收的编码、接收的类型的文件（表示的是压缩）

⑥cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;

请求行：方法、URL、版本

• 常见的方法为：GET、POST、PUT、DELETE等

• 常见的版本为：HTTP1.0、HTTP1.1、HTTP2.0等

六、服务器给出响应，将文档index.html发送给浏览器，浏览器进行解封装。

浏览器的 HTTP 请求报文通过 TCP 三次握手建立的连接通道被切分成若干报文段分别发送给服务器，服务器在收到这些报文段后，按照序号以原来的顺序重组 HTTP 请求报文。然后处理并返回一个 HTTP 响应。当然，HTTP 响应报文也要经过和 HTTP 请求报文一样的过程。

HTTP的响应报文：response响应报文，即从Web服务器到客户机(浏览器)的应答。报文的所有字段都是ASCII码。

HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成

reposes里面的状态码：重要

状态行：状态码（列举常见的）

200 : 响应成功

301：永久重定向,请求资源的url已永久更改，在响应中给出了新的url。

302：临时重定向。

304：not modify（未改变，和缓存里面的是一样的）

404：not found ，网页不存在。

502：bad gateway （网关故障），但是后端的real server挂了。

500：内部服务器错误。（服务器崩溃了）

响应头部：响应字段：

Date：日期，通用字段，但通常出现在响应头里，表示 HTTP 报文创建的时间，客户端可以使用这个时间再搭配其他字段决定缓存策略

Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。

cache-control: max-age=30

content-type：传递过来的类型。

七、浏览器显示index.html中的内容（渲染页面）

浏览器接收到服务器返回的数据包，根据浏览器的渲染机制对相应的数据进行渲染。渲染就是将响应报文里的html文件+图片+视频等展示出来，看到效果。浏览器支持HTML语言，支持http，播放器等功能。

八、释放TCP连接（四次挥手）

浏览器和服务器都不再需要发送数据后，四次挥手断开 TCP 连接。

建立一个连接需要进行三次握手，而终止一个连接需要经过四次挥手（断开连接），这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这个连接可以是客户端主动断开的，也可以是因为超过连接时间了，服务端主动断开的。

1、四次挥手

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

第二次挥手：服务端收到FIN标志位数据包之后，会给客户端发送ACK报文（ACK=1：确认报文段），表明已经收到客户端的报文了，这个报文中是把客户端的序列号值进行加一（u+1）作为确认ACK报文的序列号值（ack=u+1：确认序列号），同时也会生成一个初始序列号seq=v。此时的服务器端处于 CLOSE_WAIT （关闭等待）状态。

此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2(终止等待2)状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务器也想断开连接了（服务端没有要向客户端发出的数据），就会和客户端的第一次挥手一样，会给客户端发送一个FIN报文（FIN=1：连接释放报文，ACK=1），并且随机指定一个序列号seq=w（确认号为ack=u+1）。此时的服务端处于 LAST_ACK (最后确认)的状态，等待客户端的确认。

第四次挥手：客户端收到FIN报文（连接释放报文段）之后，一样的发送一个ACK报文（ACK=1，seq=u+1：确认报文段）作为应答，并且把服务端的序列号值+1（ack=w+1）作为自己ACK报文的序列号值。此时的客户端处于TIME_WAIT （时间等待）状态，（此时的TCP没有被释放掉）需要经过一段时间（等待时间计时器设置的时间2MSL）以确保服务端收到自己的ACK报文之后才会进入CLOSED状态，服务器端收到ACK报文之后，就处于关闭连接了，处于CLOSED状态。

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

2.3 四次挥手中的常见问题

1、timewait过多的情况

一般是客户端，nginx作为反向代理，它既是服务器又是客户端，可能出现。

（1）timewait多的原因是：访问量过大，客户机在访问新的页面。

（2）解决timewait过多情况：①增加机器。②设置防火墙 nginx limit限制 ③修改内核参数：将等待时间减小 。提高资源利用率，在等待时间不处理其他事情。

2、为什么连接的时候是三次握手，关闭的时候却是四次挥手？

因为建立连接的时候，服务器在LISTEN状态下，当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文发送给客户端。其中ACK报文是用来应答的，SYN报文是用来同步的。

但是关闭连接时，当Server端收到对方发送的FIN报文时，告诉Client端，“你发的报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

3、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

有些材料显示2msl的最大等待时间为2分钟。

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失，所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失；Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL（Maximum Segment Lifetime）。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

4、服务器端会有一个TIME_WAIT状态吗？如果是服务器端主动断开连接呢？

发起连接的主动方基本都是客户端，但是断开连接的主动方服务器端和客户端都可以充当，也就是说，只要是主动断开连接的，就会有 TIME_WAIT状态。

四次挥手是指断开一个TCP连接时，需要客户端和服务器端总共发送4个确认包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

由于TCP连接时全双工的，因此，每个方向的数据传输通道都必须要单独进行关闭。