📌 本文由 5 篇相关文章智能合并整理而成

TCP 和 UDP 区别：面向连接 vs 无连接，可靠 vs 不可靠

TCP 和 UDP 区别：面向连接 vs 无连接，可靠 vs 不可靠

一、定义

TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）是传输层最核心的两个协议。TCP 提供面向连接的可靠传输服务，UDP 提供无连接的不可靠传输服务。两者各有适用场景。

二、核心区别对比

三、TCP 特点详解

1. 可靠性机制

sequenceDiagram
    participant S as 发送方
    participant R as 接收方

    S->>R: 发送数据包 1
    R->>S: ACK 确认
    S->>R: 发送数据包 2
    Note over S: 启动定时器
    Note over R: 数据包2丢失
    Note over S: 超时未收到 ACK
    S->>R: 重传数据包 2
    R->>S: ACK 确认

可靠性机制：
– 确认应答（ACK）：接收方收到数据后回复确认
– 超时重传：发送方启动定时器，超时未收到 ACK 则重传
– 快速重传：收到三个重复 ACK，立即重传（不等超时）

2. 流量控制（滑动窗口）

接收方通告窗口大小（rwnd），告知发送方能接收多少数据，防止接收方缓冲区溢出。

3. 拥塞控制

• 慢启动：指数增长，触发阈值后改为线性增长
• 拥塞避免：线性增长，丢包后窗口减半
• 快重传：三个重复 ACK 立即重传
• 快恢复：丢包后不回到慢启动

四、UDP 特点详解

1. 无连接

发送数据前不需要建立连接，减少握手延迟。

2. 报文结构

0                16                31
├────────────────┬────────────────┤
│     源端口      │     目的端口     │
├────────────────┼────────────────┤
│     报文长度     │     校验和      │
├────────────────┴────────────────┤
│           数据载荷                │
│              ...                │
└─────────────────────────────────┘

UDP 首部仅 8 字节（TCP 首部至少 20 字节）。

五、TCP 与 UDP 应用场景

TCP 适合的场景

UDP 适合的场景

选择指南

flowchart TD
    A{传输层协议选择} --> B{需要可靠传输?}
    B -->|是| C{对延迟敏感?}
    B -->|否| D[UDP]
    C -->|是,但能容忍少量丢包| E[UDP+应用层可靠机制]
    C -->|否,必须完整准确| F[TCP]
    C -->|既可靠又需要低延迟| G[QUIC (UDP-based)]

六、特殊场景：QUIC

QUIC（Quick UDP Internet Connections）是基于 UDP 的传输协议，HTTP/3 的底层协议：

七、面试常见问题

Q1：TCP 和 UDP 分别适合什么场景？
A：TCP 适合对数据完整性要求高的场景（网页、文件、邮件）。UDP 适合对实时性要求高、能容忍少量丢包的场景（音视频通话、游戏、DNS）。

Q2：为什么视频通话和直播大多数用 UDP？
A：视频通话对延迟敏感。TCP 重传在网络不稳定时导致延迟增加。UDP 允许少量丢包（丢帧），配合编解码器的错误隐藏，用户体验更好。

Q3：UDP 可以保证可靠传输吗？
A：UDP 本身不可靠，但可在应用层实现（添加序列号、ACK、重传）。QUIC、KCP 等都是基于 UDP 实现可靠传输的协议。

Q4：TCP 的拥塞控制有哪些算法？
A：经典算法：Tahoe、Reno、CUBIC（Linux 默认）、BBR（基于带宽和延迟模型）。CUBIC 在高带宽高延迟网络中表现优秀，BBR 在丢包非拥塞的网络中效果更好。

相关文章：TCP 三次握手流程详解 | TCP 四次挥手流程详解 | HTTP 和 HTTPS 区别 | HTTP 状态码

TCP 四次挥手流程详解：TIME_WAIT 状态与 CLOSE_WAIT 问题分析

TCP 四次挥手流程详解：TIME_WAIT 状态与 CLOSE_WAIT 问题分析

一、定义

四次挥手（Four-Way Wavehand）是 TCP 断开连接时的流程。由于 TCP 是全双工通信，每一方的连接关闭都需要单独确认，因此需要四次交互来完成。

二、四次挥手流程

sequenceDiagram
    participant C as 主动关闭方 (Client)
    participant S as 被动关闭方 (Server)

    Note over C: ESTABLISHED
    Note over S: ESTABLISHED

    C->>S: 1. FIN=1, seq=u
    Note over C: FIN_WAIT_1
    Note over S: CLOSE_WAIT

    S->>C: 2. ACK=1, seq=v, ack=u+1
    Note over C: FIN_WAIT_2

    Note over S: 数据处理中...

    S->>C: 3. FIN=1, ACK=1, seq=w, ack=u+1
    Note over C: TIME_WAIT
    Note over S: LAST_ACK

    C->>S: 4. ACK=1, seq=u+1, ack=w+1
    Note over S: CLOSED

    Note over C: 等待 2MSL 后
    Note over C: CLOSED

