很全面的前端面试题——计算机网络篇（上）

前言

在当今的互联网技术面试中，网络协议知识是考察候选人基本功的重要维度。无论是前端、后端还是全栈开发岗位，对HTTP、TCP/IP等核心协议的理解都直接影响着系统设计能力和问题排查效率。

多说无益，开始吧，现在也是活力满满

一、GET和POST的请求的区别

核心区别（按重要性排序）

1. 请求目的与语义

   • GET 用于获取资源 （如查询数据），是 "读取" 操作，具有幂等性（多次请求结果一致，不改变服务器状态）。
   • POST 用于提交资源 （如表单提交、创建数据），是 "写入" 操作，不保证幂等性 （多次提交可能产生不同结果，如重复下单）。
     例：用 GET 请求查询商品详情，用 POST 请求提交订单。

2. 数据传输方式

   • GET 的参数通过URL 传递 （格式为?key1=value1&key2=value2），可见于地址栏，易被浏览器缓存、日志记录。
   • POST 的参数通过请求体（Body） 传递，不可见（但可通过工具查看），默认不被缓存。

3. 数据长度限制

   • GET 受限于 URL 长度（不同浏览器 / 服务器有差异，通常约 2KB），不适合传输大量数据。
   • POST 无明确长度限制（由服务器配置决定），适合传输表单、文件等大容量数据。

4. 安全性（相对）

   • GET 参数暴露在 URL 中，可能被缓存、历史记录捕获，不适合传输密码、令牌等敏感信息。
   • POST 参数在请求体中，相对隐蔽（但仍需通过 HTTPS 加密，否则可被抓包获取）。

5. 浏览器行为

   • 刷新 GET 请求页面，浏览器通常直接重发请求（因幂等性，无副作用）。
   • 刷新 POST 请求页面，浏览器会提示 "是否重新提交"（因可能产生重复操作，如二次支付）。

GET 和 POST 的本质区别在于语义和使用场景 ：GET 是 "查"，POST 是 "改"。 其他差异（如参数位置、长度）是技术实现导致的副产品，而非设计初衷。实际开发中需根据语义选择，而非仅依赖技术细节（例如，不能为了 "隐藏参数" 而用 POST 查询数据）。

二、常见的HTTP请求方法

1. GET

• 定义：请求服务器获取指定资源（如网页、图片、数据等）。

• 核心特点：

  • 仅用于 "读取" 资源，不修改服务器数据（幂等性：多次请求结果一致）。
  • 请求参数附加在 URL 中（如?id=1&name=test），长度有限制（受浏览器 / 服务器限制）。
  • 可被缓存、收藏，安全性较低（参数暴露在 URL 中）。

• 典型场景 ：浏览网页、搜索内容（如GET /search?keyword=xxx）。

2. POST

• 定义：向服务器提交数据，用于创建或修改资源。

• 核心特点：

  • 数据放在请求体（Body）中，长度无限制（适合传输大量数据，如表单、文件）。
  • 不幂等（多次提交可能产生不同结果，如重复下单）。
  • 不可被缓存、收藏，参数不暴露在 URL 中，安全性较高。

• 典型场景 ：提交表单（登录、注册）、上传文件、创建数据（如POST /users新增用户）。

3. PUT

• 定义 ：向服务器发送数据，用于全量更新指定资源（若资源不存在则创建）。

• 核心特点：

  • 幂等（多次请求结果一致，如多次更新同一用户的完整信息）。
  • 需指定资源的唯一标识（如 URL 中的 ID），请求体包含资源的完整数据。

• 典型场景 ：修改用户的全部信息（如PUT /users/123，请求体包含用户姓名、年龄等所有字段）。

4. PATCH

• 定义 ：向服务器发送数据，用于部分更新指定资源（仅修改资源的部分字段）。

• 核心特点：

  • 非幂等（部分场景下可能不幂等，如增量更新数量）。
  • 请求体仅包含需要修改的字段，比 PUT 更高效。

• 典型场景 ：仅修改用户的手机号（如PATCH /users/123，请求体仅含{phone: "138xxx"}）。

5. DELETE

• 定义：请求服务器删除指定资源。

• 核心特点：

  • 幂等（多次删除同一资源，结果一致：第一次删除成功，后续返回 "不存在"）。
  • 需要指定资源的唯一标识（如 URL 中的 ID）。

• 典型场景 ：删除用户（如DELETE /users/123）、删除订单。

6. HEAD

• 定义 ：与 GET 类似，但仅请求资源的响应头（不返回响应体）。

• 核心特点：

  • 用于获取资源的元信息（如文件大小、修改时间），不传输实际数据，节省带宽。
  • 幂等、可缓存。

• 典型场景 ：检查文件是否存在、获取资源的更新时间（如HEAD /files/report.pdf）。

补充说明（体现深度）

• 除上述方法外，还有 OPTIONS（获取服务器支持的请求方法）、TRACE（用于调试，回显请求信息）等，但实际开发中较少使用。
• 理解 HTTP 方法的语义很重要：例如，GET/PUT/DELETE 的幂等性可用于重试机制设计，POST 的非幂等性需注意防重复提交（如加令牌）。

三、HTTP1.0和HTTP1.1之间有哪些区别

HTTP 1.0 发布于 1996 年，是早期 HTTP 协议的标准化版本；HTTP 1.1 发布于 1999 年，针对 1.0 的缺陷进行了大幅优化，至今仍是互联网主流协议之一。 两者的核心差异体现在连接管理、缓存机制、请求处理 等方面，目的是提升 Web 性能和可靠性。

核心区别（按重要性排序）

1. 连接管理机制（最核心差异）

• HTTP 1.0 ：默认使用 "短连接" （非持久连接）。
  每次请求 - 响应完成后，TCP 连接立即关闭。若一个页面包含多个资源（如图片、CSS），需建立多次 TCP 连接，频繁的 "三次握手""四次挥手" 会显著增加延迟。
• HTTP 1.1 ：默认使用 "长连接" （持久连接，Connection: keep-alive）。
  一次 TCP 连接可处理多个请求 - 响应 （通过Keep-Alive头部控制超时时间），减少连接建立 / 关闭的开销，尤其适合包含大量资源的页面。

2. 缓存机制优化

• HTTP 1.0 ：仅支持Expires头部（基于绝对时间控制缓存过期），存在客户端与服务器时间不一致导致的缓存失效问题。

• HTTP 1.1：

  • 新增Cache-Control头部（如max-age=3600，基于相对时间控制缓存，优先级高于Expires），解决时间同步问题。
  • 新增ETag（资源唯一标识）和If-None-Match头部，支持 "增量验证"（仅当资源变化时才传输完整内容，否则返回 304 Not Modified），减少带宽消耗。

3. 请求处理能力

• HTTP 1.0 ：一个 TCP 连接同时只能处理一个请求，需等待前一个请求响应完成后才能发送下一个（"队头阻塞" 问题初现）。

• HTTP 1.1：

  • 支持 "管道化（Pipelining）"：客户端可在收到前一个响应前，向服务器连续发送多个请求 ，减少等待时间（但因浏览器实现复杂，实际应用较少）。
  • 新增Host头部 ：使一台服务器可托管多个域名（虚拟主机），例如Host: www.example.com和Host: blog.example.com可对应同一服务器的不同网站，解决了 1.0 中一台服务器只能对应一个域名的限制。

