从url输入到页面展示到底发生了什么

在此将两篇文章内容整合一下，便于以后查找。放上原文链接：
【1】https://xianyulaodi.github.io/2017/03/22/老生常谈-从输入url到页面展示到底发生了什么/
【2】https://github.com/ljianshu/Blog/issues/24

1.输入url

当我们开始在浏览器中输入网址的时候，浏览器其实就已经在智能的匹配可能的url了，它会从历史纪录，书签等地方找到已经输入的字符串可能对应的url，然后给出智能提示，让你可以补全url地址。对于google的chrome浏览器，它甚至会直接从缓存中把网页展示出来，就是说，你还没有按下enter，页面就展现出来了。

知识拓展

URL(Uniform Resource Locator)，统一资源定位符，用于定位互联网上资源，俗称网址。比如：http://www.w3school.com.cn/html/index.asp
，遵守以下的语法规则

scheme://host.domain:port/path/filename

各部分解释如下：
scheme - 定义因特网服务的类型。常见的协议有http、https、ftp、file，其中最常见的类型是http，而https则是进行加密的网络传输。
host - 定义域主机（http的默认主机是www）
domain - 定义因特网域名，比如 w3school.com.cn
port - 定义主机上的端口号（http的默认端口是80）
path - 定义服务器上的路径（如果省略，则文件必须位于网站的根目录中）。
filename - 定义文档/资源的名称。

2.浏览器查找域名的IP地址

        1.请求一旦发起，浏览器首先要做的事情就是解析这个域名，一般来说，浏览器会首先查看本地硬盘的hosts文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用hosts文件里面的ip地址。
        2.如果在本地的hosts文件没有找到对应的ip地址，浏览器会发出一个DNS请求到本地的DNS服务器。本地的DNS服务器一般都是你的网络接入服务器商提供，比如中国电信、中国移动。
        3.查询你输入网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归方式的查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询。
        4.根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到与服务器上去继续查询，并给出与服务器的地址。这种过程的迭代的过程。
        5.本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名和解析服务器的地址。
        6.最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址的对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，而且还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

下面这张图很完美的解释了这一过程：

知识拓展
1.IP地址

IP地址是互联网协议地址，是IP Address的缩写。IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP地址是一个32位的二进制数，比如127.0.0.1为本机IP。
域名就相当于IP地址乔装打扮的伪装者，戴着一副面具。它的作用就是便于记忆和沟通的一组服务器的地址。 用户通常使用主机名或域名来访问对方的计算机，而不是直接通过IP地址来访问。因为与IP地址的一组纯数字相比，用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯。但要让计算机去理解名称，相对而言就变得困难了。因为计算机更擅长处理一长串
数字。为了解决上述问题，DNS服务应运而生。

2.什么是DNS

DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。
通俗的讲，我们更习惯记住一个网站的名字，比如 www.baidu.com，而不是记住它的ip地址，比如：167.23.10.2。而计算机更擅长记住网站的ip地址，而不是像www.baidu.com等链接。DNS就相当于一个电话本，比如你要找www.baidu.com这个域名，那就翻一翻电话本，就知道它的电话（ip）是167.23.10.2.

3.DNS查询的两种方式：递归查询和迭代查询

1)递归解析
当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式，如图所示是递归方式。局部服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部的DNS服务器，再由局部的DNS服务器返回给客户端。

2）迭代解析
当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析，如图所示。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。 比如说：baidu.com的服务器ip地址在192.168.4.5这里，你自己去查吧，本人比较忙，只能帮你到这里了。

4.DNS域名称空间的组织方式
我们在前面有说到根DNS服务器，域DNS服务器，这些都是DNS域名称空间的组织方式。按其功能命名空间中用来描述 DNS 域名称的五个类别的介绍详见下表中，以及与每个名称类型的示例

5.DNS负载均衡
当一个网站有足够多的用户的时候，假如每次请求的资源都位于同一台机器上面，那么这台机器随时可能会蹦掉。处理办法就是用DNS负载均衡技术，它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去, 使得不同的客户端访问不同的服务器,从而达到负载均衡的目的｡例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等。

3.TCP三次握手

在客户端发送数据之前会发起 TCP 三次握手用以同步客户端和服务端的序列号和确认号，并交换 TCP 窗口大小信息。

1.TCP 三次握手的过程如下：

• 客户端发送一个带 SYN=1，Seq=X 的数据包到服务器端口（第一次握手，由浏览器发起，告诉服务器我要发送请求了）
• 服务器发回一个带 SYN=1， ACK=X+1， Seq=Y 的响应包以示传达确认信息（第二次握手，由服务器发起，告诉浏览器我准备接受了，你赶紧发送吧）
• 客户端再回传一个带 ACK=Y+1， Seq=Z 的数据包，代表“握手结束”（第三次握手，由浏览器发送，告诉服务器，我马上就发了，准备接受吧）

