TCP 与 UDP：传输层的 “靠谱老大哥” 与 “闪电跑腿员”

一、TCP：面向连接的 “可靠传输专家”

TCP 就像寄重要快递，会打电话确认对方收货，丢了还会重发，全程 “稳” 字当头。

1. 核心特性：

• 面向连接：传输前必须 “三次握手” 建连接，结束后 “四次挥手” 断连接，像打电话 “喂 - 能听到 - 开始说” 和 “挂了啊 - 好的 - 真挂了 - 拜拜”。
• 可靠传输：通过 “序列号 + 确认应答” 保证数据不丢、不乱。比如发送方发 1、2、3 号数据包，接收方收到 1 和 3，会回复 “确认收到 1，等 2”，发送方就重发 2。
• 流量控制：接收方会告诉发送方 “我现在最多能收 1000 字节”，避免发送太快 “撑爆” 对方缓冲区，类似 “你慢点说，我记不过来了”。
• 拥塞控制：如果网络堵车，TCP 会主动减速，等路况好再加速，防止 “添堵”，比如高速上堵车时大家会慢慢开。
• 面向字节流：把数据当成连续的字节序列，没有 “数据包” 边界，接收方会按顺序拼接，适合大文件传输。

2. 三次握手：如何 “安全建连接”？

• 第一次：客户端发 “SYN=1，seq=x”，说 “我想连你”。
• 第二次：服务端回 “SYN=1，ACK=1，seq=y，ack=x+1”，说 “我同意连，你发的 x 我收到了”。
• 第三次：客户端回 “ACK=1，seq=x+1，ack=y+1”，说 “好的，那我们开始传数据吧”。为什么三次？防止 “已失效的连接请求” 突然传到服务端，导致错误建连。比如客户端发的第一个请求堵车了，超时后又发了一个新的，结果旧请求后来到了服务端，如果两次握手，服务端会直接建连，但客户端已经不管旧请求了，浪费资源。三次握手时，客户端会验证服务端的应答，发现是旧请求就拒绝，避免这种情况。

3. 四次挥手：如何 “优雅断连接”？

• 第一次：客户端发 “FIN=1，seq=u”，说 “我数据发完了，想断开”。
• 第二次：服务端回 “ACK=1，ack=u+1”，说 “我知道了，你等我一下，我还有数据没发完”。
• 第三次：服务端发 “FIN=1，ACK=1，seq=v，ack=u+1”，说 “我数据也发完了，现在可以断了”。
• 第四次：客户端回 “ACK=1，seq=u+1，ack=v+1”，说 “收到，断开吧”，然后等 2MSL 确保服务端收到，自己再断。为什么四次？因为服务端收到断开请求时，可能还有数据没发给客户端，所以需要先回复 “知道了”，等数据发完再发 “我也断” 的请求，两次应答拆成了两次包。

4. 适用场景：对 “可靠性” 要求高，不那么急的场景

• 网页浏览、文件下载、邮件收发、在线支付。

二、UDP：无连接的 “高速传输闪电侠”

UDP 就像发微信消息，不管对方在不在，直接发，快但可能丢，主打一个 “效率至上”。

1. 核心特性：

• 无连接：直接发数据，不用建连接，省了握手时间，像喊人 “喂，东西给你放桌上了”，不等对方回应就走。
• 不可靠传输：没有序列号和确认应答，丢包了不重发，顺序乱了也不管，比如发 1、2、3 号包，对方可能收到 3、1，或者只收到 2。
• 面向数据报：每个 UDP 包都是独立的 “数据报”，有明确边界，接收方不会拼接，比如发两个 100 字节的包，对方会收到两个 100 字节，而不是一个 200 字节。
• 开销小：头部只有 8 字节，比 TCP 的 20 字节 + 更轻量，传输速度更快。

2. 头部结构：极简主义

UDP 头部只有 4 个字段，共 8 字节：

• 源端口、目标端口；
• 长度；
• 校验和。

3. 适用场景：对 “实时性” 要求高，偶尔丢包能接受的场景

• 视频通话、语音聊天；
• 在线游戏；
• 直播；
• DNS 查询。

三、TCP vs UDP：怎么选？

一句话总结：重要的数据找 TCP，快的数据找 UDP。