4. 状态码与错误处理

• HTTP 1.0：状态码较少（如 200、404、500 等基础码）。

• HTTP 1.1：新增 24 个状态码，细化错误场景：

  • 409 Conflict（资源冲突，如并发修改）
  • 410 Gone（资源永久删除，区别于 404）
  • 100 Continue（客户端可先发送请求头，服务器允许后再发送请求体，适合大文件上传）

5. 其他功能扩展

• 范围请求 ：HTTP 1.1 通过Range头部支持断点续传（如Range: bytes=0-1023），可只请求资源的部分内容，1.0 不支持，会导致资源浪费。
• 更严格的协议规范：1.1 明确了请求方法的语义（如 PUT 的幂等性）、头部字段的定义，减少了实现差异。

核心改进

HTTP 1.1 的核心目标是提升性能和可靠性 ：通过长连接减少连接开销 ，通过完善的缓存机制降低带宽消耗 ，通过 Host 头部支持虚拟主机，这些改进为现代 Web 应用的发展奠定了基础。

四、HTTP1.1和HTTP2.0的区别

回答 "HTTP 1.1 和 HTTP 2.0 之间的区别" 时，应聚焦于性能优化的核心突破 ，从协议底层设计、传输机制、安全特性等维度展开，体现对 Web 性能瓶颈及解决方案的理解。

核心区别（按技术突破重要性排序）

1. 传输格式：文本协议 vs 二进制分帧（最本质差异）

• HTTP 1.1 ：基于文本协议，请求 / 响应以明文传输，解析时需处理换行符、空格等分隔符，易出错且效率低。

• HTTP 2.0 ：采用二进制分帧层，将所有数据分割为更小的 "帧"（Frame），每个帧包含头部信息（如流 ID、类型）和二进制数据。

  优势：解析更快（二进制无需处理文本歧义）、压缩效率更高、可在帧级别实现优先级控制。

2. 连接复用：串行请求 vs 多路复用

• HTTP 1.1：存在 "队头阻塞（Head-of-Line Blocking）" 问题：

  • 即使使用长连接，同一 TCP 连接中请求需串行发送（前一个请求未响应，后一个请求需等待）。
  • 为缓解此问题，浏览器通常对同一域名建立 6-8 个并行 TCP 连接，但仍受限于 TCP 慢启动、连接开销等问题。

• HTTP 2.0：通过 "多路复用（Multiplexing）" 彻底解决队头阻塞：

  • 一个 TCP 连接中可同时传输多个请求 / 响应，每个请求对应一个 "流（Stream）"，通过帧的 "流 ID" 区分归属。
  • 不同流的帧可交错传输，接收端通过流 ID 重组数据，实现并行处理，无需建立多个 TCP 连接。

3. 头部压缩：无专门压缩 vs HPACK 算法

• HTTP 1.1：请求头（如 Cookie、User-Agent）以文本形式重复传输，未压缩，占带宽比例高（尤其大量小请求场景）。

• HTTP 2.0 ：使用HPACK 压缩算法优化头部传输：

  • 客户端和服务器维护一份 "静态字典"（常用头部如Host、User-Agent的预设键值对）和 "动态字典"（会话中频繁出现的自定义头部）。
  • 传输时仅发送字典索引或差异值，减少头部体积（实测可压缩 50%-90%）。

4. 服务器推送（Server Push）

• HTTP 1.1：服务器只能被动响应客户端请求，无法主动推送资源。例如，客户端请求 HTML 后，需解析页面再逐一请求 CSS、JS，增加延迟。

• HTTP 2.0 ：支持服务器推送：

  • 服务器可预判客户端需要的资源（如 HTML 引用的 CSS），在响应初始请求时主动推送关联资源，无需等待客户端显式请求。
  • 例：客户端请求index.html，服务器同时推送style.css和app.js，减少 "请求 - 响应" 往返次数。

5. 流优先级控制

• HTTP 1.1：无法指定请求优先级，所有请求在连接中按顺序处理，关键资源（如 CSS）可能被非关键资源（如图片）阻塞。

• HTTP 2.0 ：每个流可设置优先级（权重 + 依赖关系）：

  • 客户端可标记 "CSS 流" 优先级高于 "图片流"，服务器优先处理高优先级帧，减少页面渲染阻塞。

差异总结

• 安全性：HTTP 2.0 通常与 HTTPS 绑定（主流浏览器仅支持 TLS 加密的 HTTP 2.0），而 HTTP 1.1 可明文传输。
• 兼容性：HTTP 2.0 完全兼容 HTTP 1.1 的语义（请求方法、状态码、URI 等不变），仅改变传输层实现，无需修改应用层逻辑。

核心价值 ：HTTP 2.0 通过二进制分帧和多路复用 ，从根本上解决了 HTTP 1.1 的队头阻塞问题，结合头部压缩和服务器推送，大幅降低了延迟、减少了带宽消耗，为复杂 Web 应用（如移动端、单页应用）提供了性能支撑。

五、HTTP和HTTPS协议的区别

回答时，应从安全性核心差异 出发，延伸到技术实现、端口、性能等维度，既讲清本质区别，又体现对网络安全的理解。

核心差异

HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）的核心差异在于安全性 。HTTP 是明文传输协议，数据在传输过程中可被轻易窃听、篡改；HTTPS 则是在 HTTP 基础上加入了 SSL/TLS 加密层，通过加密、认证机制确保数据传输的机密性和完整性，是目前主流的安全传输协议。

具体技术差异（按重要性排序）

1. 数据传输安全性

• HTTP ：

  数据以明文形式 在网络中传输，中间人可直接窃听内容 （如账号密码、交易信息），也可篡改数据 （如修改订单金额），且无法验证服务器身份（易遭受 "钓鱼攻击"）。

• HTTPS ：

  通过SSL/TLS 协议实现三层安全保障：

  • 机密性：使用对称加密算法（如 AES）加密传输数据，只有客户端和服务器能解密（通过非对称加密交换对称密钥）。
  • 完整性：通过哈希算法（如 SHA）校验数据，一旦被篡改会被检测到。
  • 身份认证：服务器需配置 CA 颁发的数字证书，客户端可验证服务器身份，防止钓鱼网站冒充。

2. 技术实现原理

• HTTP：直接基于 TCP 协议传输，协议栈为 "应用层（HTTP）→传输层（TCP）→网络层→链路层"。
• HTTPS ：在 HTTP 与 TCP 之间增加了SSL/TLS 加密层 ，协议栈为 "应用层（HTTP）→安全层（SSL/TLS）→传输层（TCP）→..."。
  简单说，HTTPS = HTTP + SSL/TLS，所有 HTTP 数据在传输前会先经过 SSL/TLS 加密。

3. 端口与默认配置

• HTTP ：默认使用80 端口 （如http://example.com:80可简写为http://example.com）。
• HTTPS ：默认使用443 端口 （如https://example.com:443可简写为https://example.com）。

4. 性能与资源消耗

• HTTP ：无需加密解密过程，传输效率更高，服务器资源消耗更少。
• HTTPS ：因增加了 SSL/TLS 握手（密钥交换、证书验证）和数据加解密步骤，会产生额外性能开销（通常增加 10%-30% 延迟），且服务器需消耗更多 CPU 资源。

5. 证书与成本

