dbaplus社群 03月11日
TCP的第三次握手没有回复,会有什么问题?
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

本文深入探讨了TCP三次握手过程及其在面试中的常见问题。文章以通俗易懂的方式解释了三次握手的必要性,以及第三次握手失败时服务器可能出现的现象,如超时重传和半连接队列。同时,还涉及了SYN Flood攻击的原理和防范。此外,文章还探讨了TCP握手背后蕴含的状态确认和超时重试机制,并将其与后端系统设计中的应用相结合,为读者提供了更深层次的理解和应用。

🤝 TCP三次握手是确保客户端和服务器之间建立可靠连接的关键过程。第一次握手由客户端发起SYN请求,服务端回应SYN+ACK,最后客户端发送ACK确认,完成连接建立。

⏳ 第三次握手失败会导致服务器停留在SYN_RCVD状态,并触发超时重传机制。服务器会多次尝试重发SYN-ACK报文,若最终未收到ACK,则放弃连接,释放资源。

🛡️ SYN Flood攻击利用TCP握手漏洞,通过大量伪造IP地址发送SYN报文,耗尽服务器的半连接队列资源,导致正常连接无法建立。服务器需要采取诸如SYN Cookie等技术来防御此类攻击。

💡 TCP三次握手中的状态确认和超时重试机制,在后端系统设计中具有重要意义。例如,在微服务通信中,可以借鉴状态确认机制进行健康检查;在调用第三方API时,可以采用超时重试策略提高成功率。

捡田螺的小男孩 2025-03-11 07:15 广东

五个维度,看你是不是都知道!


前言


有位朋友去大厂面试,问了这么一道面试题:TCP的第三次握手没有回复,会有什么问题?服务器会出现什么现象?


对于这道题,我们如何去回答,才更好呢?如果是我,我会按照这几个维度:



TCP的三次握手过程



开始客户端和服务器都处于CLOSED状态,然后服务端开始监听某个端口,进入LISTEN状态



第三次握手没有回复,连接建立不了


上个小节,我们梳理完TCP三次握手流程,也就是TCP需要三次握手,才能真正建立连接。


如果服务器没有收到客户端发送的第三次握手的ACK确认包,那么从服务器的角度看,这个连接仍处于未完全建立的状态,不能正式用于数据传输。


也就是如果没有第三次握手回复,只有两次握手,那是不行的。TCP连接,为什么需要三次握手,为什么两次不行,为什么四次不行?


为了方便理解,我们以谈恋爱为例子:两个人能走到一起,最重要的事情就是相爱,就是我爱你,并且我知道,你也爱我,接下来我们以此来模拟三次握手的过程:



为什么握手不能是两次呢?


如果只有两次握手,女孩子可能就不知道,她的那句我也爱你,男孩子是否收到,恋爱关系就不能愉快展开。


为什么握手不能是四次呢?


因为握手不能是四次呢?因为三次已经够了,三次已经能让双方都知道:你爱我,我也爱你。而四次就多余了。


第三次握手没有回复,服务器会出现什么现象?


TCP三次握手:


服务器在收到客户端的 SYN 报文后,会发送一个 SYN-ACK 报文并进入 SYN-RECEIVED 状态。此时,它正在等待客户端发送的 ACK 报文。如果客户端的 ACK 报文没有到达服务器,服务器会在 SYN-RECEIVED 状态中停留一段时间(通常称为超时重传时间)。


也就是说,第三次握手没有ACK回复,服务器会在 SYN-RECEIVED 状态中停留一段时间。然后超时重传


然后如果没有收到客户端的 ACK 报文,它会重新发送 SYN-ACK 报文。


当然,重试肯定有次数限制的,如果在重传了多次之后,服务器仍然没有收到客户端的 ACK 报文,服务器会认为连接失败,并放弃这次连接。此时,服务器会进入 CLOSED 状态,释放资源。


超时重传


TCP 为了实现可靠传输,实现了重传机制。最基本的重传机制,就是超时重传,即在发送数据报文时,设定一个定时器,每间隔一段时间,没有收到对方的ACK确认应答报文,就会重发该报文。


这个间隔时间,一般设置为多少呢?我们先来看下什么叫RTT(Round-Trip Time,往返时间)。



RTT就是,一个数据包从发出去到回来的时间,即数据包的一次往返时间。超时重传时间,就是Retransmission Timeout ,简称RTO。


RTO设置多久呢?



一般情况下,RTO略大于RTT,效果是最好的。一些小伙伴会问,超时时间有没有计算公式呢?有的!有个标准方法算RTO的公式,也叫Jacobson / Karels 算法。我们一起来看下计算RTO的公式


1、先计算SRTT(计算平滑的RTT)

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加权平均


2、再计算RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //计算 SRTT 与真实值的差距


3、最终的RTO

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR


其中,α = 0.125,β = 0.25, μ = 1,∂ = 4,这些参数都是大量结果得出的最优参数。


半连接队列和SYN Flood 攻击


在TCP的三次握手中,服务器发送SYN+ACK包之后,会等待客户端的ACK。如果ACK没有按时到达,可能是因为网络丢包或是恶意攻击(如SYN Flood攻击)


如果是网络不稳定,导致的网络丢包,一般我们重试都会成功的。还有个可能的原因,就是SYN Flood攻击。


SYN Flood是一种典型的DoS (Denial of Service,拒绝服务) 攻击,它在短时间内,伪造不存在的IP地址,向服务器大量发起SYN报文。当服务器回复SYN+ACK报文后,不会收到ACK回应报文,导致服务器上建立大量的半连接队列,半连接队列满了,这就无法处理正常的TCP请求啦。


TCP 三次握手的一些后端思想应用


TCP三次握手,背后蕴含的一些思想是可以应用到后端系统设计中的。


1、状态确认思想


比如,TCP三次握手确保双方都知道对方准备好进行通信,并且双方都能确认自己的消息被对方收到。这个机制本质上是一种状态同步和确认机制。


这种机制可以应用于分布式系统的节点间通信或客户端与服务端的连接建立。例如,在微服务之间的通信中,可以在建立连接前,进行双方的状态确认或健康检查,确保后续的通信是可靠的。


2、超时重试机制


再比如,TCP三次握手中,服务端会等待客户端的ACK确认包,如果没有收到,会根据一定策略进行重试,这背后是重试与超时的机制。


在后端服务中,重试机制和超时处理也非常重要。例如在调用第三方API时,如果网络波动导致请求失败,系统可以通过配置合理的重试策略(如指数退避、限流等)来提高成功率,同时避免过载。实例:HTTP请求的重试机制、消息队列的重发策略等。


作者丨捡田螺的小男孩

来源丨公众号:捡田螺的小男孩(ID:gh_3d11c9893ca0)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn



阅读原文

跳转微信打开

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

TCP 三次握手 网络协议 SYN Flood 后端设计
相关文章