对于关闭流程，一共有三种情况：客户端主动关闭，服务器端主动关闭，客户端和服务器端同时主动关闭。这里仅仅以客户端主动关闭为例列出下图。
对于关闭流程，服务器端和客户端是对等的地位，其它两种场景处理过程类似。需要注意的是，由于对端是是可以主动关闭的，因此在代码中需要加上被动关闭的响应流程。
看到上述流程，可能有一个疑问：为什么连接和关闭的握手次数不一样？其实，不论是连接还是关闭，客户端和服务器端都是发送了一次请求（SYN/FIN），回应了一次应答（ACK），它们是对称的。但是，在连接的时候服务器端的请求和应答是在一次握手中同时完成的，而关闭的时候却是分两次完成的，所以就造成了连接和关闭的握手次数不对称。
现在，新问题又来了：为什么连接时复用一次握手，而关闭的时候不复用握手？这个则是因为连接和关闭的行为不是一样所造成的。
前面只考虑了理想的情况，在实际的过程中，可能还需要处理一些异常操作，如下则是一个完成的TCP连接的状态迁移图。
如前所述，建立或关闭一个连接时需要三或四步的，在这个过程中，TCP连接则会处于一个半打开或半关闭状态。例如，前面状态图中的FIN_WAIT_1和FIN_WAIT_2就是半关闭状态。
一般来说，半连接只是一个暂停的过程。但是，在一些异常的情况的时候（如远端主机故障）的时候常常会造成半关闭连接，由于Tcp连接处于半打开或半关闭状态的时候，仍然会占用相应的端口资源，尤其对于http之类的海量服务来说，会造成大量端口被占用，会造成资源的浪费。
另外，有的程序也针对Tcp协议的这一特征来恶意进行网络攻击。例如，对于一个服务器，大量的恶意客户端建立连接后，既不发请求，也不close套接字，这种情况下服务器如何保护自己呢。因为如果听之任之的话，大量的恶意连接会耗尽服务器的可用描述符，导致服务器不能服务。就算服务器主动close，如果客户端不close的话，那么这个连接还是不能完全释放。对于服务器来说，需要增加相应的机制进行半连接的处理。
原文：http://www.cnblogs.com/wjoyxt/p/3719659.html