探秘TCP/IP：传输层TCP与UDP

2601_95407915

550人浏览 · 2026-03-18 20:40:16

2601_95407915 · 2026-03-18 20:40:16 发布

1.传输层是什么?

传输层是OSI七层模型与TCP/IP四层模型中的核心层，位于网络层之上、应用层之下，是唯一负责端到端（End-to-End）数据传输控制的层级。

2.不同的传输层协议

1.UDP(轻量，简单，不可靠的无链接服务)

UDP在分端前加入8字节的头部，包含端口，长度，校验和。因为头部简短，所以处理速度更快，延迟更低。

但UDP没有相关保险机制，报文发出后有可能因为中转离线，接收端缓冲区溢出等原因导致报文丢失，即丢包。UDP管发出不管送达。

虽然原生的UDP不支持很多功能，但是可以通过传输层自定义扩展头来按需实现一些扩展功能，如报文重组，流量监控。

2.TCP(臃肿，复杂，但可靠的链接服务)

不同与UDP，TCP的头部包含了序列号，确认号，窗口大小等字段，并且在正式的文件传输开始与结束的前后还有“三次握手”，“四次挥手”的连接确认过程。在这样的连接下，TCP可以确保对方收到，且内容完整，顺序正确。

1.三次握手

第一次握手：客户端发送SYN（同步序列号）并转入SYN-SEND（同步已发送，数据等待）状态

第二次握手：服务端收到SYN后向客户端发送SYN+ACK（确认号）并进入SYN-RCVD(同步已接收，数据等待)状态

第三次握手：服务端收到SYN+ACK后向服务端发送ACK并进入ESTABLISHED(连接建立)状态。服务端收到ACK后也进入ESTABLISHED状态。此时连接正式建立

2.三次握手的必要性（以两次为例）

避免已失效的请求报文引起错误

若在第一次握手时，SYN因为某些原因发生了滞留，没有及时发送到服务端，而这时客户端重新发送了新的SYN并被服务端接收。在两次握手的情况下，服务端进入ESTABLISHED状态并发送SYN+ACK到客户端，客户端在收到后也进入ESTABLISHED状态，这里产生了一个连接。但如果这是滞留的SYN恢复并传输到了服务端就会导致服务端产生新的连接。客户端认为时一个连接，而服务端认为时两个连接，状态不一致。

3.四次挥手

前提：TCP连接是全双工的，数据传输结束后，通信双方都可以发起连接释放请求，挥手过程中客户端和服务端的状态会同步变化

第一次挥手：主动关闭方（通常是客户端）完成数据发送后，向被动关闭方（通常是服务端）发送FIN（终止序列号）报文，请求释放连接，同时主动关闭方进入 FIN-WAIT-1（终止等待1）状态，停止发送数据，但仍可以接收数据。

第二次挥手被动关闭方收到FIN报文后，向主动关闭方返回ACK（确认号），确认序列号为收到的FIN序号+1，此时被动关闭方进入 CLOSE-WAIT（关闭等待）状态。主动关闭方收到这个ACK后，进入 FIN-WAIT-2（终止等待2）状态，等待被动关闭方发送连接释放报文。 ✅ 注意：此时从主动关闭方到被动关闭方的单向连接已经释放，但被动关闭方可能还有未发送完的数据，因此还可以继续向主动关闭方传输数据，这个阶段是半关闭状态。

第三次挥手被动关闭方完成所有数据发送后，向主动关闭方发送FIN+ACK报文，请求释放反向的连接，此时被动关闭方进入LAST-ACK（最后确认）状态，等待主动关闭方的最终确认。

第四次挥手主动关闭方收到FIN+ACK报文后，向被动关闭方返回ACK报文，此时主动关闭方进入TIME-WAIT（时间等待）状态，需要等待2MSL（最长报文寿命，通常为2分钟）后才会进入CLOSED状态。被动关闭方收到这个ACK后，直接进入CLOSED状态，连接正式完全释放。

4.四次挥手的必要性（以三次挥手为例）

核心原因是适配TCP全双工传输的特性，避免数据丢失和状态不一致。如果简化为三次挥手，相当于把第二次和第三次挥手合并，被动关闭方收到FIN后直接返回FIN+ACK：此时如果被动关闭方还有未发送完成的剩余数据，直接发送FIN+ACK会导致这些未完成的数据无法正常传输，主动关闭方会直接释放连接，造成数据丢失。举个实际场景：客户端向服务端请求下载一个大文件，客户端发完请求后主动发起FIN（第一次挥手），如果此时直接三次挥手，服务端还没把文件传输完就被迫关闭连接，会导致文件下载不完整。四次挥手的半关闭阶段就是为了让被动关闭方有足够的时间把剩余数据全部传输完成，再发起反向的连接释放，保证双向数据都能完整传输。