TCP连接的建立（三次握手）与释放（四次挥手）

TCP连接的建立采用的是客户服务器方式，主动要求建立连接的为客户端，被建立连接的成为服务器。

1.TCP连接的建立

在讨论建立连接的过程中，先上图这样会帮助理解，如下图所示：

从上图可知，B作为服务器作为被建立连接方，在建立连接之前，客户端和服务端均处于关闭状态。其中服务器端先创建控制传输块TCB，此时服务器端处于监听状态（即时刻监听客户端发送的连接请求）。

客户端A的TCP进程也会创建控制传输块，然后会向服务器端发送请求连接报文段，此时同步位SYN=1，同时初始序号为seq=x，其中SYN=1表示不携带数据传输，但是需要占用一个序号。此时客户端为SYN-SENT(同步已发送)状态。

服务器端接收到客户端的请求连接之后，如果同意建立连接，则会向客户端发送确认报文，其中，SYN=1,ACK=1,确认号为ack=x+1，同时服务器端也会寻找一个初始序号seq=y。之后服务器端会处于SYN-RCVD（同步已接收）状态。

客户端收到服务端的确认后，会再向服务器端发送确认。其中确认报文中ACK=1,seq=x+1，ack=y+1。此时TCP连接已创建，客户端则为ESTABLISHED（连接已建立）状态。

当服务器端收到客户端的确认后，服务器端也会处于ESTABLISHED（连接已建立）状态。

此时三次握手已成功完成。或许此时的你会思考这样一个问题那就是：以我的思路来的话进行两次握手就可以建立连接了啊，为什么非要进行三次握手呢？其实建立三次连接的主要原因是为了防止已失效的连接请求，又再次发起请求，从而造成资源的浪费。

比如在客户端向服务器端发送连接请求的时候，其中由于网络的延迟，导致此次请求延缓，此时客户端会再次请求，并且后次请求成功完成，但是第一次的请求之后又再次复活，请求到达了服务器端，此时的服务器会认为此次连接为新的请求，同意并发回确认，而客户端则不认账，这样服务器端则会一直等待客户端的响应，导致资源的占用从而浪费资源。

2.TCP连接的释放

既然存在TCP的连接，那必然存在TCP连接的释放问题，关于连接的释放客户端和服务器端均可以进行释放连接的请求，废话不多说直接上图解释，如下图所示：

从图中可以看出我们依然将A作为连接释放的发起方，起初当然是A,B端在进行着数据的传输，即ESTABLISHED状态，此时若A端已经将数据传输完了之后，便会发起连接释放的请求，此时FIN（终止位）=1，初始序号为seq=u。其中FIN不携带数据也需要消耗一个序号位。其中u的值为上次传输的报文段数据的最后一个字节加1.请求发送之后，A端便处于FINWAIT1（终止等待1）状态，此时A端已经不进行数据传输了，但是会接收传过来的数据。

当B端接收到A端的请求时，当然会对请求做出相应，首先会通知上层应用接收到了断开连接的请求，并做好准备。并同时会向A端做出确认，发送报文段，ACK=1,ack=u+1，seq=v。此时B端会处于CLOSEWAIT(关闭等待)状态，而对应的A端则会处于FINWAIT2（终止等待）状态。在整体上该链接处于一个半关闭状态，即A端关闭，B端未关闭，B端依然会进行数据的传输。

当B端已经将要传输的数据传输完毕时，上层应用则会通知B端，可以断开链接了，数据已经传输完了。此时B端则会向A端发送断开连接报文段，即FIN=1,ACK=1,seq=w，ack=u+1,之后B端处于LASTACK(最终确认)状态。

当A端收到B端的断开连接报文段的时候，必须要向B端发送确认报文段，即ACK=1，ack=w+1，seq=u+1.之后A端进入TIMEWAIT（时间等待）状态，一般时间为2MSL（两个最长寿命报文段），而B端接收到确认报文后则会进入连接关闭状态，A端在时间过后也会进入关闭状态，此时四次挥手成功，连接断开成功。

最后大家可能会有疑问，为什么最后要等到2MSL之后A端才断开连接？

这样是为了A端最后一个确认报文段能够顺利到达B端，即使没有顺利达到，由于超时重传机制，B端会再次向A端发送报文段，此时A端会向B端再次发送确认报文段，防止报文段的丢失。还有一个原因是，预防建立连接中出现的无效请求，在经过2MSL时间后，所有的连接均会消失。

至此，TCP连接的建立与释放已讲解完毕，希望能够帮助到大家，若有错误的地方，希望大家能够给出指正！