• HTTP：无需证书，部署零成本。
• HTTPS ：服务器必须配置由权威 CA 机构（如 Let's Encrypt、DigiCert）颁发的数字证书，部分 CA 机构收费（如企业级证书），但也有免费证书（如 Let's Encrypt）可供个人或小型网站使用。

应用场景

• HTTP 适用场景：对安全性要求极低的静态资源（如公开文档），但目前已极少使用，主流浏览器会对 HTTP 网站标记 "不安全"。

• HTTPS 适用场景：几乎所有场景，尤其是涉及用户隐私（登录、支付、个人信息）、交易数据的网站，已成为行业标准（如电商、银行、社交平台等）。

核心结论 ：HTTPS 通过加密和认证解决了 HTTP 的安全缺陷，是互联网数据传输的安全基础，虽然存在一定性能和部署成本，但相比安全风险，这些成本在绝大多数场景下是必要的。

六、当浏览器中输入Google.com并且按下回车之后发生了什么

当在浏览器中输入 "Google.com" 并按下回车后，会经历一系列复杂的过程，主要包括 URL 解析、DNS 域名解析、建立连接、发送请求、服务器处理请求与响应、浏览器渲染页面等步骤

但是，我这里对一部分的过程进行了简化 ，比如三次握手，四次挥手等部分，因为这些后文会讲，我们在这里主要聚焦于整体的过程

1. URL 解析 ：浏览器会先对输入的内容进行分析，判断其为网址后 ，若没有协议头，会自动在开头添加 "http://"。 由于 Google 默认使用 HTTPS 协议，后续可能会通过重定向等方式将协议转换为 HTTPS。

2. DNS 域名解析 ：域名系统（DNS）会将 "Google.com" 这个人类可读的域名转换为计算机可以理解的 IP 地址 。DNS 解析器会从根服务器开始，遍历域名系统的层次结构进行查询，最终获取到 Google 服务器的 IP 地址 。若本地 DNS 服务器或浏览器有相关缓存，则可直接使用缓存中的 IP 地址，以加快解析速度。

3. 建立连接 ：浏览器获取到 IP 地址后，会与 Google 服务器建立 TCP 连接 。若使用 HTTPS 协议，还会进行 TLS 握手，以协商加密算法、验证服务器证书等，确保连接的安全性。

4. 发送请求 ：浏览器会根据解析后的 URL 生成 HTTP 或 HTTPS 请求报文 ，通常使用 GET 方法，请求路径为根目录 "/"，表示访问 Google 的首页。请求报文中还会包含一些头部信息，如用户代理（User - Agent）、接受的内容类型等。然后，浏览器将请求报文通过 TCP 连接发送给 Google 服务器。

5. 服务器处理请求 ：Google 的服务器接收到请求后，会先经过负载均衡器，将请求均匀分配到不同的服务器上。接着，服务器会根据请求信息，如请求路径、头部信息等，查询相关的资源，可能会涉及到应用服务器从数据库中获取数据，动态组合页面内容等操作。

6. 服务器响应 ：服务器将请求的内容封装成 HTTP 或 HTTPS 响应报文，响应报文中包含状态码、响应头和响应体。状态码如 200 表示请求成功，响应头包含了缓存策略、内容类型等信息，响应体则是 Google 首页的 HTML、CSS、JavaScript 等文件内容。然后将响应报文发送回浏览器。

7. 浏览器缓存处理 ：浏览器接收到响应后，会根据响应头中的缓存策略，将一些资源缓存到本地，以便下次访问相同资源时可以直接从缓存中获取，提高访问速度。

8. 浏览器渲染页面 ：浏览器开始解析响应体中的 HTML 内容，通过标记化和树的构建等过程，构建 DOM 树。同时，解析 CSS 样式表，构建 CSSOM 树，然后将两者结合生成渲染树。浏览器根据渲染树计算元素的布局，并将页面绘制到屏幕上。在这个过程中，还会加载页面中的其他资源，如图片、脚本等，并执行 JavaScript 代码，实现页面的动态效果和交互功能。

七、HTTP请求报文是什么样的

HTTP 请求报文是客户端向服务器发送请求时传递的数据格式 。它由请求行（Request Line） 、请求头（Headers） 、空行 和请求体（Body）

1. 请求行（Request Line）

请求行是报文的第一行，包含三个核心信息，用空格分隔：

• 请求方法：表示对资源的操作类型（如 GET、POST、PUT 等）。
• 请求 URI ：指定要操作的资源路径（如/index.html或/api/users）。
• HTTP 版本 ：使用的 HTTP 协议版本（如HTTP/1.1、HTTP/2）。

GET /search?q=example HTTP/1.1

2. 请求头（Headers）

请求头由多个键值对组成，每行一个，用于传递附加信息（如客户端信息、请求参数、缓存控制等）。常见请求头包括：

头部字段	说明	示例
Host	服务器域名（HTTP 1.1 必需）	Host: www.google.com
User-Agent	客户端身份（浏览器 / 设备信息）	User-Agent: Mozilla/5.0 (Windows...)
Accept	客户端可接受的响应数据类型	Accept: text/html, application/json
Content-Type	请求体的数据格式（POST/PUT 时常用）	Content-Type: application/x-www-form-urlencoded
Cookie	客户端存储的 Cookie 信息	Cookie: sessionid=abc123; user=test
Connection	是否保持长连接	Connection: keep-alive

3. 空行

请求头与请求体之间必须有一个空行（仅换行符\r\n），用于分隔头部和正文，告诉服务器头部已结束。

4. 请求体（Body）

请求体是可选部分，主要用于 POST、PUT 等方法传递数据（如表单提交、JSON 数据），GET 请求通常没有请求体（参数在 URL 中）。 示例（表单数据）：

username=test&password=123456

示例（JSON 数据）：

{"name": "test", "age": 20}

完整请求报文示例（POST 请求）：

POST /api/login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Content-Type: application/json
Content-Length: 43
Cookie: sessionid=abc123

{"username": "admin", "password": "secure123"}

核心特点：

• 文本协议（HTTP 1.1 及之前），各部分通过换行符分隔，结构清晰。
• 请求头是关键，服务器通过解析头部信息处理请求（如内容类型、认证信息）。
• 请求体的格式需与Content-Type一致，否则服务器可能无法正确解析。

八、HTTP响应报文是什么样的

HTTP 响应报文是服务器对客户端请求的回复数据格式 ，遵循固定的结构规范。它由状态行（Status Line） 、响应头（Headers） 、空行 和响应体（Body）

1. 状态行（Status Line）

状态行是报文的第一行，包含三个核心信息，用空格分隔：

• HTTP 版本 ：服务器使用的 HTTP 协议版本（如HTTP/1.1、HTTP/2）。
• 状态码：表示请求处理结果的数字代码（如 200 表示成功，404 表示资源不存在）。
• 状态描述 ：对状态码的简短文字说明（如OK、Not Found）。

示例：

HTTP/1.1 200 OK

HTTP/1.1 404 Not Found

2. 响应头（Headers）

响应头由多个键值对组成，每行一个，用于传递服务器的附加信息（如内容类型、缓存策略、服务器信息等）。常见响应头包括：

