浏览器的工作原理:URL从键入到页面显示的过程究竟发生了什么

大体流程

  1. 键盘或触屏输入URL并回车确认
  2. URL解析/DNS解析查找域名IP地址
  3. 网络连接发起HTTP请求
  4. HTTP报文传输过程
  5. 服务器接收数据
  6. 服务器响应请求/MVC
  7. 服务器返回数据
  8. 客户端接收数据
  9. 浏览器加载/渲染页面
  10. 打印绘制输出

URL的格式和解析

URL的完整格式包括:协议://用户名:密码@子域名(三级域名).域名(二级域名).顶级域名(一级域名):端口号/目录/文件名.文件后缀?参数=值#标志
协议/模式:表示从该计算机获取资源的方式,一般有http、https、ftp、file、telnet和news等协议;
端口号:相当于柜台的各个窗口,不同端口号对应不同的窗口,如果不写端口号,会有一个缺省值,例如,http协议默认端口号是80,https默认端口号是443
网络地址:可能是一个ip或者是域名,如果是域名的话需要通过DNS将该地址解析成IP地址。

DNS解析详解

一图了解dns工作流程:
在这里插入图片描述

DNS在解析域名的时候有两种方式:递归查询和迭代查询
递归查询的流程:浏览器会先按照这样的顺序依次查询缓存:浏览器缓存->系统缓存(本地host)->路由器缓存->ISP DNS缓存(本地名称服务器缓存)。如果附近的本地DNS服务器还是没有缓存我们请求的域名记录的话,这时候会根据本地DNS服务器的设置进行查询。
如果未用转发模式,则本地名称服务器再以DNS客户端的角色发送与前面一样的DNS域名查询请求转发给上一层,这里可能会经过多次转发:从本地名称服务器到权威名称服务器,到顶级名称服务器,最后到根名称服务器。转发过程和顺序可见下图。本地名称服务器发送Q2到根名称服务器(负责查询顶级名称服务器),返回A1到本地名称服务器,然后本地名称服务器再发送Q3到顶级名称服务器(负责二级名称服务器),这样依次查下去。得到结果并进行缓存。
在这里插入图片描述
在这个递归查询的过程中,对于浏览器来说是透明的,如果DNS客户端的本地名称服务器不能解析的话,则后面的查询都会以本地名称服务器为中心,全交由本地名称服务器代替DNS客户端进行查询,DNS客户端只是发出原始的域名查询请求报文,然后就一直处于坐等状态,直到本地名称服务器最终从权威名称服务器得到了正确的IP地址查询结果并返回给它。虽然递归查询是默认的DNS查询方式,但是如果有以下情况发生的话,则会使用迭代的查询方式进行。

情况一:DNS客户端的请求报文中没有申请使用递归查询,即在DNS请求报头部的RD字段没有置1。

情况二:DNS客户端的请求报文中申请使用的是递归查询(也就是RD字段置1了),但在所配置的本地名称服务器上是禁用递归查询了(即在应答DNS报文头部的RA字段置0)。

