TCP是面向链接的协议（计算机网络——运输层），每个运输链接包括链接创建、数据传送和链接释放。运输链接的管理就是使运输链接的创建和释放都能正常进行。TCP链接采用的是CS模式，主动发起的链接的应用进程叫客户（Client），被动等待链接的应用进程叫服务器（Server）。在TCP链接创建过程当中须要解决如下三个问题：缓存

（1）要使每一方可以通知对方的存在；服务器

（2）要容许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项等）；网络

（3）可以对运输实体资源（如缓存大小、链接表中的项目等）进行分配。spa

1、链接创建——三次握手

TCP链接创建的过程如上，主机A是客户应用进程，B运行服务器应用程序。初始状态，两端的TCP进程都属于CLOSED （关闭）状态。B的TCP服务器先建立传输控制块TCB，准备接受客户进程的请求，而后就处于LISTEN（监听）状态，等待客户请求。.net

（1）第一次握手：A主动打开链接， 建立传输控制模块TCB，而后向B发出请求报文段。TCP报文段首部的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。此时，TCP客户进程处于同步已发送（SYN-SENT）状态。计算机网络

（2）第二次握手：B收到请求报文段后，若是赞成链接，则向A发送确认。确认报文段中，SYN=1，ACK=1，确认号是ack=x+1，同时也为本身选择一个初始序号seq=y。这个报文段也不能携带数据，一样要消耗掉一个序号。此时TCP服务进程处于同步收到（SYN-RCVD）状态。blog

（3）第三次握手：TCP客户程序收到B的确认后，再次向B发送确认。确认报文段ACK=1，确认号ack=y+1，而本身的序号seq=x+1。TCP规定，ACK报文段能够携带数据，但若是不携带数据则不消耗序号。此时，TCP链接已经创建，A进入已创建链接（ESTABLISHED）状态。进程

B收到A的确认后，也进入已创建链接（ESTABLISHED）状态。资源

疑问：为什么A（客户端应用进程）还要再发一次确认呢？（第三次握手）get

考虑以下一种场景：A向B发送链接请求，可是因为某种缘由（在某个网络节点长时间滞留）致使在A和B以前的一次TCP链接已经释放后的某个时间，该链接请求才到达B。若是没有第三次握手，B在收到这个迟到的链接请求后，会误认为A又请求创建链接，就又会创建链接。假定有第三次握手，即使以前的某个链接请求到达B，只要B没有收到A的第三次握手确认，TCP链接就不会创建。

2、链接释放——四次挥手

数据传输结束后，双方均可以释放链接。 如今A和B都处于ESTABLISHED状态。

（1）第一次挥手：A的应用进程先先其TCP发送链接释放报文段，并中止发送数据，主动关闭链接。A把链接释放报文段首部的终止控制位FIN=1，序号seq=u（序号等于前面已经传送过的数据的最后一个字节的序号+1）。此时A进入终止等待1（FIN-WAIT-1）状态。TCP规定，FIN报文段不能携带数据，也消耗一个序号。

（2）第二次挥手：B收到链接释放报文段后发出确认，确认号ack=u+1，序号seq=v（序号等于前面已经传送过的数据的最后一个字节的序号+1）。此时B进入关闭等待（CLOSE-WAIT）状态。TCP服务进程此时应通知高层应用进程，A到B这个方向的链接就释放了，此时TCP链接处于半关闭状态。即A已经没有数据要发送了，但若是B要发送数据，A仍要接收。即，B到A方向的链接并未关闭。A收到B的确认后，进入终止等待2（FIN-WAIT-2）状态，等待B发出链接释放报文段。

（3）第三次挥手：若是B已经没有数据发送给A，其应用进程将通知链接释放。B发出的链接释放报文段FIN=1，序号seq=w（半关闭状态B可能又发送了一些数据给A，若是没有，则序号seq=v+1），B必须重复发送已经发送过的确认号ack=u+1（由于B收到的A的报文段的最后一个序号始终是u）。此时B进入最后确认（LAST-ACK）状态，等待A的确认。

（4）第四次挥手：A收到B的链接释放报文段后，必须发出确认。ACK=1，确认号ack=w+1，本身的序号seq=u+1。而后本身进入时间等待（TIME-WAIT）状态。通过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A进入CLOSED状态。

MSL指的是最长报文段寿命（Maximum Segment Life），RFC793建议为2分钟。2MSL即4分钟。

疑问：为何A在TIME-WAIT状态必须等待2分钟呢？

一方面是为了保证A发送的最后一个ACK报文段可以到达B。这个ACK报文段有可能丢失，所以处于LAST-ACK状态的B收不到对本身以前已经发送的ACK和FIN报文段的确认。B会超时重传这个ACK+FIN报文段，A就会再次发送一次ACK确认报文段，再启动计时2MSL。A发送完最后一个确认ACK后当即关闭TCP链接，若是ACK报文丢失，A收不到B重传的ACK+FIN，也就不会重传ACK确认报文段，这样B应用进程的TCP链接就没法关闭。

另外一方面，是防止上一节三次握手过程当中的无效的因为网络缘由迟到的链接请求报文出如今本链接过程当中。A发送完最后一个ACK确认报文段后，等待2MSL时间，就会使本链接持续时间内所产生的全部报文段都从网络中消失。