得物前端二面潜在问题详解

---

4. DNS 解析原理

DNS（Domain Name System，域名系统）是“互联网的电话簿”。它的核心功能是将人类可读的域名（如 www.google.com）转换为机器可读的 IP 地址（如 142.251.42.206）。

核心原理与过程

DNS 解析是一个典型的分布式、层级查询过程。其基本步骤如下：

第一步：检查缓存（Cache Lookup）
当你在浏览器中输入一个网址，系统会按以下顺序检查域名缓存，如果找到记录则直接返回 IP：

1. 浏览器缓存：浏览器会缓存之前访问过的域名。
2. 操作系统缓存：操作系统的 Hosts 文件及其内存缓存（如 Windows 的 DNS Client 服务）。
3. 路由器缓存：本地路由器也可能缓存 DNS 信息。
4. ISP DNS 缓存：你的互联网服务提供商（ISP）的 DNS 服务器拥有庞大的缓存。

第二步：递归查询（Recursive Query）
如果所有缓存中都未命中，请求会到达 ISP 的递归 DNS 服务器（也称为 LDNS）。这个服务器会代表用户完成整个查询过程，直到拿到最终答案。

第三步：迭代查询（Iterative Query）
递归服务器开始从 DNS 根目录开始自上而下进行迭代查询：

1. 查询根域名服务器：全球有13组根服务器（逻辑上）。根服务器不直接解析域名，但它会根据域名的后缀（如 .com, .org, .cn），返回对应的顶级域（TLD）服务器的地址。
2. 查询顶级域（TLD）服务器：递归服务器拿着返回的 TLD 服务器地址（例如 .com 的服务器）去询问。TLD 服务器会返回管理该域名的权威域名服务器（Authoritative Name Server） 的地址。
   • 例如，对于 www.example.com，.com TLD 服务器会返回管理 example.com 域的权威服务器地址。
3. 查询权威域名服务器：递归服务器最后向权威服务器发起查询。权威服务器是域名记录的最终来源，它存储着该域名对应的真实 IP 地址，并将其返回给递归服务器。

第四步：缓存并返回结果
递归服务器收到权威服务器的应答后：

1. 将 域名 -> IP 的映射关系缓存起来（根据 TTL 值决定缓存时间）。
2. 将最终的 IP 地址返回给你的操作系统，操作系统再交给浏览器。

第五步：建立连接
浏览器拿到 IP 地址后，就可以与目标服务器建立 TCP 连接并发送 HTTP 请求了。

重要概念

• 递归服务器：替用户干活的“跑腿小哥”，它负责完成整个查询链。你的路由器或 ISP 分配的 DNS 就是递归服务器（如 8.8.8.8）。
• 权威服务器：管理特定域名的“官方档案库”，提供该域名下记录的最终答案。
• 记录类型：
  • A记录：将域名指向一个 IPv4 地址。
  • AAAA记录：将域名指向一个 IPv6 地址。
  • CNAME记录：将域名指向另一个域名（别名）。
  • MX记录：邮件交换记录，指定负责接收邮件的服务器。

下图直观地展示了这一查询流程：

flowchart TD
A[浏览器请求域名] --> B{检查缓存<br>浏览器 → 系统 → 路由器 → ISP}
B -- 缓存命中 --> C[立即返回IP地址]
B -- 缓存未命中 --> D[请求ISP递归DNS服务器]
D --> E[递归服务器查询根域名服务器]
E --> F[根服务器返回TLD服务器地址]
F --> G[递归服务器查询TLD服务器]
G --> H[TLD服务器返回权威服务器地址]
H --> I[递归服务器查询权威服务器]
I --> J[权威服务器返回IP地址]
J --> K[递归缓存结果并返回IP]
K --> L[浏览器获取IP，发起HTTP连接]

---

5. TCP 滑动窗口详解

TCP 滑动窗口协议是 TCP 实现可靠性传输和流量控制的核心机制。它解决了两个关键问题：

1. 可靠性：确保数据包按序、无误地到达接收方。
2. 效率：在保证可靠的前提下，尽可能高效地利用网络带宽，避免发送方发送数据过快而淹没接收方。

核心概念

