TCP 和 UDP 有什么区别？
TCP：提供了可靠、面向连接的传输，适用于需要数据完整性和顺序的场景
UDP：提供了更轻量、面向报文的传输，适用于实时性要求高的场景
区别总结：
| 对比项 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手、四次挥手） | 无连接（直接发） |
| 是否可靠 | ✔ 保证可靠、有序、不丢包 | ❌ 不保证 |
| 性能 | 慢（需要确认、重传） | 快（无握手、无重传） |
| 是否有头部 | 20~60 字节 | 8 字节 |
| 适合数据大小 | 大 | 小 |
| 传输方式 | 字节流 | 报文（Datagram） |
| 是否有流量控制 | ✔ 有（滑动窗口） | ❌ 无 |
| 是否有拥塞控制 | ✔ 有 | ❌ 无 |
| 是否可广播 | ❌ 不支持 | ✔ 可广播、多播 |
| 常用场景 | HTTP、FTP、数据库通信 | 视频、直播、游戏、物联网 |
TCP三次握手
三次握手主要是为了确定双方都有接收和发送的能力
简要步骤：
- 客户端：SYN
- 服务端：SYN + ACK
- 客户端：ACK
TCP 三次握手图示：
客户端首先发送一个同步序列号（SYN）消息给服务器，服务端回复一个SYN-ACK消息，最后客户端再发送一个ACK确认消息给服务端，确认已经收到服务端发来的SYN-ACK消息
步骤解释：
- 客户端通过 SYN 控制消息并携带自己期望的初始序列号 SEQ 给服务端
- 服务端收到 SYN 消息之后，通过 ACK 控制消息以及 SEQ + 1 来进行确认并带上自己的 SEQ
- 客户端通过 ACK 控制消息以及服务端的 SEQ + 1 来进行确认，并且还能够在第三方握手通信的时候，直接携带数据进行传输
为什么要三次握手？
主要有两个原因：
- 避免历史错误连接建立，减少双方不必要的资源消耗
- 帮助通信双方同步序列号
为什么三次就能阻止错误连接？
因为网络请求比较复杂，发送方第一次发送请求后，可能由于网络原因被阻塞住了，此时发送方可能又会再次发送请求。
1）如果只有两次握手，那么接收方对于发送方的请求只能接受或者拒绝，同时接收方无法识别发送方发送的这个请求是旧的还是新的请求，如下图所示：
2）如果网络阻塞时间较长，发送方可能多次发送请求，且接收方还可能全部接受这些连接（它不清楚，以为都是有效的），这就造成了不必要的资源浪费。
因此三次握手，多了一次发送方确认接收方接受的连接是否争取的验证过程，所以避免了历史重复连接的错误情况。
帮助通信双方同步序列号
因为网络本身不稳定，可能会导致：
- 数据重复传输
- 数据乱序
- 数据丢失
然而，因为TCP是一个可靠的传输协议，可以保证数据在传输过程不丢失且有序，所以对于上述问题在TCP中引入序列号，使得：
- 接收方可以根据序列号去重
- 接收方可以根据序列号排序
- 发送方针对为接收到 ACK 的序列号对应的数据包，可以重传
序列号是有序的，因此在通信过程中，需要同步序列号，那么如何同步？
中间一步合并的优点在于：接收方告知发送方收到序列号的同时还可以把自己的序列号告知发送方
TCP四次挥手
四次挥手主要目的为了确保数据全部传输完成
简要步骤：
- 客户端：FIN
- 服务端：ACK
- 客户端：FIN
- 服务端：ACK（进入TIME_WAIT）
TCP 四次挥手图解：
- 第一次挥手（FIN -> ACK）：客户端主动关闭连接，发送 FIN 包，进入 FIN_WAIT_1 状态。服务器收到 FIN 后，表示不再接收数据，但仍可能继续发送数据
- 第二次挥手（ACK）：服务器发送 ACK 包，确认已收到 FIN，此时服务器进入 CLOSE_WAIT 状态，客户端进入 FIN_WAIT_2 状态。
- 第三次挥手（FIN -> ACK）：服务器完成所有数据传输后，发送 FIN 包，进入 LAST_ACK 状态。客户端收到 FIN 后，准备关闭连接。
- 第四次挥手（ACK）：客户端发送最后一个 ACK 包，进入 TIME_WAIT 状态，等待可能迟到的 FIN 包，服务器收到 ACK 后，关闭连接，进入 CLOSED 状态。客户端在 TIME_WAIT 计时结束后（2MSL），正式关闭连接。
Client 为什么要进入 TIME_WAIT ?
Client 进入**TIME_WAIT**是为保证所有数据安全接受，防止延迟的FIN包影响新连接的完整性，避免出现混淆问题。
为什么挥手需要四次？
主要是为了确保数据完整性
TCP 是一个全双工协议，也就是说双方都要关闭，每一方都向对方发送 FIN 和回应 ACK。
客户端发起连接断开，代表客户端没数据要发送的，但是服务器可能还有数据没有返回给客户端。
就像我对你说数据发完了，你收到之后回复说好的收到，然后你再对我说你数据发完了，我收到之后也回复你说好的收到。这样才能保证数据不会丢失
如果我说数据发完了，你收到之后说确认收到，但不说数据是否发完了，那我收到确认之后就会离开，而你的还没发完的数据就发不了了，那就会造成数据不完整性
一个FIN+ACK 代表一方的数据发送完了，我们有两个端就需要两个 FIN+ACK，也就是四次通信
挥手可以三次吗？
可以，不一定都是四次，也可以是三次。
主要发生在：
如果 Client 发送 FIN 给 Server 的时候 Server 已经没有数据发送给 Client，那么Server 就可以将 FIN 和 ACK 一起发送给 Client 了，那么四次挥手就可以变成三次挥手。
The end......
