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就会分配资源建立连接
-
当客户端不响应时会造成服务器资源浪费
-
三次握手确保双方都有发送和接收能力后才建立连接
技术本质
三次握手是保证可靠数据传输的最小通信次数，确保：
-
双方都能确认对方的收发能力正常
-
双方就初始序列号达成一致
-
防止历史连接干扰
四次挥手的必要性
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拥塞控制包含四个核心算法：
-
慢启动(Slow Start)：
-
初始拥塞窗口(cwnd)为1 MSS
-
每收到一个ACK，cwnd指数增长(1,2,4,8...)
-
当cwnd达到慢启动阈值(ssthresh)时进入拥塞避免阶段
-
-
拥塞避免(Congestion Avoidance)：
-
cwnd线性增长(每RTT增加1 MSS)
-
当检测到丢包时，调整ssthresh为当前cwnd的一半
-
-
快速重传(Fast Retransmit)：
-
收到3个重复ACK时立即重传丢失的报文段
-
不等待超时重传计时器
-
-
快速恢复(Fast Recovery)：
-
重传丢失的报文段后，cwnd = ssthresh + 3 MSS
-
每收到一个重复ACK，cwnd增加1 MSS
-
当收到新数据的ACK时，退出快速恢复
-
