计算机网络知识【推荐！！！】按照OSI七层模型梳理

OSI（Open Systems Interconnection）七层模型是由国际标准化组织（ISO）制定的网络通信参考模型，旨在标准化网络通信过程，促进不同系统之间的互联互通。它将复杂的网络通信任务划分为七个层次，每一层都承担特定的功能，并为相邻层提供服务。(xxh.xaiu.edu.cn, CSDN博客)

在前端开发中，理解OSI模型有助于更好地理解网络请求的流程、调试网络问题以及优化性能。下面是对OSI七层模型的逐层解析，结合前端开发的实际场景进行说明：

1. 应用层（Application Layer）

功能：直接为用户的应用程序提供网络服务，处理特定的应用协议。

前端相关：当您在浏览器中输入网址并访问网页时，实际上是通过HTTP或HTTPS协议与服务器进行通信。例如，使用fetch()或XMLHttpRequest发送请求，都是在应用层进行的操作。

常见协议：HTTP、HTTPS、FTP、SMTP、DNS等。(博客园)

DNS

DNS 是互联网的分布式层级名称系统，将域名解析为 IP 地址。客户端查询 DNS 解析器，如果本地缓存 miss，则递归查询根、TLD 到权威服务器，最终返回 IP 并缓存。

DNS的查询过程可以分为递归查询和迭代查询两种模式。

• 递归查询：客户端向本地DNS服务器发起查询请求，本地DNS服务器会递归地向上级DNS服务器查询，直到找到目标IP地址并返回给客户端。
• 迭代查询：客户端向本地DNS服务器发起查询请求，本地DNS服务器会返回下一级DNS服务器的地址，客户端再向该地址发起查询，如此逐级查询直到找到目标IP地址。

具体来说，当用户在浏览器中输入一个域名时，计算机会向配置的DNS服务器发送一个域名解析请求。DNS服务器首先会查看其缓存中是否有该域名的解析记录，如果有则直接返回缓存中的IP地址；如果没有，则会继续向上级DNS服务器发出查询请求，直到找到能够提供所需信息的服务器为止。最终，DNS服务器将查询到的IP地址返回给客户端，客户端便可以与该域名关联的服务器建立连接，进行相应的网络通信。

HTTP1.0-1.1-2.0-3.0

• HTTP 1.0->HTTP 1.1->HTTP 2.0 ->HTTP 3

1. 什么是管道化（HTTP/1.1 Pipelining）？为什么会出现队头阻塞？

• 管道化概念：HTTP/1.1 允许客户端在一个持久 TCP 连接上依次发送多个 GET 请求，无需等待每个响应再发下一个 (Medium)。
• 局限性：虽然请求是并行发送的，但服务器必须 严格按照请求顺序依次响应，即使某个请求延迟很长，后续响应也必须排队等待。
• 形成 HOL 阻塞：第一个慢响应会“挡住”后续所有响应，这就是应用层的 队头阻塞（Head‑of‑Line, HOL） 问题 (factory.dev)。

面试回答建议：

• 先解释管道化的原意和目的：减少 RTT 延迟。
• 接着指出其局限：顺序响应导致 HOL 阻塞，从而无法真正并发。

2. 多路复用 vs 二进制分帧（HTTP/2）

多路复用 (Multiplexing)

• HTTP/2 引入 多路复用：在一条 TCP 连接上并行传输多个 流（stream），每个流独立、互不干扰 (DEV Community, 维基百科)。
• 因为交错发送帧（frame），一个慢请求不会阻塞其他流，彻底解决了应用层 HOL 阻塞。
  

二进制分帧 (Binary Framing)

将逻辑请求/响应拆解为结构化、小型的二进制帧(frame)，便于可靠解析、交错传输与帧级控制，同时保持 HTTP 语义不变（method、URI、头部等）

• HTTP/2 不再使用文本格式，而是 二进制协议，将消息拆成不同类型的 帧（如 HEADERS、DATA），每帧都有 ID 标识所属流 (zscaler.com)。
• 这样可以灵活交错发送、优先级调度，更有效率，解析开销更低。
  

面试讲解结构建议：

1. 先讲 HTTP/1.1 的局限与 HOL。
2. 介绍 HTTP/2 引入二进制分帧结构。
3. 再讲多路复用机制如何避免阻塞，同时可做优先级控制。
   

