TCP的连接与释放

TCP连接：

TCP连接的建立采用客户服务器的方式，主动发起连接的为客户端进程（客户），被动接受连接的为服务端进程（服务器）。
TCP的连接建立：

第一次握手：主机A发送握手信号syn＝1和seq=x（随机产生的序列号）的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送syn=1，ack=x（x是主机A的Seq）+1，以及随机产生的确认端序列号seq=y的包；

第三次握手：主机A收到后检查ack是否正确（ack=x+1） ，即第一次发送的seq+1，若正确，主机A会再发送ack=y+1，以及随机序 列号seq=z，主机B收到后确认ack值则连接建立成功；

开始传送数据

A为什么最后要发送一次确认？
     为防止已失效的连接请求报文段突然又传送到了B。
     A发出请求--->但是连接请求报文丢失而未收到确认--->A重传------>收到后建立了连接
     数据传输完毕之后--->释放连接----->A发送了两个请求
     现在如果A第一遍发出的连接请求没有丢失，而是在某一个节点滞留的时间过长，然后过一段时间之后，这个连接请求到了B，B接收到之后，认为A有发送了一次连接请求，于是发出确认报文段，同意连接，如果A不确认，那么B发出之后，连接就直接建立了。
     但是A没有发出连接的请求，所以对于B发来的确认不鸟它，只是B此时认为连接建立了，B傻傻的等着A发来消息。
     这一等，大好的资源就这么的浪费了。你说气人不？所以必须A发送最后一次确认。这样才会和谐。

//中 间就是巴拉巴拉的传输数据-------------------------~~~~

TCP的连接释放

 数据传输结束之后，通信的双方都可以进行释放连接。

     A先说（发送连接释放报文段），行了，不传了，然后TCP关了---->然后A就进入 FIN-WAIT-1状态，等着B确认
     B收到连接释放报文段之后----->发个确认：A你真的要分吗？   ----->然后继续傻等（CLOSE－WAIT状态）
     //这时处于半关闭状态，A没啥可发的了，但B如果还不死心的话，A仍然要接收，不能直接拍屁股走人吧~·
     //等于是B---->A还没有关闭
     A接受到B的确认之后，进入（FIN-WAIT-2）状态，等着B彻底死心（B发出连接释放报文段）
     B如果死心了---->发出连接释放报文段（将FIN置1）  ---->B进入 LAST-ACK ，最后确认状态，等A的确认
     A收到之后，必须给B发一个交代（确认），就这样吧
     注意，这个时候还没有彻底的断掉，还有一段温存期，等待时间抹平曾经的一切（TIME-WAIT），等待一定的时间，四分钟之后，不过现在的网用不了这么长时间，彻底Over，然后等着焕发下一春就行。

 为啥要等待 WAIT-TIME 呢？
     第一：确保A的最终诀别到B的手里，万一丢了，B岂不白白的浪费了大好的资源，B收不到确认，会再次发送消息给A：你确定吗？之类的, 如果这时候A已经彻底关闭，那就只有B做傻事了
     第二：防止连接时发生的<已失效的连接请求报文段跑出来>

以上就是TCP连接释放的四次挥手，好聚好散！Over