网络问题之TCP/UDP协议

1. TCP是什么？

TCP（Transmission Control Protocol，传输控制协议）是互联网核心协议之一，属于传输层协议，为应用程序提供可靠的、面向连接的字节流服务。

基本特性

• 可靠性：通过确认机制、重传机制、校验和等确保数据准确送达

• 面向连接：通信前需建立连接（三次握手），结束后断开连接（四次挥手）

• 字节流服务：将数据视为无结构的字节序列，不保留消息边界

• 全双工通信：双方可同时发送和接收数据

• 流量控制：通过滑动窗口机制防止发送方淹没接收方

• 拥塞控制：动态调整发送速率避免网络拥塞

2.UDP是什么？

UDP（User Datagram Protocol，用户数据报协议）是互联网核心协议之一，与TCP同属传输层协议，但提供完全不同的服务模型。

基本特性

• 无连接：通信前不需要建立连接，直接发送数据

• 不可靠传输：不保证数据送达、不保证顺序、没有确认机制

• 无拥塞控制：发送速率完全由应用层控制

• 面向报文：保留应用程序定义的报文边界

• 轻量级：头部开销小（仅8字节）

• 支持广播/多播：可以向多个接收者同时发送数据

3. 与UDP的对比

特性	TCP	UDP
连接方式	面向连接（需握手）	无连接
可靠性	可靠传输（确认+重传）	不可靠传输
数据顺序	保证顺序	不保证顺序
传输效率	相对较低（有控制开销）	较高（头部仅8字节）
流量控制	有（滑动窗口）	无
典型应用	Web浏览、文件传输、邮件	视频流、DNS查询、游戏

4.TCP为啥要三次握手 四次挥手

三次握手的必要性

TCP需要三次握手(3-way handshake)建立连接的原因：

1. 防止历史重复连接初始化造成的混乱

• 如果只有两次握手，当网络中存在延迟的旧连接请求到达服务器时，服务器会误认为这是新的连接请求而建立连接

• 三次握手机制下，客户端可以识别出这是历史重复连接(RST置位)，从而拒绝该连接

2. 同步双方的初始序列号(ISN)

• 每次TCP连接双方都需要随机生成初始序列号

• 三次握手确保双方的序列号能被可靠同步：

  复制

  客户端发送：SYN=1, seq=x
  服务端回复：SYN=1, ACK=1, seq=y, ack=x+1
  客户端确认：ACK=1, seq=x+1, ack=y+1

3. 避免资源浪费

• 如果是两次握手，服务器收到SYN就会分配资源建立连接

• 当客户端不响应时会造成服务器资源浪费

• 三次握手确保双方都有发送和接收能力后才建立连接

技术本质

三次握手是保证可靠数据传输的最小通信次数，确保：

1. 双方都能确认对方的收发能力正常

2. 双方就初始序列号达成一致

3. 防止历史连接干扰

四次挥手的必要性

TCP需要四次挥手(4-way handshake)断开连接的原因：

1. TCP的全双工特性

• TCP连接是双向的，每个方向必须单独关闭

• FIN表示"我没有数据要发送了"，但还可以接收数据

• 因此需要两个方向的分别关闭：

  复制

  客户端发送FIN → 服务器回复ACK
  服务器发送FIN → 客户端回复ACK

2. 确保数据能够完整传输

• 当一方发送FIN时，可能还有数据在传输途中

• 四次挥手设计允许在收到FIN后继续发送剩余数据

• 对比直接同时关闭(RST)的暴力断开方式更加优雅

3. TIME_WAIT状态的重要性

• 主动关闭方会进入2MSL(报文最大生存时间)的TIME_WAIT状态

• 两个重要作用：

  a) 确保最后一个ACK能到达对端(如果丢失，对端会重发FIN)

  b) 让网络中残留的该连接报文都失效，避免影响新连接

特殊情况

在某些情况下可以合并为三次挥手：

• 当服务器收到客户端的FIN后，如果也没有数据要发送了，可以将自己的FIN和ACK合并发送

• 但这不是标准做法，多数实现还是保持四次挥手

常见问题解答

Q: 为什么不能合并第二次和第三次握手？