3. 为什么 TCP 会丢包？HTTP/2 中仍存在 TCP 层 HOL 阻塞

• TCP 丢包原因：网络原因如拥塞、丢包、重传机制等会导致某个 TCP 包延迟或丢失 (stackoverflow.com)。
• TCP 层 HOL 阻塞：HTTP/2 虽在应用层解决了管道 blocking，但底层依然使用单个 TCP 连接，如果一个包丢失，TCP 要重传，导致 所有流都等待该包恢复，形成 TCP‑层 HOL 阻塞 (DEV Community, stackoverflow.com)。

4. HTTP/2 和 HTTP/3 为什么要做头部压缩？常见头部有哪些？为什么压缩？

• 常见 HTTP 头部字段举例：

  • Host、User-Agent、Accept、Accept-Encoding、Cookie、Authorization 等。

• 每次请求几乎都携带这些冗余字段，尤其 Cookie/UA 重复高，开销大 (ably.com, newsletter.systemdesigncodex.com)。

• 为什么要压缩：HTTP/1.1 每次都文本发送完整头部，带宽浪费、延迟高。压缩头部能显著减少每次请求的协议开销，提高效率与响应速度 (newsletter.systemdesigncodex.com, cloudflare.com)。

5. 压缩算法有什么差异？HPACK vs QPACK

HPACK（HTTP/2）

• 使用 静态表 + 动态表 保存常见头部。
• 对重复字段使用索引引用，省去再次传输完整字符串，支持 Huffman 编码减少字节量 (datatracker.ietf.org, newsletter.systemdesigncodex.com)。
• 摆脱直接使用 DEFLATE 的 CRIME 漏洞风险 (datatracker.ietf.org)。

QPACK（HTTP/3 over QUIC）

• HTTP/3 使用 QUIC 支持多条独立流，HPACK 的上下文依赖可能造成流之间阻塞。
• 因此 HTTP/3 引入 QPACK，允许每个流可以独立解码表项，避免 HPACK 在丢包场景下依赖顺序的瓶颈，解决 TCP 层阻塞延伸到压缩上下文的 HOL 问题 (stackoverflow.com, 维基百科)。

🧠 面试回答流程建议

你可以按照以下顺序，向面试官有逻辑地介绍：

1. 背景引入：HTTP/1.1 的瓶颈 —— 多请求仍受限于顺序、重复 header 带宽浪费。

2. 管道化：解释概念及其局限 — 顺序响应，应用层 HOL 阻塞。

3. HTTP/2 创新：

   • 二进制分帧结构
   • 多路复用实现真正并发
   • 流优先级（stream prioritization）

4. TCP 层视角：指出 HTTP/2 仍受单 TCP 丢包重传的阻塞影响。

5. 头部压缩需求：常见哪些头部为什么重复，压缩可节省多少开销。

6. HPACK vs QPACK 差别：HPACK 的原理安全性、QPACK 为 HTTP/3 做的独立流兼容设计。

7. HTTP/3 解决方案：QUIC 用 UDP + 本身支持独立流、0‑RTT、安全连接迁移，彻底消除 TCP HOL 阻塞。

✅ 总结表格（面试总结可展示）

这样的结构不仅逻辑清晰，也能展示你对从协议设计到实际性能影响的全面理解。建议在讲解过程中适当用简化类比（如邮递信封、餐厅服务流程）帮助说明复杂概念，并随时准备回答深入技术细节问题。祝你面试顺利！

HTTP&HTTPS

HTTPS 在 HTTP 与 TCP 之间增加了 TLS 加密层，会将实际请求内容加密，导致即便抓包也只能看到加密数据包（TCP/IP 层信息）。要解密数据，必须通过 MITM 插入中间人证书或者借助 SSLKEYLOGFILE 获取对称密钥，才能在 Wireshark 中恢复 HTTP 内容。

下面是从浅入深、逻辑清晰的方式，向面试官系统介绍 HTTP 与 HTTPS，并附上多个常见面试问题，适合在技术面试中阐述。

一、基础概念与比较 🔍

1. HTTP 是什么？

