八股文 / 计算机网络速查
计算机网络面试速查题库
本页用于学完后的复习与面试表达。第一次学习请从 计算机网络系统课 开始，先建立分层、路由、可靠传输和应用协议的完整模型。
一、基础概念
1. TCP和UDP的区别
| 维度 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠 | 不可靠 |
| 传输顺序 | 按序到达 | 不保证顺序 |
| 协议开销 | 状态与控制机制更多 | 头部和协议机制更少 |
| 头部开销 | 20字节 | 8字节 |
| 流量控制 | 支持（滑动窗口） | 不支持 |
| 拥塞控制 | 支持 | 不支持 |
| 应用场景 | 网页、邮件、文件传输 | 视频流、游戏、DNS查询 |
主要区别：
- 连接机制 - TCP需完成三次握手/四次挥手；UDP无此过程
- 可靠传输 - TCP通过确认应答、超时重传和校验确保数据完整；UDP无重传机制
- 数据顺序 - TCP通过序列号保证按序重组；UDP可能乱序接收
- 性能特性 - TCP维护连接、可靠性和拥塞控制；UDP机制更少，但实际延迟和吞吐仍取决于网络与应用设计
- 流量和拥塞控制 - TCP支持滑动窗口和拥塞避免算法；UDP均不支持
2. HTTP请求方式
HTTP/1.1定义的8种核心请求方法：
- GET - 获取资源，参数在URL中，安全且幂等
- POST - 提交数据，可能修改服务器状态
- PUT - 全量更新资源，幂等
- DELETE - 删除资源，幂等
- HEAD - 类似GET，仅返回响应头
- OPTIONS - 查询服务器支持的请求方法，用于CORS预检
- TRACE - 回显请求（因安全风险通常禁用）
- CONNECT - 建立代理隧道
PATCH是RFC 5789（2010）后添加的扩展方法，用于局部更新资源。
3. GET请求和POST请求的区别
| 对比角度 | GET | POST |
|---|---|---|
| 用途 | 获取资源 | 提交数据 |
| 常见数据位置 | 参数常放在 URL query | 数据常放在请求体 |
| 数据大小 | 受客户端、代理和服务器 URL 限制 | 受客户端、代理和服务器 body 限制 |
| 传输安全 | 由 HTTPS 等机制决定 | 同样由 HTTPS 等机制决定 |
| 缓存 | 可被缓存 | 通常不被缓存 |
| 幂等性 | 幂等 | 非幂等 |
| 编码类型 | 仅ASCII字符 | 支持多种编码类型 |
两者传输敏感数据都应使用HTTPS。
4. HTTP状态码
| 状态码 | 名称 | 含义 |
|---|---|---|
| 200 | OK | 请求被正确处理 |
| 301 | Moved Permanently | 资源永久重定向 |
| 302 | Found | 资源临时重定向 |
| 304 | Not Modified | 资源未修改，使用缓存 |
| 400 | Bad Request | 请求格式错误 |
| 401 | Unauthorized | 未认证 |
| 403 | Forbidden | 无权限访问 |
| 404 | Not Found | 资源不存在 |
| 500 | Internal Server Error | 服务器内部错误 |
| 503 | Service Unavailable | 服务暂时不可用 |
分类：
- 2xx 成功类
- 3xx 重定向类（301永久重定向浏览器缓存新地址，302临时重定向后续仍访问原URL）
- 4xx 客户端错误类（401缺少凭证，403已认证但权限不足）
- 5xx 服务器错误类
5. HTTP请求头部字段
- 请求字段：Host（目标域名）、User-Agent（客户端信息）、Accept（可接受类型）、Authorization（认证凭证）
- 响应字段：Server（服务器信息）、Set-Cookie、Location（重定向URL）
- 通用字段：Cache-Control（缓存行为）、Connection（连接管理）
- 实体字段：Content-Type（媒体类型）、Content-Length（大小）、Content-Encoding（编码方式）
二、TCP深入
1. TCP三次握手详细流程
第一次握手（SYN）： 客户端生成初始序列号(x)，发送SYN=1的连接请求，进入SYN-SENT状态
第二次握手（SYN-ACK）： 服务器生成序列号(y)，发送SYN=1、ACK=1的确认报文，确认号为x+1，进入SYN-RCVD状态
第三次握手（ACK）： 客户端发送ACK=1，序号x+1，确认号y+1，进入ESTABLISHED状态；服务器接收后也进入ESTABLISHED状态
2. 为什么是三次握手
- 第三次握手的必要性：防止已失效的重复连接请求导致服务器浪费资源
- 两次握手不足：无法区分当前连接是否为延迟的旧请求，可能导致”半开连接”
- 四次握手不必要：三次握手已确保双方收发能力可靠，增加只会增加延迟
3. 四次挥手过程
第一次挥手： 客户端发送FIN=1，序列号u，进入FIN-WAIT-1状态
第二次挥手： 服务器回复ACK=1，确认号u+1，进入CLOSE-WAIT状态；客户端进入FIN-WAIT-2状态
第三次挥手： 服务器发送FIN=1, ACK=1，序列号w，进入LAST-ACK状态
第四次挥手： 客户端发送ACK=1，进入TIME-WAIT状态（等待2MSL后关闭）；服务器进入CLOSED状态
为什么常描述为四次： TCP 两个方向独立关闭。服务器收到 FIN 后必须确认，但可能仍有数据要发送，所以 ACK 和自身 FIN 通常分开；如果已经准备关闭，两者在实际报文中也可能合并。四次描述的是逻辑阶段，不保证抓包一定出现四个独立报文。
4. TIME_WAIT状态的作用
TIME_WAIT是主动关闭方在四次挥手后保持的状态，持续2MSL（Linux默认60秒）。
核心作用：
- 确保最后一个ACK可靠到达，防止被动关闭方重传FIN
- 让旧连接的数据包从网络消失，避免被新连接误接收
为什么是2MSL： 第一个MSL确保最后ACK到达，第二个MSL确保对方重传的FIN能到达。
TIME_WAIT过多的影响： 端口耗尽、内存占用、性能下降。优化参数：tcp_tw_reuse（推荐）、tcp_max_tw_buckets。
5. TCP可靠性保证
TCP通过以下机制确保数据”准确、有序、不丢失、不重复”：
- 序列号 - 为每字节分配序号，保证顺序并检测丢失/重复
- 确认应答(ACK) - 接收方确认已安全接收的数据范围（累积确认）
- 重传机制 - 超时重传和快速重传（3个重复ACK立即重传）
- 校验和 - 检测传输中的比特错误
- 连接管理 - 三次握手建立、四次挥手断开
- 流量控制 - 滑动窗口防止发送方压垮接收方
- 拥塞控制 - 动态调整发送速率，避免网络过载
6. 拥塞控制实现
四种经典算法：
- 慢开始（Slow Start） - 初始cwnd较小（1-10 MSS），指数增长，达到阈值ssthresh后进入拥塞避免
- 拥塞避免 - 线性增长，每个RTT增加1 MSS，谨慎探测网络容量
- 快重传 - 收到3个重复ACK时立即重传，不等待超时
- 快恢复 - 快重传后ssthresh和cwnd设为当前值一半，按拥塞避免规则增长
关键公式： 实际发送窗口 = min(cwnd, rwnd)
现代算法： TCP Reno → NewReno → CUBIC（Linux默认）→ BBR
7. TCP Keepalive与HTTP Keep-Alive的区别
| 特性 | TCP Keepalive | HTTP Keep-Alive |
|---|---|---|
| 协议层 | 传输层(TCP) | 应用层(HTTP) |
| 主要目的 | 检测连接存活性 | 复用TCP连接提高效率 |
| 触发条件 | TCP连接长时间空闲 | HTTP事务完成后 |
| 管理方 | 操作系统内核 | HTTP客户端和服务器 |
| 传输内容 | 空的探测报文 | 实际HTTP请求/响应数据 |
两种机制协同工作：HTTP Keep-Alive依赖底层TCP连接，当连接在HTTP层长时间空闲时，TCP Keepalive检测连接存活性。
三、HTTP进阶
1. HTTP/1.0和HTTP/1.1的区别
| 特性 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|
| 默认连接 | 短连接 | 长连接（标准化） |
| Host头 | 不支持 | 支持（允许单服务器托管多个网站） |
| 分块传输编码 | 不支持 | 支持（适用于实时日志流、大文件下载） |
| 缓存机制 | Expires/Last-Modified | ETag/Cache-Control |
| 队头阻塞 | 无 | 存在 |
| 范围请求 | 不支持 | 支持断点续传 |
2. HTTP/2.0的主要改进
- 多路复用 - 单个TCP连接上并行传输多个请求和响应，解决HTTP/1.1队头阻塞
- 头部压缩 - HPACK算法，静态字典（61个预定义字段）+ 动态字典 + Huffman编码，头部大小减少50%-90%
- 二进制协议 - 固定格式帧结构替代文本协议，解析速度更快
- 流优先级 - 通过权重和依赖关系定义优先级，支持动态调整
- 服务器推送 - 主动推送关联资源，客户端可拒绝冗余推送
3. HTTP多个TCP连接
HTTP/1.1： 浏览器为同一域名建立多个并行TCP连接（默认6-8个），每个连接独立完成三次握手和请求-响应，单个连接内仍存在队头阻塞。
HTTP/2.0： 多路复用在单连接上并行处理多个请求和响应。
HTTP/3.0： 基于QUIC协议（UDP），彻底解决队头阻塞，支持0-RTT快速连接。
四、安全与缓存
1. HTTPS和HTTP的区别
- 安全性：HTTP明文传输，HTTPS通过SSL/TLS加密数据并验证服务器身份
- 端口：HTTP默认80，HTTPS默认443
- 证书：HTTP无需证书，HTTPS要求可信CA签发的数字证书
- 浏览器：HTTP标记”不安全”，HTTPS显示安全标识并提升SEO
HTTPS在HTTP和TCP层之间添加SSL/TLS层。HTTP/3基于QUIC协议，强制集成TLS 1.3。
2. HTTPS工作原理
SSL/TLS握手过程：
- Client Hello - 客户端发送支持的SSL/TLS版本、加密算法套件、随机数
- Server Hello - 服务器选择算法套件并返回信息
- Certificate - 服务器发送数字证书（含公钥、域名、有效期）
- Certificate Verification - 客户端验证证书有效性
- Key Exchange - 客户端生成预主密钥，用公钥加密后发送；服务器用私钥解密
- Session Key Generation - 双方使用随机数和预主密钥生成会话密钥
- Change Cipher Spec - 通知对方切换为加密模式
- Finished - 验证握手成功
混合加密： 非对称加密用于密钥协商（安全但慢），对称加密用于数据传输（快速高效）。
3. 强缓存和协商缓存
强缓存： 浏览器直接使用本地缓存，不向服务器发送请求
- Cache-Control（HTTP/1.1）：相对过期时间，如
max-age=3600 - Expires（HTTP/1.0）：绝对时间格式
协商缓存： 浏览器向服务器发送验证请求
- Last-Modified / If-Modified-Since：基于资源修改时间
- ETag / If-None-Match：基于资源内容的唯一标识符（精度更高）
| 特性 | 强缓存 | 协商缓存 |
|---|---|---|
| 网络请求 | 无 | 有（仅验证） |
| 性能 | 最优 | 较优 |
| 适用场景 | 静态资源 | 动态资源 |
4. Cookie和Session的区别
| 维度 | Cookie | Session |
|---|---|---|
| 存储位置 | 浏览器端 | 服务器端 |
| 安全性 | 较低（用户可篡改） | 较高（服务端控制） |
| 数据类型 | 仅字符串 | 支持复杂对象 |
| 生命周期 | 可长期有效 | 通常随会话结束失效 |
| 性能影响 | 增加请求头大小 | 占用服务器资源 |
服务器创建Session后通过Cookie传递Session ID实现会话维持。现代演进方向：分布式Session使用Redis，JWT等Token方案替代传统服务端Session。
五、综合应用
1. DNS查询过程
采用”递归查询+迭代查询”混合模式：
- 本地缓存检查 - 浏览器缓存 → 操作系统DNS缓存 → hosts文件
- 本地DNS服务器 - 递归查询
- 根域名服务器 - 返回顶级域名服务器地址
- 顶级域名服务器 - 返回权威域名服务器地址
- 权威域名服务器 - 返回最终IP地址
- 结果返回 - 逐级缓存并返回
常见DNS记录类型：A记录（IPv4）、AAAA记录（IPv6）、CNAME记录（域名别名）、MX记录（邮件服务器）。
2. 从输入URL到页面展示
八个关键步骤：
- URL解析 - 提取协议、主机名、端口和路径
- DNS查询 - 将域名转换为IP地址
- TCP连接 - 三次握手建立连接
- TLS握手（HTTPS）- 加密协商
- HTTP请求 - 发送请求行、请求头和请求体
- 服务器处理 - 处理请求并生成响应
- HTTP响应 - 返回状态行、响应头和响应体
- 浏览器渲染 - DOM树构建 → CSSOM树生成 → JavaScript执行 → 渲染树合并 → 布局与绘制
来源：卡码笔记