第 11 卷
- 检测预解析效果：通过浏览器开发者工具（Chrome的“Network”面板→“DNS”选项卡）查看
预解析状态，确认是否成功缓存解析结果，避免配置错误导致优化失效。
✅ 核心要点总结
DNS预解析的核心是“提前占位，异步并行”，将DNS解析耗时从资源加载阶段提前到页面空闲阶段，是低成本、高收益的前端优化手段。实际应用中，需结合页面资源分布，通过主动标签配置+动态
触发的方式精准预解析必要域名，同时避免过度优化，确保性能提升的同时不增加额外负担。
- TCP和UDP的基本区别是什么？
TCP（Transmission Control Protocol，传输控制协议）和UDP（User Datagram Protocol，用户数据报协议）是TCP/IP协议簇中最核心的两个传输层协议，分别面向“可靠传输”和“高效传输”设
计，核心差异体现在“可靠性、连接性、传输效率”等维度，具体区别如下：
一、核心区别对比（面试必背，10个核心维度）
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接性 | 面向连接：通信前必须通过三 | 无连接：通信前无需建立连 |
| 次握手建立TCP连接，通信结 | 接，直接发送数据，发送方和 | |
| 束后需四次挥手关闭连接 | 接收方无状态关联 | |
| 可靠性 | 可靠传输：通过序列号、确认 | 不可靠传输：无确认应答、无 |
| 应答、重传机制、流量控制、 | 重传机制，数据可能丢失、重 | |
| 拥塞控制等保障数据准确、完 | 复、乱序到达，接收方不返回 | |
| 整、有序到达，无丢失、无重 | 确认信息 |
复
| 传输效率 | 效率低：连接建立/关闭、确 | 效率高：无额外开销，数据直 |
|---|---|---|
| 认应答、重传等机制会产生额 | 接发送，延迟低、吞吐量高， | |
| 外网络开销和延迟，适用于对 | 适用于对效率要求高的场景 |
效率要求不高的场景
| 数据有序性 | 有序传输：通过序列号标记数 | 无序传输：数据以数据报为单 |
|---|---|---|
| 据顺序，接收方按序列号重组 | 位独立发送，接收方按到达顺 | |
| 数据，确保数据按发送顺序到 | 序处理，无法保证与发送顺序 | |
| 达 | 一致 |
| 流量控制 | 支持：通过滑动窗口机制，根 | 不支持：发送方无限制发送数 |
|---|---|---|
| 据接收方的缓存大小动态调整 | 据，不考虑接收方处理能力， | |
| 发送速率，避免接收方因资源 | 可能导致接收方数据溢出丢失 |
不足无法处理数据
| 拥塞控制 | 支持：通过慢启动、拥塞避 | 不支持：发送方无视网络状态 |
|---|---|---|
| 免、快速重传、快速恢复等算 | 持续发送数据，可能在网络拥 | |
| 法，检测网络拥塞并调整发送 | 塞时导致大量数据丢失，加剧 | |
| 速率，避免加剧网络拥堵 | 拥堵 | |
| 头部开销 | 头部较大：TCP头部固定20字 | 头部较小：UDP头部固定8字 |
| 节，包含序列号、确认号、窗 | 节，仅包含源端口、目的端 | |
| 口大小等多个字段，额外开销 | 口、数据长度、校验和，额外 | |
| 大 | 开销小 | |
| 适用场景 | 适用于要求可靠、有序的场 | 适用于要求高效、实时的场 |
| 景：HTTP/HTTPS、FTP、 | 景：DNS解析、视频/音频流 | |
| SMTP、SSH、数据库连接 | 传输（如直播、短视频）、实 | |
| （如MySQL）等 | 时通讯（如微信语音/视 |
频）、游戏数据传输等
21. 描述TCP的三次握手
TCP三次握手是客户端与服务端建立可靠TCP连接的过程，核心目的是通过双向通信确认双方的“发送能力”和“接收能力”均正常，同时协商初始序列号（ISN），为后续可靠数据传输奠定基础。因需三
次交互，故称为“三次握手”，具体过程基于TCP报文的“标志位”（SYN、ACK）和“序列号”（Seq）实现。
一、核心概念铺垫
• 标志位：TCP报文头部的控制位，三次握手核心使用2个： SYN（同步位，用于发起连接、同步序
列号）、 ACK（确认位，用于确认接收的报文）；
• 序列号（Seq）：用于标识TCP报文的顺序，确保数据按序重组，避免丢失或乱序；初始序列号
（ISN）由双方随机生成，不重复；
• 确认号（Ack）：表示“期望接收的下一个序列号”，即对收到的Seq的确认（Ack = 对方发送的
Seq + 1）。
此时客户端状态变为 SYN_SENT（等待服务端确认），服务端未明确客户端接收能力，仅知道客户端发送能力正常。
- 第二次握手（服务端→客户端：确认连接+同步自身序列号）：
服务端监听端口并接收客户端的SYN报文后，确认“客户端发送能力正常”，随即回复“确认+同步报文”，报文特征： SYN=1（同步自身序列号）、 ACK=1（确认客户端的SYN报文）、
Seq=y（y为服务端生成的初始序列号，如y=200）、 Ack=x+1（确认收到客户端Seq=x，期望下次接收x+1）；
此时服务端状态变为 SYN_RCVD（等待客户端最终确认），客户端未明确服务端接收能力，仅知道服务端发送能力正常。
- 第三次握手（客户端→服务端：最终确认）：
客户端接收服务端的SYN+ACK报文后，确认“服务端发送能力和接收能力均正常”，随即回复“最终确认报文”，报文特征： ACK=1（确认服务端的SYN报文）、 Seq=x+1（客户端序列号递
增）、 Ack=y+1（确认收到服务端Seq=y，期望下次接收y+1）；
此时客户端状态变为 ESTABLISHED（连接建立完成），服务端接收该ACK报文后，状态也变为 ESTABLISHED，双方正式进入“数据传输阶段”。
✅ 核心要点与面试高频问题
- 为什么需要三次握手，而非两次？
答：核心是“避免历史无效连接干扰”和“完整验证双向通信能力”。若仅两次握手，服务端发送 SYN+ACK后即认为连接建立，但客户端可能因网络延迟未收到该报文，服务端会持续等待数据，浪
费资源；三次握手通过客户端的最终ACK，确保双方均确认“对方能发、自己能收”，且无历史无效连接残留。
- 三次握手过程中，Seq序列号为什么是随机的？
答：避免与“历史连接的残留报文”混淆。若Seq固定为0或1，当网络中存在历史连接的延迟报文时，可能被当前连接误判为有效数据，导致数据传输错误；随机生成ISN可大幅降低序列号重复的
概率，保障传输安全性。
- 三次握手完成后，双方已协商好哪些核心信息？
答：双方的初始序列号（客户端ISN=x，服务端ISN=y）、窗口大小（后续流量控制使用）、MSS （最大报文段长度，避免IP分片）等。
22. 解释TCP的四次挥手断开连接过程
全站分卷索引 · 21 卷
- 1第 1 卷
- 前端面试-HTTP核心高频5问（详细版）
- 1. 描述HTTP请求的整个过程
- 完整步骤（共7步）
- ◦ 响应头：携带服务端信息（服务器软件）、响应数据信息（Content-Length、Content-
- 2. 浏览器输入URL到页面加载完成，涉及的HTTP相关技术/流程
- 阶段1：URL解析与DNS域名解析（为HTTP请求铺路）
- • 浏览器先解析URL，提取协议（http/https）、域名、端口、路径（如 https 协议，域名
- • 域名解析：将域名转为IP地址（HTTP请求最终指向IP），解析顺序：浏览器缓存→系统缓存→本
- 阶段2：建立通信连接（HTTP的传输基础）
- • HTTPS协议：在TCP连接基础上，额外完成TLS四次握手（加密通信），建立安全的TLS+TCP连接
- 阶段3：发起HTTP请求（核心HTTP流程）
- • 请求头：携带 User-Agent（浏览器标识）、 Accept（可接收的响应数据类型：
- 2第 2 卷
- ✅ 补充重要细节
- 一、HTTP持久连接的定义
- • 短连接（HTTP/1.0默认）：每次HTTP请求都新建TCP连接，请求完成后立即四次挥手关闭连接，
- • 长连接（HTTP/1.1默认）：一次TCP连接建立后，可承载多次HTTP请求/响应，连接不会立即关
- 二、HTTP Keep-Alive的工作原理（核心流程）
- 三、持久连接的核心优势
- 四、关键细节
- 核心状态码含义（面试必背）
- • 注意：200仅表示「请求处理成功」，不代表业务逻辑成功（如查询数据为空，仍可能返回200+空
- • 场景：网站域名更换（如 www.old.com → www.new.com）、页面永久下架并迁移到新页面，
- • 核心原因：服务端代码bug（如空指针、语法错误）、服务器配置错误、数据库连接失败、服务端
- ✅ 补充高频状态码（面试拓展）
- 3第 3 卷
- ✅ 补充核心要点
- 一、核心加密方案：对称加密+非对称加密（扬长避短）
- • 非对称加密（用于“密钥协商”）：
- • 对称加密（用于“实际数据传输”）：
- 二、HTTPS保证安全的完整流程（核心三步）
- ✅ 核心安全保障总结
- 一、SSL/TLS协议的定义与关系
- • SSL：早期由网景公司开发，用于解决HTTP明文传输的安全问题，主要版本有SSLv1、SSLv2、
- • TLS：IETF（互联网工程任务组）在SSLv3的基础上标准化并升级而来，弥补了SSL的安全缺陷，
- • 核心关系：TLS是SSL的“升级版”，日常所说的“SSL协议”本质上已被TLS取代，但行业习惯仍
- 二、SSL/TLS在HTTPS中的核心角色（“安全加密层”）
- 4第 4 卷
- ✅ 补充要点
- 一、核心作用：颁发并验证数字证书（身份“介绍信”）
- 二、关键作用：防止中间人攻击
- 三、其他辅助作用
- ✅ 补充要点
- • CA的核心价值是“信任背书”⸺客户端信任CA，因此信任经过CA签名的证书，进而信任服务端
- • 目前有免费CA（如Let's Encrypt，支持自动续期）和付费CA（如Symantec，提供更高等级的验证
- • 若网站使用“自签名证书”（未经过CA颁发），客户端无法验证其合法性，浏览器会直接提示“不
- • HTTP/1.1的缺陷：同一条TCP连接中，只能串行发送HTTP请求，若前一个请求阻塞（如大文件加
- • HTTP/2的改进：引入“帧（Frame）”和“流（Stream）”的概念，实现多路复用：
- 二、头部压缩（减少请求头传输开销）
- 三、服务器推送（提前加载资源，提升页面渲染速度）
- 5第 5 卷
- 一、强缓存（优先触发，无需请求服务端）
- • max-age=秒数：设置缓存有效期，从资源首次请求成功后开始计时（如 max-age=3600，表
- • private：资源仅能被浏览器缓存，禁止代理服务器缓存（适用于敏感资源，如用户个人页
- • no-store：禁止任何缓存，每次都需向服务端发起全新请求（适用于实时性极高的资源，如动
- • must-revalidate：强缓存过期后，必须向服务端验证缓存有效性，不允许浏览器直接使用过
- 二、协商缓存（强缓存过期后触发，需请求服务端验证）
- 三、缓存控制头信息的优先级与执行流程
- ✅ 补充核心要点
- 一、HTTP/3的主要特点和核心改进
- • 解决TCP队头阻塞：TCP是“面向连接的字节流协议”，同一条连接中，一个数据包丢失会导致后
- 6第 6 卷
- • 更快的连接建立：TCP建立连接需3次握手（1-RTT），HTTPS需额外TLS握手（1-RTT），共2-
- • 天然支持加密：QUIC强制加密传输，所有数据（包括连接控制信息）均通过TLS 1.3加密，无需像
- • 更好的移动网络适配：UDP对网络切换（如手机从WiFi切到4G）的适应性更强，QUIC支持“连接
- • 优先级与流量控制：支持为请求流设置优先级，且流量控制粒度更细（基于QUIC流的独立控
- 二、HTTP/3与HTTP/2的核心差异
- ✅ 补充要点
- 一、核心组成部分
- • 源站：存储原始资源的服务器（如企业官网服务器），仅负责向CDN中心节点推送资源，不直接向
- • 边缘节点：分布在各地的缓存服务器（如北京、上海、广州、海外节点），直接向用户提供资源访
- • 调度系统（GSLB）：全局负载均衡系统，核心功能是“智能选择最优边缘节点”，通过DNS解析
- 二、完整工作流程（分5步）
- 7第 7 卷
- 一、显著优势（核心价值）
- ✅ 补充要点
- 一、第一步：选择合适的CDN类型（按需求匹配）
- • 国内用户为主：选择国内CDN厂商（阿里云CDN、腾讯云CDN、百度智能云CDN），优势是国内边
- • 海外用户为主：选择国际CDN厂商（Cloudflare、Akamai、Fastly），优势是全球节点覆盖广（含
- • 全球用户覆盖：选择支持“全球节点”的厂商（如Cloudflare、阿里云国际版），或混合使用国内
- • 静态资源（CSS/JS/图片）：选择通用CDN（所有厂商均支持），重点关注“缓存策略灵活
- • 视频/大文件：选择支持“大文件加速”或“视频点播加速”的CDN（如阿里云视频CDN、腾讯云
- • 动态内容（接口/动态页面）：选择支持“动态加速”的CDN（如Cloudflare Enterprise、阿里云动
- • 小程序/移动端资源：选择对移动端优化好的CDN（如腾讯云CDN、阿里云CDN），支持
- • 初创企业/小流量项目：选择免费或低成本CDN（如Cloudflare免费版、阿里云CDN新用户套
- • 中大型项目/商业网站：选择付费商业CDN，优先保障“稳定性、节点覆盖、技术支持”，可额外
- 8第 8 卷
- • 推荐接入：CSS文件、JS文件、图片（png/jpg/webp）、字体文件、静态视频、下载包（如安装
- • 不推荐接入：动态接口（实时性高的）、用户个性化资源（如用户头像）、敏感资源（如用户隐私
- • 源站路径： <link rel="stylesheet"
- • CDN路径： <link rel="stylesheet"
- • 优化后： style.[hash:8].css（如 style.abc12345.css，内容修改后哈希值变化，自
- • 长期缓存静态资源：对带哈希值的CSS/JS/图片，设置长缓存有效期（如 Cache-Control:
- • 短期缓存易变资源：对无哈希值的易变资源（如首页Banner图），设置短期缓存（如 max-
- • 禁用缓存敏感资源：对无需缓存的资源（如动态图片验证码），设置 Cache-Control: no-
- • 配置缓存预热与刷新：新资源上线前，通过CDN控制台发起“缓存预热”，将资源提前推送至边缘
- • 允许的来源：设置为前端页面域名（如 https://www.example.com），避免任意来源（*）带
- 三、第三步：规避CDN使用的常见问题
- ✅ 核心使用原则总结
- 9第 9 卷
- • CDN厂商监控：利用CDN厂商提供的监控面板（如阿里云CDN监控、Cloudflare Analytics），实
- • 第三方监控工具：使用第三方监控工具（如UptimeRobot、监控宝），从不同地区、不同网络（电
- • 用户端监控：通过前端埋点收集用户实际访问CDN资源的状态（加载成功/失败、加载耗时），及
- • 手动干预调度：若CDN自动切换延迟，可通过CDN控制台手动将故障节点下线，强制将用户请求导
- • 缓存刷新与预热：故障节点恢复后，及时对核心资源发起缓存预热，避免恢复后大量回源请求；对
- • 架构优化：分析节点宕机原因（如硬件故障、流量过载、网络攻击），后续优化CDN节点部署（如
- ✅ 核心要点总结
- 一、DNS服务器的核心作用
- • 正向解析（最常用）：将用户输入的域名（如 www.taobao.com）解析为对应的IP地址，是浏览
- • 反向解析（辅助功能）：将IP地址解析为对应的域名，主要用于身份验证和日志记录。例如，邮件
- • 例如，用户首次访问 www.baidu.com 时，需经过“本地DNS→根DNS→顶级DNS→目标
- • 缓存有过期时间（由域名的TTL参数控制），过期后会重新发起完整解析，确保IP地址更新后能及
- 10第 10 卷
- • 若本地DNS无缓存，会作为“中转节点”，向远程的高层级DNS服务器（根DNS、顶级DNS、权威
- • 根DNS服务器不存储具体的“域名-IP”映射，仅负责识别域名的“顶级域”（如
- • 顶级DNS服务器负责管理对应顶级域下的所有二级域名（如 .com 顶级DNS管理所有 xxx.com 域
- • 权威DNS服务器是域名的“最终解析源”，存储了该域名的完整“域名-IP”映射记录（由域名所有
- • 本地DNS服务器收到IP后，会将该“域名-IP”映射缓存到本地（按TTL设置缓存时间），同时将IP
- 7. 解析完成：进入页面加载流程
- ✅ 核心要点总结
- 一、DNS预解析的核心作用
- • 减少资源加载延迟：页面中通常包含多个不同域名的资源（如CDN资源、第三方插件、图片服务器
- • 不阻塞页面渲染：DNS预解析是浏览器的“后台异步操作”，不会阻塞页面的解析和渲染，在页面
- • 提升弱网络场景体验：在高延迟、弱网络环境（如移动端），DNS解析耗时占比更高，预解析能更
- 二、前端优化中的应用方式（3种核心方案）
- 11第 11 卷
- 12第 12 卷
- 一、核心概念铺垫
- • 半关闭状态：全双工通信中，一方发送FIN后，仅关闭自己的“发送通道”，仍可接收对方发送的
- • TIME_WAIT状态：客户端最终发送ACK后，不会立即释放连接，需等待2MSL（MSL为报文最大生
- 二、四次挥手完整流程（以“客户端主动发起断开”为例）
- ✅ 核心要点与面试高频问题
- 一、连接建立与终止的可靠性保障（基础前提）
- • 三次握手：通过双向交互验证双方发送/接收能力，协商初始序列号，避免无效连接建立，为后续可
- • 四次挥手：确保双方已完成所有数据的发送与接收，通过TIME_WAIT状态避免数据残留，安全终止
- 二、数据传输过程中的核心可靠性机制
- • 接收方：收到报文后，按序列号重组数据；若数据完整且有序，向发送方返回“确认报
- • 未确认重传：发送方发送报文后，启动“重传计时器”；若计时器超时前未收到对应ACK，认为数
- • 超时重传：基础重传机制，发送方为每个报文段设置超时时间（RTO，根据网络延迟动态调整），
- 13第 13 卷
- • 滑动窗口：发送方维护一个“发送窗口”，窗口内的报文段可连续发送，无需等待逐个确认，大幅
- • 累计确认：接收方无需为每个报文段单独返回ACK，可对“连续接收的多个报文段”返回一个累计
- ✅ 核心总结
- 24. 解释TCP的拥塞控制机制
- 一、核心参数铺垫
- • 拥塞窗口（cwnd）：发送方维护的“当前可发送的最大数据量”（以报文段为单位），是拥塞控
- • 慢启动阈值（ssthresh）：拥塞控制阶段切换的临界值，初始值通常较大（如为65535字节）；当
- 二、拥塞控制的四个核心阶段（Reno算法）
- 三、其他补充：拥塞控制的优化算法
- • CUBIC算法：Linux系统默认拥塞控制算法，基于Reno算法优化，在高带宽、高延迟网络（如数据
- • BBR算法：Google提出的基于“带宽延迟乘积（BDP）”的拥塞控制算法，不再通过“丢包”判
- 一、UDP的核心特性（适配实时应用的关键）
- 14第 14 卷
- • 数据分片与序号标记：应用层将大数据（如视频帧）分片，为每个分片标记序号，接收方按序号重
- • 选择性重传：仅对关键数据（如游戏核心操作、视频关键帧）进行重传，非关键数据（如视频非关
- • 差错控制：应用层加入简单的校验机制，丢弃错误数据；对视频、音频数据，可通过编码算法（如
- • 流量控制优化：应用层根据网络延迟和丢包率动态调整发送速率（如弱网络下降低视频分辨率、减
- ✅ 核心总结
- 一、场景核心需求与UDP的适配性
- 二、TCP在该场景下的致命缺陷
- 三、UDP的补充优化：应用层保障核心数据可靠性
- • 关键数据选择性重传：仅对核心操作（如攻击命中、技能释放确认）做轻量级重传，非核心数据
- • 数据分片与序号标记：将操作数据分片传输，标记序号和时间戳，接收方按时间戳筛选有效数据，
- • 冗余数据补充：周期性发送玩家完整状态数据（如位置、血量），即使个别操作数据丢失，也可通
- ✅ 核心总结
- 15第 15 卷
- • 实现步骤：
- • 缺点：实现稍复杂，需处理长度字段的字节序（大端/小端）问题（不同设备可能有差异，需统一约
- • 实现示例：
- • 缺点：需额外引入协议解析库，序列化/反序列化有轻微性能开销，适用于分布式系统、跨语言通信
- 二、粘包问题的延伸：半包处理
- ✅ 核心总结
- • 连接建立：通过“HTTP握手”完成升级（后续第29问详细说明），仅需一次握手即可建立持久连
- • 低延迟：连接建立后，数据传输无需重复握手和头部验证，且协议头部开销极小（仅2-10字节），
- • HTTP短轮询：客户端定时发送HTTP请求询问服务端是否有新数据，延迟高、开销大（频繁建立连
- • HTTP长轮询：客户端发送请求后，服务端保持连接直至有新数据或超时才响应，延迟有所降低，
- • WebSocket：全双工持久连接，服务端可主动推送数据，延迟最低、开销最小，是实时通信的最优
- ✅ 核心总结
- 16第 16 卷
- 17第 17 卷
- 18第 18 卷
- 19第 19 卷
- 20第 20 卷
- 21第 21 卷