最近看了一些前端面试方面的一些题目，看了网上许多相关的文章，发现有一个问题始终绕不开: 在浏览器中输入URL到整个页面显示在用户面前时这个过程中到底发生了什么。仔细思考这个问题，发现确实很深，这个过程涉及到的东西很多。这个问题的回答真的能够很好的考验一个web工程师的水平。

总体来说分为以下几个过程：

1. DNS域名解析对应的IP地址（输入的是域名时）

2. 建立TCP连接

3. 发送HTTP请求

4. 服务器处理请求并返回HTTP报文

5. 浏览器解析渲染页面

6. 连接结束

具体过程：

1、url

　　我们常见的RUL是这样的:http://www.baidu.com,这个域名由三部分组成：协议名、域名、端口号，这里端口是默认所以隐藏。除此之外URL还会包含一些路径、查询和其他片段，例如：http://www.tuicool.com/search?kw=%E4%。我们最常见的的协议是HTTP协议，除此之外还有加密的HTTPS协议、FTP协议、FILe协议等等。URL的中间部分为域名或者是IP，之后就是端口号了。通常端口号不常见是因为大部分的都是使用默认端口，如HTTP默认端口80，HTTPS默认端口443。说到这里可能有的面试官会问你同源策略，以及更深层次的跨域的问题，这里就不展开了。

2、用户输入url

　　当用户输入url，操作系统会将输入事件传递到浏览器中，在这过程中，浏览器可能会做一些预处理，比如 Chrome 会根据历史统计来预估所输入字符对应的网站，例如输入goog，根据之前的历史发现 90% 的概率会访问「www.google.com 」，因此就会在输入回车前就马上开始建立 TCP 链接甚至渲染了。

　　接着是输入url之后，点击回车，这时浏览器会对 URL 进行检查，首先判断协议，如果是 http 就按照 Web 来处理，另外还会对这个 URL 进行安全检查

　　安全检查完成之后，在浏览器内核中会先查看缓存，然后设置 UA 等 HTTP 信息，接着调用不同平台下网络请求的方法。

注意：

浏览器和浏览器内核是不同的概念，浏览器指的是 Chrome、Firefox，而浏览器内核则是 Blink、Gecko，Webkit，浏览器内核只负责渲染，GUI 及网络连接等跨平台工作则是浏览器实现的。

3、DNS域名解析

　　DNS，英文是Domain Name System，中文叫域名系统，是Internet的一项服务。DNS解析的过程就是寻找哪台机器上有你需要资源的过程。当你在浏览器中输入一个地址时，例如www.baidu.com，其实不是百度网站真正意义上的地址。互联网上每一台计算机的唯一标识是它的IP地址，但是IP地址并不方便记忆。用户更喜欢用方便记忆的网址去寻找互联网上的其它计算机，也就是上面提到的百度的网址。所以互联网设计者需要在用户的方便性与可用性方面做一个权衡，这个权衡就是一个网址到IP地址的转换，这个过程就是DNS解析。它实际上充当了一个翻译的角色，实现了网址到IP地址的转换。即：域名解析的过程实际是将域名还原为IP地址的过程。那么下面讲述一下DNS查询IP地址的过程。

4、DNS查询IP地址过程

假设用户在浏览器中输入的是www.google.com，大概过程：

如果输入的是域名，则需要进行dns查询，将域名解析成ip；

进行DNS查询的主机或软件叫做DNS解析器，用户使用的工作站或电脑都属于解析器。域名解析就是利用DNS解析器得到对应IP过程，解析器会向域名服务器进行查询处理。

主要过程如下：

1. 从浏览器缓存中查找域名www.google.com的IP地址
2. 在浏览器缓存中没找到，就在操作系统缓存中查找，这一步中也会查找本机的hosts看看有没有对应的域名映射（当然已经缓存在系统DNS缓存中了）
3. 在系统中也没有的话，就到你的路由器来查找，因为路由器一般也会有自己的DNS缓存

如果以上都没有找到，则继续往下向dns域名服务器查询

• 用户电脑的解析器向LDNS（也就是Local DNS，互联网服务提供商ISP），发起域名解析请求，查询www.google.com的IP地址，这是一个递归查找过程
• 在缓存没有命中的情况下，LDNS向根域名服务器.查询www.google.com的IP地址，LDNS的查询过程是一个迭代查询的过程
• 根告诉LDNS，我不知道www.google.com对应的IP，但是我知道你可以问com域的授权服务器，这个域归他管
• LDNS向com的授权服务器问www.google.com对应的IP地址
• com告诉LDNS，我不知道www.google.com对应的IP，但是我知道你可以问google.com域的授权服务器，这个域归他管
• LDNS向google.com的授权服务器问www.google.com对应的IP地址
• google.com查询自己的ZONE文件（也称区域文件记录），找到了www.google.com对应的IP地址，返回给LDNS
• LDNS本地缓存一份记录，把结果返回给用户电脑的解析器
• 在这之后，用户电脑的解析器拿到结果后，缓存在自己操作系统DNS缓存中，同时返回给浏览器，浏览器依旧会缓存一段时间。

