大家好，上一期我们聊了「从输入URL到页面显示」的整个流程，今天继续讲剩下的两个问题。
- 如何优化页面的响应时间？
- 深入网络相关问题(dns解析、tcp连接、http请求、https加密)
一、如何优化页面的响应时间？
首先第一个问题，如何优化页面的响应时间？ 我分享一下我的回答思路，也欢迎大家一起来补充。我主要会从四个方向入手：
- 第一方向，网络层加速——最快见效。 我一般会优先启用 HTTP/2 或者 HTTP/3，配合 CDN 分发静态资源。这样可以复用连接、减少延迟，对图片、样式这些静态文件的加载速度提升特别明显。
- 第二方向，资源体积瘦身——能小则小。 图片可以考虑用 WebP 格式，搭配 srcset 做响应式适配。同时开启 Gzip 或 Brotli 压缩文本资源，像 HTML、CSS、JS 这些。体积小了，下载自然更快。
- 第三方向，消除渲染阻塞——让页面尽早出来。 我会把关键的 CSS 内联到 HTML 头部，非关键的 JS 加上 async 或 defer 延迟加载。这样浏览器不会卡在资源加载上，渲染路径会更顺畅。
- 第四方向，缓存策略——让重复访问秒开。 对不常变的静态资源设置强缓存，比如设置 Cache-Control: max-age=31536000。用户第二次访问时，基本直接从本地加载，体验接近秒开。
这是我针对第一个问题的回答。当然，优化是一个持续的过程，不同场景下策略也会有差异，大家如果有更好的实践，也欢迎一起交流。
二、深入网络相关问题
这个问题，是面试中经常被追问的——关于 DNS 解析、TCP 连接、HTTP 等网络基础。
如果面试官想重点考察网络知识，通常会从以下几个子问题展开：
（1）DNS解析是怎么进行的 （2）TCP 三次握手、四次挥手过程，为什么要需要3次握手... （3）HTTP/1.0、1.1、2.0、3.0 的主要区别 （4）HTTPS 的加密过程
（1）DNS 解析是怎么进行的？
简单来说，就是把域名转换成 IP 地址的过程。 它会按照这样的顺序查询：浏览器缓存 → 系统 hosts 文件 → 本地 DNS 服务器 → 如果本地没有，再依次向根域名服务器、顶级域名服务器、权威域名服务器发起递归查询，直到拿到对应的 IP 地址。
实际优化中，我们常会用到 DNS 预解析，通过 提前解析后续可能访问的域名，减少等待时间。
（2）TCP 三次握手、四次挥手过程
（2-1）TCP 三次握手过程的目的，是建立可靠的连接。 三次握手是这样的： 客户端向服务器发送SYN=1，seq=x的报文，请求建立连接； 服务器收到后，回复SYN=1，ACK=1，ack=x+1，seq=y+1的报文，确认连接； 客户端收到后，回复ACK=1，ack=y+1，seq=x+1的报文，确认连接。
通常面试官会追问为什么是3次握手，而不是2次。 之所以需要3次是需要保证双方的收信息和发信息能力都是正常的。
（2-2）四次挥手是断开连接的过程：
客户端 --> 服务器: FIN=1, seq=x
服务器 --> 客户端: ACK=1, ack=x+1, seq=y 至此，客户端关闭连接
服务器 --> 客户端: FIN=1, seq=z
客户端 --> 服务器: ACK=1, ack=z+1, seq=x+1 至此，服务器关闭连接
挥手多一次的原因，是因为 TCP 是全双工的，两边都需要独立关闭自己的通道。
（3）HTTP/1.0、1.1、2.0、3.0 的主要区别
HTTP/1.0：每个请求都要新建连接，用完就关，效率比较低。
HTTP/1.1：引入了持久连接（Keep-Alive），允许复用 TCP 连接，还支持管道化（但仍有队头阻塞问题），缓存机制也更完善。
HTTP/2.0：支持多路复用，头部压缩，服务端推送，解决了队头阻塞，大幅提升了并发性能。
HTTP/3.0：基于 QUIC 协议，运行在 UDP 之上，默认整合了 TLS 1.3，减少了握手次数，抗丢包能力更强，特别适合移动网络和高延迟场景。
（4）HTTPS 的加密过程
HTTPS 简单理解，就是 HTTP 加上 TLS/SSL 加密层。
它的核心是混合加密机制：
- 客户端发起请求，发送支持的加密协议版本；
- 服务器返回数字证书，里面包含公钥；
- 客户端验证证书合法性，生成对称加密的密钥，然后用公钥加密这个密钥发送给服务器；
- 服务器用私钥解密这个密钥，得到客户端生成的密钥，之后的通信就都用这个对称密钥来加密和解密。
这样既保证了安全性，又兼顾了效率。
网络这部分如果问得深入，主要是考察我们对连接建立、协议演进、安全机制有没有体系化的理解。不一定要死记硬背每个细节，但关键流程和设计思想最好能说清楚。
那今天这两个问题就先聊到这里，如果哪里有讲得不清楚，或者大家有更好的回答思路，欢迎在评论区一起交流讨论。