• 窗口（Window）：代表接收方当前能够接收并缓冲的数据量的大小（以字节为单位）。它是一个动态变化的值。
• 滑动：随着数据的发送、确认，窗口的位置和大小会向前“滑动”，从而允许发送新的数据。

窗口的组成

发送方维护着一个虚拟的窗口，其结构由四个指针定义，将数据分为三部分：

1. 已发送已确认（Sent and Acknowledged）：数据已成功被接收方接收。
2. 已发送未确认（Sent but not Acknowledged）：数据已发出，但尚未收到接收方的确认（ACK）。
3. 可发送未发送（Sendable / Usable Window）：在流量控制限制内，可以立即发送的数据。
4. 不可发送（Not Sendable）：超出接收方窗口大小，不允许发送的数据。

随着ACK的到达，窗口的左边界向右移动（滑动）。随着接收方通知的新窗口大小（rwnd）变化，窗口的右边界可能扩展或收缩。

工作流程

1. 三次握手建立连接：双方会交换自己的接收窗口大小（rwnd），告知对方自己的缓冲能力。
2. 发送数据：发送方在窗口范围内，可以连续发送多个数据段，而无需等待每一个的确认。这大大提高了信道利用率（管道化）。
3. 确认与窗口更新：接收方收到数据后：
   • 会发送 ACK 报文，其中包含两个关键信息：
     • 确认号（Ack）：期望收到的下一个字节的序列号。所有小于此号的数据都已正确接收。这推动了窗口的左边界。
     • 窗口大小（Window）：接收方当前的可用缓冲区大小。这确定了窗口的右边界。
   • 如果应用层程序读走了缓冲区的数据，空出了新的空间，接收方会在下一次 ACK 中通告一个更大的窗口。
4. 窗口滑动：发送方收到 ACK 后，根据确认号和新的窗口大小来滑动自己的发送窗口，然后继续发送新数据。

核心作用：流量控制与拥塞控制

• 流量控制（Flow Control）：由接收方控制。通过通告窗口大小（rwnd）来防止发送方发送过快过多，导致自己缓冲区溢出。这是滑动窗口最直接的目的。

  • 零窗口（Zero Window）：如果接收方缓冲区已满，它会通告一个窗口为 0 的报文。发送方会暂停发送，并周期性地发送“零窗口探测报文”来查询接收方窗口是否已可用。

• 拥塞控制（Congestion Control）：由发送方控制。发送方根据自己感知的网络拥塞程度，维护一个拥塞窗口（cwnd）。最终的实际发送窗口大小取 min(接收方窗口rwnd, 拥塞窗口cwnd)。拥塞控制算法（如慢启动、拥塞避免、快速重传、快速恢复）独立地调节 cwnd 的大小，以防止网络过载。

总结

滑动窗口协议巧妙地将可靠性（通过确认机制）、流量控制（通过接收方窗口）和高效传输（允许连续发送多个报文）结合在一起，是 TCP 协议如此强大的基石。拥塞控制机制的引入，进一步使其成为维护互联网稳定的关键。

---

​​DNS解析​​就像是互联网的导航系统，当用户输入网址时，浏览器会从本地缓存到ISP服务器进行层层查询，最终从权威域名服务器拿到对应的IP地址，从而完成访问。
​​TCP滑动窗口​​是保证传输效率和可靠性的核心机制，它通过接收方动态通告的窗口大小来控制发送速率，既能批量发送数据提升效率，又能通过流量控制防止网络拥塞或接收方过载，确保数据有序、完整地送达。

---

---

---

以下是针对 iframe 的详解及面试高频考点的系统梳理，结合核心原理与实战技巧：

---

一、iframe 核心概念

定义

• iframe（内联框架）：HTML 标签 <iframe>，用于在当前页面嵌套另一个独立 HTML 文档（形成“页面中的页面”）。
• 核心属性：
  • src：指定嵌套页面的 URL。
  • sandbox：设置安全限制（如禁用脚本、表单提交）。
  • allow：控制权限（如摄像头、全屏、定位）。

---

二、iframe 的优缺点（高频考点）

