串联高频面试问题，触类旁通，一通百通！

前言

开宗明义，本瓜深知汝之痛点：前端面试知识点太杂，卿总为了面试而面试，忘了记，记了又忘，循环往复，为此叫苦不迭。

来，让本瓜带领各位都稍稍回顾一下，自己曾经在学生时代记忆元素周期表的光辉岁月。

氢、氦、锂、铍、硼、碳、氮、氧、氟、氖、钠、镁、铝、硅、磷、硫、氯、氩、钾、钙、钪、钛、钒、铬、猛、铁、钴、镍、铜、锌…

咱当初记这前三十位元素，是死记硬背的吗？答案是否定的，机智的我们用到了 串联记忆法 。

一定是像这样或类似这样去记：

第一周期：氢 氦 ———— 轻嗨：轻轻的打个了招呼：嗨！
第二周期：锂 铍 硼 碳 氮 氧 氟 氖 ———— 你皮捧碳 蛋养福奶：你很皮，手里捧了一把碳。鸡蛋能够滋养福气的奶妈
第三周期：钠 镁 铝 硅 磷 硫 氯 氩 ———— 那美女桂林留绿牙：那美女在桂林留绿色的牙齿
第四周期：钾 钙 钪 钛 钒 铬 猛 铁 钴 镍 铜 锌 ———— 贾盖坑太凡哥 猛铁骨裂痛心：“贾盖”坑了“太凡哥”，导致猛男铁汉骨头碎裂很痛心

串联联想与二元链式联想记忆的方法有相似之处，就是都要通过想象、创造和编故事来帮助我们达到双脑学习和记忆的目的。—— 出处

有木有？本瓜记得尤为清楚，以上串联起来的谐音故事简直可以写出一个狗血剧本了。尤其是“那美女（钠镁铝）”简单三字仿佛就能激起青春期的荷尔蒙。如此，学习能不有兴趣吗？兴趣是最好的老师！想忘掉都难啊！

于是乎，本瓜类比归化，将自己遇到过的高频面试问题运用串联联想法进行了“串联”整理，以期形成系统，与各位同好分享。

上图！

• 本文脑图支持：processon

撰文不易✍ 点赞鼓励👍 您的反馈📑 我的动力💪

我是掘金安东尼，愿一直与你同行！
我的个站：https://tuaran.site
My Blog：https://tuaran.github.io

串联一：

从输入URL到页面加载发生了什么？

此题是经典中的经典，可挖掘的点非常之多，亦非常之深。

一图胜万言

• 原创脑图，转载请说明出处

串联知识点：URL解析、DNS查询、TCP握手、HTTP请求、浏览器处理返回报文、页面渲染

串联记忆：共计六步，归并为一句话来记忆：UDTH，处理返回加渲染。

“UDTH” 即URL解析、DNS查询、TCP握手、HTTP请求，

“处理返回加渲染”，即浏览器处理返回报文，和页面渲染。

同时，本瓜倾情在脑图上标注了每个步骤可能考察的知识点“关键词”，真的是个个重点，不容错过！

一、URL 解析

URL（Uniform Resource Locator），统一资源定位符，用于定位互联网上资源，俗称网址。

// 示例引自 wikipedia

                    hierarchical part
        ┌───────────────────┴─────────────────────┐
                    authority               path
        ┌───────────────┴───────────────┐┌───┴────┐
  abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
  └┬┘   └───────┬───────┘ └────┬────┘ └┬┘           └─────────┬─────────┘ └──┬──┘
scheme  user information     host     port                  query         fragment


scheme       - 定义因特网服务的类型。常见的协议有 http、https、ftp、file，
               其中最常见的类型是 http，而 https 则是进行加密的网络传输。
host         - 定义域主机（http 的默认主机是 www）
domain       - 定义因特网域名，比如 baidu.com
port         - 定义主机上的端口号（http 的默认端口号是 80）
path         - 定义服务器上的路径（如果省略，则文档必须位于网站的根目录中）。
filename     - 定义文档/资源的名称
query        - 即查询参数
fragment     - 即 # 后的hash值，一般用来定位到某个位置

更多可见：

1. URL RFC
2. Wikipedia-URI

URL 编码

一般来说，URL 只能使用英文字母、阿拉伯数字和某些标点符号，不能使用其他文字和符号。此在 URL RFC 已做硬性规定。