注意：向dns域名服务器递归查询过程是很耗时的，所以dns优化就要提到dns缓存以及DNS负载均衡。

DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存(ps:上面已部分提到)。

DNS负载均衡

　　不知道大家有没有思考过一个问题: DNS返回的IP地址是否每次都一样？如果每次都一样是否说明你请求的资源都位于同一台机器上面，那么这台机器需要多高的性能和储存才能满足亿万请求呢？其实真实的互联网世界背后存在成千上百台服务器，大型的网站甚至更多。但是在用户的眼中，它需要的只是处理他的请求，哪台机器处理请求并不重要。DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡，又叫做DNS重定向。大家耳熟能详的CDN(Content Delivery Network)就是利用DNS的重定向技术，DNS服务器会返回一个跟用户最接近的点的IP地址给用户，CDN节点的服务器负责响应用户的请求，提供所需的内容。在这里打个免费的广告，我平时使用的比较多的是七牛云的CDN(免费)储存图片，作为我个人博客的图床使用。

5、TCP连接

有了 IP 地址，就可以通过 Socket API 来发送数据了，这时可以选择 TCP 或 UDP 协议。

http本质是tcp协议。

TCP是一种面向有连接的传输层协议。他可以保证两端（发送端和接收端）通信主机之间的通信可达。他能够处理在传输过程中丢包、传输顺序乱掉等异常情况；此外他还能有效利用宽带，缓解网络拥堵。

建立TCP连接一开始都要经过三次握手：

第一次握手，请求建立连接，发送端发送连接请求报文第二次握手，接收端收到发送端发过来的报文，可知发送端现在要建立联机。然后接收端会向发送端发送一个报文第三次握手，发送端收到了发送过来的报文，需要检查一下返回的内容是否是正确的；若正确的话，发送端再次发送确认包

在TCP连接建立完成之后就可以发送HTTP请求了。可以将数据发送给服务器，并收到返回信息。

当请求结束，需要经厉连接终止协议（四次挥手）。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

抽象为：

客户端：我已经关闭了向你那边的主动通道了，只能被动接收了服务端：收到通道关闭的信息服务端：那我也告诉你，我这边向你的主动通道也关闭了客户端：最后收到数据，之后双方无法通信

这里简单补述一下HTTPS协议：

　　HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

HTTPS过程

　　HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。

6、HTTP请求

　　其实这部分又可以称为前端工程师眼中的HTTP，它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。

请求行

格式如下:
Method Request-URL HTTP-Version CRLF

eg: GET index.html HTTP/1.1

常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

请求报头

请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。
PS: 客户端不一定特指浏览器，有时候也可使用Linux下的CURL命令以及HTTP客户端测试工具等。
常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

　　上图是使用Chrome开发者工具截取的对百度的HTTP请求以及响应报文，从图中可以看出，请求报头中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息，Accept-Encoding与Accept类似，它用于指定接受的编码方式。Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP连接建立的时间。

请求正文

　　当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息，例如: 现在的Web应用通常采用Rest架构，请求的数据格式一般为json。这时就需要设置Content-Type: application/json。

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

自然而然这部分对应的就是后端工程师眼中的HTTP。后端从在固定的端口接收到TCP报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，我使用过的Web服务器有Tomcat, Jetty和Netty等等。

HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。

状态码

状态码是由3位数组成，第一个数字定义了响应的类别，且有五种可能取值:

• 1xx：指示信息–表示请求已接收，继续处理。

• 2xx：成功–表示请求已被成功接收、理解、接受。

• 3xx：重定向–要完成请求必须进行更进一步的操作。

• 4xx：客户端错误–请求有语法错误或请求无法实现。

• 5xx：服务器端错误–服务器未能实现合法的请求。
  平时遇到比较常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500(分别表示什么请自行查找)。

响应报头

常见的响应报头字段有: Server, Connection...。

响应报文

服务器返回给浏览器的文本信息，通常HTML, CSS, JS, 图片等文件就放在这一部分。

8、浏览器解析渲染页面

浏览器在收到HTML,CSS,JS文件后，它是如何把页面呈现到屏幕上的？下图对应的就是WebKit渲染的过程。

　　浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

　　JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。但是又存在某些任务比较耗时，如IO读写等，所以需要一种机制可以先执行排在后面的任务，这就是：同步任务(synchronous)和异步任务(asynchronous)。JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务，异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行，形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件；脚本运行时先依次运行执行栈，然后会从任务队列里提取事件，运行任务队列中的任务，这个过程是不断重复的，所以又叫做事件循环(Event loop)。

　　浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等，浏览器将继续下载该资源。请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

参考文章：

https://segmentfault.com/a/1190000017053582

https://segmentfault.com/a/1190000006879700