第一步：FIN

主动关闭方发送 FIN 报文：
– 标志位：FIN=1
– 序列号：seq=u
– 主动方：ESTABLISHED → FIN_WAIT_1
– 含义：主动方说”我数据发完了，不再发送数据了”

第二步：ACK

被动关闭方回复 ACK：
– 标志位：ACK=1
– 序列号：seq=v，确认号：ack=u+1
– 主动方：FIN_WAIT_1 → FIN_WAIT_2
– 被动方：ESTABLISHED → CLOSE_WAIT
– 含义：”收到关闭请求，但我还有数据要发”

第三步：FIN

被动关闭方发送 FIN：
– 标志位：FIN=1, ACK=1
– 序列号：seq=w，确认号：ack=u+1
– 主动方：FIN_WAIT_2 → TIME_WAIT
– 被动方：CLOSE_WAIT → LAST_ACK
– 含义：”我的数据处理完了，可以关闭了”

第四步：ACK

主动关闭方发送 ACK 确认：
– 标志位：ACK=1
– 序列号：seq=u+1，确认号：ack=w+1
– 被动方：LAST_ACK → CLOSED
– 主动方等待 2MSL 后：TIME_WAIT → CLOSED

三、关键状态说明

四、为什么是四次挥手，不是三次？

TC 是全双工通信，连接双向的关闭需要独立处理。被动方回复的 ACK 和发送的 FIN 之间，被动方可能还有未发送完的数据，所以不能合并。

如果被动方也没有数据要发送了，可以将步骤 2 和 3 合并，变成三次挥手：

sequenceDiagram
    participant C as 主动关闭方
    participant S as 被动关闭方

    C->>S: FIN
    S->>C: FIN + ACK（合并）
    C->>S: ACK

五、TIME_WAIT 状态详解

为什么需要 TIME_WAIT？

1. 保证最后一个 ACK 到达对方：如果 ACK 丢失，被动方会重发 FIN，TIME_WAIT 状态下能重新回复 ACK
2. 防止旧的报文段干扰新连接：等待 2MSL，确保网络中所有老报文段消失

MSL 含义

• MSL（Maximum Segment Lifetime）：报文最大生存时间，Linux 默认 30 秒
• TIME_WAIT 时长：2 × MSL = 60 秒

大量 TIME_WAIT 问题与解决

# 查看 TIME_WAIT 数量
netstat -an | grep TIME_WAIT | wc -l

# 调整参数
net.ipv4.tcp_tw_reuse = 1       # 复用 TIME_WAIT 连接（客户端场景）
net.ipv4.tcp_fin_timeout = 30   # FIN_WAIT_2 超时

六、四次挥手场景总结

七、面试常见问题

Q1：为什么需要 TIME_WAIT 状态？
A：两个原因：① 保证最后一个 ACK 可靠送达，如果丢失被动方重发 FIN 后还有 TIME_WAIT 能回复 ACK；② 保证旧报文在 2MSL 内失效，防止干扰新连接。

Q2：大量 TIME_WAIT 有什么危害？如何解决？
A：危害：占用端口资源（限制 65K），降低系统吞吐。解决：① 开启 tcp_tw_reuse（客户端场景）；② 调整 MSL；③ HTTP/1.1 keep-alive 减少连接创建；④ 使用连接池。

Q3：大量 CLOSE_WAIT 是什么原因？怎么解决？
A：服务端收到被动关闭，但应用层没有调用 close()。常见于：资源未正确释放、连接池未及时归还。解决：确保每个 socket 都正确关闭、使用 try-with-resources。

Q4：TCP 同时关闭（Simultaneous Close）会怎么样？
A：双方同时发送 FIN，各自进入 FIN_WAIT_1，收到对方的 FIN 后回复 ACK 进入 CLOSING，然后各自进入 TIME_WAIT，最终双方都等待 2MSL 后关闭。

相关文章：TCP 三次握手流程详解 | TCP 和 UDP 区别 | HTTP 和 HTTPS 区别 | HTTP 状态码

TCP 三次握手流程与核心原理：为何是三次而非两次？

TCP 三次握手流程与核心原理：为何是三次而非两次？

一、定义

TCP（Transmission Control Protocol）是面向连接的可靠传输协议。三次握手（Three-Way Handshake）是 TCP 建立连接时，客户端和服务端交换三个报文段以同步序列号、确认传输能力和协商参数的过程。

二、三次握手流程

