计算机网络知识体系

---

一、 计算机网络体系结构

1. OSI 七层模型

• 应用层：最靠近用户的层，负责处理特定的应用程序细节。这一层提供了网络服务与用户应用软件之间的接口。例如，Web 浏览器、FTP 客户端和服务器、电子邮件客户端等。
• 表示层：确保从一个系统发送的信息可以被另一个系统的应用层读取。它负责数据的转换、压缩和加密。例如，确保数据从一种编码格式转换为另一种（如 ASCII 到 EBCDIC）。
• 会话层：管理用户的会话，控制网络上两节点间的对话和数据交换的管理。它负责建立、维护和终止会话。例如，建立一个会话令牌，以便在网络上的两个节点之间传递。
• 传输层：提供端到端的通信服务，保证数据的完整性和正确顺序。这一层包括 TCP 和 UDP 等协议。
• 网络层：负责在多个网络之间进行数据传输，确保数据能够在复杂的网络结构中找到从源到目的地的最佳路径。这层使用的是 IP（Internet Protocol）协议。
• 数据链路层：在物理连接中提供可靠的传输，负责建立和维护两个相邻节点间的链路。包括帧同步、MAC（媒体访问控制）。
• 物理层：负责在物理媒介上实现原始的数据传输，比如电缆、光纤和无线信号传输。涉及的内容包括电压、接口、针脚、电缆的规格和传输速率等。

2. TCP/IP 四层模型

• 应用层：包括所有和网络有关的高级协议，如 HTTP、FTP、SMTP。
• 传输层：负责端到端数据传输服务，包括数据分割、流量控制和错误恢复（TCP、UDP 协议）。
• 网际层：主要协议 IP，负责数据包的寻址和路由。
• 网络接口层：负责数据帧的物理传输，包括硬件地址寻址（MAC）、数据封装和解封装，以及错误检测和纠正。

3. 五层结构

• 应用层：网络服务和最终用户之间的接口，提供一系列供应用程序使用的协议，如 HTTP、FTP 等，使用户的应用程序可以访问网络服务。
• 传输层：提供进程到进程的通信管理，确保数据按顺序、无错误地传输（TCP 和 UDP）。
• 网络层：负责数据包从源到目的地的传输和路由选择，包括跨越多个网络，使用逻辑地址来表示唯一设备。
• 数据链路层：确保从一个节点到另一个节点可靠、有效的数据传输。
• 物理层：物理传输介质，如电缆、光纤、网络适配器等。

---

二、 网络综合

1. 浏览器地址栏输入 URL 到显示主页过程

1. DNS 解析：浏览器发起一个 DNS 请求到 DNS 服务器，将域名解析为服务器的 IP 地址。
2. TCP 连接：浏览器通过解析得到的 IP 地址与服务器建立 TCP 连接（通常是通过 443 端口进行 SSL 加密的 HTTPS 连接）。这一步涉及到 TCP 的三次握手过程，确保双方都准备好进行数据传输。
3. 发送 HTTP 请求：浏览器构建 HTTP 请求消息，包括请求行（如 GET / HTTP/1.1）、请求头（包含用户代理、接受的内容类型等信息）和请求体（如果有），将请求发送到服务器。
4. 服务器处理请求：服务器接收到 HTTP 请求后，根据请求的资源路径，经过后端处理（可能包括数据库查询等），生成 HTTP 响应消息。响应消息包括状态行（如 HTTP/1.1 200 OK）、响应头（内容类型、缓存控制等信息）和响应体（请求的资源内容）。
5. 浏览器接收 HTTP 响应：浏览器接收到服务器返回的 HTTP 响应数据，开始解析响应体中的 HTML 内容；然后构建 DOM 树、解析 CSS 和 JavaScript 文件等，最终渲染页面。
6. 断开连接：进行 TCP 四次挥手，连接结束。

2. DNS 解析过程

