TCP三次握手四次挥手状态转移

请大家先看一下这个图，我们用图来仔细分析！！！！！！！！！！！！！！！！！！！

         

相信大家只要有一点网络基础都可以很容易就看懂

看到这个图接下来就会有一些问题：比如为什么是三次握手，可不可以是两次，或者四次，四次挥手可以是三次吗等等一系列问题，我们接下来会一一解答

—————————————————————————————————————————————————————————

1》首先呢：我们来分析这样一个问题：为什么TCP不可以是两次握手呢？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

两次握手的情景应该是这样的：client 给sever发送SYN，sever收到SYN返回ACK

在谢希仁版的《计算机网络》有这样一个例子：

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留了，以至于延误到连接释放以后的某个时间才到达sever,本来这是一个已经失效的连接请求，但是sever收到此失效的连接请求就会以为是client发出的一个新的连接请求，于是就会向client发出一个新的确认报文段，表示同意链接，假设不采用“三次握手”，那么只要sever发出确认，新的连接就建立好了，由于现在client并没有发出建立连接的请求，因此不会去理睬sever的确认（此时client处于CLOSED状态，接收到任何包都会丢弃），也不会向sever发送ack包，但是sever却以为是新的连接已经建立，

并一直等待client发来数据，这样，sever就会浪费很多资源，采用三次握手的办法可以防止上述现象发生，比如刚才那种情况，client不给sever的确认发送确认包，sever收不到确认，就知道client并没有要求建立连接。

其实两次握手是存在隐患的！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

2》三次握手的原因：

在第四版书中这样讲到：三次握手的目的是防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误，在另外一部书中提到：三次握手的目的是为了解决“网络中存在延迟的重复分组”的问题，其实这两个观点应该表达的是同一个意思

3》为什么不是四次握手：

四次握手的场景无非是client发起连接请求，sever收到syn，发送ack确认报文,severt同时发送同步信号syn，然后client发送ack确认报文，很明显，这是可以合并成三次的

4》TCP三次握手一般会在那个阶段抛出异常：

TCP三次握手如果失败的话，ACK丢失，那么服务器会超时重传syn

如果客户端此时发送数据（客户端发送ACK后，自己认为连接已经建立），那么数据包中自带ack将得到服务器的确认，服务器进入ESTABLISHED状态，双方可以正常通信

如果ACK后的数据包也丢失，服务器收不到客户端的ACK，则重传一定次数后将发送RST报文结束连接

—————————————————————————————————————————————————————————————————————————————

接下来我们再来分析一下四次挥手的场景：

客户端发起请求关闭（FIN），服务器处于close_wait(半关闭状态)，关闭读端，向客户端发送ack确认关闭，此时，服务器可能还有数据要发送，过一段时间，服务器向客户端发送FIN，此时服务器发送完FIN后关闭写端，应用程序结束，客户端收到FIN后，进入TIME_WAIT状态，关闭读端，并向服务器发送ACK确认报文，至此，服务器CLOSED。

！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

三次挥手的场景：

就是其中服务器把发送SYN和ACK放在了一起，这种场景是可能存在的

我们再来分析一下这些状态都有什作用？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

TIME_WAIT：主动关闭端TCP接到FIN后，就会发出ACK回应FIN，并进入TIME_WAIT状态，一般停留2 max segment lifetime（这是TCP/IP必不可少的，也就是解决不了的），等待从本地用户发来的连接中断请求

主要有两个原因：

1》防止上一次连接中的包，迷路后重新出现，影响新连接：经过 2MSL，上一次连接中所有的重复包都会消失（//保证迟来的报被识别并且终止掉）

2》可靠的关闭TCP连接：在主动关闭方发送的最后一个ack,这个ACK很可能会丢失，这时被动方会重新发送FIN，如果这是主动方处于CLOSED状态，就会响应RST而不是ACK，所以主动方处于TIME_WAIT状态，而不是CLOSED状态，TIME_WAIT并不会占用很大的资源的，除非收到攻击。