优点	缺点	补充说明
✅ 内容隔离：第三方内容（广告/地图）嵌入不影响主页面样式/脚本	❌ 性能开销：每个 iframe 独立加载资源，阻塞主页面 onload 事件	建议动态加载（懒加载）减少阻塞
✅ 并行加载：浏览器可同时加载主页和 iframe 内容	❌ SEO 不友好：搜索引擎难以抓取 iframe 内的动态内容	需提供替代内容（如 <noscript>）
✅ 跨域支持：原生支持跨域内容嵌入	❌ 安全风险：跨域 iframe 可能被用于点击劫持、XSS 攻击	必须配置 X-Frame-Options + sandbox
✅ 模块复用：公共模块（页头/页脚）复用方便	❌ 响应式适配难：需动态计算高度（内容高度变化时）	子页面通过 postMessage 向父页面上报高度

面试回答技巧：
先分点对比优缺点，再针对性补充解决方案（如性能优化用懒加载，安全用 sandbox）。

---

三、跨域通信（必考！）

1. window.postMessage（首选方案）

// 父页面向子页面发送消息
iframe.contentWindow.postMessage("数据", "https://子页面域名");// 子页面接收消息
window.addEventListener("message", (event) => {if (event.origin !== "https://父页面域名") return; // 验证来源！console.log(event.data);
});

• 关键点：必须验证 event.origin，否则可能导致 XSS 攻击。

2. document.domain（仅限同主域）

• 前提：父子页面均属于同一主域（如 a.example.com 和 b.example.com）。
• 代码：

  // 父子页面均设置
  document.domain = "example.com";
  

• 缺点：仅支持同主域，且放宽策略后安全性降低。

---

四、安全防护（核心考点）

1. 服务端设置

• X-Frame-Options：
  • DENY：禁止页面被嵌入任何 iframe。
  • SAMEORIGIN：仅允许同源页面嵌入。
• Content-Security-Policy (CSP)：

  Content-Security-Policy: frame-src 'self' https://trusted.com;
  

2. 客户端配置

• sandbox 最小化权限：

  <iframe sandbox="allow-same-origin allow-forms"></iframe>
  

• 禁用危险组合：
  • ❌ 避免同时启用 allow-scripts + allow-same-origin（可能导致沙箱逃逸）。

---

五、性能优化策略

1. 动态加载：

   // 按需设置 src，避免阻塞首页渲染
   document.getElementById("myIframe").src = "url";
   

2. 懒加载：

   <iframe loading="lazy" src="..."></iframe>
   

3. 减少嵌套层级：每个 iframe 消耗约 1MB 内存，避免多层嵌套。

---

六、高频面试题与技巧

1. “如何实现 iframe 高度自适应？”

• 答案：
  子页面监听内容变化，通过 postMessage 上报高度给父页面 → 父页面动态设置 iframe 高度。

  // 子页面
  window.parent.postMessage({ height: document.body.scrollHeight }, "*");
  

2. “如何安全嵌入第三方广告？”

• 答案：
  1. 配置 sandbox="allow-scripts allow-popups"（最小权限）。
  2. 设置 CSP：frame-src https://广告商域名。
  3. 通过 postMessage 通信，严格验证 event.origin。

3. “iframe 通信方案有哪些？”

• 分层回答：
  • 跨域首选 postMessage（安全灵活）。
  • 同源可用 BroadcastChannel / SharedWorker。
  • 历史方案 window.name（已淘汰）。

---

七、替代方案（加分项）

1. Web Components：通过 Shadow DOM 实现轻量级内容隔离。
2. 微前端框架：如 qiankun，动态加载子应用，避免 iframe 性能损耗。

---

速记表：核心考点

考点	核心答案要点
优缺点	隔离性✓ 并行加载✓ / 性能开销✗ SEO✗ 安全风险✗
跨域通信	postMessage + 验证 event.origin
安全防护	X-Frame-Options + sandbox 最小权限 + 禁用 allow-scripts+allow-same-origin
性能优化	动态加载 + 懒加载 + 减少嵌套

---

掌握以上内容，可覆盖 90% 的 iframe 面试题。实际开发中优先考虑现代替代方案（如微前端），若需使用 iframe，务必严格遵循安全规范。