• HTTP（HyperText Transfer Protocol）是一种基于 TCP、文本形式的应用层协议，用于客户端（如浏览器）与服务器之间的交互通信(finalroundai.com)。
• 数据以明文方式传输，容易被拦截或篡改，安全性较低(GeeksforGeeks, GeeksforGeeks)。

2. HTTPS 是什么？

• HTTPS 是 HTTP 之上的安全协议，通过 TLS/SSL 加密来保护通信内容，常运行在 TCP 443 端口(GeeksforGeeks, GeeksforGeeks, Amazon Web Services, Inc.)。
• 它既提供加密，又提供服务器身份认证（证书机制），确保通信安全且可信(GeeksforGeeks, vervecopilot.com)。

二、为什么 HTTPS 很重要？

• 防止中间人攻击：信息如用户名、密码、Cookies、Token 均以加密形式保护，避免被网络监听者读取或篡改(职业长廊, arxiv.org, javarevisited.blogspot.com)。
• 身份验证服务器：通过 CA 签名的证书，浏览器能验证服务器身份，防止假冒服务(vervecopilot.com, GeeksforGeeks)。
• SEO 和浏览器支持：大多数搜索引擎和现代浏览器都倾向或强制使用 HTTPS，未使用 HTTPS 的站点可能被标记为“不安全”(GeeksforGeeks, indeed.com)。

三、系统架构层面差异

• HTTP 工作在应用层，直接在 TCP 上传输；
• HTTPS 则在 TCP 之上先建立 TLS 安全层，再发送 HTTP 报文；
• HTTPS 握手流程包括协商加密算法、公钥交换和对称密钥生成等步骤(Amazon Web Services, Inc.)。
  
  

四、常考面试问题列表（由浅入深）

基础题

1. HTTP 和 HTTPS 分别代表什么？
2. 默认端口分别是多少？
3. HTTP 为什么不安全？

HTTP明文传输导致数据泄露风险、缺乏身份验证易受钓鱼攻击、无法保证数据完整性，以及性能瓶颈​（如队头阻塞）

进阶题

5. 描述 HTTPS 握手与密钥协商流程。

