当前位置：首页 > news >正文

（面试）TCP、UDP协议

news 来源：原创 2025/8/7 14:23:45

TCP（传输控制协议）和UDP（用户数据报协议）是互联网核心的传输层协议，负责应用程序之间的数据传输。它们在设计目标、特性和适用场景上有显著差异：

TCP：面向连接，可靠的，速度慢、效率低，适用于需要传输可靠的数据时使用。
UDP：无连接，不可靠，速度快、效率高，适用于高效传输忽略可靠性时使用

1. TCP（Transmission Control Protocol）

特点：
- 面向连接：通信前需通过“三次握手”建立连接，结束后通过“四次挥手”断开连接。
- 可靠传输：通过确认应答（ACK）、超时重传、数据排序等机制确保数据不丢失、不重复、按序到达。
- 流量控制：通过滑动窗口机制动态调整发送速率，避免接收方缓冲区溢出。
- 拥塞控制：通过慢启动、拥塞避免等算法减少网络拥塞。
- 全双工通信：支持双向数据流。
头部开销：较大（通常20字节，可扩展至60字节），包含序列号、确认号、控制标志等字段。
适用场景：需要高可靠性的应用，如网页浏览（HTTP/HTTPS）、文件传输（FTP）、电子邮件（SMTP）等。

2. UDP（User Datagram Protocol）

特点：
- 无连接：无需建立连接，直接发送数据包。
- 不可靠传输：不保证数据到达、不保证顺序，无重传机制。
- 轻量高效：头部仅8字节（含源/目标端口、长度、校验和），无复杂控制机制。
- 支持广播/多播：可向多个目标同时发送数据。
- 低延迟：无需等待确认或重传，适合实时应用。
适用场景：对实时性要求高、可容忍少量丢失的应用，如视频会议（Zoom）、在线游戏、DNS查询、VoIP（如Skype）、物联网传感器数据等。

TCP三次握手与四次挥手全指南

三次握手确保客户端与服务器收发能力正常，四次挥手处理双向连接释放。

图中字符详解：
SYN：代表连接请求或接收的报文段。
seq：指发送的第一个字节的序号。
ACK：确认报文段，用于回应SYN。
ack：确认号，表示希望收到的下一个数据的第一个字节的序号。

在TCP协议中，主动发起连接请求的一方被称为客户端，而被动等待连接的一方则被称为服务端。无论是客户端还是服务端，一旦TCP连接成功建立，双方均可进行数据的发送与接收。

连接建立之初，服务器和客户端都处于CLOSED状态。在通信正式开始前，双方需要分别创建自己的传输控制块（TCB）。服务器完成TCB创建后，会进入LISTEN状态，随时准备接收客户端发来的连接请求。
1、第一次握手：
客户端向服务端发送一个SYN报文（SYN=1），并指明客户端的初始化序列号ISN(x)，即图中的seq=x，它表示本报文段所发送的数据的第一个字节的序号。在发送SYN报文后，客户端进入SYN_SENT状态，意味着它正在等待服务端的连接确认。

SYN_SENT状态解释：当客户端发送连接请求后，它进入SYN_SENT状态，等待服务端的响应。在这个状态下，客户端准备好了接受服务端的连接确认。

TCP协议规定：SYN=1的报文段是用于建立连接的请求，它不携带任何数据，但会消耗一个序号。这是TCP协议确保连接建立过程中的有序性和可靠性的一种方式。
2、第二次握手：
服务器在接收到客户端的SYN报文后，会以SYN报文作为回应（SYN=1），并赋予自己独特的初始化序列号ISN(y)，即图中的seq=y。同时，服务器将客户端的ISN+1设置为确认号ack的值，以此确认已收到客户端的SYN报文，并期待接收到的下一个数据报的起始序号为x+1。在此之后，服务器会进入SYN-RCVD状态，等待对连接请求的进一步确认。

SYN-RCVD状态解析：当服务器在收到并发送连接请求后，会进入SYN-RCVD状态，此时它正在等待对初始连接请求的确认。在这个状态下，服务器已经准备好接受来自客户端的进一步通信。

TCP协议规定：SYN=1且ACK=1的报文段是用于确认连接的应答，它同样不携带任何数据，但通过确认号的使用，确保了连接建立过程中的有序性和可靠性。
3、第三次握手：
在收到服务器发送的SYN报文后，客户端会回应一个ACK报文。这个ACK报文将服务器的ISN+1作为ack的值，表明客户端已经收到了服务器的SYN报文，并期待接收到的下一个数据报的起始序号为y+1。同时，客户端将自己的序列号seq设置为x+1，即初始序列号seq=x增加1。完成这些操作后，客户端进入ESTABLISHED状态，表示连接已成功建立。服务器在收到这个ACK报文后，也会转入ESTABLISHED状态，此时双方连接的建立工作全部完成。

ESTABLISHED状态解释：当一个TCP连接进入ESTABLISHED状态时，它意味着连接已经打开，数据可以开始在双方之间传送。