sequenceDiagram
    participant C as 客户端 (Client)
    participant S as 服务端 (Server)

    Note over C: CLOSED
    Note over S: LISTEN

    C->>S: 1. SYN=1, seq=x
    Note over C: SYN_SENT
    Note over S: SYN_RCVD

    S->>C: 2. SYN=1, ACK=1, seq=y, ack=x+1

    C->>S: 3. ACK=1, seq=x+1, ack=y+1
    Note over C: ESTABLISHED
    Note over S: ESTABLISHED

    Note over C,S: 连接建立完成

第一步：SYN

客户端发送 SYN 报文：
– 标志位：SYN=1, ACK=0
– 序列号：seq=x（随机初始序列号 ISN）
– 客户端状态：CLOSED → SYN_SENT
– 作用：告知服务端”我要建立连接”，同步自己的序列号

第二步：SYN+ACK

服务端回复 SYN+ACK 报文：
– 标志位：SYN=1, ACK=1
– 序列号：seq=y（服务端随机初始序列号）
– 确认号：ack=x+1（确认收到客户端的 SYN）
– 服务端状态：LISTEN → SYN_RCVD
– 作用：告知客户端”收到你的请求，这是我的序列号”

第三步：ACK

客户端发送 ACK 报文：
– 标志位：ACK=1, SYN=0
– 序列号：seq=x+1
– 确认号：ack=y+1（确认收到服务端的 SYN）
– 客户端：SYN_SENT → ESTABLISHED
– 服务端收到后：SYN_RCVD → ESTABLISHED
– 作用：确认收到服务端的响应，连接正式建立

三、为什么是三次握手？两次不行吗？

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    Note over C: 发送 SYN(seq=100)
    C->>S: SYN (seq=100) [网络阻塞]
    Note over C: 超时重传
    C->>S: SYN (seq=300)
    S->>C: SYN+ACK (ack=301)
    C->>S: ACK (seq=301)
    Note over C,S: 正常连接建立

    Note over C: 此时旧 SYN(seq=100) 到达
    C->>S: SYN (seq=100) [旧的]

    S->>S: 如果没有第三次握手<br>服务端会误以为新连接
    S->>C: SYN+ACK (ack=101)
    C->>S: RST (拒绝)
    Note over S: 浪费资源

核心原因：

四、三次握手的核心作用总结

五、SYN Flood 攻击与防御

攻击原理

攻击者大量发送伪造 IP 的 SYN 报文，服务端回复 SYN+ACK 后无法收到客户端的 ACK，导致服务端保持大量半连接（SYN_RCVD），耗尽资源。

防御措施

六、相关参数

# Linux 内核参数
net.ipv4.tcp_syn_retries = 6        # SYN 重试次数
net.ipv4.tcp_synack_retries = 5     # SYN+ACK 重试次数
net.ipv4.tcp_max_syn_backlog = 1024 # 半连接队列大小
net.ipv4.tcp_syncookies = 1         # 启用 SYN Cookie

七、面试常见问题

Q1：为什么 TCP 建立连接要三次握手，而不是两次或四次？
A：两次握手无法防止已失效的连接请求到达服务端，且无法确保服务端知道客户端收到了自己的 SYN。四次握手可以但浪费了一次交互，三次是理论最小值。

Q2：三次握手中可以携带数据吗？
A：前两次（SYN、SYN+ACK）不能携带数据，因为序列号尚未同步。第三次（ACK）可以携带数据，因为双方序列号已同步。

Q3：什么是半连接队列和全连接队列？
A：半连接队列（SYN Queue）：服务端收到 SYN 后的连接队列。全连接队列（Accept Queue）：三次握手完成后的连接队列。

Q4：第三次握手的 ACK 丢失怎么办？
A：服务端收不到 ACK 会保持 SYN_RCVD 状态，超时重发 SYN+ACK。客户端收到 SYN+ACK 后重新回复 ACK。

相关文章：TCP 四次挥手流程详解 | TCP 和 UDP 区别 | HTTP 和 HTTPS 区别 | HTTP 状态码

HTTP 状态码详解：2xx / 3xx / 4xx / 5xx 全系列速查

HTTP 状态码详解：2xx / 3xx / 4xx / 5xx 全系列速查

一、定义

HTTP 状态码（Status Code）是服务器在响应请求时返回的三位数字代码，用于表示请求的处理结果。状态码分为五大类，每类代表不同的响应语义。

二、状态码分类

三、常见状态码详解

2xx 成功

HTTP/1.1 200 OK
Content-Type: application/json
{"id": 1, "name": "Alice"}

HTTP/1.1 201 Created
Location: /api/users/1

HTTP/1.1 204 No Content

3xx 重定向

301 vs 302 对比：

4xx 客户端错误