迭代查询的流程
开始也是从浏览器缓存到系统缓存到路由缓存,如果还是没找到则客户端向本机配置的本地名称服务器(在此仅以首先DNS服务器为例进行介绍,其它备用DNS服务器的解析流程完全一样)发出DNS域名查询请求。本地名称服务器收到请求后,先查询本地的缓存,如果有该域名的记录项,则本地名称服务器就直接把查询的结果返回给客户端;如果本地缓存中没有该域名的记录,则向DNS客户端返回一条DNS应答报文,报文中会给出一些参考信息,如本地名称服务器上的根名称服务器地址等。DNS客户端在收到本地名称服务器的应答报文后,会根据其中的根名称服务器地址信息,向对应的根名称服务器再次发出与前面一样的DNS查询请求报文。根名称服务器在收到DNS查询请求报文后,通过查询自己的DNS数据库得到请求DNS域名中顶级域名所对应的顶级名称服务器信息,然后以一条DNS应答报文返回给DNS客户端。DNS客户端根据来自根名称服务器应答报文中的对应顶级名称服务器地址信息,向该顶级名称服务器发出与前面一样的DNS查询请求报文。顶级名称服务器在收到DNS查询请求后,先查询自己的缓存,如果有请求的DNS域名的记录项,则直接把对应的记录项返回给DNS客户端,否则通过查询后把对应域名中二级域名所对应的二级名称服务器地址信息以一条DNS应答报文返回给DNS客户端。然后DNS客户端继续按照前面介绍的方法一次次地向三级、四级名称服务器查询,直到最终的权威名称服务器返回到最终的记录。如果权威名称服务器也找不到对应的域名记录,则会向DNS客户端返回一条查询失败的DNS应答报文。当然,如果这个权威名称服务器上配置了指向其它名称服务器的转发器,则权威名称服务器还会在转发器指向的名称服务器上进一步查询。另外,如果DNS客户端上配置了多个DNS服务器,则还会继续向其它DNS服务器查询。
在这里插入图片描述
所以,我们发现在递归查询中后面的查询工作是由本地名称服务器替代DNS客户端进行的(以“本地名称服务器”为中心),只需要本地名称服务器向DNS客户端返回最终的查询结果即可。而DNS迭代查询的所有查询工作则全部是DNS客户端自己进行(以“DNS客户端”自己为中心)。

应用层客户端发送HTTP请求

通过TCP/IP协议进行网络通信时,通信顺序为:应用层,传输层,网络层,数据链路层。
通过以上步骤得到ip地址后,浏览器会开始构造一个http请求,应用层客户端向服务器端发送http请求。该请求是纯文本格式的,所以在 TCP 的数据段中可以直接分析 HTTP 文本的。

传输层TCP传输报文

为了解决 TCP 协议的性能问题,Chrome 团队提出了 QUIC 协议,它是基于 UDP 实现的可靠传输,比起 TCP,它能减少很多来回(round trip)时间,还有前向纠错码(Forward Error Correction)等功能。另外,浏览器对同一个域名有连接数限制,大部分是 6,但并非将这个连接数改大后就会提升性能,Chrome 团队有做过实验,发现从 6 改成 10 后性能反而下降了,造成这个现象的因素有很多,如建立连接的开销、拥塞控制等问题,而像 SPDY、HTTP 2.0 协议尽管只使用一个 TCP 连接来传输数据,但性能反而更好,而且还能实现请求优先级。

网络层IP协议查询MAC地址

ip协议的作用是把tcp分割好的各种数据包封装到ip包里面传送给对方,而且保证确实能传到需要接受对方的mac地址,ip和mac地址是一一对应的。ARP协议可以将ip地址解析成对应的mac地址。当通信的双方不再一个局域网时,需要多次中转才能达到最终的目标。

数据达到数据链路层

在找到对方的MAC地址后,已被封装好的IP包再被封装到数据链路层的数据帧结构中,将数据发送到数据链路层传输,再通过物理层的比特流送出去。这时,客户端发送请求的阶段结束。

这些分层的意义在于分工合作,数据链路层通过 CSMA/CD 协议保证了相邻两台主机之间的数
据报文传递,而网络层的 IP 数据包通过不同子网之间的路由器的路由算法和路由转发,保证了
互联网上两台遥远主机之间的点对点的通讯,不过这种传输是不可靠,于是可靠性就由传输层
的 TCP 协议来保证,TCP 通过慢开始,乘法减小等手段来进行流量控制和拥塞避免,同时提供
了两台遥远主机上进程到进程的通信,最终保证了 HTTP 的请求头能够被远方的服务器上正在
监听的 HTTP 服务器进程收到,终于,数据包在跳与跳之间被拆了又封装,在子网与子网之间
被转发了又转发,最后进入了服务器的操作系统的缓冲区,服务器的操作系统由此给正在被阻
塞住的 accept 函数一个返回,将他唤醒。

服务器接收数据

接收端的服务器在链路层接收到数据包,再层层向上直到应用层。这过程中包括在传输层通过TCP协议将分段的数据包重新组成原来的HTTP请求报文。
之后就是服务器响应请求并返回相应文件,浏览器开始处理数据信息并渲染页面。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页