深入分析计算机网络传输层和应用层面试题
三、传输层面试题（Transmission Layer）
传输层位于 OSI 七层模型的第四层，它的核心任务是为两个主机之间的应用层提供可靠的数据传输服务。它不仅承担了数据的端到端传输，而且还实现了诸如差错检测、数据流控制、拥塞控制等机制，是网络面试中非常关键的一层。
1. TCP 和 UDP 的区别详解及应用场景分析
概述：TCP 和 UDP 是传输层的两种协议，各有优缺点，使用场景不同。
| 特性 | TCP（Transmission Control Protocol） | UDP（User Datagram Protocol） |
|---|---|---|
| 是否连接 | 是，面向连接（需要三次握手建立连接） | 否，无连接 |
| 可靠性 | 可靠，确保数据无差错、无重复、按序到达 | 不可靠，可能出现丢包、乱序、重复 |
| 流控制和拥塞控制 | 有滑动窗口机制，进行流量控制和拥塞控制 | 无此机制 |
| 传输效率 | 较低，但保证可靠性 | 高效，但不保证可靠性 |
| 开销 | 较大，需要维护连接状态、确认机制等 | 小，无连接状态，报文头较短 |
| 应用场景 | 适合对可靠性要求高的应用，如网页浏览、文件传输、电子邮件 | 适合对实时性要求高但可容忍丢包的应用，如视频通话、直播、在线游戏 |
总结：
如果应用需要精确的数据传输、数据完整性，选择 TCP。
如果更看重时效性，且可以接受部分数据丢失，比如音视频通信，选择 UDP。
2. TCP 三次握手（Three-Way Handshake）详解
过程描述：
第一次握手：客户端发送 SYN 报文，表示请求建立连接，并发送初始序列号（seq=x）。
第二次握手：服务器收到 SYN 报文后，回复一个 SYN-ACK 报文，表示接受连接请求，发送自己的初始序列号（seq=y），并确认客户端的序列号（ack=x+1）。
第三次握手：客户端收到 SYN-ACK 报文后，发送 ACK 报文，确认服务器的序列号（ack=y+1），此时连接建立完成。
重点问题解析：
为什么需要三次握手？
防止失效的连接请求报文造成错误连接。
需要双方都确认收发能力正常。
图示：
客户端 服务器| ———— SYN ————> || <—— SYN+ACK —— || ———— ACK ————> |
连接建立完成3. TCP 四次挥手（Four-Way Handshake）详解
过程描述：
客户端发送 FIN 报文，请求关闭连接。
服务器接收后回复 ACK，表示收到关闭请求。
服务器处理完数据后，发送 FIN 报文，表示可以关闭连接。
客户端收到后发送 ACK 报文，进入 TIME_WAIT 状态。
重点：
TCP 是全双工协议，必须双方都关闭连接。
为什么需要 TIME_WAIT：确保最后 ACK 能到达服务器，防止老数据污染新连接。
4. TCP 状态变迁及 TIME_WAIT 深入解析
TCP 在连接和断开过程中，会经历多种状态，包括：
LISTEN
SYN_SENT
SYN_RECEIVED
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
CLOSE_WAIT
CLOSING
LAST_ACK
TIME_WAIT
CLOSED
重点分析 TIME_WAIT：
等待两倍最大报文寿命（MSL）时间，确保服务端已收到 ACK。
防止旧连接报文影响新连接。
如何优化 TIME_WAIT 过多问题？
操作系统调优（如
tcp_tw_reuse）。使用短连接或连接池。
5. TCP 的可靠性机制详解
1. 序列号与确认号（SEQ/ACK）
每个 TCP 报文都有 SEQ（数据序号）与 ACK（确认号）。
确保报文按顺序传输。
2. 重传机制：
超时重传（Timeout Retransmission）
快速重传（Fast Retransmit）：连续收到三个相同 ACK 时立即重传
3. 滑动窗口机制（Sliding Window）
控制发送速率，实现流量控制。
接收方窗口通知发送方可接收的数据量。
4. 拥塞控制机制：
慢启动（Slow Start）
拥塞避免（Congestion Avoidance）
快速重传（Fast Retransmit）
快速恢复（Fast Recovery）
6. TCP 粘包与拆包问题及解决方法
出现原因：
粘包：多条小数据连续发送，接收方一次性接收。
拆包：一条大数据被拆分成多段接收。
解决方式：
固定长度分隔
特殊分隔符（如 \n）
报文头部添加长度字段（常用）
四、应用层面试题（Application Layer）
应用层是 OSI 模型的第七层，直接为用户提供服务。常见的协议如 HTTP、DNS、SMTP、FTP、DHCP 等。面试中考查频率极高，尤其是 HTTP 协议相关内容。
1. HTTP 和 HTTPS 的区别（深入详解）
| 特性 | HTTP | HTTPS |
| 安全性 | 明文传输，容易被窃听或篡改 | 使用 TLS/SSL 加密传输，确保数据安全 |
| 数据完整性 | 无保障 | 使用数字签名与证书校验数据完整性 |
| 端口 | 默认端口 80 | 默认端口 443 |
| 握手开销 | 无需额外握手 | 需 TLS 握手（增加延迟） |
| 数字证书 | 不需要 | 需要 CA 签发的数字证书 |
TLS 握手过程简述：
客户端发起请求，包含支持的加密算法等信息；
服务端返回证书和公钥；
客户端验证证书有效性，生成对称密钥并用公钥加密；
服务端用私钥解密对称密钥，之后使用该密钥进行加密通信。
2. HTTP1.0、HTTP1.1、HTTP2.0、HTTP3.0 对比
| 特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |
| 连接 | 短连接 | 默认长连接 | 单连接多路复用 | 基于 UDP 的 QUIC 协议 |
| 请求数 | 一次请求一次连接 | 持久连接 | 多个请求复用连接 | 同上，更快恢复丢包 |
| 压缩 | 无 | 无 | 头部压缩 | 更高效 |
| 服务器推送 | 不支持 | 不支持 | 支持 | 支持 |
3. HTTP 状态码分类与详解
1xx：信息性（如 100 Continue）
2xx：成功（如 200 OK, 204 No Content）
3xx：重定向（如 301 Moved Permanently, 302 Found）
4xx：客户端错误（如 400 Bad Request, 403 Forbidden, 404 Not Found）
5xx：服务器错误（如 500 Internal Server Error, 502 Bad Gateway）
面试技巧： 掌握常见状态码的语义与使用场景。
4. Cookie、Session、Token 与 JWT 区别
| 特性 | Cookie | Session | Token（如 JWT） |
| 存储位置 | 客户端 | 服务端 | 客户端（本地存储） |
| 安全性 | 易被窃取伪造 | 相对安全 | 安全，签名校验 |
| 状态性 | 有状态 | 有状态 | 无状态 |
| 适用场景 | 浏览器本地记住信息 | 服务端保持用户会话 | 前后端分离、移动端认证 |
JWT 结构： Header.Payload.Signature
Header：声明类型和算法
Payload：用户信息、权限等
Signature：对前两者进行签名，防篡改
5. DNS 的解析过程详解
浏览器缓存：是否解析过该域名？
系统缓存（如 /etc/hosts 文件）
本地 DNS 服务器
根域名服务器
顶级域服务器（如 .com、.cn）
权威域名服务器（提供最终 IP）
最终解析出 IP 地址返回给客户端，客户端发起请求。
面试加分点：
DNS 轮询负载均衡（RR）
DNS 缓存机制
CDN 与 DNS 的结合优化访问路径
本文为计算机网络面试题进阶总结，涵盖传输层与应用层的高频知识点及深入解析。适合面试前系统复习，帮助应对实际面试中可能出现的综合性网络问题。