计算机网络复试面试问题总结_计算机网络复试问题汇总-CSDN博客
网络OSI模型和TCP/IP模型分别介绍一下
层数 名称 核心功能 典型协议/设备 7 应用层（Application） 为用户提供网络服务接口 HTTP, FTP, SMTP, DNS 6 表示层（Presentation） 数据格式转换、加密解密、压缩 SSL/TLS（部分功能） 5 会话层（Session） 建立、管理和终止会话 RPC, NetBIOS 4 传输层（Transport） 端到端可靠传输、流量控制、差错恢复 TCP, UDP 3 网络层（Network） 逻辑寻址、路由选择 IP, ICMP, ARP 2 数据链路层（Data Link） 物理寻址（MAC）、帧同步、差错检测 Ethernet, PPP, 交换机 1 物理层（Physical） 比特流传输、电气/机械接口 网线、光纤、集线器 TCP/IP 四层模型（实际使用的工业标准）
层数 名称 对应 OSI 层 核心功能 典型协议 4 应用层（Application） 应用层 + 表示层 + 会话层 提供应用程序通信接口 HTTP, DNS, FTP, SMTP 3 传输层（Transport） 传输层 端到端数据传输 TCP, UDP 2 网络层（Internet） 网络层 IP 寻址与路由 IP, ICMP, IGMP 1 网络接口层（Link） 数据链路层 + 物理层 物理传输与 MAC 寻址 Ethernet, Wi-Fi, ARP
tcp、ip分别位于哪一层？
- tcp 在传输层
- ip 在网络层
应用层有哪些协议？
HTTP、HTTPS、CDN、DNS、FTP 都是应用层协议
HTTP常用的状态码？
| 类别 | 范围 | 含义 |
|---|---|---|
| 1xx | 100--199 | 信息响应（临时状态，很少用） |
| 2xx | 200--299 | 成功 ✅ |
| 3xx | 300--399 | 重定向 |
| 4xx | 400--499 | 客户端错误 ❌ |
| 5xx | 500--599 | 服务端错误 ⚠️ |
4xx 客户端错误（重点排查！）
| 状态码 | 含义 | 典型原因 |
|---|---|---|
| 400 Bad Request | 请求格式错误 | JSON 格式错、参数缺失、类型不匹配 |
| 401 Unauthorized | 未认证 | Token 缺失、过期、无效（需登录） |
| 403 Forbidden | 无权限 | 用户已登录，但角色无权访问（如普通用户访问管理员接口） |
| 404 Not Found | 资源不存在 | URL 错、ID 不存在（如 /users/99999） |
| 405 Method Not Allowed | 方法不支持 | 对只允许 GET 的接口发了 POST |
| 429 Too Many Requests | 请求过于频繁 | 触发限流（如 Sentinel / Nginx 限流） |
5xx 服务端错误（需监控告警！
| 状态码 | 含义 | 常见原因 |
|---|---|---|
| 500 Internal Server Error | 服务器内部错误 | 代码异常（NPE、DB 连接失败等） |
| 502 Bad Gateway | 网关错误 | Nginx 无法连接上游（如 Spring Boot 应用宕机） |
| 503 Service Unavailable | 服务不可用 | 服务过载、维护中、依赖服务不可用 |
| 504 Gateway Timeout | 网关超时 | Nginx 等待后端响应超时 |
HTTP层请求的类型有哪些？
| 方法 | 是否安全 | 是否幂等 | 典型用途 | Java 后端示例 |
|---|---|---|---|---|
| GET | ✅ 安全 | ✅ 幂等 | 获取资源 | @GetMapping("/users/{id}") |
| POST | ❌ | ❌ | 创建资源 / 触发操作 | @PostMapping("/users") |
| PUT | ❌ | ✅ | 全量更新 或创建（指定 ID） | @PutMapping("/users/{id}") |
| PATCH | ❌ | ❌ | 局部更新 | @PatchMapping("/users/{id}") |
| DELETE | ❌ | ✅ | 删除资源 | @DeleteMapping("/users/{id}") |
| HEAD | ✅ | ✅ | 获取响应头（不返回 body） | 检查资源是否存在、最后修改时间 |
| OPTIONS | ✅ | ✅ | 查询服务器支持的 HTTP 方法 | CORS 预检请求（Preflight） |
| TRACE | ✅ | ✅ | 回显请求（用于诊断） | 极少用，常被禁用（安全风险） |
GET和POST的使用场景，有哪些区别？
GET：用于获取/查询资源。 其设计是幂等 且安全的。这意味着多次执行相同的 GET 请求，不会对服务器资源状态产生任何改变（就像查字典），并且应该是安全的（不修改数据）。
POST：用于提交/创建资源。 其设计是非幂等的。这意味着多次执行相同的 POST 请求，可能会在服务器上创建多个资源或产生其他副作用（就像提交订单）。
维度 GET POST 语义 获取资源（只读） 提交数据 / 触发操作（可写） 幂等性 ✅ 幂等 ❌ 非幂等 安全性 ✅ 安全（无副作用） ❌ 不安全（可能修改状态） 参数位置 URL 查询字符串（?key=value） 请求体（Body） 参数长度限制 受浏览器/服务器限制（通常 ≤ 2KB） 理论上无限制（受服务器配置约束） 缓存 ✅ 可被浏览器、代理缓存 ❌ 默认不缓存（除非显式设置） 书签/历史 ✅ 可收藏、后退无风险 ❌ 刷新可能重复提交 编码类型 仅 ASCII（URL 编码） 支持 multipart/form-data、application/json 等
https和http的区别？
HTTP 和 HTTPS 的主要区别在于安全性。HTTP 是明文传输，数据容易被窃取或篡改;而 HTTPS 通过SSL/TLS 加密，确保数据传输的安全性和完整性，HTTPS 还需要数字证书验证服务器身份，防止中间人攻击。另外，HTTPS的默认端口是 443，而 HTTP是 80。越来越多的网站采用 HTTPS 来保护用户隐私和数据安全，各大浏览器也会对 HTTP 网站标记为"不安全"
维度 HTTP HTTPS 协议层 应用层（直接跑在 TCP 上） 应用层 + SSL/TLS 安全层（跑在 TCP 之上） 端口 默认 80 默认 443 数据传输 明文（可被抓包查看） 加密（对称 + 非对称混合加密） 身份认证 无 通过 数字证书 验证服务器身份（防钓鱼） 数据完整性 无法保证（可能被篡改） 通过 MAC / AEAD 保证数据未被篡改 SEO 影响 被 Google 标记为"不安全" Google 优先收录，浏览器显示"🔒 安全" 性能 快（无加密开销） 略慢（首次握手有 RTT 开销，但现代优化已大幅降低）
token，session，cookie、jwt的区别？
名称 定义 Cookie 客户端存储的小型文本数据 ，由服务器通过 Set-Cookie设置，浏览器自动携带。Session 服务端存储的会话状态，通常用内存/Redis保存用户信息，客户端只持有 Session ID（常通过 Cookie 传递）。 Token 广义概念：服务端签发的字符串凭证，用于标识用户身份（JWT 是 Token 的一种实现）。 JWT（JSON Web Token） 一种标准化的 Token 格式（RFC 7519），自包含、可验证、无状态。
维度 Cookie + Session Token（如 JWT） 存储位置 Cookie（客户端） + Session（服务端） 客户端（LocalStorage / Cookie / Memory） 服务端状态 有状态（需存储 Session） 无状态（Token 自包含用户信息） 扩展性 集群需共享 Session（如 Redis） 天然支持水平扩展 安全性 Cookie 可设 HttpOnly+Secure防 XSS；但需防 CSRF无 CSRF 风险；但需防 XSS（若存 LocalStorage） 跨域支持 Cookie 默认不跨域（需 CORS + credentials） Token 可轻松跨域（放在 Header） 生命周期 依赖 Cookie 过期时间或 Session 超时 Token 内置 exp过期时间性能 每次请求需查 Session 存储 无需查库，直接解析 Token 典型场景 传统 Web 应用（如后台管理系统） 前后端分离、移动端、微服务 Cookie 是客户端存储机制，Session 是服务端有状态方案，Token 是认证凭证的统称，而 JWT 是一种自包含、无状态的 Token 实现。在现代 Web 开发中，前后端分离架构普遍采用 JWT，而传统 Web 应用仍广泛使用 Cookie + Session。选择的关键在于：是否需要无状态、是否跨域、是否要求强会话控制。
jwt 令牌原理
jwt 简介 全称:JSON Web Token 定义了一种简洁的、自包含的格式，用于在通信双方以 json 数据格式安全的传输信息。 由于数字签名的存在，这些信息是可靠的。
JWT（JSON Web Token）令牌的原理主要基于 "前端携带签名令牌，后端负责校验，不再存储会话状态" 的机制。
1. JWT 的结构
JWT 一共分为三部分，用
.拼接：
第一部分:Header(头)，记录令牌类型、签名算法等。
例如:{"alg":"HS256","type":"JWT"}
**Payload（负载）**第二部分:Payload(有效载荷)，携带一些自定义信息、默认信息等。例 如:{"id":"1","username":"Tom")
存用户信息，如
userId、role存标准字段，如
exp（过期时间）**Signature（签名）**第三部分:Signature(签名)，防止 Token 被篡改、确保安全性。将 header、payload， 并加入指定秘钥，通过指定签名算法计算而来。
用 Header + Payload + 秘钥 进行签名
保证令牌不被篡改
jwt的无状态指什么？
JWT 的无状态特性是指服务端不需要在服务器本地存储会话信息或状态信息，而是通 过令牌本身来验证用户身份和权限。
JWT 的工作流程（以身份验证为例）
用户登录
客户端发送用户名/密码到服务器。
服务器验证成功后生成 JWT
服务器使用密钥（secret 或私钥）对 header + payload 进行签名，生成完整的 JWT。
返回 JWT 给客户端
通常放在响应体中，或通过
Authorization: Bearer <token>返回。客户端存储 JWT
一般存于 localStorage、sessionStorage 或 Cookie（注意安全策略）。
后续请求携带 JWT
每次请求在 HTTP Header 中带上：
Authorization: Bearer <token>服务器验证 JWT
- 解码头部和载荷（Base64Url 解码）
- 使用相同密钥重新计算签名，与第三段比对
- 检查
exp是否过期等声明- 验证通过则处理请求
JWT 的优缺点
优点：
- 无状态（Stateless）：服务端无需存储会话信息，适合分布式系统。
- 自包含：所有必要信息都在 token 中。
- 跨域支持良好
- 标准化，广泛支持
缺点：
- 无法主动失效：除非设置较短过期时间或引入黑名单机制。
- 体积较大：相比 session ID，JWT 更大。
- 安全性依赖实现：若密钥泄露或使用弱算法，易被伪造。
- 不适合存储敏感数据：Payload 只是编码，不是加密。
什么是WebSocket？
WebSocket 是一种基于 TCP 的全双工通信协议，它允许服务器和客户端之间建立持久连接，实现实时、双向的数据通信。
一句话总结：WebSocket = 客户端和服务端长连接 + 双向通信 + 实时推送
WebSocket 的核心特点
1）全双工通信（Full-Duplex）
客户端和服务器可以 随时相互发送数据，不用轮询。
2）单一 TCP 连接，长连接
建立一次连接后，不需要每条消息都重新建立 HTTP 连接。
3）实时性非常强
适用于消息推送、Chat、Web 实时系统。
4）降低网络和服务器压力
不需要像 HTTP 轮询那样不断发 GET 请求浪费资源。
5）支持跨域
与 HTTP 不同，WebSocket 本身不会被同源策略限制。
什么是 RESTful 风格？
RESTful 是一种基于资源（Resource）和 HTTP 语义的 API 设计风格，使用统一的 URL 和 HTTP 方法来表达对资源的操作。它不是协议，也不是标准，而是一组设计约束和原则
RESTful 的六大核心原则
- 客户端-服务器分离（Client-Server）
- 前后端解耦，各自独立演进。
- 无状态（Stateless）
- 每个请求必须包含处理所需全部信息，服务端不保存会话状态（Session 不符合严格 REST，JWT 更契合）。
- 可缓存（Cacheable）
- 响应需明确标示是否可缓存（如
Cache-Control），提升性能。- 统一接口（Uniform Interface） ← 最关键！
- 资源通过 URI 唯一标识；
- 通过标准 HTTP 方法操作资源；
- 使用标准状态码反馈结果；
- 资源以标准格式（JSON/XML）表示。
- 分层系统（Layered System）
- 客户端无需知道是否直接连最终服务器（可经过网关、代理、负载均衡等）。
- 按需代码（Code on Demand，可选）
- 服务器可临时扩展客户端功能（如返回 JavaScript），但 Web API 中很少用。
JWT 令牌和传统方式有什么区别？
- 无状态性：JWT是无状态的令牌，不需要在服务器端存储会话信息。相反，JWT令牌中包含了所有必要的信息，如用户身份、权限等。这使得JWT在分布式系统中更加适用，可以方便地进行扩展和跨域访问。
- 安全性：JWT使用密钥对令牌进行签名，确保令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析。这种方式比传统的基于会话和Cookie的验证更加安全，有效防止了CSRF（跨站请求伪造）等攻击。
- 跨域支持：JWT令牌可以在不同域之间传递，适用于跨域访问的场景。通过在请求的头部或参数中携带JWT令牌，可以实现无需Cookie的跨域身份验证。
JWT 令牌为什么能解决集群部署，什么是集群部署？
- 在传统的基于会话和Cookie的身份验证方式中，会话信息通常存储在服务器的内存或数据库中。但在集群部署中，不同服务器之间没有共享的会话信息，这会导致用户在不同服务器之间切换时需要重新登录，或者需要引入额外的共享机制（如Redis），增加了复杂性和性能开销。
- 而JWT令牌通过在令牌中包含所有必要的身份验证和会话信息，使得服务器无需存储会话信息，从而解决了集群部署中的身份验证和会话管理问题。当用户进行登录认证后，服务器将生成一个JWT令牌并返回给客户端。客户端在后续的请求中携带该令牌，服务器可以通过对令牌进行验证和解析来获取用户身份和权限信息，而无需访问共享的会话存储。
- 由于JWT令牌是自包含的，服务器可以独立地对令牌进行验证，而不需要依赖其他服务器或共享存储。使得集群中的每个服务器都可以独立处理请求，提高了系统的可伸缩性和容错性。
jwt的缺点是什么？
JWT 一旦派发出去，在失效之前都是有效的，没办法即使撤销JWT。
要解决这个问题的话，得在业务层增加判断逻辑，比如增加**黑名单机制。**使用内存数据库比如 Redis 维护一个黑名单，如果想让某个 JWT 失效的话就直接将这个 JWT 加入到 黑名单 即可。然后，每次使用 JWT 进行请求的话都会先判断这个 JWT 是否存在于黑名单中。
HTTP长连接与WebSocket有什么区别？
| 特性 | HTTP 长轮询 | WebSocket |
| 通信方式 | 客户端发请求，服务端延迟返回（轮询） | 双向全双工，客户端和服务端可主动推送 |
| 连接类型 | 每次请求都是新的 HTTP 连接（短连接） | 单一 TCP 长连接，持续不断 |
| 实时性 | 依赖轮询间隔，延迟高 | 实时性强，服务端可立即推送消息 |
| 网络开销 | 每次请求/响应都携带 HTTP 头，开销大 | 连接建立后数据帧小，开销低 |
| 服务器压力 | 高并发下需维护大量请求阻塞 | 高并发下只维持少量长连接即可 |
适用场景 简单实时通知，消息量低 聊天、实时监控、游戏、行情推送等高实时场景 HTTP 长轮询实现简单、兼容性好，但延迟高、开销大；
WebSocket 实时性高、双向通信、节省资源，但实现复杂，需要管理长连接和安全。选择方案取决于业务需求和场景。
什么是反向代理？
反向代理是一种网络服务器架构，它接受客户端的请求，并将这些请求转发到内部的 多个服务器上。这样做的主要目的是实现负载均衡、提高性能、提高访问速度、增强 安全性和灵活地管理请求流量。（反向代理其代理对象是服务器，而正向代理的对象是 客户端。
反向代理的主要功能
1. 负载均衡：反向代理可以将客户端请求分发到多个内部服务器上，以平衡服务器 的负载。
2. 隐藏内部服务器： 反向代理可以隐藏后端服务器的真实 IP 地址和信息，从而增加 了服务器的安全性。
3. SSL 终端： 反向代理可以用作 SSL 终端，负责处理客户端和服务器之间的加密通信。
反向代理和正向代理的联系与区别？
- 正向代理（Forward Proxy） ：代表客户端 去访问服务器，隐藏客户端身份。
- 反向代理（Reverse Proxy） ：代表服务器 接收客户端请求，隐藏服务器身份
维度 正向代理 反向代理 代理对象 客户端 服务器 谁配置 客户端主动配置（如浏览器设代理） 服务端部署（用户无感知） 目的 访问被限制资源（如翻墙）、匿名访问、缓存加速 负载均衡、安全防护、SSL 终止、动静分离、高可用 对客户端透明性 不透明（需手动设置） 透明（用户以为直接访问目标服务器） 典型工具 Squid、Charles、Fiddler Nginx、Apache、HAProxy、Cloudflare IP 暴露情况 服务器看到的是代理 IP，不知道真实客户端 客户端看到的是代理 IP，不知道后端真实服务器
Nginx位于七层网络结构中的哪一层？
应用层，nginx 是七层负载均衡。
TCP与UDP的区别
1、TCP 面向连接，UDP 是无连接的；
2、TCP 提供可靠的服务，也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；
3、UDP 尽最大努力交付，即不保证可靠交付
4、TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道
5、每一条 TCP 连接只能是点到点的（一对一）；UDP 支持一对一，一对多，多对一和多对多的交互通信
6、TCP 面向字节流（可能出现黏包问题），实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的（不会出现黏包问题）
7、UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
8、TCP 首部开销20字节；UDP 的首部开销小，只有 8 个字节
TCP的可靠性如何保证？
TCP（传输控制协议）之所以被称为"可靠"的传输协议，是因为它通过一系列机制确保数据能够"按序、不丢、不重、无差错"地从发送方传送到接收方。
1、确认和超时重传2、数据合理分片和排序3、流量控制4、拥塞控制5、数据校验
（1）确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
（2）数据校验：检测数据在传输过程中是否发生变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据超时后会重发数据。
（3）数据合理分片和排序：TCP会根据最大传输单元合理分片，以防止在传输过程中进行二次分片。接收方会缓存未按序到达的数据，重新排序后再交给应用层。
（4）流量控制 ：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。
**（5）拥塞控制：**当网络拥塞时，TCP会减少数据的发送，以防止全网中网络负载过重。
讲一下tcp三次握手与四次挥手？
TCP三次握手是为了建立可靠的连接，双方确认彼此的发送 和接收 能力都正常，并同步初始序列号**。两次不安全（无法确认客户端接收能力或服务端发送能力）**
TCP四次挥手是为了全双工连接有序关闭。
为什么不采用"两次握手"建立连接呢？
这主要是为了防止已失效的连接请求报文段突然又传送到服务器而产生错误。
比如客户端向服务器发出TCP连接请求，第一个连接请求报文在网络的某个结点长时间滞留，客户端超时后认为报文丢失，于是再重传一次连接请求，服务器收到后建立连接。
数据传输完毕后双方断开连接。而此时，前一个滞留在网络中的连接请求到达服务器，而服务器会认为客户端又发来连接请求，此时若使用三次握手，则服务器向客户端返回确认报文段，但由于这是一个失效的报文段，所以客户端将不会对服务器发送的确认报文段进行确认，也就不会错误地再次建立连接 。
但若采用的是"两次握手"，则这种情况下服务器认为传输连接已经建立，并一直等待客户端传输数据，而客户端此时并无连接请求，这样就造成了服务器的资源白白浪费。
为何不采用"三次挥手"释放连接
如果客户端已经和服务器建立了TCP连接，当客户端主动断开与服务器的连接时，经过前两次挥手，客户端到服务器端的连接已经释放。
在第三次挥手时，服务器往客户端发送连接释放报文段，如果客户端不进行第四次挥手对该报文进行确认，那么该报文一旦丢失，客户端将一直处于无法关闭状态。因为此时服务器已经关闭连接了，无法再次发送连接释放报文。
为什么四次挥手之后要等2MSL?
原因 1：确保最后一个 ACK 能到达对方
- 在四次挥手的第 4 步，主动关闭方发送了对服务端 FIN 的 ACK；
- 如果这个 ACK 在网络中丢失 ，服务端会重传 FIN（因为它处于
LAST_ACK状态，未收到确认）；- 主动关闭方在
TIME_WAIT期间如果收到重传的 FIN，会重新发送 ACK，确保服务端能正常关闭；- 2MSL 的时间足够让"ACK 丢失 → 对方重传 FIN → 本端重发 ACK"整个过程完成。
若没有
TIME_WAIT，服务端可能永远卡在LAST_ACK，导致连接无法释放（资源泄漏）
服务器ping不通但是http能请求成功，会出现这种情况吗?什么原因造成的?
ping 走的是 icmp 协议，http 走的是 tcp 协议。
有可能服务器的防火墙禁止 icmp 协议，但是 tcp 协议没有禁止，就会出现服务器 ping 不通，但是 http能请求成果。
路由器、交换机、防火墙？
交换机 负责连接网络设备 （如交换机、路由器、防火墙、无线AP等）和终端设备（如计算机、服务器、摄像头、网络打印机等）；
路由器实现局域网与局域网的互联，局域网与Internet的互联；
而防火墙作为一个安全网络设备，作用于内部网络与内部网络之间，或者内部网络与Internet之间。
总的来说，交换机 负责连接设备 ，路由器 负责连接网络 ，防火墙 负责网络访问限制。
TCP拥塞控制的四种算法
拥塞控制是指防止过多的数据注入网络，防止网络中的路由器或链路过载。
（1）慢开始算法
在TCP刚刚连接好并开始发送TCP报文段时，先令拥塞窗口为1,即一个最大报文段的长度。每收到一个对新报文段的确认后，拥塞窗口+1。也就是每经过一个往返时延，拥塞窗口加倍。慢开始一直把拥塞窗口增大到慢开始门限，然后改用拥塞避免算法。
（2）拥塞避免算法
发送端的拥塞窗口每经过一个往返时延就增加1，而不是加倍，使拥塞窗口按线性规律缓慢增长，也就是加法增大。而当出现一次超时时，令慢开始门限等于当前拥塞窗口的一半，并重置拥塞窗口为1，也就是乘法减少。
（3）快重传
当发送方连续收到三个重复的ACK报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时。
（4）快恢复
发送端收到连续三个冗余ACK时，把慢开始门限设置为出现拥塞时发送方拥塞窗口的一半。与慢开始的不同之处是，它把拥塞窗口的值设置为慢开始门限改变后的数值，而不是1，然后开始执行拥塞避免算法使拥塞窗口缓慢地线性增大