头部字段	说明	示例
Content-Type	响应体的数据格式及编码	Content-Type: text/html; charset=UTF-8
Content-Length	响应体的字节长度（可选）	Content-Length: 1234
Server	服务器软件信息	Server: Nginx/1.21.0
Date	服务器响应时间	Date: Thu, 07 Aug 2025 12:00:00 GMT
Cache-Control	缓存控制策略	Cache-Control: max-age=3600
Set-Cookie	服务器向客户端设置 Cookie	Set-Cookie: sessionid=abc123; Path=/
Location	重定向的目标 URL（配合 3xx 状态码使用）	Location: https://www.google.com

3. 空行

响应头与响应体之间必须有一个空行（仅换行符\r\n），用于分隔头部和正文，告诉客户端头部已结束。

4. 响应体（Body）

响应体是可选部分，包含服务器返回的实际数据，其格式由Content-Type指定。常见的响应体类型：

• HTML 页面代码（text/html）
• JSON 数据（application/json）
• 图片二进制数据（image/jpeg）
• 纯文本（text/plain）

示例（HTML 响应体）：

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Hello World</h1></body>
</html>

示例（JSON 响应体）：

{"status": "success", "data": {"id": 1, "name": "Example"}}

完整响应报文示例（成功返回 HTML）：

HTTP/1.1 200 OK
Server: Nginx/1.21.0
Date: Thu, 07 Aug 2025 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 156
Cache-Control: max-age=60

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Google</title>
</head>
<body>
    <h1>Welcome to Google</h1>
</body>
</html>

核心特点：

• 状态码是核心标识，客户端通过状态码快速判断请求结果（如 2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务器错误）。
• 响应头控制着客户端如何处理数据（如缓存策略、解析方式、重定向逻辑）。
• 响应体的格式与Content-Type必须一致，否则客户端可能无法正确解析（如 JSON 数据需对应application/json）。

九、什么是HTTPS协议

HTTPS即超文本传输安全协议 ，是在 HTTP 协议基础上加入加密层 的安全版本，旨在通过加密传输保护客户端与服务器之间的数据安全。它基于 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）协议实现加密，是目前互联网中保护敏感信息（如登录凭证、支付数据等）传输的主流标准。

HTTPS 的核心原理

HTTPS 并非独立协议，而是 "HTTP + 加密层（TLS/SSL）" 的结合体。其核心逻辑是：在客户端与服务器建立连接时，先通过 TLS/SSL 协议协商加密方式、交换密钥，随后所有 HTTP 数据都通过协商好的加密方式传输，确保数据在传输过程中不被窃取或篡改。

具体流程可简化为：

1. 握手阶段 ：客户端与服务器交换证书、协商加密算法（如 RSA、ECDHE），生成会话密钥。
2. 加密传输 ：后续所有 HTTP 请求和响应都使用会话密钥进行加密，第三方无法解密或篡改。

HTTPS 的核心特点（与 HTTP 对比）

特点	HTTP	HTTPS
安全性	明文传输，数据易被窃取 / 篡改	加密传输，数据机密性和完整性有保障
端口	默认使用 80 端口	默认使用 443 端口
证书	无需证书	需由 CA（证书颁发机构）签发的 SSL 证书
性能	无加密开销，速度较快	加密解密过程会增加少量性能开销
适用场景	非敏感数据（如公开新闻）	敏感数据（如登录、支付、个人信息）

HTTPS 的加密方式

HTTPS 采用混合加密机制（非对称加密 + 对称加密），兼顾安全性和效率：

1. 非对称加密（握手阶段）：

   • 服务器拥有一对密钥：公钥（公开）和私钥（保密）。
   • 客户端用服务器公钥加密 "会话密钥" 并发送，只有服务器的私钥能解密，确保会话密钥安全。

2. 对称加密（数据传输阶段）：

   • 客户端与服务器使用握手阶段协商的 "会话密钥"（对称密钥）加密后续所有数据。
   • 对称加密效率远高于非对称加密，适合大量数据传输。

HTTPS 的证书作用

SSL 证书是 HTTPS 安全的核心凭证，由权威 CA（如 Let's Encrypt、DigiCert）签发，包含：

• 服务器域名、公钥、证书有效期、CA 签名等信息。

• 作用：

  1. 验证服务器身份（防止 "中间人攻击"，确保客户端连接的是真实服务器）。
  2. 提供服务器公钥，用于握手阶段的加密协商。

若证书无效（如过期、域名不匹配、未被信任 CA 签发），浏览器会提示 "不安全" 警告。

HTTPS 的优势

• 数据机密性 ：加密传输可防止数据被窃听（如公共 Wi-Fi 中的监听）。
• 数据完整性 ：通过哈希算法校验数据，确保传输中未被篡改。
• 身份认证 ：通过证书验证服务器真实性，避免钓鱼网站。
• 搜索引擎友好 ：Google 等搜索引擎优先收录 HTTPS 网站，影响排名。

HTTPS 通过加密、认证和完整性校验，解决了 HTTP 明文传输的安全漏洞，是现代互联网中保护用户数据安全的基础协议。 尽管存在少量性能开销 ，但在隐私保护日益重要的今天，已成为网站（尤其是涉及用户敏感信息的平台）的标配。

十、TLS/SSL的工作原理

TLS和 SSL是用于在网络通信中提供加密、身份认证和数据完整性的安全协议（TLS 是 SSL 的后续版本，目前主流使用 TLS 1.2/1.3 ）。它们的核心作用是在客户端和服务器之间建立一个安全的加密通道，确保数据传输不被窃听、篡改或伪造。

TLS/SSL 的核心目标

1. 机密性：通过加密算法将数据转为密文，只有通信双方能解密。
2. 完整性：确保数据在传输中未被篡改（通过哈希校验实现）。
3. 身份认证：验证通信对方的真实身份（主要通过证书验证服务器，可选验证客户端）。

TLS/SSL 的工作流程（以 TLS 1.2 为例）

TLS/SSL 的工作过程可分为两大阶段：握手阶段 （协商加密参数、交换密钥）和数据传输阶段（用协商的密钥加密通信）。

1. 握手阶段（核心步骤）

握手阶段是 TLS/SSL 最复杂的部分，目的是让客户端和服务器协商出一个会话密钥（用于后续对称加密），并验证服务器身份。以下是简化流程：

• 步骤 1：客户端发起 "客户端问候"（Client Hello）

  客户端向服务器发送：

  • 支持的 TLS 版本（如 TLS 1.2）。
  • 支持的加密套件列表（如ECDHE-RSA-AES256-GCM-SHA384，包含密钥交换算法、对称加密算法、哈希算法）。
  • 一个随机数（Client Random），用于后续生成会话密钥。
  • 其他可选信息（如压缩方法）。

• 步骤 2：服务器回应 "服务器问候"（Server Hello）

  服务器从客户端的选项中选择合适的配置并返回：

  • 确认的 TLS 版本。
  • 选定的加密套件（如ECDHE-RSA-AES256-GCM-SHA384）。
  • 服务器生成的随机数（Server Random）。

• 步骤 3：服务器发送证书（Certificate）

  服务器向客户端发送SSL 证书（由权威 CA 签发），包含：

  • 服务器的公钥（用于后续加密）。
  • 证书持有者信息（如域名）、有效期、CA 签名等。
    客户端会验证证书的有效性（如是否过期、域名是否匹配、是否被信任的 CA 签发），若无效则提示风险。

• 步骤 4：服务器发送 "服务器问候完成"（Server Hello Done）

  告知客户端：服务器的问候信息已发送完毕，等待客户端回应。

