输入url到页面显示发生了什么？

布满荆棘的人生 2021-09-03 04:47 454阅读 0赞

### 输入url到页面显示发生了什么？ ###

1.浏览器查找当前URL是否存在缓存，并比较缓存是否过期。

2.DNS解析URL对应的IP。

3.建立TCP连接（三次握手）。

4.HTTP发起请求。

5.服务器处理请求，浏览器接收HTTP响应。

6.浏览器解析渲染页面。

7.关闭TCP连接（四次挥手）。

**URL**

url由这几部分组成：`协议、主机、端口、路径`

protocol（协议）

指定使用的传输协议, 最常用的是`HTTP`协议,还有`HTTPS`

hostname（主机名）

是指存放资源的服务器的域名系统(DNS) 主机名或 `IP` 地址

port（端口号）

整数，可选，省略时使用方案的默认端口，各种传输协议都有默认的端口号，如http的默认端口为80。如果输入时省略，则使用默认端口号。

path（路径）

由零或多个“/”符号隔开的字符串，一般用来表示主机上的一个目录或文件地址。

输入url

![b1d91c754d359e3773bb1a6b60602b91.png][]

我们在输入url的时候，浏览器会从历史记录，书签等找到可能对应的url,给出提示，当按下Enter键之后，如果是url是域名不是IP地址，就会进行域名解析(DNS解析)

**DNS域名解析**

地址栏输入的域名并不是最后资源所在的真实位置，域名只是与IP地址的一个映射，网络服务器的IP地址太多不好记忆，就产生了域名，一个域名对应一个IP地址，域名解析的过程是将域名还原为IP地址的过程。

1.我们本地硬盘下有一个`hosts`文件，作用是将一些常用的网址域名与其对应的`IP`地址建立一个关联“数据库”。一般来说，系统会首先自动从`hosts`文件中寻找对应的`IP`地址，如果有的话就直接使用`hosts`文件里面的`IP`地址，然后直接进行端口确认,找到则返回。

2.如果没有找到，会查找本地`DNS`解析器的缓存，是否有这个网址映射关系，找到则返回。

3.如果`hosts`与本地`DNS`解析器缓存都没有相应的网址映射关系，首先会找`TCP/IP`参数中设置的首选`DNS`服务器，在此我们叫它`本地DNS服务器`，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

4.如果上一步没有找到，即本地`DNS`服务器不知道被查询域名的`IP`地址，如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址给本地DNS服务器，当本地DNS服务器收到这个地址后，就会找下一级DNS服务器域服务器，重复上面的动作，进行查询，直至找到返回。

5.如果设置了转发，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

`递归查询：在该模式下DNS服务器接收到客户机请求，必须返回一个准确的查询结果给客户机。如果该DNS服务器本地没有存储被查询的DNS信息，那么该服务器会（替客户机）询问其他服务器，并将返回的查询结果再返回给客户机。`

`DNS缓存:DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。`

`DNS委派:DNS服务器把一个区域的子域委派给另外一台DNS服务器来管理，这样当客户端向DNS提交查询请求时，根域的DNS服务器会把这种请求转发给维护其子域的DNS服务器。`

`DNS转发:所有非本域的和在缓存中无法找到的域名查询都将转发到设置的DNS转发器上，由这台DNS来完成解析工作并做缓存，因此这台转发器的缓存中记录了丰富的域名信息。因而对非本域的查询，很可能转发器就可以在缓存中找到答案，避免了再次向外部发送查询，减少了流量。只有当服务器是非授权的，并且缓存中没有相关记录时，才会进行转发。`

**TCP连接**

为实现数据的可靠传输，`TCP`要在应用进程间建立传输连接。它是在两个传输用户之间建立一种逻辑联系，使得通信双方都确认对方为自己的传输连接端点。

建立连接前，服务器端首先被动打开其熟知的端口，对端口进行侦听。当客户端要和服务器端建立连接时，发起一个主动打开端口的请求（该端口一般为临时端口）；然后进入三次握手的过程

![573c5044de477737d49d1aa889cd6ced.png][]

可以通俗的理解为

1.A给B打电话，说能听到嘛？ `A不知道B是否能听到自己讲话。`

2.B听到A讲话了，回复下A,表示自己能听到，问下A能听到自己讲话不？`B不知道A是否知道自己听到了`。

3.这时候A可以确认两件事，B能听到自己讲话，自己也能听到B讲话，此时回复B,我能听到你说话`可以聊天了`

**为什么是三次握手**

三次握手是为了防止失效的连接请求报文段被服务端接收，从而产生错误。

`client`发出的一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达`server`。本来这是一个早已失效的报文段。但`server`收到此失效的连接请求报文段后，就误认为是`client`再次发出的一个新的连接请求。于是就向`client`发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要`server`发出确认，新的连接就建立了。但是由于现在`client`并没有发出建立连接的请求，因此不会理睬`server`的确认，也不会向`server`发送数据。而`server`却以为新的连接已经建立，并一直等待`client`发来数据。这样，`server`的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，`client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接`

