参考博客
在可靠的TCP网络通信中，客户端和服务器端通信建立连接的过程可简单表述为三次握手(建立连接的阶段)和四次挥手(释放连接阶段)，下图是这两个阶段的一个完整的表述：
其状态图可以表示为，
在TCP连接建立的时候，存在一个如下的有限状态机：
在状态转化图中，其中客户端的状态转移用带箭头的粗实线表示，服务器端的状态转换用带箭头的粗虚线表示。带箭头的细线表示一些不常见的事件，如复位、同时打开、同时关闭等。关于有限状态图可以参考博客http://blog.csdn.net/lycb_gz/article/details/8515062，里面的细节都将的很清楚；如果要深入理解TCP连接建立和释放的过程就需要结合socket编程里的connect()，socket()，bind()，listen()，send()，close()等函数。
从图中看到，三次握手对应的Berkeley Socket API：connect, listen, accept 3个，connect用在客户端，另外2个用在服务端。对于TCP/IP protocol stack来说，TCP层的tcp_in&tcp_out也参与这个过程。我们这里只讨论这3个应用层的API干了什么事情。
（1） connect()
发送了一个SYN，收到Server的SYN+ACK后，代表连接完成。发送最后一个ACK是protocol stack,tcp_out完成的。
（2）listen()
在server这端，准备了一个未完成的连接队列，保存只收到SYN_C的socket结构；还准备了已完成的连接队列，即保存了收到了最后一个ACK的socket结构。
（3）accept()
应用进程调用accept的时候，就是去检查上面说的已完成的连接队列，如果队列里有连接，就返回这个连接；如果没有，即空的，blocking方试调用，就睡眠等待；客户端调用connect函数之后就发起完成TCP的三次握手，客户端调用connect后，由内核中的TCP协议完成TCP的三次握手，close操作会完成四次挥手。
其中accept发生在三次握手之后。
第一次握手：客户端发送syn包(syn=j)到服务器。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个ASK包（ask=k）。
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)。
三次握手完成后，客户端和服务器就建立了tcp连接。这时可以调用accept函数获得此连接。
我们如何判断有一个建立链接请求或一个关闭链接请求：
TIME_WAIT
TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态，系统会在 TIME_WAIT 状态下等待 2MSL（maximum segment lifetime ）后才能释放连接（端口）。通常约合 4 分钟以内。TIME_WAIT 状态等待 2MSL 的意义：
1、确保连接可靠地关闭； 即防止最后一个ACK丢失。
2、避免产生套接字混淆（同一个端口对应多个套接字）。
为什么说可以用来避免套接字混淆呢？一方close发送了关闭链接请求，对方的应答迟迟到不了(例如网络原因)，导致TIME_WAIT超时，此时这个端口又可用了，我们在这个端口上又建立了另外一个socket链接。 如果此时对方的应答到了，怎么处理呢？其实这个在TCP层已经处理了，由于有TCP序列号，所以内核TCP层，就会将包丢掉，并给对方发包，让对方将sockfd关闭。所以应用层是没有关系的。即我们用socket API编写程序，就不用处理。
注意:TIME_WAIT是指操作系统的定时器会等2MSL，而主动关闭sockfd的一方，并不会阻塞。（即应用程序在close时，并不会阻塞）。当主动方关闭sockfd后，对方可能不知道这个事件。那么当对方(被动方)写数据，即send时，将会产生错误，即errno为: ECONNRESET。服务器产生大量 TIME_WAIT 的原因：(一般我们不这样开发Server，但是web服务器等这种多客户端的Server，是需要在完成一次请求后，主动关闭连接的，否则可能因为句柄不够用，而造成无法提供服务。)服务器存在大量的主动关闭操作，需关注程序何时会执行主动关闭（如批量清理长期空闲的套接字等操作）。一般我们自己写的服务器进行主动断开连接的不多，除非做了空闲超时之类的管理。(TCP短链接是指，客户端发送请求给服务器，客户端收到服务器端的响应后，关闭链接)。
CLOSE_WAIT
CLOSE_WAIT 是被动关闭 TCP 连接时产生的，如果收到另一端关闭连接的请求后，本地(Server端)不关闭相应套接字就会导致本地套接字进入这一状态。
(如果对方关闭了，没有收到关闭链接请求，就是下面的不正常情况)按TCP状态机，我方收到FIN，则由TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果我方不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。如果存在大量的 CLOSE_WAIT，则说明客户端并发量大，且服务器未能正常感知客户端的退出，也并未及时 close 这些套接字。(如果不及时处理，将会出现没有可用的socket描述符的问题，原因是sockfd耗尽)。
正常情况下:一方关闭sockfd，另外一方将会有读事件产生， 当recv数据时，如果返回值为0，表示对端已经关闭。此时我们应该调用close，将对应的sockfd也关闭掉。
不正常情况下:一方关闭sockfd，另外一方并不知道，(比如在close时，自己断网了，对方就收不到发送的数据包)。此时，如果另外一方在对应的sockfd上写send或读recv数据。
recv时，将会返回0，表示链接已经断开。
send时， 将会产生错误，errno为ECONNRESET。
3.close()函数和shutdown()函数的区别:
首先我们来看看close()函数的原型:
头文件：#include <unistd.h>
定义函数：int close(int fd);
close 一个套接字的默认行为是把套接字标记为已关闭，然后立即返回到调用进程，该套接字描述符不能再由调用进程使用，也就是说它不能再作为read或write的第一个参数，然而TCP将尝试发送已排队等待发送到对端的任何数据，发送完毕后发生的是正常的TCP连接终止序列。在多进程并发服务器中，父子进程共享着套接字，套接字描述符引用计数记录着共享着的进程个数，当父进程或某一子进程close掉套接字时，描述符引用计数会相应的减一，当引用计数仍大于零时，这个close调用就不会引发TCP的四路握手断连过程。如果是主动调用close()则会发起内核TCP协议的四次挥手，断开连接.
再来看看shutdown()函数的原型：
int shutdown(int sockfd,int howto); //返回成功为0，出错为-1.
该函数的行为依赖于howto的值
1.SHUT_RD：值为0，关闭连接的读这一半。
2.SHUT_WR：值为1，关闭连接的写这一半。
3.SHUT_RDWR：值为2，连接的读和写都关闭。
终止网络连接的通用方法是调用close函数。但使用shutdown能更好的控制断连过程（使用第二个参数）。
当调用SHUT_RD的时候，套接字sockfd的读端将会关闭，不能调用接受数据的函数，这对于协议层没有影响。然和当前在sockfd读端的数据缓冲区的数据都会被舍弃掉，进程将不能对该套接字发起读操作，对TCP套接字调用SHUT_RD将会导致协议层将接收到的数据无声的丢掉！！！如果想要继续接受数据都要重置链接；
当调用SHUT_WR的时候，对于tcp套接字来说，这意味着会在所有数据发送出并得到接受端确认后产生一个FIN包。而此时套接字的状态会由ESTABLISHED变成FIN_WAIT_1，然后对方发送一个 ACK包作为回应，套接字又变成FIN_WAIT_2。如果对方也关闭了连接则对方会发出FIN，我方会回应一个ACK并将套接字置为 TIME_WAIT。
4.如何判断socket连接断开：
非阻塞模式，如果暂时没有数据，返回的值也会是<=0的，如果用阻塞模式的话，返回<=0的值是可以认为socket已经无效了。当使用 select()函数测试一个socket是否可读时，如果select()函数返回值为1，且使用recv()函数读取的数据长度为0 时，就说明该socket已经断开。经过代码试验，如果进程受到一些信号时，例如：EINTR，recv()返回值小于等于0时，这是就需要判断 errno是否等于 EINTR , 如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的，socket连接还是正常的，不应close掉socket连接。如果write，我觉得还有一些情况需要考虑，那就是写的太快的时候，有可能buffer写满了，errno是EAGAIN，可以根据实际需要，如果errno是EAGAIN的话，再写几次。