四次挥手连接释放：
TCP连接的终止需要经过四次包的交换，因此被称为四次挥手。在这四次交换中，客户端或服务器都可以主动发起连接的释放动作。值得注意的是，TCP连接是双向的，因此四次挥手中，前两次主要用于断开一个方向的连接，后两次则用于断开另一方向的连接。

1、第一次挥手
客户端首先发送一个FIN报文，其中包含一个序列号seq=u，表示请求连接终止。在发送完毕后，客户端停止数据发送，并主动关闭TCP连接。此时，客户端进入FIN_WAIT_1状态，等待服务器的确认。

FIN_WAIT_1状态解析：该状态表示客户端正在等待远程TCP的连接中断请求，或者等待先前连接中断请求的确认。FIN=1标志着该报文段是一个连接释放请求。而seq=u则代表客户端向服务器发送的最后一个字节的序号。
2、第二次挥手
服务端在收到客户端的FIN报文后，会发送一个ACK报文作为回应。这个ACK报文中，序列号值设为客户端序号值加1，意在确认已收到客户端的报文。随后，服务端进入CLOSE_WAIT状态，等待本地用户的连接中断请求。

CLOSE_WAIT状态解析：在此状态下，服务端等待来自本地用户的连接释放请求。ACK报文中的ACK=1表示应答，而seq=v则指明了服务端释放应答报文段的首字节序号。同时，ack=u+1表明服务端希望从第u+1个字节开始接收报文段，并已成功接收了前u个字节。

完成第二次挥手后，客户端到服务端的连接已释放，服务端不再接收客户端数据，而客户端也已无数据待发送。然而，服务端到客户端的连接仍保持开启，若服务端在此期间发送数据，客户端仍需正常接收。此状态将持续一段时间，直至整个CLOSE-WAIT状态结束。
3、第三次挥手
服务端在完成数据的发送后，会向客户端发送一个连接释放报文。这个报文头包含FIN标志位为1，以及ack序号值为u+1。由于在CLOSE_WAIT状态期间，服务端可能又发送了一些数据，假设此时的序列号为seq=w。发送完毕后，服务端进入LAST_ACK状态，等待来自客户端的连接中断确认。
4、第四次挥手
客户端在收到服务端的FIN报文后，会响应一个ACK报文，其中ack序号值为w+1，同时将自己的序列值加1作为ACK报文的seq序号值，即seq=u+1。此后，客户端进入TIME_WAIT状态。
TIME_WAIT：确保远程TCP收到连接中断请求的确认
该状态会持续2MSL（最长报文段寿命）的时间。在此期间，TCP连接并未完全释放。若在这段时间内未收到服务端的重发请求，客户端将进入CLOSED状态，并撤销TCB。
服务端在收到客户端的确认ACK报文后，会立即进入CLOSED状态，并撤销TCB，从而结束此次TCP连接。值得注意的是，服务端结束TCP连接的时间点通常早于客户端。
1、为何TCP建立连接时采用三次握手而非两次或四次？
采用两次握手会导致已失效的连接请求报文段被重新发送至服务端，从而造成服务端资源的无效消耗。而三次握手已足够确保握手过程中的通信正常，无需增加至四次，否则将显得冗余。
2、为何TCP关闭连接时需要四次挥手？
TCP协议的半关闭特性允许其连接的一端在完成发送后，仍能继续接收来自另一端的数据。因此，任何一方都可以在数据传输结束后主动发起连接释放的通知，并在对方确认后进入半关闭状态。当另一方也确认无数据再发送时，才会发出最终的连接释放通知，对方确认后，TCP连接即完全关闭。
3、为何TIME_WAIT状态需持续2MSL后才能转为CLOSE状态？

当TCP连接的一方完成连接释放后，会进入TIME_WAIT状态。这个状态需要持续2倍的最大段寿命（Maximum Segment Lifetime，MSL）的时间，这是为了确保在传输过程中可能存在的延迟数据包能够被对方完全接收。只有当2MSL时间过去后，确认对方已收到所有数据，该TCP连接才能完全关闭，进入CLOSE状态。

确保服务端能够接收到客户端的确认应答。

如果客户端在发送完确认应答后立即进入CLOSED状态，而该应答不幸丢失，服务端在等待超时后将尝试重新发送连接释放请求。但此时，由于客户端已经关闭，无法再作出响应，这会导致服务端无法正常关闭TCP连接。因此，TIME_WAIT状态的持续存在，是为了保证服务端能够接收到并处理客户端的确认应答，从而确保连接的平滑关闭。
2. 防止“三次握手”中提及的“已失效的连接请求报文段”干扰当前连接。

当客户端发送完最后一个确认报文后，经过2MSL的时间间隔，可以确保在本连接持续时间内产生的所有报文段都已从网络中清除。这样，新建立的连接就不会受到旧连接请求报文的影响。

1. TCP（Transmission Control Protocol）

2. UDP（User Datagram Protocol）

TCP三次握手与四次挥手全指南

相关文章：