1. 浏览器检查缓存中是否有域名对应的 IP 地址，有就直接返回。
2. 检查本地 DNS 缓存是否有该域名的记录，没有就向根域名服务器发送请求。
3. 根域名服务器将请求指向更具体的服务，返回顶级域名服务器地址。
4. 顶级域名服务器再将请求指向权限域名服务器，返回对应的 IP 地址。
5. 浏览器使用获得的 IP 地址发起 HTTP 请求到目标服务器。

---

三、 TCP 协议

1. 三次握手

• 第一次握手（SYN）：
  • 过程：客户端发送一个 TCP 报文段到服务器。报头中 $\text{SYN} = 1$，客户端随机选择初始序列号 $x$（$\text{seq} = x$）。
  • 目的：客户端通知服务器希望建立连接，并告知初始序列号。
  • 状态：客户端进入 SYN_SENT 状态；服务器初始处于 LISTEN 状态。
• 第二次握手（SYN + ACK）：
  • 过程：服务器收到请求后，若同意建立连接，回复应答报文。$\text{SYN} = 1, \text{ACK} = 1$，随机生成服务器初始序列号 $y$（$\text{seq} = y$），且确认号 $\text{ack} = x + 1$。
  • 目的：服务器同意建立连接，并告知客户端自己的初始序列号。
  • 状态：服务器进入 SYN_RCVD 状态。
• 第三次握手（ACK）：
  • 过程：客户端收到应答后发送最终确认。$\text{ACK} = 1$，确认号 $\text{ack} = y + 1$，序列号 $\text{seq} = x + 1$。
  • 目的：客户端确认收到服务器的同步应答，完成握手。
  • 状态：客户端与服务器均进入 ESTABLISHED 状态。

为什么不是两次或四次握手？

• 两次的缺陷：若服务端回复的 SYN+ACK 丢失，服务端无法得知客户端是否收到，会导致持续等待；此外，若有已失效的连接请求报文段延迟到达服务端，两次握手会让服务端错误地建立不再需要的连接。
• 无需四次：三次握手已经能确保双方双向通信能力的可靠建立，无需再多一次握手。

2. 四次挥手

通信双方均可主动断开连接，假设客户端主动发起：

1. 第一次挥手：客户端发送释放连接报文（$\text{FIN} = 1, \text{seq} = u$），进入 FIN_WAIT_1 状态。
2. 第二次挥手：服务端收到后发送确认报文（$\text{ACK} = 1, \text{ack} = u + 1, \text{seq} = v$），进入 CLOSE_WAIT 状态。客户端收到后进入 FIN_WAIT_2 状态。
3. 第三次挥手：服务端处理完数据后，发送释放连接报文（$\text{FIN} = 1, \text{ACK} = 1, \text{seq} = w, \text{ack} = u + 1$），进入 LAST_ACK 状态。
4. 第四次挥手：客户端收到关闭请求后发送确认（$\text{ACK} = 1, \text{seq} = u + 1, \text{ack} = w + 1$），进入 TIME_WAIT 状态。经过 $2\text{MSL}$（两个最大报文段生命周期）后进入 CLOSED 状态。服务端收到 ACK 后立即进入 CLOSED 状态。

常见问题探讨：

• 为什么挥手需要四次？
  • 客户端发送 FIN 仅代表客户端不再发送数据，但仍能接收数据。服务端收到 FIN 时，先回应 ACK 表示收到；但服务端可能还有未处理完的数据，等服务端数据发送完毕后，才单独发送 FIN 报文表示同意关闭。因此 ACK 与 FIN 分两步发送，共需四次。
• 为什么需要等待 $2\text{MSL}$ 才进入 CLOSED 状态？
  1. 保证可靠关闭：防止最后一个 ACK 丢失导致服务端处于 LAST_ACK 状态而不断超时重传 FIN+ACK。$2\text{MSL}$ 保证了重传和响应的时间。
  2. 清除失效报文：使本连接时间内产生的所有报文段都从网络中消失，避免后续新连接收到旧的无效报文。

3. TCP 如何保证可靠性