“HTTPS 使用 TLS 协议，在 TCP 三次握手后启用 TLS 握手。(协商加密算法、公钥交换&堆成密钥生成）客户端发送 ClientHello 建立支持的协议版本和加密套件，服务器以 ServerHello 响应并发送证书。客户端验证证书后生成 Pre‑Master Secret（RSA 或 ECDHE），加密发送给服务器。双方使用随机串与 Pre‑Master Secret 派生 Master Secret，再派生 Session Keys。交换 ChangeCipherSpec 和 Finished 消息完成握手，此后所有 HTTP 通信都通过协商出的对称密钥加密传输。TLS 1.3 使握手仅需一轮往返并强制使用 Diffie‑Hellman，从而提升性能和安全性。”

6. HTTPS 如何验证服务器身份？什么是证书颁发机构（CA）？

HTTPS 在 TLS 握手中验证服务器身份逻辑如下：服务器返回一个由 CA 签名的证书，证书中含服务器的公钥和域名等信息。浏览器验证这个证书的签名、有效期与域名是否匹配，并构建一个至信任根 CA 的证书链，同时检查是否被吊销。通过所有校验后才继续后续加密通信。证书颁发机构（CA）就是那个受信任的第三方，它负责验证身份、颁发证书与维护吊销信息，并通过根和中间证书形成信任体系

8. 为什么 HTTPS 会略慢，但仍推荐使用？

五、面试时的逻辑讲法建议

结构化回答建议如下：

1. 先讲定义与区别：HTTP 是明文、无认证、无加密的协议；HTTPS 增加了 TLS/SSL 层，实现加密与身份验证。
2. 讲为什么要 HTTPS：数据机密性、完整性、用户信任、安全规范等驱动。
3. 描述握手流程：浏览器发起连接 → 服务器发送证书 → 验证证书 → 双方协商密钥 → 建立安全通信。
4. 性能影响与优化：虽然多一步握手，但启用 HTTP/2、TLS 1.3 后性能接近 HTTP；实际效率高于 HTTP 首次连接成本差。
5. 安全加固措施：如使用 HSTS、证书透明度、OCSP stapling 等机制增强安全性。
6. 结合现代协议：HTTPS 是 HTTP/2 与 HTTP/3 的基础；其升级提升了头部压缩、多路复用、QUIC 等能力。

🧠 简要答题模板

“HTTP 是无加密的超文本传输协议，运行在 TCP 80 端口；HTTPS 则在此之上加了 TLS/SSL 安全层，运行在 443 端口，保障加密与身份验证。”
“HTTPS 握手流程是浏览器验证服务器证书、协商对称密钥、建立加密通道，然后通信所有内容都在这个安全通道内进行。”

希望以上内容能帮助你在技术面试中，有条理、有深度地讲解 HTTP 与 HTTPS 的区别及其背后的安全设计理念。如果你还需要更具体的 TLS 握手流程图、证书细节或 HSTS 应用与验证示例，欢迎继续提问！

2. 表示层（Presentation Layer）

功能：负责数据的格式化、加密和解密、压缩和解压缩，确保发送方和接收方能够正确解析数据。

前端相关：浏览器接收到服务器返回的JSON数据后，会将其解析为JavaScript对象；或者将图片数据解码并显示在页面上，这些都是表示层的工作。

3. 会话层（Session Layer）

功能：管理通信双方之间的会话，建立、维护和终止会话连接。(cloud.tencent.com)

前端相关：在使用WebSocket进行实时通信时，会话层负责维持持续的连接状态，确保数据的顺序和完整性。(博客园)

WebSocket&SSE

下面是一个逻辑清晰、适用于前端面试场景的 WebSocket vs SSE（Server‑Sent Events） 介绍，包括核心概念、对比分析、典型面试问题与详细回答：

一、基础概念与原理对比

WebSocket

• 是基于 TCP 的双向通信协议，浏览器通过 HTTP Upgrade 握手升级到 WebSocket 连接，一旦建立连接，客户端和服务器可以双向实时交换数据 (维基百科)。
• 优势：支持双向通信，延迟低、效率高，适合聊天、游戏、协作编辑等复杂场景 (维基百科, Ably Realtime)。
• 缺点：协议复杂，实现成本高，需要手动处理心跳、重连、安全校验等 (hellojavascript.info)。

SSE（Server‑Sent Events）

• 基于标准 HTTP（通常 HTTP/1.1 或 HTTP/2），由浏览器原生 EventSource 对象建立持久连接，服务器可以通过该连接单向推送数据给客户端 (greatfrontend.com)。
• 优势：实现简单，自动重连，资源开销低，适合数据流式推送场景如新闻、股价、系统监控等 (hellojavascript.info)。
• 限制：通信单向（server→client）、只支持文本（UTF‑8）、IE 浏览器不支持等 (hellojavascript.info)。

二、适用场景 & 权衡分析（逻辑结构）

三、典型前端面试问题及示范答案

1. 请解释 WebSocket 和 SSE 的区别

答：

• WebSocket 是 TCP 上的双向通信协议，支持客户端与服务器实时互发消息；SSE 是基于 HTTP 的单向连接，只允许服务器向客户端推送事件。
• WebSocket 支持文本与二进制，延迟低；SSE 仅支持 UTF-8 文本，适合单方向更新。
• SSE 简单、自动重连、开销低；WebSocket 灵活但实现复杂 (medium.com)。

2. SSE 的自动重连机制是如何工作的？如何控制重连时间？

答：
浏览器默认遇到连接断开时会尝试自动重新连接，重连间隔一般为几秒。服务器可以通过发送 retry: <毫秒>\n\n 指定下次连接等待时间。还可以为每个事件设置 id，浏览器 reconnect 时会带上 Last‑Event‑ID，服务器据此可以补发遗漏事件 (hellojavascript.info)。

3. WebSocket 如何防止跨站请求滥用？

答：
WebSocket 握手阶段会携带 HTTP Origin 头，服务器应验证 Origin 是否允许连接，从而防止类似 CSRF 的 cross‑site WebSocket hijacking 攻击。此外，对于敏感场景建议使用 Token 或其他认证方式进行连接授权 (维基百科)。

4. 如果客户端只需要接收数据而不发送，SSE 和 WebSocket 哪个更合适，为什么？

答：
当只需单向传输（例如新闻流、监控更新等），SSE 更合适：实现简单、无需书写协议层、自动重连、开销低；而 WebSocket 更重、开发复杂，反而不必要 (medium.com, dev.to)。

5. 使用 SSE 时，经常有哪些潜在问题？如何应对？

答：

• 浏览器兼容性问题 —— IE 不支持，需要 fallback（如轮询或 WebSocket）。
• 连接超时或中断 —— 可以用自定义 retry、服务端设置心跳或检测客户端 close。
• 丢失事件 —— 通过 id 与 Last‑Event‑ID 配合重发机制处理。
• CORS 限制 —— 需要在服务器配置允许跨域请求头。
• 消息类型的区分 —— 可使用 event: 字段，客户端用 addEventListener('类型', handler) 进行处理 (hellojavascript.info)。

6. 面试官问：“如何在前端代码中使用 SSE 实时获取数据？”你会怎么答？

答（示范代码）：

const source = new EventSource('/stream');
source.onopen = () => console.log('连接建立');
source.onmessage = evt => {
  const data = JSON.parse(evt.data);
  console.log('收到数据', data);
};
source.onerror = evt => {
  if (source.readyState === EventSource.CLOSED) {
    console.log('连接已关闭');
  } else {
    console.error('发生错误', evt);
  }
};

如果有自定义事件类型：

source.addEventListener('priceUpdate', evt => { … });

需要服务器设置响应头：

Content‑Type: text/event‑stream
Cache‑Control: no‑cache
Connection: keep‑alive

以及使用 retry: 或 id: 控制重连与事件续传 (hellojavascript.info)。

四、总结笔记（面试提炼重点）

• 逻辑结构：先区分通信方向→协议复杂度→实现简易度→应用场景→面试问答。

• 关键点：

  • WebSocket 双向、低延迟、高灵活；
  • SSE 单向、简单、适合推送；
  • 掌握握手、安全、重连、事件识别等常见问题；
  • 提供示例代码，展示前端使用实操。

将上述内容组织成条理清晰的“讲解 + 问答”风格，在面试时非常占优势。希望对你的前端面试准备有帮助！

4. 传输层（Transport Layer）

功能：提供端到端的通信服务，确保数据的可靠传输，包括错误检测和流量控制。(博客园)

前端相关：当您发送一个HTTP请求时，传输层的TCP协议确保数据包按顺序到达，并在发生丢包时进行重传。

常见协议：TCP、UDP。(博客园)

TCP&UDP

以下是一个面向前端面试官的 TCP 与 UDP 讲解结构，包括协议原理、对比分析、常见面试问题与详尽回答，帮助你逻辑清晰地展示网络协议基础：

一、什么是 TCP 和 UDP？（基础概念 + 前端相关性）

TCP（Transmission Control Protocol）

• 面向连接：通信前需三次握手建立连接。(维基百科)
• 可靠传输：保证数据按序交付、不重复、不丢失，使用确认应答、重传、流控、拥塞控制机制。(维基百科, 维基百科)
• 应用场景：HTTP/HTTPS、WebSockets、文件传输、邮件等端对端通信。对前端而言，浏览器发起 HTTP 请求和 WebSocket 通信，本质上都是基于 TCP。(LinkedIn, 维基百科)

TCP 被称为可靠的传输协议，是因为它通过连接建立、序列号、确认应答、重传机制、校验、流量控制和拥塞控制等一系列机制，确保即便在复杂的网络环境下，数据也能无丢包、无乱序地送达目的地。对于前端来说，浏览器发起的 HTTP 请求或 WebSocket 通信，其底层就是依赖 TCP，这意味着你可以依赖其稳定性来保证用户数据的正确传输

UDP（User Datagram Protocol）

• 无连接：不建立连接，数据直接以报文形式发送，无握手。(维基百科, SynchroNet)
• 不可靠但快速：不保证顺序、不保证交付、不做重传，只有基础校验。适合允许少量丢包的实时应用。(LinkedIn)
• 应用场景：视频/语音通话、直播、游戏、DNS、WebRTC、HTTP/3（QUIC）等。(LinkedIn)

二、TCP vs UDP 的对比分析（一目了然）

三、常见面试问题及推荐回答

1. TCP 和 UDP 的本质区别是什么？

答：
TCP 是面向连接、可靠的传输协议，确保数据按序、不丢、不重复。UDP 则是无连接、不可靠但高效的协议，适用于对实时性要求高、容忍少量丢包的场景。适配时，应根据对可靠性与延迟的取舍进行选择。(GeeksforGeeks)

2. TCP 使用了哪些机制来保证可靠性？

答：
TCP 引入三次握手、多次确认与重传机制、序号与窗口流控机制，以及拥塞控制策略，确保数据完整准确地传输，同时避免发送端压垮接收端或网络。(维基百科, 维基百科)

3. 为什么 UDP 更快？为何没有可靠性？

答：
UDP 省略了连接建立（握手）、确认应答、流控和重传等复杂机制，用更小头部和更少控制开销，适合对延迟敏感但能容忍部分丢包的应用场景。(维基百科, GeeksforGeeks)

4. 能举几个前端开发中应用 UDP 的例子吗？

答：

• WebRTC：通过 UDP 建立多媒体传输，因为延迟要求高，更倾向丢包也不能引起卡顿。(LinkedIn)
• HTTP/3（QUIC）：运行在 UDP 之上，但它自己实现了可靠性和拥塞控制，优化了 HTTP 性能。(LinkedIn)

5. 面试官问：“如何判断 TCP 与 UDP 哪个更适合项目？”你该怎么答？

答：

• 若应用对数据完整性、顺序及安全性要求高（如表单提交、账户相关请求、文件下载），选 TCP。
• 若应用对实时性要求高，且允许丢包（如直播、语音通话、游戏），选 UDP 或 QUIC（HTTP/3）。
• 如果使用 WebSocket 属于 TCP，而 WebRTC 内部为 UDP。明确协议底层特性与场景匹配。(LinkedIn, SynchroNet)

6. 问：常见 TCP 头部有哪些重要字段？它们用于什么？

答：
TCP 报文段的头部字段包括源/目的端口、序号、确认号、头部长度、控制标志（SYN/ACK/FIN 等）、窗口大小、校验和、紧急指针等，支持连接控制、流量管理、可靠传输和状态管理。(nwkings.com)

四、总结性逻辑结构（适合面试讲解）

1. 定义层面阐述：TCP = 可靠连接 + 重传确认；UDP = 无连接 + 轻量高效
2. 对比核心机制：握手、确认、重传、顺序 vs 无确认、无序、低头
3. 应用场景举例：HTTP/WebSocket vs 视频/游戏/WebRTC/QUIC
4. 具体示例体现前端经验：Axios/WebSocket → TCP；WebRTC/HTTP3 → UDP
5. 问答梳理：抓住机制和应用场景最重要

通过这种结构：先定义概念→对比机制→场景举例→面试问答，能让面试官快速理解你对 TCP/UDP 的清晰把握，也展示出你前端项目中的实战思考能力，帮助你在面试中脱颖而出。祝你面试顺利！

5. 网络层（Network Layer）

功能：负责数据包的路由选择和逻辑地址（如IP地址）分配，确保数据从源头到达目的地。

前端相关：当您访问一个网站时，网络层通过IP协议将数据包从您的设备路由到目标服务器。

常见协议：IP、ICMP、ARP等。

6. 数据链路层（Data Link Layer）

功能：在物理层之上，提供可靠的数据传输，进行帧的封装与解封装，处理物理地址（如MAC地址）。(CSDN博客)

前端相关：虽然前端开发者通常不直接接触这一层，但它确保了您的设备能够通过局域网与路由器或交换机通信。

7. 物理层（Physical Layer）

功能：负责数据的物理传输，包括电信号、光信号等的传输方式。

前端相关：这涉及到网络硬件，如网线、无线信号等，确保您的设备能够物理连接到网络。

总结

OSI七层模型为网络通信提供了清晰的分层结构，帮助开发者理解数据在网络中的流动过程。对于前端开发者而言，虽然主要关注应用层，但了解下层的工作原理有助于更有效地进行性能优化和问题排查。(xxh.xaiu.edu.cn)

参考资料：

• 白话OSI 七层网络模型 - freeCodeCamp
• OSI七层模型及各层功能概述 - CSDN博客
• 什么是OSI 模型？– 7 个OSI 层详解 - AWS