• 步骤 5：客户端验证证书并生成 "预主密钥"（Pre-Master Secret）

  客户端验证证书通过后：

  • 生成一个随机数Pre-Master Secret（预主密钥）。
  • 用服务器证书中的公钥 加密Pre-Master Secret，发送给服务器（只有服务器的私钥能解密）。

• 步骤 6：客户端和服务器生成 "会话密钥"

  客户端和服务器分别使用已交换的三个随机数（Client Random、Server Random、Pre-Master Secret），通过加密套件中约定的算法，生成相同的会话密钥（对称密钥，用于后续数据加密）。

• 步骤 7：客户端发送 "完成通知"（Client Finished）

  客户端用会话密钥加密一段 "结束信息"（包含握手阶段的所有数据哈希值），发送给服务器，证明握手未被篡改，且客户端已准备好加密通信。

• 步骤 8：服务器发送 "完成通知"（Server Finished）

  服务器用会话密钥解密客户端的 "完成通知"，验证通过后，同样加密一段 "结束信息" 发送给客户端，证明服务器也已准备好。

  至此，握手阶段结束，双方已确认会话密钥一致，且握手过程未被篡改。

2. 数据传输阶段

握手完成后，客户端和服务器使用会话密钥（对称加密算法，如 AES）对所有后续通信数据进行加密和解密。同时，通过哈希算法（如 SHA-256）生成数据的校验值，确保数据传输中未被篡改（若篡改，校验值会不匹配）。

TLS 1.3 的优化（与 TLS 1.2 对比）

TLS 1.3 是目前最新的版本，简化了握手流程，提升了安全性和效率：

• 减少握手次数：将握手从 "2-RTT"（往返次数）缩短到 "1-RTT"，甚至首次连接可实现 "0-RTT"（复用之前的会话信息）。
• 移除不安全加密套件：禁用了 SHA-1、RC4 等弱加密算法，仅保留更安全的选项（如 ECDHE 密钥交换、AES-GCM 对称加密）。
• 简化流程：合并了部分步骤（如服务器问候和证书发送可并行），减少数据传输量。

核心总结

TLS/SSL 通过 "非对称加密交换密钥，对称加密传输数据" 的混合模式，兼顾了安全性和效率：

1. 握手阶段用非对称加密（服务器公钥加密预主密钥）确保密钥安全交换。
2. 数据传输阶段用对称加密（会话密钥）高效加密大量数据。
3. 证书用于验证服务器身份，防止 "中间人攻击"。
4. 哈希校验确保数据传输的完整性。

十一、HTTPS是如何保证安全的

HTTPS通过结合加密技术 、身份认证 和数据完整性校验 ，在 HTTP 的基础上构建了一套安全机制，确保客户端与服务器之间的通信不被窃听、篡改或伪造 。其核心安全保障来自于TLS/SSL 协议（传输层安全协议）的加持

具体的TLS/SSL工作原理可以看上一道面试题

十二、常见的状态码

HTTP 状态码是服务器对客户端请求的响应状态标识 ，由三位数字组成，分为 5 类（以第一位数字区分）。以下是常见状态码的详细说明：

一、1xx：信息性状态码（请求已接收，继续处理）

表示服务器已接收请求，正在处理或需要进一步操作。

• 100 Continue：服务器已收到请求头，客户端可继续发送请求体（常用于大文件上传）。
• 101 Switching Protocols：服务器同意客户端的协议切换请求（如从 HTTP 切换到 WebSocket）。

二、2xx：成功状态码（请求已成功处理）

表示客户端请求被服务器正常接收并处理。

• 200 OK：请求成功，服务器返回对应数据（最常见状态码）。
• 201 Created：请求成功且服务器创建了新资源（如 POST 提交表单创建用户）。
• 204 No Content：请求成功，但服务器无数据返回（如 DELETE 删除资源后）。
• 206 Partial Content：客户端请求部分资源（如断点续传），服务器成功返回部分数据。

三、3xx：重定向状态码（需要进一步操作以完成请求）

表示客户端需要通过额外操作（如跳转）才能完成请求。

• 301 Moved Permanently：资源永久迁移到新 URL，浏览器会缓存新地址（下次直接访问新 URL）。
• 302 Found：资源临时迁移到新 URL，浏览器不会缓存新地址（每次请求仍需通过原 URL 跳转）。
• 304 Not Modified：资源未修改，客户端可使用本地缓存（常用于静态资源优化，减少带宽消耗）。
• 307 Temporary Redirect：与 302 类似，但要求客户端必须使用原请求方法（如 POST 不能改为 GET）。

四、4xx：客户端错误状态码（请求存在错误，服务器无法处理）

表示客户端请求有问题（如语法错误、权限不足），服务器无法处理。

• 400 Bad Request：请求语法错误（如参数格式错误），服务器无法解析。
• 401 Unauthorized：请求需要身份认证（如未登录时访问需登录的页面），通常会返回登录页面。
• 403 Forbidden：服务器拒绝请求（如登录后无权限访问某资源）。
• 404 Not Found：请求的资源不存在（最常见错误，如 URL 拼写错误）。
• 405 Method Not Allowed：请求方法不被允许（如用 POST 访问仅支持 GET 的接口）。
• 408 Request Timeout：客户端请求超时（服务器等待太久未收到完整请求）。
• 409 Conflict：请求与服务器当前状态冲突（如创建已存在的用户）。

五、5xx：服务器错误状态码（服务器处理请求时发生错误）

表示服务器在处理请求时出现内部错误。

• 500 Internal Server Error：服务器内部错误（如代码 bug、数据库连接失败）。
• 502 Bad Gateway：服务器作为网关 / 代理时，收到上游服务器的无效响应（如反向代理后端服务崩溃）。
• 503 Service Unavailable：服务器暂时无法处理请求（如维护中、负载过高），通常会包含重试时间。
• 504 Gateway Timeout：服务器作为网关 / 代理时，等待上游服务器响应超时。

总结

状态码的第一位数字代表大类：

• 1xx：临时响应
• 2xx：成功
• 3xx：重定向
• 4xx：客户端错误
• 5xx：服务器错误

理解状态码有助于快速定位问题（如 4xx 排查客户端请求，5xx 排查服务器故障）。

十三、DNS协议是什么

DNS（Domain Name System，域名系统）是互联网的核心协议之一，被称为 "互联网的地址簿"，其核心作用是将人类易读的域名（如www.google.com）转换为计算机可识别的 IP 地址（如142.250.185.14） ，使客户端能通过域名访问服务器。

DNS 的核心功能

• 域名解析：最主要功能，将域名映射到对应的 IP 地址（正向解析），也可将 IP 地址反向映射到域名（反向解析）。
• 负载均衡：通过返回多个 IP 地址，实现请求分发（如大型网站会为同一域名配置多个服务器 IP）。
• 容错机制：当某个 IP 对应的服务器故障时，可返回其他可用 IP，提高服务可用性。

DNS 的域名结构（层级体系）

域名采用层级化结构，类似文件系统的目录树，从右到左层级升高：

• 根域名 ：最顶层，用.表示（如www.google.com.，末尾的.常省略）。
• 顶级域名（TLD） ：根域名下的第一层，如.com（商业）、.org（组织）、.cn（国家）。
• 二级域名 ：顶级域名下的层级，如google.com中的google。
• 子域名 ：二级域名下可继续细分，如www.google.com中的www（常用作网站前缀）。