• 连接管理：通过三次握手与四次挥手保证可靠建立与释放连接。
• 校验和：保持首部和数据的端到端校验和，若接收端发现校验和有错，直接丢发并不发确认。
• 序列号与确认应答：每个数据包均编号，接收方应答包号；发送方根据应答判断是否重发。
• 流量控制：根据接收方缓冲区大小控制发送速率（滑动窗口机制）。
• 最大消息长度（MSS）：建立连接时约定 MSS 作为发送和重传的最小单位。
• 超时重传：设定超时计时器，若超过规定时间未获确认则触发重传。
• 拥塞控制：引入慢启动等机制，根据网络拥堵状况动态调整传输速度。

4. TCP 流量控制

• 原理：基于可变大小的滑动窗口协议，让发送端根据接收端的实际接收能力控制发送数据量。
• 零窗口处理：当接收窗口为 0 时，发送方暂停发送，并开启定时探针任务（Zero Window Probe），定期询问接收方是否已有可用窗口。

5. TCP 拥塞控制

• 拥塞窗口（$\text{cwnd}$）：发送方维护的动态变量，随网络拥堵程度变化。
• 发送窗口公式：$\text{swnd} = \min(\text{cwnd}, \text{rwnd})$（发送窗口取拥塞窗口与接收窗口的最小值）。
• 变化规则：网络无拥塞则增大 $\text{cwnd}$，发生拥塞则减小 $\text{cwnd}$。

常用算法：

1. 慢启动（Slow Start）：
   • 刚建立连接时，先探测网络。每收到一个 ACK，$\text{cwnd} = \text{cwnd} + 1$（单位 MSS），每轮次按指数增长。
   • 当 $\text{cwnd} > \text{ssthresh}$（慢启动阈值，初始通常为 65535 字节）时，转入拥塞避免阶段。
2. 拥塞避免（Congestion Avoidance）：
   • 每收到一个 ACK 时，$\text{cwnd} = \text{cwnd} + \frac{1}{\text{cwnd}}$；每经过一个往返时间 RTT，$\text{cwnd} = \text{cwnd} + 1$。按线性上升，避免网络快速拥塞。
3. 拥塞发生（Congestion Occurrence）：
   • RTO 超时重传：$\text{ssthresh} = \frac{\text{cwnd}}{2}$，$\text{cwnd}$ 重置为 1，重新进入慢启动。
   • 快速重传：收到 3 个连续重复的 ACK 时触发。$\text{cwnd} = \frac{\text{cwnd}}{2}$，$\text{ssthresh} = \text{cwnd}$，进入快速恢复阶段。
4. 快速恢复（Fast Recovery）：
   • $\text{cwnd} = \text{ssthresh} + 3$；
   • 重传丢失的数据包；
   • 若再收到重复 ACK，则 $\text{cwnd} = \text{cwnd} + 1$；
   • 若收到新数据的 ACK，恢复 $\text{cwnd} = \text{ssthresh}$，重新进入拥塞避免算法。

6. TCP 重传机制

• 超时重传：发送数据后开启计时器，若超时（RTO 略大于 RTT）未收到 ACK 则重传。
• 快速重传：当连续收到 3 个重复 ACK 时，在定时器到期前直接重传丢失的报文段。
• 带选择确认的重传（SACK）：在 TCP 首部加入 SACK 选项，告知发送方已接收的不连续数据块范围（例如仅丢失 200~299），发送方只针对性重传丢失部分。
• 重复 SACK（DSACK）：利用 SACK 告知发送方哪些数据包被重复接收，帮助判断是否发生了包失序、ACK 丢失或伪重传。

---

四、 UDP 协议

1. TCP 与 UDP 的区别

特性	TCP	UDP
连接性	面向连接	无连接
可靠性	可靠传输（无差错、不丢失）	不可靠传输（尽力而为）
传输形式	字节流	报文 / 数据段
传输效率	较慢	快
首部开销	20 ~ 60 字节	仅 8 字节
应用场景	文件传输、邮件（FTP, SMTP, HTTP）	即时通讯、音视频通话

2. UDP 如何保证消息不丢失

虽然 UDP 本身不可靠，但可以通过应用层补足：

