一、引言
在网络工程、系统架构等技术岗位的面试中，TCP/IP网络模型常常是面试官关注的重点之一。作为网络通信的基础框架，TCP/IP模型不仅是理解网络协议的根基，更是网络架构、性能优化、安全性等诸多领域的核心。在这一篇文章中，我们将深入探讨TCP/IP网络模型的各个层级，分析面试中常见的相关问题及其解答，帮助你全面理解并掌握这一知识点，提升你的面试竞争力。
无论你是网络工程师、系统管理员，还是准备进入技术领域的新人，TCP/IP模型都是不可忽视的基础知识。本文不仅涵盖了TCP/IP的基本概念，还将对面试中频繁出现的问题进行详细解读，让你在实际面试中游刃有余。让我们从头开始，带你走进TCP/IP模型的世界，解锁成功面试的密码。
二、TCP协议与UDP协议
2.1、TCP协议与UDP协议分别是如何工作的？
TCP协议与UDP协议都工作在传输层，他们的目标都是在程序之间传输数据，这里的数据可以是文本文件、音频、图片，对TCP协议与UDP协议来说都是一堆二进制数据，几乎无任何差别。虽然它们的作用相似，但在工作原理、特性和使用场景上存在显著差异。
2.2、TCP协议与UDP协议的区别？
从连接方式来看，TCP协议是面向连接的，在数据传输前必须先建立连接（通过"三次握手"），确保双方可以可靠地通信。而UDP协议是无连接的，数据直接发送，不需要建立连接，发送方和接收方之间没有正式的连接过程；从可靠性来看，TCP协议提供可靠的数据传输确保数据按顺序到达接收方，如果数据丢失或损坏，TCP会自动重传。而UDP协议，不保证可靠性，数据可能丢失、重复或乱序到达接收方。接收方需要自己处理这些问题（如果有需要的话）。从顺序保证来看，TCP协议，保证数据按发送顺序到达接收方，数据包会重新排序，确保顺序一致。而UDP协议，不保证数据包的顺序，接收方收到的数据可能乱序。这是TCP协议与UDP协议最主要的三个区别，面试被问到区别，尽量往这三个反面回答。
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（需要建立连接） | 无连接（无需建立连接） |
| 可靠性 | 保证可靠传输（通过重传、确认机制等） | 不保证可靠传输，数据丢失或乱序可能发生 |
| 顺序保证 | 保证数据按顺序到达 | 不保证顺序，可能乱序 |
| 流量控制 | 支持流量控制（滑动窗口） | 不支持流量控制 |
| 拥塞控制 | 支持拥塞控制（慢启动、拥塞避免等） | 不支持拥塞控制 |
| 错误检测与修复 | 自动重传丢失的数据，确保完整性 | 仅提供简单的错误检测，无修复 |
| 开销 | 较大（建立连接、确认机制等） | 较小（无连接管理，数据直接发送） |
| 传输速度 | 较慢（有较多的控制和管理开销） | 较快（没有连接和控制的开销） |
三、HTTP/HTTP协议
3.1、HTTP/HTTPS协议原理
HTTP（Hypertext Transfer Protocol）是无状态的、无连接的协议，通常用于Web浏览器与服务器之间的通信。它用于请求和响应数据（例如网页、图片、视频等），并且没有持续连接，每次请求都会重新建立连接。而HTTPS（Hypertext Transfer Protocol Secure）是HTTP的安全版本，它通过在HTTP协议上添加SSL/TLS协议来实现数据加密和验证，确保数据的安全性和完整性。
3.2、HTTP和HTTPS的区别
HTTP和HTTPS的主要区别在于是否加密通信内容，HTTPS相较于HTTP通过SSL/TLS协议提供了加密和安全性。因为HTTP是明文传输，采用HTTP协议传输数据会带来三个风险：被窃听、被篡改、被冒充。那HTTPS如何解决这些问题？加密放偷看、校验防篡改、证书防冒充。理论上来讲HTTPS的性能相较于HTTP会慢一些（多一次握手），但在QUIC的加持下，在现代网络中几乎可以忽略不计。HTTP端口号默认80，HTTPS端口号默认443。现代浏览器基本上都给HTTP标红不安全，搜索引擎优先收录HTTPS。
| 特性 | HTTP | HTTPS |
|---|---|---|
| 连接方式 | 无连接，每次请求都需要建立新的TCP连接 | 通过SSL/TLS协议在建立连接时进行加密 |
| 安全性 | 不加密，数据明文传输，容易被窃听和篡改 | 加密传输，数据在传输过程中无法被窃听或篡改 |
| 端口 | 默认使用端口80 | 默认使用端口443 |
| 性能 | 更快，因为没有加密过程 | 相对较慢，因加密和解密过程增加了开销 |
| 证书 | 无需证书 | 需要SSL/TLS证书，由受信任的证书颁发机构（CA）签发 |
| 适用场景 | 用于不敏感数据传输，如普通网页浏览 | 用于需要保密和身份验证的场景，如网上银行、电子商务等 |
四、DNS协议工作原理
DNS协议又称域名解析协议，是互联网的一个基本服务，它的作用是将人们容易记住的域名转化为对应的IP地址，就像电话簿一样。
4.1、DNS查询流程
1、用户发起请求：
由用户向浏览器发起一个域名请求，如：https://baidu.com，操作系统会通过本地DNS解析器来查询是否缓存了该域名的IP地址。
2、检查本地缓存：
操作系统会首先检查本地缓存是否已经存储了该域名的IP地址。若缓存中有对应记录，那么直接返回这个IP地址，浏览器可以通过它来建立连接。
3、递归查询（现代网络结构最常用的方式）：
如果本地缓存中无对应记录，操作系统会向本地DNS域名服务器发起DNS查询请求。
4、DNS递归解析：
如果本地DNS服务器也没有该域名的解析记录，它将充当递归查询者，通过一系列的查询请求向多个上级DNS服务器发起查询，直到获得最终的IP地址。
4.2、DNS查询方式
DNS查询分为递归查询和迭代查询，而递归查询由于其查询次数少速度快的优势，在现代网络结构中更为常用。
| 方式 | 查询次数 | 是否缓存友好 | 实际使用占比 | 速度 | 负载分布能力 | 备注 |
|---|---|---|---|---|---|---|
| 递归查询 | 少 | ★★★★★ | ★★★★★ | 最快 | 一般 | 99%+ 的日常上网用这个 |
| 迭代查询 | 多 | ★★☆☆☆ | ★☆☆☆☆ | 较慢 | ★★★★★ | 递归解析器之间、权威服务器之间用 |
五、TCP协议的三次握手与四次挥手
TCP/IP协议是有连接的可靠传输协议，因此在进行数据传输之前需要进行建立连接，而这个过程就称之为三次握手。四次挥手是TCP协议中用于连接终止的一种过程。它确保了通信双方都能确认连接已经彻底关闭，避免数据丢失或重复传输
5.1、三次握手流程
首先由客户端发送建立连接请求，即第一次握手。客户端发送 SYN 报文（SYN=1, seq=x），进入 SYN_SENT 状态。表示"我想和你建立连接，我的起始序号seq=x"；服务端收到客户端发送的SYN报文，紧接着回复SYN+ACK报文（SYN=1,ACK=1,seq=y,seq_ack=x+1)，进入SYN_RCVD状态。表示"我收到你的请求，我的起始序号seq=y，我期望下一次收到起始序号为x+1的数据包"；最后客户端收到服务端的SYN+ACK报文，确认服务端能够确认和接受，然后客户端发送客户端发送 ACK 报文（ACK=1, ack=y+1），进入 ESTABLISHED 状态。 在服务端收到后也会进入ESTABLISHED状态。表示"我确认了你的序列号，期望下一个序列号是y+1"。
5.2、四次挥手流程
第一次挥手由客户端向服务端发送一个FIN数据包，表示客户端请求关闭连接。客户端进入 FIN_WAIT_1 状态，等待服务器的确认。第二次挥手在服务端收到客户端发送的FIN包后，发送一个ACK数据包，确认收到了客户端的关闭连接请求，服务器进入 CLOSE_WAIT 状态，等待应用程序关闭连接（在这个时间段内服务端仍然可以向客户端发送数据）。第三次挥手在服务器准备好关闭连接时，发送一个FIN数据包，表示服务端也没有数据发送了，请求关闭连接。服务器进入LAST_ACK状态。第四次挥手在客户端收到服务端的FIN数据包后，发送一个ACK数据包，确认服务器关闭请求。客户端进入 TIME_WAIT 状态，等待2倍MSL（最大报文生存时间），以确保服务器收到最后的ACK确认。然后，客户端关闭连接，进入 CLOSED 状态。
面试常问问题：为什么是三次握手，不能是二次握手或四次握手呢？
事实上，三次握手的设计已经是最小化开销的同时保证可靠连接建立的完美平衡。之所以不能是二次握手，是因为客户端虽然知道服务端能够接受但并不知道其接收能力。极端情况：假如有一个过时的旧SYN包延迟到达服务端，服务器会认为这是一个新的连接请求，直接回 SYN+ACK 并进入半连接状态。如果只有两次，这会导致服务端资源浪费，甚至连接错误。之所以不能是四次握手，是因为三次握手已经满足所有需求，再加上一个毫无意义的握手时纯冗余。反而增加了网络往返延迟以及宽带处理开销。
六、TCP流量控制与拥塞控制机制及流程
6.1、流量控制机制
TCP流量控制机制是TCP可靠传输的核心机制之一，目的是防止发送方发送数据过快，导致接收方缓冲区溢出而丢包。而TCP流量控制的核心机制为滑动窗口机制。
接收窗口（rwnd）：接收方根据自己的缓冲区剩余空间，在每个 ACK 报文中通过 Window 字段（16位） 通告给发送方："我还能接收多少字节"。
发送窗口：发送方所维护的发送窗口大小=min{拥塞窗口 cwnd，接收窗口 rwnd}，发送方只能在窗口内发送数据。
初始时假设rwnd=4000B，序列号从1开始，在建立连接后接收方在 SYN+ACK 或第一个 ACK 中通告 rwnd，然后发送根据当前窗口大小连续的发送多个段，接收方收到数据放入缓冲区，处理一部分，接收方发送 ACK，同时更新 Window 字段，发送方收到ACK后移动窗口，并更新窗口大小。重复此过程，知道连接关闭。
6.2、拥塞控制机制
TCP拥塞控制机制TCP 可靠传输的另一核心机制，目的是防止发送方发送数据过快，导致网络中间设备（如路由器）拥塞而大量丢包。其核心原理为基于窗口的加性增加乘性减少（AIMD）
经典算法（慢开始算法）包括四个阶段：
| 阶段 | 触发条件 | cwnd 变化规则 | 目的 |
|---|---|---|---|
| 慢启动（Slow Start） | 连接刚建立 或 超时重传后 | 从 1 MSS 开始，每收到一个 ACK，cwnd += 1 MSS（指数增长：1→2→4→8...） | 快速探测网络可用带宽 |
| 拥塞避免（Congestion Avoidance） | cwnd ≥ ssthresh | 每收到一个完整 RTT 的 ACK，cwnd += 1 MSS（线性增长） | 缓慢探测，避免突然拥塞 |
| 快重传（Fast Retransmit） | 收到 3 个重复 ACK（表示单个包丢失） | 立即重传丢失段（不等超时） | 快速恢复丢失包 |
| 快恢复（Fast Recovery） | 快重传后 | ssthresh = cwnd / 2 cwnd = ssthresh + 3 MSS 每收到一个重复 ACK，cwnd += 1 MSS 收到新数据 ACK 后，cwnd = ssthresh（进入拥塞避免） | 保守降低速率，继续发送新数据 |
面试常见问题汇总：
1、描述一次HTTP请求的完整过程 (包含DNS)？
- URL解析：解析协议/域名/路径/端口，查缓存和hosts。
- DNS解析：本地无缓存 → 递归问本地DNS → 迭代根→TLD→权威，得IP。
- TCP连接：三次握手（SYN → SYN+ACK → ACK）。
- TLS握手（HTTPS）：ClientHello → ServerHello → 密钥交换（1-RTT）。
- 发送请求：构造并发送HTTP报文（支持多路复用）。
- 服务器处理：负载均衡 → 业务 → 返回响应。
- 浏览器处理：收响应 → 处理状态码 → 渲染HTML + 加载资源。
- 连接管理：keep-alive复用或四次挥手关闭。
2、GET和POST请求的区别？
| 方面 | GET | POST |
|---|---|---|
| 目的 | 获取资源（查询、读取） | 提交数据（创建、更新） |
| 幂等性 | 幂等（多次请求结果相同，无副作用） | 非幂等（多次可能产生不同结果） |
| 安全性 | 安全（不修改服务器状态） | 非安全（可能修改服务器状态） |
| 参数位置 | 参数放在 URL 查询字符串中（?key=value） | 参数放在请求体（Body）中 |
| 参数长度 | 有长度限制（浏览器/服务器限制，通常2KB） | 无理论长度限制（适合大数据） |
| 缓存 | 可被浏览器/代理缓存 | 不可缓存 |
| 书签/历史 | 参数可见，可书签、可分享 | 参数不可见，不可书签 |
| 数据类型 | 只支持 ASCII 字符 | 支持二进制（如文件上传） |
| 适用场景 | 搜索、页面跳转、分页查询 | 登录、表单提交、文件上传 |
在面试时可以挑几个重要反面去回答。
3、HTTPS如何保证安全？
- 身份验证：服务端证书（CA签发），客户端验证防伪造/中间人。
- 保密性：非对称密钥交换（ECDHE）生成会话密钥，对称加密（AES）传输数据。
- 完整性：MAC/AEAD 校验，防篡改。
4、DNS解析中递归查询和迭代查询的区别？
| 方面 | 递归查询（Recursive Query） | 迭代查询（Iterative Query） |
|---|---|---|
| 定义 | 查询方只发一次查询，解析器负责完整解析过程 | 查询方逐步迭代问不同服务器，自己追逐答案 |
| 过程 | 解析器问根 → TLD → 权威，直到得到最终IP，返回给查询方 | 问根得TLD指针 → 问TLD得权威指针 → 问权威得IP |
| 负担方 | 递归解析器（负担重，跑断腿） | 查询方自己（负担重） |
| 实际使用 | 客户端/主机 → 本地DNS服务器（递归解析器） | 本地DNS服务器 → 根/TLD/权威服务器 |
| 响应类型 | 直接返回最终答案（或NXDOMAIN） | 返回最佳已知信息（通常是引用/指针） |
| 优缺点 | 查询方简单、快；解析器负载高、可能缓存少 | 解析器负载低、分布式；查询方查询次数多 |
5、 TCP的流量控制和拥塞控制有什么区别？
| 项目 | 拥塞控制（Congestion Control） | 流量控制（Flow Control） |
|---|---|---|
| 目的 | 防止网络中间路由器拥塞 | 防止接收方缓冲区溢出 |
| 主导方 | 发送方（维护 cwnd） | 接收方（通告 rwnd） |
| 依据 | 网络反馈（丢包、重复 ACK） | 接收缓冲区剩余空间 |
| 窗口调整 | AIMD（加性增加、乘性减少） | 接收方动态通告 |
| 实际发送窗口 | min(cwnd, rwnd) | 同上，但 rwnd 主导 |
7、为什么DNS通常使用UDP？
DNS 默认使用 UDP 端口 53，主要原因：
- 速度快、无连接开销：UDP 无需三次握手，直接发送，适合 DNS 的"短查询-快速响应"模式
- 头部开销小：UDP 头部仅 8 字节，效率高。
- 高并发支持：DNS 服务器每天处理海量查询，UDP 轻量、无状态，更易扩展。
- 简单可靠：大多数查询小而简单，偶尔的丢包可通过重试解决（客户端通常超时重发）。