401 vs 403 区别：
– 401：你不知道你是谁（未登录/token 无效）
– 403：我知道你是谁，但你没有权限

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

HTTP/1.1 403 Forbidden
{"error": "您没有访问此资源的权限"}

HTTP/1.1 429 Too Many Requests
Retry-After: 60
{"error": "请 60 秒后重试"}

5xx 服务端错误

502 vs 504 对比：

四、状态码速记表

五、RESTful API 状态码选择

六、面试常见问题

Q1：301 和 302 的区别？各在什么场景使用？
A：301 永久移动，浏览器缓存重定向（域名迁移、HTTPS 跳转）。302 临时移动，不缓存（登录跳转、A/B 测试）。

Q2：401 和 403 有什么区别？
A：401 未提供有效认证凭证（未登录、token 过期）；403 已认证但无权限（角色不足、IP 被拉黑）。

Q3：502 和 504 有什么区别？
A：502 网关收到无效响应（上游挂了），504 网关等待超时（上游处理太慢）。

Q4：RESTful API 设计中怎么选状态码？
GET 成功 200，POST 成功 201，DELETE 成功 204。参数错误 400，认证失败 401，无权限 403，资源不存在 404，冲突 409，限流 429，服务器异常 500。

相关文章：HTTP 和 HTTPS 区别 | TCP 三次握手 | TCP 四次挥手 | TCP 和 UDP 区别

HTTP 和 HTTPS 区别：SSL/TLS 握手 / 加密原理 / 性能对比

HTTP 和 HTTPS 区别：SSL/TLS 握手 / 加密原理 / 性能对比

一、定义

HTTP（HyperText Transfer Protocol）是超文本传输协议，HTTPS（HyperText Transfer Protocol Secure）是 HTTP 的安全版本，通过在 HTTP 基础上加入 SSL/TLS 加密协议来实现通信安全。

二、核心区别

三、HTTPS 的工作原理

SSL/TLS 握手流程

sequenceDiagram
    participant C as 客户端
    participant S as 服务端

    C->>S: 1. ClientHello (TLS版本, 加密套件列表)
    S->>C: 2. ServerHello (选定加密套件)
    S->>C: 2. Server Certificate (公钥证书)
    S->>C: 2. ServerHelloDone

    C->>C: 3. 验证证书有效性
    C->>C: 3. 生成 pre-master secret
    C->>S: 3. ClientKeyExchange (公钥加密的密钥)
    C->>C: 3. 生成会话密钥
    C->>S: 3. ChangeCipherSpec + Finished

    S->>S: 4. 用私钥解密 pre-master secret
    S->>S: 4. 生成相同会话密钥
    S->>C: 4. ChangeCipherSpec + Finished

    Note over C,S: 5. 加密通信开始（对称加密 AES/ChaCha20）
    C->>S: 加密的 HTTP 请求
    S->>C: 加密的 HTTP 响应

加密方式混合使用

四、HTTP 的三大安全问题

1. 窃听（Eavesdropping）

GET /api/user HTTP/1.1
Cookie: session=abc123      ← 明文，可被中间人截获

2. 篡改（Tampering）

原始请求：转账 100 元 → 攻击者改为：转账 10000 元

3. 冒充（Impersonation）

伪装成银行网站，诱导用户输入密码

五、HTTPS 性能优化

性能开销与优化方案

# Nginx 配置
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_stapling on;

六、HTTP 版本演进

七、面试常见问题

Q1：HTTPS 握手的具体过程是什么？
① 客户端发送 ClientHello（支持的 TLS 版本、加密套件）→ ② 服务端返回 ServerHello、数字证书 → ③ 客户端验证证书，生成 pre-master secret 并用公钥加密发送 → ④ 双方生成会话密钥 → ⑤ 切换为对称加密通信。

Q2：HTTPS 为什么混合使用对称和非对称加密？
非对称加密安全但速度慢（比对称慢 1000 倍以上），适合小量数据加密（如密钥交换）；对称加密速度快但密钥分发困难。两者结合兼顾安全与性能。

Q3：中间人攻击如何攻击 HTTPS？如何防范？
攻击者伪造证书欺骗客户端。防范：使用受信任的 CA 证书、验证证书链、证书锁定（Certificate Pinning）、使用 HSTS 强制 HTTPS。

Q4：HTTPS 和 HTTP/2 有什么关系？
HTTP/2 不要求必须使用 HTTPS，但主流浏览器只对 HTTPS 连接启用 HTTP/2，因此 HTTP/2 几乎等于 HTTPS 的升级。HTTP/2 带来多路复用、服务端推送、头部压缩等优化。

相关文章：HTTP 状态码详解 | TCP 三次握手 | TCP 和 UDP 区别 | 微服务核心组件