**发起HTTP请求**

从客户端到服务器端的请求消息。浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：`（1）请求方法URI协议/版本（2）　请求头(Request Header)（3）　请求正文`

1.请求行：“方法URI协议/版本”例如：`GET/sample.jsp HTTP/1.1` 常用的方法有: `GET, POST, PUT, DELETE, OPTIONS, HEAD。`

2.请求头:请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

![23b48bab6b90377614eb27d9b8b26018.png][]

3.请求正文:当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息

![617129590107bdfdd5d12f21fb249e11.png][]

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

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

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

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

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

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

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

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

响应报头: ![0d968b6fdf8bc57db01137050f6cc6a6.png][]

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

![68d19bb82cfd89c35eca0b445fb70ff4.png][]

**浏览器解析渲染页面**

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

![d76117cd1daa77a7fec1d06242148baa.png][]

浏览器是边解析变渲染的过程

`1.浏览器解析HTML文件构建DOM树。`

`2.CSS资源会解析成CSS Rule Tree。`

`3.结合DOM和CSSOM构建渲染树。`

`4.浏览器开始布局渲染树并将其绘制到屏幕上。`(这个过程比较复杂 涉及到reflow(回流)和repain(重绘))， DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow过程是非常消耗性能的，应该尽可能少的减少reflow。

`渲染树和DOM树的关系`：那些不可见的DOM元素（如…，display=none的元素）不会被插入渲染树中；还有像一些节点是绝对定位或浮动，这些节点会在文本流之外，因此他们会在渲染树和DOM树的不同位置，渲染树标识出真实的位置，并用一个占位结构标识出他们原来的位置，而DOM树上是他们原来的位置

`如果遇到＜script＞标签，浏览器会立即执行`（暂不考虑defer及async属性），此时会出现`页面阻塞`，不仅要等待文档中JS文件下载加载完毕，还要等待JS解析执行完毕，才可以恢复HTML文档的加载解析。这是浏览器为了`防止出现JS修改DOM树`，需要重新构建DOM树的情况，`DOM`树改变浏览器需要回过头来重新渲染这部分代码，所以浏览器希望通过阻塞其他内容的下载和呈现，来避免出现更多的不必要的`Reflow`称为回流或者重排,`CSS`文件的加载不影响JS文件的加载，但是却影响`JS`文件的执行。`JS`代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

如果遇到图片资源，浏览器也会另外发出一个请求，来获取图片资源，这是异步请求，所以不会等到图片下载完，而是继续渲染后面的HTML文档,等到服务器返回图片文件，如果先前并没有为这个图片设定宽高，那么由于图片占用了一定面积，影响了后面段落的排布，浏览器会进行Reflow

**关闭TCP连接**

![b5fc5b1216fb82256206c35c6f1449d7.png][]

`tcp是全双工通信，服务端和客服端都能发送和接收数据。 tcp在断开连接时，需要服务端和客服端都确定对方将不再发送数据。`

1.A告诉B,任务处理完啦，想要断开连接，`表示A不会主动发请求了，但是还可以接收信息`。

2.B收到后，回复A我收到你的断开请求了(`这样A不会因为没有B收到应答而继续发送断开连接的请求`)，我准备下，`此时B可能还有需要发送给A的数据`。

3.`保证数据通信正常可靠地完成`，B处理完数据后，告诉A我准备好了，可以断开了，B进入超时等待状态。

4.A告诉B确认中断，B可以进行释放，连接断开。

[b1d91c754d359e3773bb1a6b60602b91.png]: /images/20210813/fad21c40437a476fbc06fdb02c0af991.png
[573c5044de477737d49d1aa889cd6ced.png]: /images/20210813/132a5fbf481f45c7944d2d14354114e9.png
[23b48bab6b90377614eb27d9b8b26018.png]: /images/20210813/e937a0f36ca84184bb3e8d56c44f9b84.png
[617129590107bdfdd5d12f21fb249e11.png]: /images/20210813/fcfa6cb2e9484a2b81caf2b075257fc9.png
[0d968b6fdf8bc57db01137050f6cc6a6.png]: /images/20210813/eeec6883c0e0404b8b686565fe5bffbb.png
[68d19bb82cfd89c35eca0b445fb70ff4.png]: /images/20210813/10e5db50de00457e8c255b0fbcdbe6d3.png
[d76117cd1daa77a7fec1d06242148baa.png]: /images/20210813/0536932c51f54b1dbc94ad40ed3063ac.png
[b5fc5b1216fb82256206c35c6f1449d7.png]: /images/20210813/447d4251e820420886f7c94995c6243a.png