|
|
51CTO旗下网站
|
|
移步端
创造专栏

TCP 四次挥手,你熟了!那意外情况呢?恶意攻击呢?单端跑路呢?

顶我们聊到 TCP 协和的时节,聊的最多的就是三次握手与四次挥手,但是你有没有想过,三次握手或者四次挥手时,如果发生异常了,是如何处理的?又是由谁处理的?

笔者:张�D| 2020-01-10 09:51

一、先后

顶我们聊到 TCP 协和的时节,聊的最多的就是三次握手与四次挥手,但是你有没有想过,三次握手或者四次挥手时,如果发生异常了,是如何处理的?又是由谁处理的?

TCP 表现一个靠谱的商谈,在传输数据的左右,要求在双端之间确立连接,并在双端各自维护连接的状态。TCP 并没有多么神奇,在面对着多变的网络情况,也只能通过不断的份额传和各族算法来保证可靠性。

顶数据传输完成,要求断开连接的时节,TCP 会通过四次握手来形成双端的断连,并回收各自的风源。这就是说今天就来继承聊聊,TCP 四次挥手过程中,如果出现异常,单端跑路等问题,是如何处理的。

二、TCP 四次挥手

2.1 大概理解四次挥手

虽然是在说四次挥手的突出状态,在此之前,咱们还是先来概括了解一下 TCP 的四次挥手。

顶数据传输完成,要求断开连接的时节,TCP 会利用四次挥手的措施,来安全的断开连接。

为什么握手需要三次,而挥手需要四次呢?

实质上来说,双端都要求经过一次「离别」的经过,来保证自己和对头的状态不错。本着友好协商的态势,你先提出的分别,也要把最大的好心�o美方,决不能打了我党一个措手不及。你说不玩了就不玩了,那以后谁还敢和你玩。

下这张图,是比较经典的 TCP 四次挥手的信息和双端状态的转移。

咱们解释一下这张图:

1. 初步时双端还都处于 ESTABLISHED 状态并传输数据,某端可以主动发起「FIN」包准备断开连接,在此间的面貌下,是客户端发起「FIN」呼吁。在发射「FIN」此后,客户端进入 FIN-WAIT-1 状态。

2. 劳务端收到「FIN」信息后,回复「ACK」表示理解了,并从 ESTABLISHED 状态进入 CLOSED-WAIT 状态,起来做一些断开连接前的准备工作。

3. 客户端收到之前「FIN」的回答「ACK」信息后,进去 FIN-WAIT-2 状态。而当服务端做好断开前的准备工作以后,也会发送一个「FIN,ACK」的信息�o客户端,表示我也好了,呼吁断开连接,并在殡葬消息后,劳务端进入 LAST-ACK 状态。

4. 客户端在接受「FIN,ACK」信息后,会立即回复「ACK」表示理解了,并进入 TIME_WAIT 状态,为了稳定和安全考虑,客户端会在 TIME-WAIT 状态等待 2MSL 的时长,末了进入 CLOSED 状态。

5. 劳务端收到客户端回复的「ACK」信息后,直接从 LAST-ACK 状态进入 CLOSED 状态。

正常的经过四次挥手之后,双端都进入 CLOSED 状态,在此之后,双端正式断开了交接。

2.2 TCP 挥手的突出状态

四次挥手的健康发包和回答过程,咱们已经简单了解了,然后就继续看看,四次挥手过程中,出现的突出状态。

三次握手的健康发包和回答,以及双端的状态扭转我们已经讲了,然后就来看望在这三次握手的经过中,出现的突出状态。

1. 断开连接的 FIN 包丢了。

咱们面前一直强调过,如果一个包发出去,在固定时间内,只要没有接受对头的「ACK」回复,平均认为这个包丢了,会触发超时重传机制。而不会关切到底是团结发的包丢了,还是对方的「ACK」丢掉了。

故此在此间,如果客户端率先发的「FIN」包丢了,或者没有接受对头的「ACK」回复,则会触发超时重传,直到触发重传之用户数,直接关闭连接。

对于服务端而言,如果客户端发来之「FIN」没有接受,就没有其他感知。会在一段日子后,也关闭连接。