2.为啥需要三次握手
谢希仁著《计算机网络》中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。

4.浏览器向web服务器发送一个HTTP请求

TCP 三次握手结束后，开始发送 HTTP 请求报文。

请求报文由请求行（request line）、请求头（header）、请求体四个部分组成,如下图所示：

1.请求行包含请求方法、URL、协议版本
请求方法包含 8 种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
URL 即请求地址，由 <协议>：//<主机>：<端口>/<路径>?<参数> 组成
协议版本即 http 版本号

POST  /chapter17/user.html HTTP/1.1

以上代码中“POST”代表请求方法，“/chapter17/user.html”表示 URL，“HTTP/1.1”代表协议和协议的版本。现在比较流行的是 Http1.1 版本

2.请求头包含请求的附加信息，由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。

请求头部通知服务器有关于客户端请求的信息。它包含许多有关的客户端环境和请求正文的有用信息。 其中比如：Host，表示主机名，虚拟主机；Connection,HTTP/1.1 增加的，使用 keepalive，即持久连接，一个连接可以发多个请求；User-Agent，请求发出者，兼容性以及定制化需求。

3.请求体，可以承载多个请求参数的数据，包含回车符、换行符和请求数据，并不是所有请求都具有请求数据。

name=tom&password=1234&realName=tomson

上面代码，承载着 name、password、realName 三个请求参数。

5.服务器处理请求

服务器
服务器是网络环境中的高性能计算机，它侦听网络上的其他计算机（客户机）提交的服务请求，并提供相应的服务，比如网页服务、文件下载服务、邮件服务、视频服务。 而客户端主要的功能是浏览网页、看视频、听音乐等等，两者截然不同。 每台服务器上都会安装处理请求的应用——web server。常见的 web server 产品有 apache、nginx、IIS 或 Lighttpd 等。

web server 担任管控的角色，对于不同用户发送的请求，会结合配置文件，把不同请求委托给服务器上处理相应请求的程序进行处理（例如 CGI 脚本，JSP 脚本，servlets，ASP 脚本，服务器端 JavaScript，或者一些其它的服务器端技术等），然后返回后台程序处理产生的结果作为响应。

MVC 后台处理阶段
后台开发现在有很多框架，但大部分都还是按照 MVC 设计模式进行搭建的。

1、视图（view）

它是提供给用户的操作界面，是程序的外壳。

2、模型（model）

模型主要负责数据交互。 在 MVC 的三个部件中，模型拥有最多的处理任务。一个模型能为多个视图提供数据。

3、控制器（controller）

它负责根据用户从"视图层"输入的指令，选取"模型层"中的数据，然后对其进行相应的操作，产生最终结果。 控制器属于管理者角色，从视图接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示模型处理返回的数据。

这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。

至于这一阶段发生什么？简而言之，首先浏览器发送过来的请求先经过控制器，控制器进行逻辑处理和请求分发，接着会调用模型，这一阶段模型会获取 redis db 以及 MySQL 的数据，获取数据后将渲染好的页面，响应信息会以响应报文的形式返回给客户端，最后浏览器通过渲染引擎将网页呈现在用户面前。

MVC 是一个设计模式，将应用程序分成三个核心部件：模型（model）-- 视图（view）–控制器（controller），它们各自处理自己的任务，实现输入、处理和输出的分离。

6.服务器返回一个HTTP响应

经过前面的几个步骤，服务器收到了我们的请求，也处理我们的请求，到这一步，它会把它的处理结果返回，也就是返回一个HTTP响应。
HTTP响应与HTTP请求相似，HTTP响应也由3个部分构成，分别是：响应行，响应头，响应主体。

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

＜html＞
＜head＞
＜title＞http＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞

1.响应行：
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。

格式:    HTTP-Version Status-Code Reason-Phrase CRLF
例如:    HTTP/1.1 200 OK \r\n

– 协议版本：是用http1.0还是其他版本
– 状态描述：状态描述给出了关于状态代码的简短的文字描述。比如状态代码为200时的描述为 ok
– 状态代码：状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。如下

