计算机网络面试题

一、 HTTP 请求方法深度对比

1. GET vs POST

• 幂等性：GET 是幂等的（多次执行结果相同），POST 是非幂等的（多次执行会创建多个资源）
• 安全性：GET 参数暴露在 URL 中，会被浏览器历史记录保留；POST 数据在 Body 中，相对更私密
• 缓存：GET 默认可缓存；POST 除非特别设置，否则不缓存

2. POST vs PUT

• POST：侧重于“新建”，向服务器发送数据以创建新资源
• PUT：侧重于“更新”，通过发送完整数据来修改现有资源。PUT 也是幂等的

二、 HTTP 协议版本

三、HTTP 与 HTTPS 之间区别

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

1. 解析URL：首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径
2. 缓存判断：浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求
3. DNS解析：下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向各级域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户
4. 获取MAC地址：当浏览器得到 IP 地址后，通过 ARP 协议来询问目标 IP 的 MAC
5. TCP三次握手：首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态
6. HTTPS握手：如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程
7. 返回数据：当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程
8. 页面渲染：浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树（Render Tree ）。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制
9. TCP四次挥手：若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，当前服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（60s 最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态

五、HTTP 缓存策略

1. 强缓存 (不发请求)

• Cache-Control:max-age=3600(HTTP/1.1 推荐，相对时间)
• Expires: 绝对时间 (HTTP/1.0，受限于本地时间)

2. 协商缓存 (发请求询问)

• Etag / If-None-Match: 基于内容 Hash，最精确
• Last-Modified / If-Modified-Since: 基于最后修改时间，秒级精度

六、HTTP 报文结构

HTTP 报文是前后端交互的载体。无论是请求还是响应，它们都遵循相似的四段式结构

1. HTTP 请求报文 (Request)

• 请求行：告诉服务器“干什么、去哪干、按什么规矩干”（如POST /login HTTP/1.1）
• 请求头：补充信息。如Host（目标域名）、User-Agent（什么浏览器）、Cookie（身份凭证）
• 空行：法定的分隔符，告诉服务器“头结束了，下面是正文”
• 请求体：具体的负载数据（如登录时的用户名密码）

2. HTTP 响应报文 (Response)

• 状态行：告诉客户端“结果如何”（如HTTP/1.1 200 OK）
• 响应头：服务器信息。如Content-Type（数据类型）、Set-Cookie（种下凭证）
• 空行：分隔符
• 响应体：服务器回传的实际内容（HTML、图片、JSON 等）

七、 URL 的解构

URL（统一资源定位符）就像是一个坐标，指引浏览器找到互联网上的特定资源

以http://www.example.com:80/news/index.html?id=10#top为例：