示例：mail.tech.example.com的层级为：
com（顶级）→ example（二级）→ tech（三级）→ mail（四级）

DNS 解析的工作流程（以解析www.google.com为例）

DNS 解析采用递归查询 + 迭代查询结合的方式，流程如下：

1. 客户端查询本地缓存 ：

   浏览器、操作系统会缓存近期解析过的域名 - IP 映射，若存在则直接返回（最快，无需网络请求）。

2. 本地 DNS 服务器查询 ：

   若本地缓存无结果，客户端向本地 DNS 服务器 （如路由器分配的 DNS 或手动设置的8.8.8.8）发送查询请求。

3. 迭代查询各级 DNS 服务器 ：

   本地 DNS 服务器若自身无缓存，会逐级向更高层级的 DNS 服务器查询：

   • 先查询根 DNS 服务器 ，获取.com顶级域名服务器的 IP。
   • 再查询.com顶级域名服务器，获取google.com权威 DNS 服务器的 IP。
   • 最后查询google.com的权威 DNS 服务器，获取www.google.com对应的 IP。

4. 返回结果并缓存 ：

   本地 DNS 服务器将获取的 IP 返回给客户端，同时缓存该结果（一段时间内再次查询可直接返回）。

DNS 的关键特点

• 分布式架构 ：全球有大量根服务器、顶级域名服务器和权威服务器，共同构成分布式系统，避免单点故障。
• 缓存机制 ：各级都有缓存（客户端、本地 DNS、服务器），减少重复查询，提升解析速度。
• UDP 协议为主 ：DNS 查询默认使用 UDP 的 53 端口（传输快），复杂查询（如返回数据量大）会自动切换到 TCP。

DNS 是互联网的 "翻译官"，解决了 "人类记域名、机器认 IP" 的矛盾 。没有 DNS，用户访问网站需记住冗长的 IP 地址（如142.250.185.14），互联网的易用性会大幅下降。其分布式架构和缓存机制确保了高效、可靠的域名解析服务，是现代网络通信的基础。

十四、DNS完整的查询过程

这部分算是对DNS的补充

NS（域名系统）的完整查询过程是一个从本地到全球分布式服务器 的层级查询流程，结合了缓存机制和层级解析 ，目的是高效地将域名（如www.example.com）转换为 IP 地址。以下是详细步骤：

前提：DNS 的层级结构

DNS 服务器按层级划分，从上到下依次为：

1. 根 DNS 服务器（全球共 13 组，负责顶级域名的解析）
2. 顶级域名服务器 （如.com、.cn、.org对应的服务器）
3. 权威 DNS 服务器（域名持有者配置的服务器，存储域名与 IP 的映射关系）
4. 本地 DNS 服务器（用户设备或网络服务商提供的 DNS 服务器，如路由器 DNS、ISP DNS）

完整查询流程（以 "客户端访问www.example.com" 为例）

1. 客户端本地缓存查询（最快路径）

• 当用户在浏览器输入www.example.com并回车时，客户端会先检查本地缓存：

  • 浏览器缓存：浏览器会缓存近期解析过的域名（如 Chrome 默认缓存 1 分钟到 1 小时）。
  • 操作系统缓存 ：操作系统（如 Windows 的hosts文件、DNS 缓存服务）也会缓存域名解析结果。

• 若命中缓存：直接返回 IP 地址，无需后续步骤，解析结束。

2. 本地 DNS 服务器查询（递归查询）

• 若本地缓存无结果，客户端会向本地 DNS 服务器 （通常由路由器或 ISP 自动分配，如192.168.1.1或223.5.5.5）发送查询请求，这是一次递归查询（客户端只需等待最终结果，无需自己逐级查询）。

• 本地 DNS 服务器先检查自身缓存：

  • 若命中缓存：直接将 IP 返回给客户端。
  • 若未命中 ：进入下一步，向更高层级的 DNS 服务器发起迭代查询。

3. 向根 DNS 服务器查询（迭代查询第一步）

• 本地 DNS 服务器向根 DNS 服务器 （全球共 13 组，如a.root-servers.net）发送查询请求：

  • 根服务器不直接存储www.example.com的 IP，但知道.com顶级域名服务器的地址。
  • 根服务器返回：.com顶级域名服务器的 IP 列表（如a.gtld-servers.net）。

4. 向顶级域名服务器查询（迭代查询第二步）

• 本地 DNS 服务器向.com顶级域名服务器发送查询请求：

  • 顶级域名服务器知道example.com对应的权威 DNS 服务器地址（由域名持有者在购买域名时配置，如阿里云 DNS、Cloudflare DNS）。
  • 顶级域名服务器返回：example.com的权威 DNS 服务器 IP 列表（如dns1.example.com）。

5. 向权威 DNS 服务器查询（迭代查询第三步）

• 本地 DNS 服务器向example.com的权威 DNS 服务器发送查询请求：

  • 权威 DNS 服务器是域名持有者直接管理的服务器，存储着www.example.com与 IP 的映射关系（如192.0.2.1）。
  • 权威 DNS 服务器返回：www.example.com对应的 IP 地址。

6. 结果返回与缓存

• 本地 DNS 服务器将获取到的 IP 地址返回给客户端，并将该结果缓存（缓存时间由域名的TTL值决定，通常为几分钟到几小时）。
• 客户端收到 IP 地址后，缓存该结果，然后通过 IP 地址与目标服务器建立连接（如 TCP 连接），完成后续的 HTTP/HTTPS 请求。

特殊情况

• DNS 负载均衡：权威 DNS 服务器可能返回多个 IP 地址（对应同一域名的不同服务器），本地 DNS 服务器或客户端会选择一个 IP 进行连接，实现流量分发。
• CDN 加速：若域名使用 CDN（如 Cloudflare、阿里云 CDN），权威 DNS 服务器会返回离客户端最近的 CDN 节点 IP，减少访问延迟。
• 反向 DNS 查询：少数场景下（如邮件服务器反垃圾邮件），会通过 IP 地址查询对应的域名（与正向解析流程相反）。

核心逻辑

DNS 查询是一个 "从本地到全球，从缓存到权威" 的层级过程：

1. 优先使用本地缓存（客户端→操作系统→本地 DNS），减少网络请求。
2. 未命中缓存时，通过迭代查询从根服务器→顶级域名服务器→权威服务器逐级获取解析结果。
3. 各级均有缓存机制，确保解析效率和可靠性。

这一分布式架构既解决了 "域名到 IP 的映射" 问题，又通过缓存和层级设计支撑了全球互联网的高效运转。

十五、OSI七层模型

OSI 七层模型（Open Systems Interconnection Reference Model）是国际标准化组织（ISO）定义的网络通信架构标准，将网络通信过程分为 7 个层次，每层负责特定功能，通过标准化接口实现层间协作。这种分层设计的核心优势是模块化 （每层独立开发）和兼容性（不同厂商设备可互通）。

OSI 七层模型从下到上的层级及功能：

1. 物理层（Physical Layer）