2. 劳务端第一次回复的 ACK 丢掉了。

此刻因为客户端没有接受「ACK」应答,会尝试重传之前的「FIN」呼吁,劳务端收到后,又会再重传「ACK」。

而此时服务端已经进入 CLOSED-WAIT 状态,起来做断开连接前的准备工作。顶准备好之后,会回复「FIN,ACK」,瞩目这个消息是携带了之前「ACK」的呼唤序号的。

只要这个消息没少,客户端可以凭借「FIN,ACK」包中的响应序号,直接从 FIN-WAIT-1 状态,进去 TIME-WAIT 状态,起来长达 2MSL 的等待。

3. 劳务端发送的 FIN,ACK 丢掉了。

劳务端在超时后会重传,此刻客户端有两种情景,要么处于 FIN-WAIT-2 状态(先前的 ACK 也丢了),会一直等待;要么处于 TIME-WAIT 状态,会等待 2MSL 时光。

具体地说,在后的一小段日子内客户端还在,客户端在接受服务端发来之「FIN,ACK」包后,也会回复一个「ACK」应答,并做团结之状态切换。

4. 客户端最后回复的 ACK 丢掉了。

客户端在回答「ACK」此后,会进入 TIME-WAIT 状态,并开始长达 2MSL 的等待,劳务端因为没有接受「ACK」的回答,会重试一段日子,直到劳动端重试超时后主动断开。

或者等待新的客户端接入后,接受服务端重试的「FIN」信息后,回复「RST」信息,在接受「RST」信息后,复位服务端的状态。

5. 客户端收到 ACK 此后,劳务端跑路了。

客户端在接受「ACK」此后,进去了 FIN-WAIT-2 状态,等待服务端发来之「FIN」包,而如果服务端跑路了,其一包永远都等不到。

在 TCP 协和中,是没有对这个状态的拍卖体制的。但是协议不管,系统来凑,操作系统会接管这个状态,例如在 Linux 从,就足以通过 tcp_fin_timeout 数,来对这个状态设定一个超时时间。

要求注意的是,顶超过 tcp_fin_timeout 的限制后,状态并不是改制到 TIME_WAIT,而是直接进入 CLOSED 状态。

参考:https://blog.huoding.com/2016/09/05/542

6. 客户端收到 ACK 此后,客户端自己跑路了。

客户端收到「ACK」此后直接跑路,劳务端后续在殡葬的「FIN,ACK」就没有接到端,也就不会得到答复,会不断的往来 TCP 的逾期重试的公有制,此刻服务端处于 LAST-ACK 状态。

那就要分 2 种情景分析:

  1. 在超过一定时间后,劳务端主动断开。
  2. 接受「RST」此后,再接再厉断开连接。

「RST」信息是一种重置消息,表示当前错误了,有道是回到初始的状态。如果客户端跑路后有新的客户端接入,会在此发送「SYN」以期望建立连接,此刻这个「SYN」名将把忽视,并直接回答「FIN,ACK」信息,新客户端在接受「FIN」信息后是不会认的,并且会回复一个「RST」信息。

参考:https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

三、总结时刻

当日我们聊了 TCP 在四次挥手阶段出现错误时的组成部分处理策略。

绝大多数情况下,TCP 协和本身已经保证了可靠性,例如超时重传,而有些时候,又要求操作系统来接管一些状态,例如 tcp_fin_timeout 等。

关于 TCP 三次握手的突出状态,在头里的篇章中全方位讲解,有需求可以点击蓝字阅读。

【本文为51CTO专栏作者“张�D”的原创稿件,转载请通过微信公众号联系作者获取授权】

戳这里,瞧该作者更多好文

【编纂推荐】

  1. 如何用Python贯彻TCP的过渡与通信?
  2. IP、UDP和TCP的关联
  3. 3000字讲讲TCP协和,拉手挥手不是你想的那么简单
  4. 图集:TCP/IP协和集和安全
  5. 4000字详解TCP逾期与重传,看完没收获算我输
【义务编辑: 武晓燕 TEL:(010)68476606】

点赞 0
  • TCP  恶意  攻击
  • 分享:
    大家都在看
    猜你喜欢
    1. <strong id="188bf77c"></strong>