这意味着，如果URL中有汉字，就必须编码后使用。但是麻烦的是，RFC 1738没有规定具体的编码方法，而是交给应用程序（浏览器）自己决定。这导致"URL编码"成为了一个混乱的领域。

阮老师早在 2010 年已解释了：关于URL编码- 阮一峰

这里可直接看结论：浏览器对 URL 编码会出现差异从而造成混乱，所以假设我们使用 Javascript 预先对 URL 编码，然后再向服务器提交。因为Javascript 的输出总是一致的，这样就保证了服务器得到的数据是格式统一的。

我们常使用到：encodeURI()、encodeURIComponent()；前者对整个 URL 进行 utf-8 编码，后者是对 URL 部分进行编码。

本瓜请问：你能清楚的解释 ASCII、Unicode、UTF-8、GBK 含义和关系吗？

也许我们并不太了解我们常见、常用的东西。

类型	含义
ASCII	8位一个字节,1个字节表示一个字符.即: 2 ** 8 = 256,所以ASCII码最多只能表示256个字符。
Unicode	俗称万国码,把所有的语言统一到一个编码里.解决了ASCII码的限制以及乱码的问题。unicode码一般是用两个字节表示一个字符,特别生僻的用四个字节表示一个字符。
UTF-8	“可变长的编码方式”,如果是英文字符,则采用ASCII编码,占用一个字节。如果是常用汉字,就占用三个字节,如果是生僻的字就占用4~6个字节。
GBK	国内版本,一个中文字符 == 两个字节 英文是一个字节

强缓存、协商缓存

言外之音：本瓜起初是将强缓存、协商缓存放在第三步 “HTTP 请求”中，后来了解到：如果命中了强缓存则可不再走DNS解析这步。遂将其归到此处。浏览器强缓存是按照ip还是域名缓存的？

强缓存、协商缓存是必考题。具体流程如下：

1. 浏览器在加载资源时，根据请求头的 expires和 cache-control判断是否命中强缓存，是则直接从缓存读取资源，不会发请求到服务器。

   expires：HTTP/1.0 时期，根据对比本地时间和服务器时间来判断。

   cache-control：HTTP/1.1 时期，根据相对时间来判断，如设置max-age，单位为秒。

2. 如果没有命中强缓存，浏览器一定会发送一个请求到服务器，通过Etag和Last-Modified-If验证资源是否命中协商缓存，如果命中，服务器会将这个请求返回（304），告诉浏览器从缓存中读取数据。

   【ETag、If-None-Match】成对：Etag 是服务器返回给浏览器的，If-None-Match 是浏览器请求服务器的。通过对比二者来判断，它们记录的是：文件生成的唯一标识。

   【Last-Modified，If-Modified-Since】成对：Modified-Since 是服务器返回给浏览器的，If-Modified-Since 是浏览器请求服务器的。通过对比二者来判断，它们记录的是：最后修改时间。

   注：ETag 的优先级比 Last-Modified 更高。大部分 web 服务器都默认开启协商缓存，而且是同时启用【ETag、If-None-Match】和 【Last-Modified，If-Modified-Since】。

3. 如果前面两者都没有命中，直接从服务器加载资源。

综上，强缓存和协商缓存如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；不同的是：强缓存不会发请求到服务器，协商缓存会发请求到服务器进行对比判断得出是否命中。

• 借一个流程图，暂未找到真实出处，保留引用说明坑位。

以上还有另一个重点，就是cache-control的值的分类：如“no-cache”、“no-store”、“private”等，需要细扣。此处仅暂列二三、作初步释义。

1. no-cache: 跳过当前的强缓存，发送HTTP请求，即直接进入协商缓存阶段。
2. no-store：不进行任何形式的缓存。
3. private： 这种情况就是只有浏览器能缓存了，中间的代理服务器不能缓存。

更多可见：

• Cache-Control - MDN
• 缓存（二）——浏览器缓存机制：强缓存、协商缓存 #41

二、DNS查询

递归查询

DNS 解析 URL（自右向左） 找到对应的 ip

// 例如：查找www.google.com的IP地址过程（真正的网址是www.google.com.）：

