前端面试：页面输入url之后发生了什么？

本文主旨：帮助自己理清页面输入url地址之后的一个整体流程

首先，用户第一次向服务器发送对应url地址请求，此时，客户端没有缓存

1.用户输入url通过DNS解析为对应的IP地址。

2.应用层：HTTP协议生成针对目标Web服务器的HTTP请求报文。

3.传输层：TCP协议为了传输方便，将HTTP请求报文进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。

4.网络层：IP协议增加作为通信目的地的MAC地址后转发给链路层。

接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。

然后服务器将返回对应请求，设置相应的缓存

这中间还涉及一个面试很喜欢问的问题，就是TCP协议中的“三次握手，四次挥手”

握手过程中使用了TCP标志——SYN（synchronize）和ACK（acknowledgement）

1.发送端首先发送一个带SYN标志的数据包给对方

2.接收端接收到后，回传一个带有SYN/ACK标志数据包表示传达确认信息

3.发送端再回传一个带ACK标志的数据包，代表“握手结束”

四次挥手

1.客户端（Client）发送中断连接请求，发送FIN报文

2.服务端（Server）接收到FIN报文后，向客户端发送ACK报文（反馈客户端信息，你的请求我收到了，但是我还没有准备好，请等待我的消息），这个时候客户端就进入FIN-WAIT状态

3.当服务端确定数据已发送完毕，则向客户端发送FIN/ACK报文，告诉客户端，我这边数据发送完毕，可以关闭连接

4.客户端收到信息后，就知道可以关闭连接了，但它不相信网络，怕服务端不知道要关闭，所以发送ACK报文后进入TIME_WAIT状态，如果服务端没有收到ACK则可以重传，服务端收到ACK后，就直到可以断开连接了。客户端等待2MSL后依然没有收到回复，则证明服务端已经正常关闭，那好，客户端也关闭连接。TCP连接关闭

当第一次请求完成之后，以后再进行相应请求时，就要讨论缓存是否过期的问题了

看完这幅图，有没有什么大胆的想法~

根据这幅图，一步一步理清关于页面输入url地址之后发生了什么这个问题

前提：客户端对于上述url地址请求是有缓存的

Expires

首部字段Expires会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

当缓存未过期时，页面直接取缓存，进行页面展示。

缓存过期后，进行Etag判断

ETag

首部字段ETag能告诉客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应ETag值。

另外，当资源更新时，ETag值也需要更新。生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配。

强ETag值：不论实体发生多么细微的变化都会改变其值。

弱ETag值：只用于提示资源是否相同。只有资源发生了根本改变，产生差异时才会改变ETag值。这时，会在字段值最开始处附加W/。

If-None-Match

属于附带条件之一。用于指定If-None-Match字段值的实体标记（ETag）值与请求资源的ETag不一致时，它就告知服务器处理该请求。

在GET或HEAD方法中使用首部字段If-None-Match可获得最新的资源

Last-Modified

指明资源最终被修改的时间。

If-Modified-Since

附带条件之一。

用于确认代理或客户端拥有的本地资源的有效性。

它会告知服务器若If-Modified-Since字段值早于资源的更新时间，则希望能处理该请求。

而在指定字段值的日期时间之后，如果请求的资源都没有更新过，则返回状态码304响应。

200 OK

从客户端发来的请求在服务器端被正常处理了。

304 Not Modified

服务器端资源未改变，可直接使用客户端未过期的缓存。资源已找到，但未符合条件请求

表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304。

总结：

当页面输入url地址之后，首先进行是否有缓存的判断，没有缓存，正常通过向服务器发起请求获取页面资源

有缓存的话进行缓存是否过期等一系列判断，最终将页面资源展示出来

先走缓存，再服务器请求，一切以快速，简捷为目的

上面只是简单介绍了一下从输入url到请求到页面资源的过程，还有页面展示，各种缓存的问题，有兴趣的朋友可以自己研究一下，这里就先不做介绍

如果有什么错误、问题请在第一时间联系我

如果感觉这篇文章对你有所启发，就请点个赞吧

附录：

点击打开链接 http://www.alloyteam.com/2016/03/discussion-on-web-caching/

《图解HTTP》