Interview | Enter zmheang.cn in the address bar and hit enter what happened

This is really a very classic interview question, so classic that it basically contains all the front-end knowledge points. It can comprehensively examine the applicant's mastery of knowledge, and can also examine the interviewer's overall thinking on the front end

1. User input: The address bar will determine whether the entered keyword is the search content or the requested URL

2. If searching for content, the address bar will use the browser's default search engine to synthesize a new URL with search keywords

3. If it is judged that the input content conforms to the URL rules, the address bar will synthesize the complete URL according to the rules.

4. The browser process sends the url request to the network process through inter-process communication (IPC).

5. After the network process receives the url request, it checks whether the local cache has cached the requested resource, and if so, returns the resource to the browser process

6. If the cache is not hit, the network process initiates an http request to the web server

   1. Perform DNS resolution to obtain the IP address of the server. If it is an HTTPS request, a TLS connection needs to be established.
   2. Establish a tcp connection with the server using the ip address
   3. Build request headers
   4. send request headers
   5. After the server responds, the network process receives the response header and response information, and parses the response content

7. Network process parsing response process

   Check status code

   1. Redirection: After receiving the response header returned by the server, the network process begins to parse the response header. If it finds that the returned status code is 301 or 302, it will read the redirected address in the Location field of the response header, and then create a new one. wheel

   2. Response data type handling

      After processing the jump information, it is necessary to decide how to display the content of the response body according to the requested data type ( Content-Type ).

render stage

8. Prepare the rendering process. By default, Chrome will assign a rendering process to each page, but if another new page is opened from a page, and the new page and the current page belong to the same site (same root domain name, same protocol), Then the new page will reuse the rendering process of the parent page ( process-par-site-instance )

9. Submit document (document refers to the response body data returned by the URL request)

   • ‘提交文档’的消息是由浏览器进程发出的，渲染进程接收到后，会和网络进程建立传输数据的管道
   • 当文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程
   • 浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态，地址栏的URL，前进后退的历史状态，并更新web页面

10. 解析HTML生成DOM树

11. 渲染引擎将接收的文本转换为浏览器可以理解的结构---styleSheets

12. 转换styleSheets中的属性值，使其标准化

13. 计算出DOM树中每个节点的具体样式（可以通过chrome的控制台查看每个元素最终的样式：Element -> Computed ）

布局阶段

14. 创建布局树：

1.  遍历DOM树中所有可见节点，并把这些节点加到布局中
2.  而不可见的节点会被布局树忽略掉
复制代码

15. 布局计算

1.  渲染引擎为特定节点生成专用的图层（拥有层叠上下文属性的元素和需要裁剪的地方会被创建为新图层），并生成一棵对应的图层树
2.  渲染引擎吧一个图层的绘制拆分为很多小的绘制指令，然后把这些指令按照顺序组成一个待绘制列表，实际上执行绘制操作的是渲染引擎中的合成线程来完成的
3.  一个页面可能很大，但是用户只能看到其中的一部分，这部分就叫做视口，图层可能很大，但是全部渲染出来又没必要，造成资源的浪费，基于这个原因，合成线路会将图层划分为图块（通常是256x256或者512x512）
4.  然后合成线程会按照视口附近的图块优先生成位图（栅格化：图块->位图，过程使用GPU加速），渲染进程维护了一个栅格化的线程池，一旦所有的图块都被光栅化，合成线路就会生成一个绘制的命令--**DrawQuad**，然后将该命令提交给浏览器进程
5.  浏览器进程中有一个**viz**组件，用来接收合成线路发过来的**DrawQuad**命令，然后根据指令将页面内容绘制到内存中，最后显示在屏幕上
复制代码

16. 分层
17. 合成
18. 分块

优先渲染视口附近的图块

---

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指定

三次握手：

1. 客户端（通过执行connect函数）向服务器端发送一个SYN包，请求一个主动打开，该包携带客户端为这个连接请求而设定的随机数A作为消息序列号
2. 服务器端收到一个合法的SYN包后，把该包放入SYN队列中，回送一个SYN/ACK，ACK的确认码应为A + 1，SYN/ACK包本身携带一个随机产生的序列B
3. 客户端收到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报文段进行排序以及检测重复的数据；使用校验和检测报文段的错误，即无错传输；使用确认和计时器来检测和纠正丢包或者延时；流控制；拥塞控制；丢失包的重传。

Refer to the working principle of the article browser
There are many others, but I forgot to record 0.0 ｜If the author finds it, please contact me