• 核心功能 ：负责将数据转换为电信号、光信号或无线电信号，在物理介质（如网线、光纤、无线信道）上传输原始比特流（0 和 1）。
• 关键技术：定义物理接口（如 RJ45 接口）、传输速率（如 100Mbps）、信号编码方式（如曼彻斯特编码）、介质类型（如双绞线、光纤）。
• 典型设备：网卡、集线器（Hub）、网线、光纤。

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

• 核心功能 ：在物理层基础上，将原始比特流封装为帧（Frame） ，实现相邻设备间的可靠传输（如同一局域网内的两台设备）。

• 主要任务：

  • 帧同步（标识帧的开始和结束）。
  • 差错控制（通过校验码检测 / 纠正传输错误）。
  • 流量控制（避免接收方过载）。
  • MAC 地址寻址（通过 MAC 地址识别局域网内的设备）。

• 典型设备：交换机（Switch）、网桥（Bridge）。

• 常见协议：以太网（Ethernet）、PPP（点对点协议）、MAC 协议。

3. 网络层（Network Layer）

• 核心功能 ：实现不同网络之间的数据包路由（如从局域网到互联网），解决跨网络的通信问题。

• 主要任务：

  • 逻辑寻址（通过 IP 地址标识设备，区别于数据链路层的 MAC 地址）。
  • 路由选择（通过路由算法选择最优路径，如 OSPF、RIP 协议）。
  • 分片与重组（对超过最大传输单元（MTU）的数据包拆分，到达后重组）。

• 典型设备：路由器（Router）、三层交换机。

• 常见协议：IP（IPv4/IPv6）、ICMP（互联网控制消息协议，如 ping 命令）、ARP（地址解析协议，IP 转 MAC）。

4. 传输层（Transport Layer）

• 核心功能 ：为端到端（如客户端到服务器）的应用程序提供可靠的数据传输服务，屏蔽底层网络的差异。

• 主要任务：

  • 端口寻址（通过端口号区分同一设备上的不同应用，如 80 端口对应 HTTP）。
  • 可靠传输（如 TCP 的三次握手、重传机制）。
  • 流量控制与拥塞控制（避免网络拥塞）。
  • 数据分段与重组（将应用层数据拆分为适合传输的段，到达后重组）。

• 常见协议：

  • TCP（传输控制协议，可靠、面向连接，如 HTTP/HTTPS、邮件）。
  • UDP（用户数据报协议，不可靠、无连接，如视频流、实时通信）。

5. 会话层（Session Layer）

• 核心功能 ：建立、管理和终止应用程序之间的会话连接，确保通信双方有序交互。

• 主要任务：

  • 会话建立（如验证身份、协商通信参数）。
  • 会话维护（如断点续传的 checkpoint 标记）。
  • 会话终止（正常关闭连接或异常中断处理）。

• 典型应用：数据库连接会话、远程登录（如 Telnet）的会话管理。

6. 表示层（Presentation Layer）

• 核心功能 ：处理数据的格式转换和表示，确保发送方和接收方对数据的理解一致。

• 主要任务：

  • 数据格式转换（如不同编码的字符串转换，ASCII 与 Unicode）。
  • 数据压缩（减少传输量，如 gzip）。
  • 数据加密 / 解密（如 HTTPS 中的 TLS 加密）。

• 典型应用：JPEG 图片编码、XML/JSON 格式处理、SSL/TLS 加密。

7. 应用层（Application Layer）

• 核心功能 ：直接为用户应用程序提供网络服务，是用户与网络的接口。

• 常见协议与服务：

  • HTTP/HTTPS（网页访问）。
  • FTP（文件传输）、SMTP（邮件发送）、POP3/IMAP（邮件接收）。
  • DNS（域名解析）、Telnet（远程登录）、SSH（安全远程登录）。

• 典型应用程序：浏览器、邮件客户端、文件传输工具。

数据传输流程：封装与解封装

• 发送端 ：数据从应用层向下传递，每层会添加本层的头部信息 （部分层还会添加尾部），这一过程称为封装。
• 接收端 ：数据从物理层向上传递，每层会剥离本层的头部信息，提取有效数据并传递给上层，这一过程称为解封装。

例如：浏览器访问网页时，数据流程为：

应用层（HTTP 请求）→ 传输层（TCP 段，添加端口）→ 网络层（IP 包，添加 IP 地址）→ 数据链路层（帧，添加 MAC 地址）→ 物理层（比特流）→ 传输介质 → 接收端反向解封装。

OSI 七层模型是理解网络通信的经典框架，但是实际应用中更常用简化的 TCP/IP 四层模型

十六、TCP/IP五层协议

TCP/IP 五层协议是对网络通信流程的简化分层模型，结合了 OSI 七层模型的实用性和简洁性，广泛应用于实际网络设计与教学中。它将网络通信划分为从底层到上层的 5 个层次，每层负责特定功能，通过协议协作实现数据的端到端传输。

TCP/IP 五层协议的层级及核心功能（从下到上）

1. 物理层（Physical Layer）

• 核心功能 ：负责将二进制数据（0 和 1）转换为物理信号（如电信号、光信号、无线电波），通过物理介质（网线、光纤、无线信道）传输。
• 关键技术：定义物理接口标准（如 RJ45 接口、光纤接口）、传输速率（如 100Mbps、1Gbps）、信号编码方式（如曼彻斯特编码）、传输介质类型（双绞线、光纤、无线频谱）。
• 典型设备：网卡、集线器（Hub）、网线、光纤、无线网卡。

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

• 核心功能 ：在物理层基础上，将原始比特流封装为帧（Frame） ，实现同一局域网内相邻设备间的可靠传输。

• 主要任务：

  • 帧同步：通过帧头和帧尾标识帧的边界（如以太网的前导码和帧校验序列 FCS）。
  • 差错控制：使用 CRC 校验检测帧传输错误，错误帧会被丢弃并要求重传。
  • MAC 寻址：通过 MAC 地址（硬件地址，如网卡的物理地址）识别局域网内的设备，确保数据发送到正确目标。
  • 流量控制：调节发送速率，避免接收方缓冲区溢出。

• 典型设备：交换机（Switch）、网桥（Bridge）。

• 核心协议：以太网（Ethernet）协议、PPP（点对点协议，用于拨号上网）、ARP（地址解析协议，将 IP 地址转换为 MAC 地址）。

3. 网络层（Network Layer）

• 核心功能 ：实现跨网络（不同局域网 / 广域网）的数据包路由与转发，解决 "不同网络之间如何通信" 的问题。

• 主要任务：

  • 逻辑寻址 ：通过 IP 地址（如 IPv4 的192.168.1.1、IPv6 的2001:db8::1）标识设备的网络位置，区分不同网络。
  • 路由选择：通过路由协议（如 RIP、OSPF）计算最优路径，将数据包从源网络转发到目标网络。
  • 分片与重组：当数据包大小超过网络的最大传输单元（MTU）时，将其拆分为小分片，到达目标后重组。

• 典型设备：路由器（Router）、三层交换机。

• 核心协议 ：IP（Internet Protocol，IPv4/IPv6，负责数据包的路由）、ICMP（互联网控制消息协议，如ping命令用于检测网络连通性）、IGMP（组播管理协议）。

4. 传输层（Transport Layer）

• 核心功能 ：为端到端的应用程序提供可靠的数据传输服务，屏蔽底层网络的差异，确保数据完整、有序地到达。

