TCP三次握手四次挥手过程梳理

1. 数据传输的大致示意图

1.1 TCP数据报文首部内部

1.2 TCP连接的几种状态说明

　　即命令 netstat 结果中的所有状态:

2. TCP连接建立的全过程 

2.1 TCP三次握手建立TCP连接

　　1)客户端和服务端都处于CLOSED状态。(发起TCP请求的称为客户端，接受请求的称为服务端)
　　2)服务端打开服务端口，处于listen状态。
　　3)客户端发起连接请求。首先发送SYN(synchronous)报文给服务端，等待服务端给出ACK报文回应。发送的SYN=1，ACK=0，seq=x,表示只发送了SYN信号。此时客户端处于SYN-SENT状态（SYN信号已发送）。

　　4)服务端收到SYN信号后，发出ACK报文回应，并同时发出自己的SYN信号请求连接。此时服务端处于SYN-RECV状态(syn recieved，在图中显示的是SYN-RCVD)。发送的SYN=1 ACK=x+1，seq=y,表示发送了SYN+ACK。
　　5)客户端收到服务端的确认信号ACK后，再次发送ACK信号给服务端以回复服务端发送的syn。此时客户端进入ESTABLISHED状态，发送的SYN=0，ACK=y+1,seq=x+1,表示只发送了ACK。
　　6)服务端收到ACK信号后，也进入ESTABLISHED状态。此后进行数据的传输都通过此连接进行。其中第3、4、5步是三次握手的过程。这个过程通俗地说就是双方请求并回应的过程：①A发送syn请求B并等待B回应；②B回应A，并同时请求A；③A回应B

                               

2.2 TCP释放连接,四次挥手断开TCP连接全过程

　　1)客户端发送FIN(finally)=1,seq=u报文信号，请求断开。此后客户端进入FIN-WAIT-1状态。
　　2)服务端收到FIN信号，给出确认信号ACK=1,seq=v,ack=u+1表示同意断开。此时服务端进入CLOSE-WAIT状态。此过程结束后表示从客户端到服务端方向的TCP连接已经关闭了，也就是说整个TCP连接处于半关闭状态。
　　3)客户端收到服务端的ACK后进入FIN-WAIT-2状态，以等待服务端发出断开信号FIN。在客户端的FIN-WAIT-2状态的等待过程中，服务端再发出自己的FIN信号给客户端,FIN=1,ACK=1,seq=w,ack=u+1。此时服务端进入LAST-ACK状态。
　　4)客户端收到服务端的FIN信号，给出回应信号ACK，ACK=1,seq=u+1,ack=w+1,表示接受服务端的断开请求，此时客户端进入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是进行优化/封堵.

?

1 2 3 4

[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