TCP连接的建立与断开

 

建立连接：

1、建立连接时，客户端发送SYN包（SYN=J）到服务器，并进入SYN_SENT状态，等待服务器确认；

2、服务器收到SYN包，必须确认客户的SYN（ack=J+1），同时自己也发送一个SYN包（SYN=K），即SYN+ACK包，此时服务器进入SYN_RECV状态；

3、客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=K+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手，客户端与服务器开始传送数据。

SYN攻击：

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了。

，使用如下命令可以让之现行：

#netstat -nap | grep SYN_RECV

断开连接：

1、第一次挥手：客户端发送一个FIN=M的包，用来关闭客户端到服务器的数据传送，Client进入FIN_WAIT_1状态；

2、第二次挥手：服务器收到FIN包后，发送一个ACK（ack=M+1）给客户端，服务器进入CLOSE_WAIT状态，客户端收到之后进入FIN_WAIT_2状态；

3、第三次挥手：服务器发送一个FIN=N的包，用来关闭服务器到客户端的数据传送。服务器进入LAST_ACK状态。

4、第四次挥手：客户端收到FIN包后，进入TIME_WAIT状态，接着发送一个ACK（ack=N+1）给服务器，服务器进入CLOSED状态，完成四次挥手。

为什么建立连接是三次握手，而关闭连接却是四次挥手？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

为什么TIME_WAIT状态需要经过2MSL（最大报文段生存时间）才能回到CLOSE状态？

（1）保证TCP协议的全双工能够可靠关闭

如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

（2）保证这次连接的重复数据段从网络中消失

如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

转载自http://m.blog.csdn.net/qq_39010647/article/details/77531920