对于TCP连接的终止，它的过程与TCP连接建立的过程稍有不同。由于TCP连接没有主次之分，因此任何一方都可以单独地进行关闭。首先进行关闭的一方，发送第一个FIN标志位置位的TCP报文段，开始执行主动关闭，而另一个将执行被动关闭。

假设A发送关闭请求给B，则A为主动关闭方，B为被动关闭方。TCP连接的终止也使用三次握手过程，不过在实际中常修改成四次握手过程，如图6-4所示。

图6-4　TCP连接终止的流程

TCP连接的终止过程对三次握手中的第二步进行了修改。不同之处在于，B可以立即发回一个回复，确认A的关闭请求，但B自身的关闭请求并不能同时发送。因为B在对A发送一个确认的同时，要先将释放连接的请求通知自己的应用程序，而请求应用程序并获得响应的过程可能需要相当长的一段时间。只有当B的应用程序完全释放了连接后，B的TCP实体才能也发送一个FIN报文段给A。而A收到B发来的请求后，继续完成三次握手的第三步，对B的FIN报文段进行确认。

当然，在这里，如果B并不是立即发送对于主动关闭方A的FIN报文段的确认，而是在等待时延后与B的FIN报文段一起发送，那么这样不就又可以回到经典的三次握手模型了吗？事实上，如果A在较长的时间内没有收到确认，会因超时重传A的FIN报文段，而B会因为收到这个重传的FIN报文段，而打乱自己的应用程序关闭过程。所以B对于主动关闭方A的FIN报文段进行立即确认是必要的。

实际上，在TCP连接终止中，因为时延的关系，将三次握手中的第二次握手中的两个信息分成两次独立的过程发送。这样就形成了TCP连接终止貌似需要“四次握手”的过程。(www.daowen.com)

当然，在整个TCP连接终止的过程中，各个报文段和TCP连接建立时一样，仍然采用序号确认的方式。为了突出重点，没有在图中标出。对于主动关闭方来说，关闭连接的过程就是，发送一个FINi（表示FIN置位，序号为i）的报文段，并接收一个ANi的报文段，然后再接收一个FINj的报文段，并发送一个ANj的报文段就万事大吉了。

下面是一个TCP连接终止的实例。在前面的telnet实例中，当连接建立成功后，使用quit命令退出登录，然后对断开过程进行抓包，得到如图6-5所示的结果。

图6-5　TCP连接终止的实际例子

从图中看出，捕获了4个TCP报文段，与TCP连接终止的四次握手相对应。当把quit命令送给服务器时（注意telnet是终端仿真程序，所有命令都在服务器端执行），服务器开始执行主动关闭过程。首先是服务器端发送带有FIN标记的终止命令，接着客户端发回应答，并随后发送客户端带有FIN标记的终止命令。最后服务器端发送对于客户端FIN终止命令的响应，完成四次握手。