// 根域名服务器 -> com顶级域名服务器 -> google.com域名服务器 -> www.google.com对应的ip
. -> .com -> google.com. -> www.google.com.

这是一个递归查询的过程。

关于根域名的更多知识，可见
根域名的知识-阮一峰。

DNS 缓存

请记住：有 DNS 的地方，就有 DNS 缓存。

DNS存在着多级缓存，从距离浏览器的距离排序的话，有以下几种:

1.浏览器缓存 2.系统缓存 3.路由器缓存 4.IPS 服务器缓存 5.根域名服务器缓存 6.顶级域名服务器缓存 7.主域名服务器缓存。

查看缓存：

1. 浏览器查看 DNS 缓存：chrome://net-internals/#dns

2. win10 系统查看 DNS 缓存:win+R => cmd => ipconfig /displaydns

DNS 负载均衡

DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。—— 百科

三、TCP握手

DNS解析返回域名的IP之后，接下来就是浏览器要和该IP建立TCP连接了。

言外之音：TCP 的相关知识在大学基础课程《计算机网络》都有，本瓜内心苦：出来混的迟早是要还的…

TCP/IP 模型：链路层-网络层-传输层-应用层。

与之对应，OSI（开放式系统互联模型）也不能忘。通常认为 OSI 模型的最上面三层（应用层、表示层和会话层）对应 TCP/IP 模型中的应用层。wiki

在 TCP/IP 模型中，像常用的 HTTP/HTTPS/SSH 等协议都在应用层上。

三次握手、四次挥手

所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

三次握手就跟早期打电话时的情况一样：1、A：听得到吗？2、B：听得到，你呢？3、A：我也听到了。然后才开始真正对话。

1. 第一次握手(SYN=1, seq=x):

客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。

发送完毕后，客户端进入 SYN_SEND 状态。

2. 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。

3. 第三次握手(ACK=1，ACKnum=y+1)

客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1

发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。

所谓四次挥手(Four-way handshake)，是指 TCP 的连接的拆除需要发送四个包。

四次挥手像老师拖堂的场景：1、学生说：老师，下课了。2、老师：好，我知道了，我说完这点。3、老师：好了，说完了，下课吧。4、学生：谢谢老师，老师再见。

1. 第一次挥手(FIN=1，seq=x)

假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。

发送完毕后，客户端进入 FIN_WAIT_1 状态。

2. 第二次挥手(ACK=1，ACKnum=x+1)

服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。

发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

3. 第三次挥手(FIN=1，seq=y)

服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。

发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

4. 第四次挥手(ACK=1，ACKnum=y+1)

客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。

服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。

你若问我：三次握手、四次挥手的详细内容太难记了，还记不记？本瓜答：进大厂是必要的。

动图来源：两张动图-彻底明白TCP的三次握手与四次挥手

流量控制（滑动窗口）

为了增加网络的吞吐量，想将数据包一起发送过去，实现“流量控制”，这时候便产生了“滑动窗口”这种协议。

滑动窗口允许发送方在收到接收方的确认之前发送多个数据段。窗口大小决定了在收到目的地确认之前，一次可以传送的数据段的最大数目。窗口大小越大，主机一次可以传输的数据段就越多。当主机传输窗口大小数目的数据段后，就必须等收到确认，才可以再传下面的数据段。

窗口的大小在通信双方连接期间是可变的，通信双方可以通过协商动态地修改窗口大小。改变窗口大小的唯一根据，就是接收端缓冲区的大小。

拥塞控制

需求>供给 就会产生拥塞

通过“拥塞窗口”、“慢启动”、“快速重传”、“快速恢复”动态解决。

TCP 使用多种拥塞控制策略来避免雪崩式拥塞。TCP会为每条连接维护一个“拥塞窗口”来限制可能在端对端间传输的未确认分组总数量。这类似 TCP 流量控制机制中使用的滑动窗口。TCP在一个连接初始化或超时后使用一种“慢启动”机制来增加拥塞窗口的大小。它的起始值一般为最大分段大小（Maximum segment size，MSS）的两倍，虽然名为“慢启动”，初始值也相当低，但其增长极快：当每个分段得到确认时，拥塞窗口会增加一个MSS，使得在每次往返时间（round-trip time，RTT）内拥塞窗口能高效地双倍增长。—— TCP拥塞控制-wikipedia</