当前位置：首页 > news >正文

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

news 2025/8/1 16:00:06

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)。
这样可以灵活交错发送、优先级调度，更有效率，解析开销更低。

面试讲解结构建议：

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

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, 维基百科)。

🧠 面试回答流程建议

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

背景引入：HTTP/1.1 的瓶颈 —— 多请求仍受限于顺序、重复 header 带宽浪费。
管道化：解释概念及其局限 — 顺序响应，应用层 HOL 阻塞。
HTTP/2 创新：
- 二进制分帧结构
- 多路复用实现真正并发
- 流优先级（stream prioritization）
TCP 层视角：指出 HTTP/2 仍受单 TCP 丢包重传的阻塞影响。
头部压缩需求：常见哪些头部为什么重复，压缩可节省多少开销。
HPACK vs QPACK 差别：HPACK 的原理安全性、QPACK 为 HTTP/3 做的独立流兼容设计。
HTTP/3 解决方案：QUIC 用 UDP + 本身支持独立流、0‑RTT、安全连接迁移，彻底消除 TCP HOL 阻塞。

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

版本	核心技术	应对 HOL 方式	头部压缩算法
HTTP/1.1	文本 + Pipelining	应用层 HOL 阻塞	无
HTTP/2	二进制帧 + 多路复用	应用层无阻塞，仍有 TCP 层 HOL	HPACK
HTTP/3 (QUIC)	QUIC on UDP + 独立流	QUIC 层无 HOL 阻塞	QPACK

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

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)。

特点	HTTP	HTTPS
端口	默认 80	默认 443
加密	无	TLS/SSL 加密
安全性	易被监听篡改	提供隐私、完整性、认证保障
性能	握手少、传输快	`握手耗时稍高，但现代优化后速度相当`

二、为什么 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.)。

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

基础题

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

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

进阶题

描述 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，从而提升性能和安全性。”

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

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

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

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

结构化回答建议如下：

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

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

情况	SSE 更适合	WebSocket 更适合
数据方向	服务器主动推送 → 客户端（单向）	双向交互（客户端 ↔ 服务器）
通信内容	文本（JSON、文本）	文本或二进制
实现复杂度	简单，只需 `EventSource`	较复杂，需要手动握手、帧、心跳、压缩等
重连行为	自动，浏览器处理，可设置 `retry`	需开发者自行实现重连策略
浏览器兼容性	IE 不支持，现代浏览器均支持 (hellojavascript.info, fr.wikipedia.org)	几乎所有现代浏览器支持 (维基百科)
性能与延迟	延迟稍高，但足够文本行为	延迟极低，适合高频互动及二进制传输
示例应用	股票行情、新闻推送、系统监控、事件通知等 (medium.com, dev.to)	即时聊天、多人协作游戏、协作编辑、鼠标位置同步等

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

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 的对比分析（一目了然）

特性	TCP（可靠）	UDP（快速）
连接方式	面向连接（三次握手）	无连接，数据即发
可靠性	有确认、重传、流控、拥塞控制	无确认、不保证递送、不顺序
传输效率	相对较慢（头部大、控制复杂）	更轻量，头部仅 8 字节
是否按序	`保证`	不保证，由应用决定
应用类型	HTTP/HTTPS、文件、WebSocket 等	实时音视频、多人游戏、DNS、QUIC 等
前端关注	请求稳定性、高安全性、高顺序性	低延迟、容忍部分丢包、适合实时场景