• 应用层确认与重传：接收方收到后发确认帧，发送方超时未收到则重传。
• 包序列号（Sequence Number）：消息附带唯一序列号，用于防重和判丢。
• 数据持久化：本地/服务端数据库保存消息，异常时拉取恢复。

---

五、 IP 协议与 ARP 协议

1. IP 协议作用

• 寻址与路由：根据源/目的 IP 地址，在复杂网络中经路由器寻找最佳路径进行转发。
• 分段与重组：根据不同网络链路的 MTU 限制，对数据包实施切片分段，到达目标主机后再行组装。

2. ARP 协议工作过程

1. ARP 请求：主机 A 查询本地 ARP 缓存。若无目标 IP 的 MAC 地址，则在局域网内广播发送 ARP 请求包。
2. ARP 应答：网络内所有主机收到广播，仅目标主机 B 匹配 IP，并以单播形式回复自己的 MAC 地址，同时缓存主机 A 的 IP-MAC 映射。
3. 更新 ARP 缓存：主机 A 收到应答后，将主机 B 的映射写入本地 ARP 缓存表。

---

六、 HTTP / HTTPS 协议

1. GET 与 POST 的区别

• 报文层面：GET 参数附在 URL 上，数据量受限且敏感信息易暴露；POST 参数放在请求体（Body）中，大小无限制，相对安全。
• 数据库/语义层面：GET 具有幂等性和安全性（仅读取）；POST 不具备幂等性（用于增改操作）。
• 缓存与书签：GET 响应可被浏览器缓存、保留历史记录或存为书签；POST 不行。

2. HTTP 报文结构

【请求报文】              【响应报文】
请求行 (Method/URL/Ver)   状态行 (Ver/Status/Reason)
请求头部 (Headers)        响应头部 (Headers)
空行                      空行
消息正文 (Body, 可选)      消息正文 (Body, 可选)

3. HTTPS 工作流程

1. 客户端请求：建立 TCP 连接后发起 HTTPS 请求。
2. 服务器响应证书：返回数字证书（含服务器公钥及 CA 信息）。
3. 验证证书与生成对称密钥：客户端校验证书合法性，若合法则生成一个随机对称密钥，并用服务器公钥加密后发送。
4. 服务器解密：服务器用私钥解密得到对称密钥。
5. 对称加密通信：后续通信全由该对称密钥加密传输；连接关闭后密钥销毁。

4. Cookie 与 Session

• Session：服务器端记录客户状态的机制。客户端再次访问时查找对应 Session。
• Cookie：客户端保存的小文本数据，请求时自动携带发送给服务端。

Cookie 与 Session 的区别：

1. 存储位置：Cookie 在客户端；Session 在服务端。
2. 数据类型：Cookie 仅支持 ASCII 字符串；Session 可存储任意数据类型。
3. 有效期：Cookie 可长期有效（如“记住密码”）；Session 随会话结束或超时失效。
4. 安全性：Cookie 易被截获；Session 存储于服务器，安全性更高。
5. 存储容量：单 Cookie 上限约 $4\text{KB}$；Session 容量远高于 Cookie。

5. HTTP 状态码

• 1XX 提示信息：协议处理的中间状态。
• 2XX 成功：
  • 200 OK：一切正常，包含 Body。
  • 204 No Content：成功处理但无 Body 数据。
  • 206 Partial Content：应用于分块下载或断点续传。
• 3XX 重定向：
  • 301 Moved Permanently：永久重定向。
  • 302 Found：临时重定向。
  • 304 Not Modified：资源未修改，指示客户端继续使用缓存。
• 4XX 客户端错误：
  • 400 Bad Request：通用客户端请求语法错误。
  • 403 Forbidden：服务器拒绝访问该资源。
  • 404 Not Found：请求资源不存在。
• 5XX 服务器错误：
  • 500 Internal Server Error：通用服务器内部错误。
  • 501 Not Implemented：服务器不支持该请求功能。
  • 502 Bad Gateway：网关/代理服务器访问上游节点失败。
  • 503 Service Unavailable：服务器忙或正在维护。