TCP的运输连接管理概述

TCP是面向连接的协议，它基于运输连接来传送TCP报文段

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程

TCP运输连接有以下三个阶段

TCP的运输连接管理就是使运输连接的建立和释放都能正常的进行

TCP建立连接的三次握手（重要）

TCP三次握手使用指令（TCP标记）：

TCP使用三报文握手建立连接

第一次：客户向服务器发送连接请求段，建立连接请求控制段（SYN=1），表示传输的报文段的第一个数据字节的序列号是x，此序列号代表整个报文段的序号（seq=x）；客户端进入 SYN_SEND （同步发送状态）；

第二次：服务器发回确认报文段，同意建立新连接的确认段（SYN=1），确认序号字段有效（ACK=1），服务器告诉客户端报文段序号是y（seq=y），表示服务器已经收到客户端序号为x的报文段，准备接受客户端序列号为x+1的报文段（ack_seq=x+1）；服务器由LISTEN进入SYN_RCVD （同步收到状态）;

第三次：客户对服务器的同一连接进行确认.确认序号字段有效(ACK=1),客户此次的报文段的序列号是x+1(seq=x+1),客户期望接受服务器序列号为y+1的报文段(ack_seq=y+1);当客户发送ack时，客户端进入ESTABLISHED 状态;当服务收到客户发送的ack后，也进入ESTABLISHED状态;第三次握手可携带数据;

为什么要进行三次握手？

主要原因：防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

第一次握手： 客户端向服务器端发送报文，证明客户端的发送能力正常

第二次握手：服务器端接收到报文并向客户端发送报文证明服务器端的接收能力、发送能力正常

第三次握手：客户端向服务器发送报文，证明客户端的接收能力正常

如果两次握手会出现以下情况：

客户端向服务器端发送的请求报文由于网络等原因滞留，未能发送到服务器端，此时连接请求报文失效，客户端会再次向服务器端发送请求报文，之后与服务器端建立连接，当连接释放后，由于网络通畅了，第一次客户端发送的请求报文又突然到达了服务器端，这条请求报文本该失效了，但此时服务器端误认为客户端又发送了一次连接请求，两次握手建立好连接，此时客户端忽略服务器端发来的确认，也不发送数据，造成不必要的错误和网络资源的浪费。

如果采用三次握手的话，就算那条失效的报文发送到服务器端，服务器端确认并向客户端发送报文，但此时客户端不会发出确认，由于客户端没有确认，由于服务器端没有接收到确认，就会知道客户端没有请求连接。

TCP释放连接的四次挥手（重要）

TCP使用四报文挥手释放连接

第一次：客户向服务器发送释放连接报文段，发送端数据发送完毕，请求释放连接（FIN=1），其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态

第二次： 服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT 关闭等待状态

第三次：客户端接收到服务器端的确认请求后，客户端就会进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL后（最长报文寿命），当客户端撤销相应的TCB后，客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成

为什么客户端要等待2MSL？

1.为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。这个ACK 报文段有可能丢失，因而使处在LAST-ACK状态的服务端就收不到对已发送的FIN + ACK报文段的确认。服务端会超时重传这个 FIN+ACK 报文段，而客户端就能在 2MSL 时间内(超时+1MSL传输)收到这人重传的FIN+ACK 报文段。接着客户端重传一次确认，重新启动 2MSL计时器。最后，客户端和服务器都正常进入到CLOSED状态。(简述· 防ack报文美失，Server再次发送Fin报文，一来一最长时间就是2MSL
2.防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。