A: 因为第二次握手是服务端的SYN+ACK，表示服务端的序列号初始化和对客户端SYN的确认。第三次握手是客户端对服务端SYN的确认，两者目的不同。

Q: 为什么TIME_WAIT需要2MSL时间？

A: 1MSL确保主动方的ACK能到达对端，另1MSL确保对端重传的FIN能到达。2MSL确保两个方向上的残留报文都消失。

Q: 如果第三次握手丢失会怎样？

A: 服务端会超时重传SYN+ACK，客户端收到后会再次发送ACK。如果多次重传失败，服务端最终会关闭这个半连接。

Q: 为什么建立连接是三次而关闭连接是四次？

A: 建立连接时服务端的SYN和ACK可以合并发送，但关闭连接时服务端收到FIN后可能还有数据要发送，所以ACK和FIN不能立即合并发送。

5.TCP为啥会粘包

tcp 粘包可能发生在发送端或者接收端，分别来看两端各种产生粘包的原因：

• 发送端粘包：发送端需要等缓冲区满才发送出去，造成粘包；
• 接收方粘包：接收方不及时接收缓冲区的包，造成多个包接收。

6.如何解决TCP粘包问题

tcp粘包/拆包的解决办法

TCP粘包/拆包的解决方法主要包括协议设计优化和框架级解码器支持，核心思路是为数据包定义明确的边界规则。‌

主要解决方案

‌固定长度法‌

发送方将每个数据包封装为固定长度（如200字节），不足部分填充特定字符（如空格或0）。接收方按固定长度读取数据，避免粘包/拆包。 ‌1

示例：设定每个数据包长度为100字节，发送端填充不足部分，接收端每次读取100字节。

‌特殊分隔符法‌

在数据包末尾添加特定分隔符（如\r ），接收方根据分隔符拆分数据。例如FTP协议使用换行符作为边界。 ‌1

适用场景：文本协议或需要人工可读的数据格式。

‌消息头定义长度法‌

在数据包头部添加长度字段（如4字节的int值），接收方先读取长度信息，再按该长度读取完整数据包。 ‌1

优势：灵活适配变长数据，广泛应用于自定义协议设计。

‌应用层协议封装‌

设计更复杂的协议规范，例如将消息分为消息头和消息体，头部包含校验、版本等信息，消息体按业务逻辑扩展。 ‌12

典型应用：Netty等框架通过:ml-search[LengthFieldBasedFrameDecoder]支持此类协议。

‌框架级解码器支持‌

使用网络框架（如Netty）内置的解码器自动处理粘包/拆包：

FixedLengthFrameDecoder：固定长度解码； ‌3

LineBasedFrameDecoder：基于换行符分割；

DelimiterBasedFrameDecoder：自定义分隔符；

LengthFieldBasedFrameDecoder：头部含长度的通用方案。 ‌

优势：减少手动处理复杂度，提升开发效率。

其他补充

‌HTTP协议的解决方案‌：通过Content-Length明确数据长度，或使用chunked编码分块传输，天然规避粘包问题。 ‌

‌UDP无粘包问题‌：因其面向数据报且自带消息边界保护。

‌建议结合具体场景选择方案‌：简单文本通信可用分隔符法，高性能场景推荐消息头长度法或Netty框架集成。

7.TCP的拥塞控制机制是如何工作的？

TCP拥塞控制包含四个核心算法：

1. 慢启动(Slow Start)：

   • 初始拥塞窗口(cwnd)为1 MSS

   • 每收到一个ACK，cwnd指数增长(1,2,4,8...)

   • 当cwnd达到慢启动阈值(ssthresh)时进入拥塞避免阶段

2. 拥塞避免(Congestion Avoidance)：

   • cwnd线性增长(每RTT增加1 MSS)

   • 当检测到丢包时，调整ssthresh为当前cwnd的一半

3. 快速重传(Fast Retransmit)：

   • 收到3个重复ACK时立即重传丢失的报文段

   • 不等待超时重传计时器

4. 快速恢复(Fast Recovery)：

   • 重传丢失的报文段后，cwnd = ssthresh + 3 MSS

   • 每收到一个重复ACK，cwnd增加1 MSS

   • 当收到新数据的ACK时，退出快速恢复