1. 协议(http://)：通信的语言
2. 域名(www.example.com)：服务器的名字
3. 端口(:80)：服务器的“房号”。HTTP 默认 80，HTTPS 默认 443
4. 路径(/news/index.html)：资源在服务器上的物理或逻辑位置
5. 查询参数(?id=10)：传递给服务器的额外指令
6. 锚点(#top)：页面内的“书签”，不会发送给服务器，仅由浏览器跳转位置

八、HTTP 协议的优缺点

优点

• 简单灵活：报文清晰易懂，且能传输任何类型的数据（图片、视频、文本）
• 无连接：处理完即断开，节省服务器维持连接的资源（注：HTTP/1.1 后通过Keep-Alive优化）
• 无状态：服务器不记得你是谁，处理速度快，适合大规模并发

缺点

• 无状态（双刃剑）：需要借助 Cookie/Session 才能实现登录状态保持
• 明文传输：数据在网络中“裸奔”，极易被窃听（Wireshark 抓包可见）
• 不安全：不验证对方身份（可能连到伪造网站），不验证内容完整性（数据可能被篡改）

九、OSI 七层模型

1. 应用层 (Application)：直接为用户提供网络服务（HTTP, FTP, SMTP, DNS）

2. 表示层 (Presentation)：负责数据格式化、加密解密、压缩解压（如 Base64 编解码、JSON 转化）

3. 会话层 (Session)：负责建立、管理和终止应用程序间的会话连接

4. 传输层 (Transport)：解决数据怎么发的问题（TCP 可靠传输、UDP 尽力而为），关注的是端口

5. 网络层 (Network)：负责 IP 寻址和路由选择，决定数据包走哪条路

6. 数据链路层 (Data Link)：将比特流封装成帧，通过MAC 地址在物理媒介上进行差错检测

7. 物理层 (Physical)：传输 0 和 1 的电信号，涉及网线、光纤、集线器等硬件

十、TCP/IP五层协议

1. 应用层：整合了 OSI 的上三层（应用、表示、会话）
2. 传输层：核心协议是TCP（面向连接，稳）和UDP（无连接，快）
3. 网络层：核心协议是IP
4. 数据链路层：主要负责物理寻址（ARP 协议在此工作）
5. 物理层：最底层的物理介质

十一、TCP 与 UDP

1. UDP (User Datagram Protocol) —— 用户数据报协议

1. 特点解析

• 无连接：像寄平信，不需要预先建立连接，想发就发
• 面向报文：不拆分、不合并，保留应用层交下来的报文边界。应用层给多大，UDP 就发多大
• 不可靠但实时：没有确认机制，没有重传。即使网络拥塞，它也按恒定速率发送。这使得它在视频会议、在线游戏等对延迟敏感的场景中表现卓越
• 开销极小：头部仅8 字节，包含源端口、目的端口、长度和校验和

2. TCP (Transmission Control Protocol) —— 传输控制协议

1. 特点解析

• 面向连接：发送数据前必须进行“三次握手”，确保双方都准备好了
• 可靠传输：
  • 序列号与确认应答 (ACK)：给每个包编号，收到后回传确认
  • 超时重传：没收到确认就重发
• 流量控制与拥塞控制：通过“滑动窗口”调整发送速度，防止把网络或接收方“压垮”
• 面向字节流：数据像水流一样传输，没有明确的边界
• 全双工：双方可以同时收发数据

3. 深度对比：TCP vs UDP

4. 应用场景的选择

1. 什么时候选 TCP？

• 对数据准确性要求 100% 的场景
• 例如：浏览器网页 (HTTP/HTTPS)、文件传输 (FTP)、邮件 (SMTP)、远程登录 (SSH)。在这些场景中，丢一个字节都可能导致文件损坏或登录失败

2. 什么时候选 UDP？

• 对实时性要求高，能容忍少量丢包的场景
• 例如：视频直播/会议（卡一下能接受，重发旧帧没意义）、语音通话、在线竞技游戏（位置同步需要极低延迟）、DNS 查询（请sh求小，UDP 更快）

十二、 三次握手与四次挥手

1. 三次握手：同步与确认

三次握手是为了解决“网络延迟导致旧连接重连”和“同步初始化序列号（ISN）”的问题

流程拆解

1. 第一次握手 (SYN=1, seq=x)：客户端发送连接请求。意义：证明客户端有发送能力
2. 第二次握手 (SYN=1, ACK=1, seq=y, ack=x+1)：服务端收到并同意连接，发回确认。意义：证明服务端有接收能力和发送能力
3. 第三次握手 (ACK=1, seq=x+1, ack=y+1)：客户端再次确认。意义：证明客户端有接收能力，且双方序列号已同步

为什么两次不行？

• 防止失效的连接请求突然传送到服务端：如你所说，网络拥堵可能导致旧的请求在连接释放后才到达。如果没有第三次握手，服务端一发回确认连接就建立了，会导致服务端一直等待一个早已不存在的客户端，白白浪费资源

2. 四次挥手

TCP 是全双工的，这意味着客户端和服务器都能同时收发数据。断开时，每一方都要单独关闭自己的发送通道

流程拆解

1. 第一次挥手 (FIN=1, seq=u)：客户端告诉服务端：“我没数据要发了。”（客户端进入FIN_WAIT1）
2. 第二次挥手 (ACK=1, ack=u+1, seq=v)：服务端回复：“收到，但我可能还有数据没发完，你等我一下。”（此时处于半关闭状态，服务端进入CLOSE_WAIT）
3. 第三次挥手 (FIN=1, ACK=1, ack=u+1, seq=w)：服务端发完了，告诉客户端：“好了，我也可以关了。”（服务端进入LAST_ACK）
4. 第四次挥手 (ACK=1, ack=w+1, seq=u+1)：客户端回复：“收到，拜拜。”（客户端进入TIME_WAIT）

为什么需要四次？

• 异步性：当服务端收到 FIN 时，它可能还有数据在缓冲区没发完。它只能先回一个 ACK 告知已收到，等自己处理完了再发 FIN

十三、WebSocket

1. 深度理解 WebSocket

WebSocket是一种在单个 TCP 连接上进行全双工通信的协议

WebSocket原理：

​ 客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件

核心优势

• 双向性：服务器可以主动“推”，客户端可以主动“发”
• 轻量化：连接建立后，数据包头部非常小（通常只有几个字节），远小于 HTTP 报头
• 低延迟：不需要频繁建立和断开连接

2. 即时通讯方案比较

3. WebSocket 实战代码片段

客户端 (浏览器端)

constsocket=newWebSocket('ws://chat.example.com');// 连接成功socket.onopen=()=>socket.send('Hello Server!');// 接收消息socket.onmessage=(event)=>console.log('收到：',event.data);// 关闭连接socket.onclose=()=>console.log('连接已关闭');