这真的是一道很经典的面试题，经典到它基本包含了前端的所有知识点。能比较全面的考察应聘者知识的掌握程度，还可以考察面试者的对前端的一个整体思考
-
用户输入：地址栏会判断输入的关键字是搜索内容还是请求的URL
-
若是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的URL
-
若判断输入内容符合URL规则，那么地址栏会根据规则合成完整的URL
-
浏览器进程通过进程间通信（IPC）把url请求发送给网络进程
-
网络进程接收到url请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回到浏览器进程
-
如果缓存没有命中，网络进程向web服务器发起http请求
- 进行DNS解析，获取服务器ip地址，若是HTTPS请求，还需要建立TLS连接
- 利用ip地址和服务器建立tcp连接
- 构建请求头信息
- 发送请求头信息
- 服务器响应后，网络进程接收响应头和响应信息，并解析响应内容
-
网络进程解析响应流程
检查状态码
-
重定向：接收到服务器返回的响应头后，网络进程开始解析响应头，如果发现返回的状态码是301或者302，就会去响应头的Location字段中读取重定向的地址，然后新的一轮
-
响应数据类型处理
处理了跳转信息之后，就要根据请求的数据类型（Content-Type）决定如何显示响应体的内容
-
渲染阶段
-
准备渲染进程，默认情况下Chrome会为每个页面分配一个渲染进程，但是如果从一个页面中打开了另一个新页面，并且新页面和当前页面属于同一站点（根域名相同，协议相同）的话，那么新页面就会复用父页面的渲染进程（process-par-site-instance）
-
提交文档（文档指的是URL请求返回的响应体数据）
- ‘提交文档’的消息是由浏览器进程发出的，渲染进程接收到后，会和网络进程建立传输数据的管道
- 当文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程
- 浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态，地址栏的URL，前进后退的历史状态，病更新web页面
-
解析HTML生成DOM树
-
渲染引擎将接收的文本转换为浏览器可以理解的结构---styleSheets
-
转换styleSheets中的属性值，使其标准化
-
计算出DOM树中每个节点的具体样式（可以通过chrome的控制台查看每个元素最终的样式：Element -> Computed ）
-
布局阶段
-
创建布局树：
- 遍历DOM树中所有可见节点，并把这些节点加到布局中
- 而不可见的节点会被布局树忽略掉
-
布局计算
- 渲染引擎为特定节点生成专用的图层（拥有层叠上下文属性的元素和需要裁剪的地方会被创建为新图层），并生成一棵对应的图层树
- 渲染引擎吧一个图层的绘制拆分为很多小的绘制指令，然后把这些指令按照顺序组成一个待绘制列表，实际上执行绘制操作的是渲染引擎中的合成线程来完成的
- 一个页面可能很大，但是用户只能看到其中的一部分，这部分就叫做视口，图层可能很大，但是全部渲染出来又没必要，造成资源的浪费，基于这个原因，合成线路会将图层划分为图块（通常是256x256或者512x512）
- 然后合成线程会按照视口附近的图块优先生成位图（栅格化：图块->位图，过程使用GPU加速），渲染进程维护了一个栅格化的线程池，一旦所有的图块都被光栅化，合成线路就会生成一个绘制的命令--DrawQuad，然后将该命令提交给浏览器进程
- 浏览器进程中有一个viz组件，用来接收合成线路发过来的DrawQuad命令，然后根据指令将页面内容绘制到内存中，最后显示在屏幕上
TCP
tcp(Transmission Control Protocol):传输控制协议，是一种面向连接的，可靠的，基于字节流的传输层通信协议，由IEFE的RFC 793定义，在因特网协议族中，TCP层是位于IP层之上，应用层之下的中间层，不同主机的应用层之间经常需要可靠的，像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。应用层向TCP层发送用于网间传输的，用8位字节标示的数据流，然后TCP把数据流分割成适当长度的报文段，之后TCP把结果包传给IP层由它来透过网络将包传送给接收端实体的TCP层，数据在TCP层成为流（stream），数据分组成为分段（segment）,数据在IP层称为datagram,数据分组称为分片（fragment）
TCP协议的运行可分为三个阶段，连接创建，数据传送，连接终止
创建通路也就是用我们常说的三次握手（three-way handshake）创建一个连接。通常是由一端（服务器端）打开一个套接字（socket）然后监听来自另一端（客户端）的连接，这就是所谓的被动打开（passive open）,服务器端被动打开之后，客户端就可以创建主动打开（active open）。服务端执行了listen函数后，就在服务端创建起两个队列：
SYN队列：存放完成了二次握手的结果，队列长度由listen函数的参数backlog指定ACCEPT队列：存放完成了三次握手的结果，队列长度由listen函数的backlog指定
三次握手：
- 客户端（通过执行connect函数）向服务器端发送一个
SYN包，请求一个主动打开，该包携带客户端为这个连接请求而设定的随机数A作为消息序列号 - 服务器端收到一个合法的
SYN包后，把该包放入SYN队列中，回送一个SYN/ACK，ACK的确认码应为A + 1，SYN/ACK包本身携带一个随机产生的序列B - 客户端收到
SYN/ACK包后，发送一个ACK包，该包的序号被设定为A + 1,而ACK的确认码则为B + 1，然后客户端的connect函数成功返回，当服务器端收到这个ACK包的时候，把请求帧从SYN队列中移出，放至ACCEPT队列中，这是accept函数如果处于阻塞状态，可以被唤醒，从ACCEPT队列中取出ACK包，重新创建一个新的用于双向通信的socketfd,并返回
如果服务器端接到了客户端发的SYN后回了SYN-ACK后客户端掉线了，服务器端没有收到客户端回来的LCK，那么这个连接处于一个中间状态，既没成功，也没失败，于是服务器端如果在一定时间内没有收到的TCP会重发SYN-ACK。在linux下，默认的次数为5次，重试的间隔时间从1s开始每次都翻倍，5次的重试时间为1s，2s，4s，8s，16s，第5次发出后还要等32s才知道第五次的结果，所以一共需要63s，TCP才会断开这个连接
主机收到一个TCP包时，用两端的ip地址与端口号来标识这个TCP包属于哪个session。使用一张表来存储所有的session，表中的每条称作Transmission Control Block(TCB),tcb结构定义包括连接使用的源端口、目的端口、目的ip、序号、应答序号、对方窗口大小、己方窗口大小、tcp状态、tcp输入/输出队列、应用层输出队列、tcp的重传有关变量等等...
服务器端的连接数量是无限的，只受内存的限制，客户端的连接数量在过去受空闲端口数量的限制，现在有了socket选项IP_BIND_ADDRESS_NO_PORT,它通知linux内核不保留usingbind使用端口号为0时内部使用的临时端口，在connect时会自动选择端口以组成独一无二的四元组
对于不能确认的包、接收但还没读取的数据，都会占用操作系统的资源
在TCP的数据传输状态，很多重要的机制保证了TCP的可靠性和强壮型，它们包括：使用序号、对收到的 TCP报文段进行排序以及检测重复的数据；使用校验和检测报文段的错误，即无错传输；使用确认和计时器来检测和纠正丢包或者延时；流控制；拥塞控制；丢失包的重传。
参考文章
浏览器工作原理
其他还有很多，但是忘了记录 0.0 ｜有作者发现请联系我
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用？
- 本站所有资源版权均属于原作者所有，这里所提供资源均只能用于参考学习用，请勿直接商用。若由于商用引起版权纠纷，一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了？
- 找不到素材资源介绍文章里的示例图片？
- 模板不会安装或需要功能定制以及二次开发？
发表评论
还没有评论，快来抢沙发吧！