1xx：信息性状态码，表示服务器已接收了客户端请求，客户端可继续发送请求。
100 Continue
101 Switching Protocols
2xx：成功状态码，表示服务器已成功接收到请求并进行处理。
200 OK 表示客户端请求成功
204 No Content 成功，但不返回任何实体的主体部分
206 Partial Content 成功执行了一个范围（Range）请求
3xx：重定向状态码，表示服务器要求客户端重定向。
301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL
302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源
303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源
304 Not Modified 服务器内容没有更新，可以直接读取浏览器缓存
307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET，但实际使用时并不一定，307则更多浏览器可能会遵循这一标准，但也依赖于浏览器具体实现
4xx：客户端错误状态码，表示客户端的请求有非法内容。
400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解
401 Unauthonzed 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
403 Forbidden 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
404 Not Found 请求的资源不存在，例如，输入了错误的URL
5xx：服务器错误状态码，表示服务器未能正常处理客户端的请求而出现意外错误。
500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求
503 Service Unavailable 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常

2.响应头：
响应头部：由关键字/值对组成，每行一对，关键字和值用英文冒号":"分隔，典型的响应头有：

3.响应主体
包含着我们需要的一些具体信息，比如cookie，html,image，后端返回的请求数据等等。这里需要注意，响应正文和响应头之间有一行空格，表示响应头的信息到空格为止，下图是fiddler抓到的请求正文，红色框中的：响应正文：

7.浏览器解析渲染页面

浏览器拿到响应文本 HTML 后，接下来介绍下浏览器渲染机制

浏览器解析渲染页面分为一下五个步骤：

• 根据 HTML 解析出 DOM 树
• 根据 CSS 解析生成 CSS 规则树
• 结合 DOM 树和 CSS 规则树，生成渲染树
• 根据渲染树计算每一个节点的信息
• 根据计算好的信息绘制页面

1.根据 HTML 解析 DOM 树

根据 HTML 的内容，将标签按照结构解析成为 DOM 树，DOM 树解析的过程是一个深度优先遍历。即先构建当前节点的所有子节点，再构建下一个兄弟节点。
在读取 HTML 文档，构建 DOM 树的过程中，若遇到 script 标签，则 DOM 树的构建会暂停，直至脚本执行完毕。

2.根据 CSS 解析生成 CSS 规则树

解析 CSS 规则树时 js 执行将暂停，直至 CSS 规则树就绪。
浏览器在 CSS 规则树生成之前不会进行渲染。

3.结合 DOM 树和 CSS 规则树，生成渲染树

DOM 树和 CSS 规则树全部准备好了以后，浏览器才会开始构建渲染树。
精简 CSS 并可以加快 CSS 规则树的构建，从而加快页面相应速度。

4.根据渲染树计算每一个节点的信息（布局）

布局：通过渲染树中渲染对象的信息，计算出每一个渲染对象的位置和尺寸
回流：在布局完成后，发现了某个部分发生了变化影响了布局，那就需要倒回去重新渲染。

5.根据计算好的信息绘制页面

绘制阶段，系统会遍历呈现树，并调用呈现器的“paint”方法，将呈现器的内容显示在屏幕上。
重绘：某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会引起浏览器的重绘。
回流：某个元素的尺寸发生了变化，则需重新计算渲染树，重新渲染。

8.TCP四次挥手

当数据传送完毕，需要断开 tcp 连接，此时发起 tcp 四次挥手。

• 发起方向被动方发送报文，Fin、Ack、Seq，表示已经没有数据传输了。并进入 FIN_WAIT_1 状态。(第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧)
• 被动方发送报文，Ack、Seq，表示同意关闭请求。此时主机发起方进入 FIN_WAIT_2 状态。(第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧)
• 被动方向发起方发送报文段，Fin、Ack、Seq，请求关闭连接。并进入 LAST_ACK 状态。(第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧)
• 发起方向被动方发送报文段，Ack、Seq。然后进入等待 TIME_WAIT 状态。被动方收到发起方的报文段以后关闭连接。发起方等待一定时间未收到回复，则正常关闭。(第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧)

知识拓展
为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
　    这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

参考文章

1、从输入页面地址到展示页面信息都发生了些什么？https://github.com/kaola-fed/blog/issues/271

2、前端经典面试题: 从输入 URL 到页面加载发生了什么？https://segmentfault.com/a/1190000006879700

3、TCP 的三次握手四次挥手 https://juejin.im/post/5a0444d45188255ea95b66bc

4、访问 Web，tcp 传输全过程（三次握手、请求、数据传输、四次挥手）https://blog.csdn.net/sinat_21455985/article/details/53508115

5、浏览器发送 http 请求过程分析 https://segmentfault.com/a/1190000010156898

6、谢希仁著《计算机网络》第四版 https://book.douban.com/subject/26960678/

7、图解 http https://book.douban.com/subject/25863515/

8、从点击到呈现 — 详解一次HTTP请求（2）https://zrj.me/archives/589

9、What really happens when you navigate to a URL http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/