TCP三次握手四次挥手过程梳理
Posted blog-tim
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP三次握手四次挥手过程梳理相关的知识,希望对你有一定的参考价值。
1. 数据传输的大致示意图
1.1 TCP连接的几种状态说明
即命令 netstat 结果中的所有状态:
2. TCP连接建立的全过程
2.1 TCP三次握手建立TCP连接
1)客户端和服务端都处于CLOSED状态。(发起TCP请求的称为客户端,接受请求的称为服务端)
2)服务端打开服务端口,处于listen状态。
3)客户端发起连接请求。首先发送SYN(synchronous)报文给服务端,等待服务端给出ACK报文回应。发送的SYN=1,ACK=0,表示只发送了SYN信号。此时客户端处于SYN-SENT状态(SYN信号已发送)。
4)服务端收到SYN信号后,发出ACK报文回应,并同时发出自己的SYN信号请求连接。此时服务端处于SYN-RECV状态(syn recieved,在图中显示的是SYN-RCVD)。发送的SYN=1 ACK=1,表示发送了SYN+ACK。
5)客户端收到服务端的确认信号ACK后,再次发送ACK信号给服务端以回复服务端发送的syn。此时客户端进入ESTABLISHED状态,发送的SYN=0,ACK=1表示只发送了ACK。
6)服务端收到ACK信号后,也进入ESTABLISHED状态。此后进行数据的传输都通过此连接进行。其中第3、4、5步是三次握手的过程。这个过程通俗地说就是双方请求并回应的过程:①A发送syn请求B并等待B回应;②B回应A,并同时请求A;③A回应B
2.2 TCP释放连接,四次挥手断开TCP连接全过程
1)客户端发送FIN(finally)报文信号,请求断开。此后客户端进入FIN-WAIT-1状态。
2)服务端收到FIN信号,给出确认信号ACK=1,表示同意断开。此时服务端进入CLOSE-WAIT状态。此过程结束后表示从客户端到服务端方向的TCP连接已经关闭了,也就是说整个TCP连接处于半关闭状态。
3)客户端收到服务端的ACK后进入FIN-WAIT-2状态,以等待服务端发出断开信号FIN。在客户端的FIN-WAIT-2状态的等待过程中,服务端再发出自己的FIN信号给客户端。此时服务端进入LAST-ACK状态。
4)客户端收到服务端的FIN信号,给出回应信号ACK,表示接受服务端的断开请求,此时客户端进入TIME-WAIT状态,此时客户端已脱离整个TCP,只需再等待一段时间(2*MSL)就自动进入CLOSED状态。
5)服务端收到客户端的回应ACK信号,知道客户端同意了服务端到客户端方向的TCP断开,直接进入CLOSED状态。以上1.2.3.4是四次挥手的阶段,握手和挥手的过程是类似的.区别是:握手时发送的SYN和ACK是放在同一个数据包发送的,而挥手时,是将服务端发送的ACK和FIN分卡发送的.
注意:如果是客户端请求断开,那么服务端就是被动断开端,可能会保留大量的CLOSE-WAIT状态的连接,如果是服务端主动请求断开,则可能会保留大量的TIME_WAIT状态的连接。由于每个连接都需要占用一个文件描述符,高并发情况下可能会耗尽这些资源。因此,需要找出对应问题,做出对应的防治,一般来说,可以修改内核配置文件 /etc/sysctl.conf 来解决一部分问题。
3. Linux下查看和预防SYN洪水攻击
SYN洪水攻击是一种常见的DDoS攻击手段.攻击者可以通过工具在极短时间内伪造大量随机不存在的ip向服务器指定端口发送tcp连接请求,也就是发送了大量syn=1 ack=0的数据包,当服务器收到了该数据包后会回复并同样发送syn请求tcp连接,也就是发送ack=1 syn=1的数据包,此后服务器进入SYN-RECV状态,正常情况下,服务器期待收到客户端的ACK回复。但问题是服务器回复的目标ip是不存在的,所以回复的数据包总被丢弃,也一直无法收到ACK回复,于是不断重发ack=1 syn=1的回复包直至超时。在服务器被syn flood攻击时,由于不断收到大量伪造的syn=1 ack=0请求包,它们将长时间占用资源队列,使得正常的SYN请求无法得到正确处理,而且服务器一直处于重传响应包的状态,使得cpu资源也被消耗。总之,syn flood攻击会大量消耗网络带宽和cpu以及内存资源,使得服务器运行缓慢,严重时可能会引起网络堵塞甚至系统瘫痪.
可使用 netstat -lntap 命令判断服务器是否遭受SYN洪水攻击,结合 /etc/sysctl.conf 和防火墙iptables是进行优化/封堵.
[root@xuexi ~]# netstat -tnlpa | grep tcp | awk ‘{print $6}‘ | sort | uniq -c 1 ESTABLISHED 7 LISTEN 256 SYN_RECV
以上大部分内容参考好友报文博文 https://www.cnblogs.com/f-ck-need-u/p/7397146.html
以上是关于TCP三次握手四次挥手过程梳理的主要内容,如果未能解决你的问题,请参考以下文章
OSI(七层)网络模型,三次握手四次挥手梳理,Socket.TCP/IP.HTTP三者说明