• 主要任务：

  • 端口寻址：通过端口号（如 80 端口对应 HTTP、443 端口对应 HTTPS）区分同一设备上的不同应用程序，实现 "进程到进程" 的通信。
  • 可靠传输：通过 TCP 协议的三次握手、确认重传、拥塞控制等机制，保证数据无丢失、无重复、按序到达。
  • 高效传输：通过 UDP 协议提供无连接、低延迟的传输服务，适合实时性要求高的场景（如视频流、游戏）。

• 核心协议：

  • TCP（传输控制协议） ：面向连接、可靠、有序，适用于 HTTP、邮件、文件传输等需要确保数据完整性的场景。
  • UDP（用户数据报协议） ：无连接、不可靠、低延迟，适用于视频通话、直播、DNS 查询等实时性优先的场景。

5. 应用层（Application Layer）

• 核心功能 ：直接为用户应用程序提供网络服务，是用户与网络的接口，定义了应用程序之间的通信规则。

• 常见协议与服务：

  • 网页访问：HTTP/HTTPS
  • 文件传输：FTP（文件传输协议）、SFTP（安全文件传输）
  • 邮件服务：SMTP（发送邮件）、POP3/IMAP（接收邮件）
  • 域名解析：DNS（将域名转换为 IP 地址）
  • 远程登录：Telnet、SSH（安全远程登录）

• 典型应用：浏览器、邮件客户端（如 Outlook）、文件传输工具（如 FileZilla）、即时通讯软件。

数据传输流程：封装与解封装

在 TCP/IP 五层模型中，数据的传输遵循 "封装→传输→解封装" 的流程：

• 发送端 ：应用程序产生的数据从应用层向下传递，每层会添加本层的头部信息（部分层含尾部），形成该层的协议数据单元（PDU）：

  • 应用层：数据（Data）
  • 传输层：段（Segment，TCP）或数据报（Datagram，UDP）
  • 网络层：数据包（Packet）
  • 数据链路层：帧（Frame）
  • 物理层：比特流（Bit）

• 接收端：数据从物理层向上传递，每层会剥离本层的头部信息，提取有效数据并传递给上层，最终到达应用程序。

示例 ：用浏览器访问www.example.com时，数据流程为：

1. 应用层：浏览器生成 HTTP 请求数据。
2. 传输层：添加 TCP 头部（含源端口、目标端口 80），形成 TCP 段。
3. 网络层：添加 IP 头部（含源 IP、目标 IP），形成 IP 包。
4. 数据链路层：添加 MAC 头部（含源 MAC、目标 MAC），形成以太网帧。
5. 物理层：将帧转换为电信号，通过网线传输。
6. 接收端（服务器）反向解封装，最终将 HTTP 请求传递给 Web 服务器处理。

与 OSI 七层模型的对应关系

TCP/IP 五层模型是 OSI 七层模型的简化，两者的对应关系如下：

• 物理层 → 对应 OSI 物理层
• 数据链路层 → 对应 OSI 数据链路层
• 网络层 → 对应 OSI 网络层
• 传输层 → 对应 OSI 传输层
• 应用层 → 对应 OSI 会话层、表示层、应用层（将这三层功能合并）

TCP/IP 五层协议以简洁实用的方式描述了网络通信的分层逻辑，每层通过标准化协议实现特定功能，层间通过接口协作，最终实现 "从应用程序到应用程序" 的数据传输。

十七、TCP和UDP的区别

TCP（传输控制协议）和 UDP（用户数据报协议）是 TCP/IP 协议栈中传输层的两个核心协议，它们在设计目标、工作方式和适用场景上有显著区别。

1. 连接性

• TCP：

  • 面向连接：通信前必须通过 "三次握手" 建立连接，通信结束后通过 "四次挥手" 释放连接，类似打电话前的拨号和结束后的挂断。
  • 例：浏览器访问网页（HTTP 基于 TCP）时，客户端与服务器会先建立 TCP 连接，再传输数据。

• UDP：

  • 无连接：通信前无需建立连接，直接发送数据，类似写信时直接投递，无需提前通知对方。
  • 例：DNS 查询时，客户端直接向 DNS 服务器发送 UDP 数据包，无需预先建立连接。

2. 可靠性

• TCP：

  • 可靠传输：通过多种机制确保数据准确、完整地到达：

    • 确认机制：接收方收到数据后必须发送确认（ACK），发送方未收到 ACK 则重传；
    • 序号与重排：数据按序号传输，接收方会重组乱序的数据包；
    • 流量控制：通过滑动窗口限制发送速率，避免接收方缓冲区溢出；
    • 拥塞控制：检测网络拥塞时降低发送速率，减少数据包丢失。

• UDP：

  • 不可靠传输：不提供确认、重传、排序等机制，数据包可能丢失、重复或乱序，且不保证送达。
  • 仅在 IP 层提供最基本的校验和（可选），用于检测数据在传输中是否损坏，若损坏则直接丢弃。

3. 传输效率

• TCP：

  • 因连接建立 / 释放、确认、重传等机制，开销大、延迟高，适用于对可靠性要求高但可接受一定延迟的场景（如文件传输、网页加载）。

• UDP：

  • 无连接管理和复杂控制机制，头部开销小（仅 8 字节，TCP 头部至少 20 字节）、延迟低、传输效率高，适用于实时性要求高的场景（如视频通话、游戏数据传输）。

4. 数据边界

• TCP：

  • 字节流传输：数据被视为连续的字节流，发送方和接收方不保留数据的 "边界"。例如，发送方分 3 次发送 "Hello""World""！"，接收方可能一次性收到 "HelloWorld！"。
  • 需应用层自行处理数据分割（如 HTTP 通过 Content-Length 标识数据长度）。

• UDP：

  • 数据报传输：每个 UDP 数据包是独立的 "数据报"，发送方发送的每个数据包会被完整接收（若未丢失），保留数据边界。例如，发送方分 3 次发送 3 个 UDP 包，接收方会按 3 个独立包处理。

5. 适用场景

协议	典型应用场景	核心原因
TCP	网页访问（HTTP/HTTPS）、文件传输（FTP）、邮件收发（SMTP/POP3）、即时通讯文本消息	需确保数据完整（如文件不能损坏，网页代码不能缺失）。
UDP	视频 / 语音通话（如 Zoom）、在线游戏、DNS 查询、广播 / 组播（如流媒体推送）	允许少量数据丢失，但需低延迟（如游戏操作延迟需低于 100ms，视频卡顿可容忍）。

总结对比表

对比维度	TCP	UDP
连接性	面向连接（三次握手建立连接）	无连接（直接发送）
可靠性	可靠（确认、重传、排序等）	不可靠（无确认，可能丢失）
传输效率	低（开销大、延迟高）	高（开销小、延迟低）
数据形式	字节流（无边界）	数据报（有边界）
头部大小	至少 20 字节	8 字节
拥塞控制 / 流量控制	支持	不支持
适用场景	对可靠性要求高的场景（文件、网页）	对实时性要求高的场景（视频、游戏）

一句话总结 ：TCP 像 "挂号信"，确保送达但流程繁琐；UDP 像 "普通平信"，简单高效但不保证送达，两者分别满足不同的网络通信需求。

十八、TCP和UDP的使用场景

同上

十九、TCP三次握手和四次挥手

这里就推荐一篇文章(建议收藏)TCP协议灵魂之问，巩固你的网路底层基础TCP - 掘金

总结

燃尽了