一、序
当我们聊到 TCP 协议的时候,聊的最多的就是三次握手与四次挥手,但是你有没有想过,三次握手或者四次挥手时,如果发生异常了,是如何处理的?又是由谁来处理?
TCP 作为一个靠谱的协议,在传输数据的前后,需要在双端之间建立连接,并在双端各自维护连接的状态。TCP 并没有什么特别之处,在面对着多变的网络情况,也只能通过不断的重传和各种算法来保证可靠性。
建立连接前,TCP 会通过三次握手来保证双端状态正确,然后就可以正常传输数据了,在数据传输完毕后,又通过四次挥手来保证双端合理的断开连接并回收各自的资源。
我们在学习 TCP 建连和断连时,都是一个标准的流程,但是网络是多变的,很多时候并不像教科书那样标准,那么今天就来聊聊 TCP 三次握手出现异常的时候,是如何处理的。
二、TCP 三次握手
2.1 简单理解三次握手
虽然是说三次握手的异常情况,我们还是先来了解一下三次握手。
在通过 TCP 传输数据时,第一步就是要先建立一个连接。TCP 建立连接的过程,就是我们常说的三次握手。
我们经常将三次握手,描述成「请求 → 应答 → 应答之应答」。
至于 TCP 握手为什么是三次,其实就是要让双端都经历一次「请求 → 应答」的过程,来确认对方还在。网络情况是多变的,双端都需要一次自己主动发起的请求和对方回复的应答过程,来确保对方和网络是正常的。
下面这张图,是比较经典的 TCP 三次握手的消息和双端状态的变化。
我们先来解释一下这张图:
-
在初始时,双端处于 CLOSE 状态,服务端为了提供服务,会主动监听某个端口,进入 LISTEN 状态。
-
客户端主动发送连接的「SYN」包,之后进入 SYN-SENT 状态,服务端在收到客户端发来的「SYN」包后,回复「SYN,ACK」包,之后进入 SYN-RCVD 状态。
-
客户端收到服务端发来的「SYN,ACK」包后,可以确认对方存在,此时回复「ACK」包,并进入 ESTABLISHED 状态。
-
服务端收到最后一个「ACK」包后,也进入 ESTABLISHED 状态。
正常的三次握手之后,双端都进入 ESTABLISHED 状态,在此之后,就是正常的数据传输过程。
2.2 TCP 握手的异常情况
三次握手的正常发包和应答,以及双端的状态扭转我们已经讲了,接下来就来看看在这三次握手的过程中,出现的异常情况。
1. 客户端第一个「SYN」包丢了。
如果客户端第一个「SYN」包丢了,也就是服务端根本就不知道客户端曾经发过包,那么处理流程主要在客户端。
而在 TCP 协议中,某端的一组「请求-应答」中,在一定时间范围内,只要没有收到应答的「ACK」包,无论是请求包对方没有收到,还是对方的应答包自己没有收到,均认为是丢包了,会触发超时重传机制。
所以此时会进入重传「SYN」包。根据《TCP/IP详解卷Ⅰ:协议》中的描述,此时会尝试三次,间隔时间分别是 5.8s、24s、48s,三次时间大约是 76s 左右,而大多数伯克利系统将建立一个新连接的最长时间,限制为 75s。
也就是说三次握手第一个「SYN」包丢了,会重传,总的尝试时间是 75s。
参考:http://docs.52im.net/extend/docs/book/tcpip/vol1/18/
2. 服务端收到「SYN」并回复的「SYN,ACK」包丢了。
此时服务端已经收到了数据包并回复,如果这个回复的「SYN,ACK」包丢了,站在客户端的角度,会认为是最开始的那个「SYN」丢了,那么就继续重传,就是我们前面说的「错误 1 流程」。
而对服务端而言,如果发送的「SYN,ACK」包丢了,在超时时间内没有收到客户端发来的「ACK」包,也会触发重传,此时服务端处于 SYN_RCVD 状态,会依次等待 3s、6s、12s 后,重新发送「SYN,ACK」包。
而这个「SYN,ACK」包的重传次数,不同的操作系统下有不同的配置,例如在 Linux 下可以通过 tcp_synack_retries 进行配置,默认值为 5。如果这个重试次数内,仍未收到「ACK」应答包,那么服务端会自动关闭这个连接。
同时由于客户端在没有收到「SYN,ACK」时,也会进行重传,当客户端重传的「SYN」收到后,会立即重新发送「SYN,ACK」包。
3. 客户端最后一次回复「SYN,ACK」的「ACK」包丢了。
如果最后一个「ACK」包丢了,服务端因为收不到「ACK」会走重传机制,而客户端此时进入 ESTABLISHED 状态。
多数情况下,客户端进入 ESTABLISHED 状态后,则认为连接已建立,会立即发送数据。但是服务端因为没有收到最后一个「ACK」包,依然处于 SYN-RCVD 状态。
那么这里的关键,就在于服务端在处于 SYN-RCVD 状态下,收到客户端的数据包后如何处理?
这也是比较有争议的地方,有些资料里会写到当服务端处于 SYN-RCVD 状态下,收到客户端的数据包后,会直接回复 RTS 包响应,表示服务端错误,并进入 CLOSE 状态。
但是这样的设定有些过于严格,试想一下,服务端还在通过三次握手阶段确定对方是否真实存在,此时对方的数据已经发来了,那肯定是存在的。
所以当服务端处于 SYN-RCVD 状态下时,接收到客户端真实发送来的数据包时,会认为连接已建立,并进入 ESTABLISHED 状态。
实践出真知,具体测试流程可以参考这篇文章:https://blog.csdn.net/zerooffdate/article/details/79359726
那么实际情况,为什么会这样呢?
当客户端在 ESTABLISHED 状态下,开始发送数据包时,会携带上一个「ACK」的确认序号,所以哪怕客户端响应的「ACK」包丢了,服务端在收到这个数据包时,能够通过包内 ACK 的确认序号,正常进入 ESTABLISHED 状态。
参考:https://stackoverflow.com/questions/16259774/what-if-a-tcp-handshake-segment-is-lost
4. 客户端故意不发最后一次「SYN」包。
前面一直在说正常的异常逻辑,双方都还算友善,按规矩做事,出现异常主要也是因为网络等客观问题,接下来说一个恶意的情况。
如果客户端是恶意的,在发送「SYN」包后,并收到「SYN,ACK」后就不回复了,那么服务端此时处于一种半连接的状态,虽然服务端会通过 tcp_synack_retries 配置重试的次数,不会无限等待下去,但是这也是有一个时间周期的。
如果短时间内存在大量的这种恶意连接,对服务端来说压力就会很大,这就是所谓的 SYN FLOOD 攻击。
这就属于安全攻防的范畴了,今天就不讨论了,有兴趣可以自行了解。
转载于:https://www.cnblogs.com/shijingxiang/articles/12174425.html