本文旨在用最通俗的语言讲述最枯燥的基本知识
面试过前端的老铁都知道，对于前端，面试官喜欢一开始先问些 HTML5 新增元素啊特性啊，或者是 js 闭包啊原型啊，或者是 css 垂直水平居中怎么实现啊之类的基础问题，当你能倒背如流的回答这些之后，面试官脸上会划过一丝诡异的笑容，然后晴转多云，故作深沉的清一下嗓子问：从用户输入 URL 到浏览器呈现页面经过了哪些过程？如果你懂，巴拉巴拉回答了一堆，他又接着问：那网页具体是如何渲染出来的呢？如果你还懂，又巴拉巴拉的回答了一堆，他还会继续问：那你有哪些网页性能优化的经验呢？当你还能巴拉巴拉的回答了一堆之后，面试官这下心里就有逼数了，转而去问你一些和技术无关的七大姑八大姨之类的事情，这时候，你就可以欢呼你的 offer 基本已经到手了。
那么各位问题来了，真正轮到你去面试的时候你能否很好的回到这些问题呢？
用户输入 URL 回车之后，浏览器到底做了啥？
页面渲染的完整流程是怎样的？
前端性能优化有哪些经验？
如果不能，那我们往下走：（有人会疑惑说不是讲前端吗？为毛要讲 TCP、DNS 这些与前端无关的知识? 别慌咯，跟着文章走吧，多学无害！）
文章提纲：
TCP
UDP
套接字 socket
HTTP 协议
DNS 解析
HTTP 请求发起和响应
页面渲染的过程
页面的性能优化
TCP 连接
TCP：Transmission Control Protocol，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。说的这么专业，有啥用呢？先来举个栗子吧还记得小时候我们做的纸杯电话么？两个纸杯用一条绳子连到一起，两个各拿一个纸杯把线拉直，一个对着纸杯讲，一个用耳朵对着纸杯听。
这其实就是一种最简单的连接通信，两人通过一根线连接起来，声音从这边的纸杯发出通过线传输到另一个纸杯接收，扩展到现在家家户户都有的固定电话也是如此，它的通信也是建立在双方可接受并且信任的基础上进行，如：
A 拿起电话，拨通 0775-6532122，开始呼叫 B
B 听到电话声响起，拿起电话，此时 A 收到 B 已经拿起电话的声音
双方开始讲话。
回到我们的 tcp 协议，其实它和上面所说的电话协议差不多，只不过电话的协议是服务于电话通信，而 tcp 是服务于网络通讯的一种协议，类似的，通讯双方建立一次 tcp 连接，也需要经过三个步骤（握手）。
客户端发送 syn 包 (syn=j) 到服务器，并进入 SYN_SEND 状态，等待服务器确认。
服务器收到 syn 包，必须确认客户的 SYN（ack=j+1），同时自己也发送一个 SYN 包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态。
客户端收到服务器的 SYN+ACK 包，向服务器发送确认包 ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。
上面几个唧唧歪歪的英文看的有点懵逼，翻译一下吧：(大家最好记一下这些状态码，在服务器连接数的性能优化中会经常用到)
SYN:synchronous 建立联机 ACK:acknowledgement 确认 SYN_SENT: 请求连接 SYN_RECV: 服务端被动打开后, 接收到了客户端的 SYN 并且发送了 ACK 时的状态。再进一步接收到客户端的 ACK 就进入 ESTABLISHED 状态。
值得注意的是：tcp 在握手过程中并不携带数据，(就像你打电话给酒店订房时，在确认对方是酒店客服人员之前，你也不会马上把身份证号码报给他吧？)，而是在三次握手完成之后，才会进行数据传送。
至于它的应用场景，其实是根据它本身的特点而定的，比如对网络通讯质量有要求，需要保证数据准确性时，就需要用到 TCP 协议了，如 HTTP、ftp 等文件传输协议、或一些邮件传输协议（SMTP、pop 等）
UDP 协议
(UDP 协议并非本文需要重点着笔的内容，但是讲到 TCP 了，作为他的互补兄弟，在此掠过一笔)
UDP：User Datagram Protocol 用户数据报协议相比于 TCP 的面向连接需要反复确认的繁琐步骤，UDP 是一中性格特立独行并且主观性超强的非面向连接的协议，使用 udp 协议经常通信并不需要建立连接，它只是负责把数据尽可能快的发送出去，简单粗暴，并且不可靠，而在接收端，UDP 把每个消息断放入队列中，接收端程序从队列中读取数据。
有人会说，UDP 协议这么不可靠，为啥还会造出来呢？话说回来，天底下没有无用之人，只有你不懂用的人而已，虽然 UDP 不可靠，但是它的传输速度快，效率高，在一些对数据准确性要求不高的场景，UDP 就变得很有用了，比如 qq 语音、qq 视频。
套接字 socket
为什么要说嵌套字？那是因为就像前面说的，TCP 或 UDP 都是一种协议，也就是计算机网络通信中在传输层的一种协议，简单地说，就是一种约定，就像合作双方的合同一样，然后合同是死的，只有履行合同才是实质性的行动，因此无论是 TCP 还是 UDP 要产生作用，都需要有实际的行为去执行才能体现协议的作用，那么，有什么办法让这些协议作用呢？这就要说到 socket 了。
socket：也叫嵌套字，是一组实现 TCP/UDP 通信的接口 API，也就是说无论 TCP 还是 UDP，通过对 scoket 的编程，都可以实现 TCP/UCP 通信，作为一个通信链的句柄，它包含网络通信必备的 5 种信息：
连接使用的协议
本地主机的 IP 地址
本地进程的协议端口
远地主机的 IP 地址
远地进程的协议端口
可见，socket 包含了通信本方和对方的 ip 和端口以及连接使用的协议（TCP/UDP）。通信双方中的一方（暂称：客户端）通过 scoket（嵌套字）对另一方（暂称：服务端）发起连接请求，服务端在网络上监听请求，当收到客户端发来的请求之后，根据 socket 里携带的信息，定位到客户端，就相应请求，把 socket 描述发给客户端，双方确认之后连接就建立了。因此套接字之间的连接过程有三个步骤：
服务器监听: 服务器实时监控网络状态等待客户端发来的连接请求
客户端请求: 客户端根据远程主机服务器的 IP 地址和协议端口向其发起连接请求
连接确认: 服务端收到套接字的连接请求之后，就响应请求，把服务端套接字描述发给客户端，客户端收到后一旦确认，则双方建立连接，进行数据交互。
通常情况下 socket 连接就是 TCP 连接，因此 socket 连接一旦建立, 通讯双方开始互发数据进行通信，直到其中一方或双方断开连接为止。
socket 在即时通讯（qq 等各种聊天软件）等应用上应用广泛。
HTTP 协议
HTTP 协议：Hypertext Transfer Protocol 也叫超文本传送协议，它是一种基于 TCP/IP 协议栈、在表示层和应用层上的协议（TCP 在传输层的协议），通俗一点说就是：
TCP/IP 是位于传输层上的一种协议，用于在网络中传输数据；
HTTP 协议是应用层协议，基于 TCP 协议，用于包装数据，程序使用它进行通信，可以简单高效的处理通信中数据的传输和识别处理
而在现在应用非常广泛的 HTTP 连接则是建立在 HTTP 协议上的、处于应用层中的一种具体应用。上面说到 socket 连接一旦建立就保持连接状态，而 HTTP 连接则不一样，它基于 tcp 协议的短连接，也就是客户端发起请求，服务器响应请求之后，连接就会自动断开，不会一直保持。
URL
前面讲了 tcp、udp、http… 等等都是为了讲一个具体问题而做的知识点铺垫，那就是：我们开发的 web 应用中请求的发起和响应，是一个怎样的底层原理。我们都知道，web 应用绝大部分都是通过 HTTP 来进行请求的，而 URL 则是 HTTP 用来做连接建立和传输数据的一种具体实现，因此在此要简单讲一下 URL。
URL：Uniform Resource Locator 统一资源定位符。说白了就是网络上用来标识具体资源的一个地址，包含了用户查找该资源的信息，HTTP 使用它来传输数据和建立连接一个 URL 有以下组成部分：
协议
服务器地址（域名或 IP+ 端口）
路径
文件名
比如：https://www.baidu.com/index.html 其中
https:// 是一种协议 当然，HTTP 也是 ftp 也是 …
www.baidu.com 是服务器地址，当然你知道百度的 IP 也可以, 例如我用 ping 命令得到百度的 ip
14.215.177.39，那么我可以用 http://14.215.177.39 打开百度
index.html 包含了路径和文件名，当然通常 index.html 是可以省略的，所以你打开百度时，并没有看到这个。
DNS
DNS:Domain Name Server，域名服务器。是进行域名 (domain name) 和与之相对应的 IP 地址 (IP address)转换的服务器。DNS 中保存了一张域名 (domain name) 和与之相对应的 IP 地址 (IP address)的表，以解析消息的域名。在平时我们进行开发时，后端提供的接口地址通常是有 IP 地址加上端口号（8080 什么鬼的）组成的，但是当我们把网站发布出去时，通常都需要把 IP 改成用域名。为什么呢？你想想哦，比如谷歌的地址是 89.12.21.221:9090, 百度的地址是 132.21.33.221:8766。。。这么一看你根本没有欲望是记住这些乱七八糟的数字吧？但是域名就不一样了，比如谷歌的 google.com，百度的 baidu.com 是不是一遍就记住了呢？所以为了处理这个问题，就需要用域名去映射 IP 地址，达到易记易用的目的。
因此，当用户在浏览器输入 https://www.baidu.com 回车时，它经历了以下步骤：
浏览器根据地址去本身缓存中查找 dns 解析记录，如果有，则直接返回 IP 地址，否则浏览器会查找操作系统中（hosts 文件）是否有该域名的 dns 解析记录，如果有则返回。
如果浏览器缓存和操作系统 hosts 中均无该域名的 dns 解析记录，或者已经过期，此时就会向域名服务器发起请求来解析这个域名。
请求会先到 LDNS（本地域名服务器），让它来尝试解析这个域名，如果 LDNS 也解析不了，则直接到根域名解析器请求解析
根域名服务器给 LDNS 返回一个所查询余的主域名服务器（gTLDServer）地址。
此时 LDNS 再向上一步返回的 gTLD 服务器发起解析请求。
gTLD 服务器接收到解析请求后查找并返回此域名对应的 Name Server 域名服务器的地址，这个 Name Server 通常就是你注册的域名服务器（比如阿里 dns、腾讯 dns 等）
Name Server 域名服务器会查询存储的域名和 IP 的映射关系表，正常情况下都根据域名得到目标 IP 记录，连同一个 TTL 值返回给 DNS Server 域名服务器
返回该域名对应的 IP 和 TTL 值，Local DNS Server 会缓存这个域名和 IP 的对应关系，缓存的时间有 TTL 值控制。
把解析的结果返回给用户，用户根据 TTL 值缓存在本地系统缓存中，域名解析过程结束。
HTTP 请求发起和响应
如果这篇文章的主题是网络通信，那到这里已经可以告一段落了，但今天我们要讲的是 web 应用中请求的发起和响应以及页面渲染的原理，因此以上只是铺垫。在一个 web 程序开发中，一般都有前端和后端之分，前端负责向后端请求数据和展示页面，后端负责接收请求和做出响应发回给前端，他们之间的协作的桥梁是什么呢？是 APIAPI 是什么？不就是一个 URL 吗？URL 又是啥呢？上面说到就是 HTTP 连接的一种具体的载体因此，无论对于前端或者是后端，理解 HTTP，无论是对自身对编程的理解，还是和同事协作，都是好处大大的，下面，根据上面各个知识点的理解，我们来整理一下并解决一下上面提到的第一个问题：从用户输入 URL，到浏览器呈现给用户页面，经过了什么过程
用户输入 URL，浏览器获取到 URL
浏览器 (应用层) 进行 DNS 解析（如果输入的是 IP 地址，此步骤省略）
根据解析出的 IP 地址 + 端口，浏览器（应用层）发起 HTTP 请求，请求中携带（请求头 header（也可细分为请求行和请求头）、请求体 body），
header 包含：
请求的方法（get、post、put..）
协议（http、https、ftp、sftp…）
目标 url（具体的请求路径已经文件名）
一些必要信息（缓存、cookie 之类）
body 包含：
请求的内容
请求到达传输层，tcp 协议为传输报文提供可靠的字节流传输服务，它通过三次握手等手段来保证传输过程中的安全可靠。通过对大块数据的分割成一个个报文段的方式提供给大量数据的便携传输。
到网络层，网络层通过 ARP 寻址得到接收方的 Mac 地址，IP 协议把在传输层被分割成一个个数据包传送接收方。
数据到达数据链路层，请求阶段完成
接收方在数据链路层收到数据包之后，层层传递到应用层，接收方应用程序就获得到请求报文。
接收方收到发送方的 HTTP 请求之后，进行请求文件资源（如 HTML 页面）的寻找并响应报文
发送方收到响应报文后，如果报文中的状态码表示请求成功，则接受返回的资源（如 HTML 文件），进行页面渲染。
页面的渲染
当一个请求的发起和响应都完成之后，浏览器就会收到响应内容，但浏览器收到的是一串串的代码或 URL 链接，怎么把这些代码转化成用户可以看得懂的界面呈现出来，就是浏览器的工作了。目前市场上的浏览器已经不下百种，各个浏览器根据内核又可以分成几大类，每一类浏览器对页面的渲染原理和过程有所差异。
但总的来说，各个浏览器渲染页面都基本遵循如下图的流程：
图中有几处英文词汇可能不好理解，没关系，先做一下解释：
HTML parser：HTML 解析器，其本质是将 HTML 文本解释成 DOM tree。
CSS parser：CSS 解析器，其本质是讲 DOM 中各元素对象加入样式信息
JavaScript 引擎：专门处理 JavaScript 脚本的虚拟机，其本质是解析 JS 代码并且把逻辑（HTML 和 CSS 的操作）应用到布局中，从而按程序要的要求呈现相应的结果
DOM tree: 文档对象模型树，也就是浏览器通过 HTMLparser 解析 HTML 页面生成的 HTML 树状结构以及相应的接口。
render tree：渲染树，也就是浏览器引擎通过 DOM Tree 和 CSS Rule Tree 构建出来的一个树状结构，和 dom tree 不一样的是，它只有要最终呈现出来的内容，像 <head> 或者带有 display:none 的节点是不存在 render tree 中的。
layout：也叫 reflow 重排，渲染中的一种行为。当 rendertree 中任一节点的几何尺寸发生改变了，render tree 都会重新布局。
repaint：重绘，渲染中的一种行为。render tree 中任一元素样式属性（几何尺寸没改变）发生改变了，render tree 都会重新画，比如字体颜色、背景等变化。
所以，根据关键词汇的解释以及顺着流程图的流程，可以总结出，浏览器解析渲染页面主要包括以下过程：
浏览器通过 HTMLParser 根据深度遍历的原则把 HTML 解析成 DOM Tree。
将 CSS 解析成 CSS Rule Tree（CSSOM Tree）。
根据 DOM 树和 CSSOM 树来构造 render Tree。
layout：根据得到的 render tree 来计算所有节点在屏幕的位置。
paint：遍历 render 树，并调用硬件图形 API 来绘制每个节点。
前端性能优化
对于页面渲染基本上这样就是一个的流程，看完之后，有没有什么感觉在实际编码中可以优化的点呢？没有吧？因为很多细节都没有讲述，因此为了找到可优化的点，在此对页面渲染过程的几个关键步骤做一下陈述：
1. HTML 解析：
上面讲到，HTML 解析是浏览器的 HTML 解析器把 HTML 解析成 dom tree，而在解析过程，浏览器根据 HTML 文件的结构从上到下解析 html，HTML 元素是以深度优先的方式解析，而 script、link、style 等标签会使解析过程产生阻塞，阻塞的情况有：
外部样式会阻塞内部脚本的执行。
外部样式与外部脚本并行加载，但外部样式会阻塞外部脚本执行。
如果外部脚本带有 async 属性，则外部脚本的加载与执行不受外部样式影响
如果 link 标签是动态创建（js 生成），不管有无 async 属性，都不会阻塞外部脚本的加载与执行。
2. CSS 解析:
CSS Parser 作用就是将很多个 CSS 文件中的样式合并解析出具有树形结构 Style Rules，在对样式解析的过程中，默认 CSS 选择器是从右往左进行解析的。至于为什么是从右到左，而不是从左到右、也是不会从左到左 … 下面举个栗子来说一下：假如现在有这样的一个样式:
#parent .ch1 .dh1 {}
.fh1 .ch1 .dh1{}
.ah1 .ch1 .eh1 {}
#parent .fh1 {}
.ch1 .dh1{}
我们来比较从左到右和从右到左两种方式的结果：从两个图的比较就可以看几点：
右边的 tree 复杂度要比左边的低
右边的 tree 公用样式重合度比左边的低
右边的 tree 从根开始的节点数要比左边的少
可能光看这几点没看出什么问题，但你要知道：浏览器中的 css 解析器负责 css 的解析，并为每个节点计算出样式，因此虽然 css 解析器要做的事情不多，但要每个节点都要进行遍历查找计算，计算量极大，因此解析的方式是决定其性能的关键点。就如
#parant .a{}
和
.a{}
估计绝大多数人都会认为前者要比后者性能更优，其实不然，在解析过程中 #paran .a{}意味着 css 解析器要先找到 #parent 再找到他下面的.a 所在节点而后者可以直接定位到.a{}因此哪一种方式更优，显而易见。
3. 脚本执行:
浏览器解析 HTML 时，当遇到 <script> 标签就会立即解析脚本，同时阻塞解析文档直到脚本执行完毕（你可能问为什么要这样设计，明显啊，脚本的执行是改变 css 和 dom，会造成 render tree 不停的重绘和重排的），而当 <script> 是引入外部 js 文件时，会阻塞到 js 文件下载完成并且执行完成为止（除非加了 defer 或者 async 属性）。脚本在解析过程中将对 dom 或 css 的操作解析出来加入到 DOM Tree 和 cssom 中。
性能优化
把这些度讲完之后，对于性能优化的点，相信大家心里都有点 X 数了吧，下面简单总结一下日常开发过程中常用的性能优化的地方：
1. 对于 css：
优化选择器路径：健全的 css 选择器固然是能让开发看起来更清晰，然后对于 css 的解析来说却是个很大的性能问题，因此相比于 .a .b .c{}，更倾向于大家写.c{}。
压缩文件：尽可能的压缩你的 css 文件大小，减少资源下载的负担。
选择器合并：把有共同的属性内容的一系列选择器组合到一起，能压缩空间和资源开销
精准样式：尽可能减少不必要的属性设置，比如你只要设置 {padding-left:10px} 的值, 那就避免 {padding:0 0 0 10px} 这样的写法
雪碧图：在合理的地方把一些小的图标合并到一张图中，这样所有的图片只需要一次请求，然后通过定位的方式获取相应的图标，这样能避免一个图标一次请求的资源浪费。
避免通配符：.a .b *{} 像这样的选择器，根据从右到左的解析顺序在解析过程中遇到通配符（*）回去遍历整个 dom 的，这样性能问题就大大的了。
少用 Float:Float 在渲染时计算量比较大，尽量减少使用。
0 值去单位：对于为 0 的值，尽量不要加单位，增加兼容性
2. 对于 JavaScript：
尽可能把 script 标签放到 body 之后，避免页面需要等待 js 执行完成之后 dom 才能继续执行，最大程度保证页面尽快的展示出来。
尽可能合并 script 代码，
css 能干的事情，尽量不要用 JavaScript 来干。毕竟 JavaScript 的解析执行过于直接和粗暴，而 css 效率更高。
尽可能压缩的 js 文件，减少资源下载的负担
尽可能避免在 js 中逐条操作 dom 样式，尽可能预定义好 css 样式，然后通过改变样式名来修改 dom 样式，这样集中式的操作能减少 reflow 或 repaint 的次数。
尽可能少的在 js 中创建 dom，而是预先埋到 HTML 中用 display:none 来隐藏，在 js 中按需调用，减少 js 对 dom 的暴力操作。
3. 对于 HTML：
避免再 HTML 中直接写 css 代码。
使用 Viewport 加速页面的渲染。
使用语义化标签，减少 css 的代码，增加可读性和 SEO。
减少标签的使用，dom 解析是一个大量遍历的过程，减少无必要的标签，能降低遍历的次数。
避免 src、href 等的值为空。
减少 dns 查询的次数。
以上就是文章的所有内容，总的来说，入门的文章是领人入门，进阶的文章带人进阶，就像 Java 的书会有入门教程和进阶教程一样，这个文章里边写的大部分知识点都是为了让读者对页面请求和呈现有一个铺垫和整体的认知，由于涉及的知识点过多，每个知识点拎出来都可以写一本书，所以大家把本文作为一个引路文，需要对某个知识点进行深入研究时再找相关书籍研究，不喜勿喷。
觉得本文对你有帮助？请分享给更多人关注「编程无界」，提升装逼技能