TCP之种种连接异常

1. connect出错：

(1) 若TCP客户端没有收到syn分节的响应，则返回ETIMEOUT错误；调用connect函数时，内核发送一个syn，若无响应则等待6s后再发送一个，若仍然无响应则等待24s后在发送一个，若总共等待75s后仍未收到响应则返回本错误；

(2) 若对客户的syn响应是rst，则表明该服务器在我们指定的端口上没有进程在等待与之连接，这是一种硬错误，客户一收到rst马上返回ECONNREFUSED错误；

(3) 若客户发送的syn在中间的某个路由器上引发了目的不可达icmp错误，则认为是一种软错误。客户主机内核保存该消息，并按照第一种情况的时间间隔继续发送syn，咋某个规定时间后仍未收到响应，则把保存的消息作为EHOSTUNREACH或者ENETUNREACH错误返回给进程；

2. accept返回前连接中止：

在比较忙的服务器中，在建立三次握手之后，调用accept之前，可能出现客户端断开连接的情况；如，三次握手之后，客户端发送rst，然后服务器调用accept。posix指出这种情况errno设置为CONNABORTED;

注意Berkeley实现中，没有返回这个错误，而是EPROTO，同时完成三次握手的连接会从已完成队列中移除；在这种情况下，如果我们用select监听到有新的连接完成，但之后又被从完成队列中删除，此时如果调用阻塞accept就会产生阻塞；

解决办法：

(1) 使用select监听套接字是否有完成连接的时候，总是把这个监听套接字设置为非阻塞；

(2) 在后续的accept调用中忽略以下错误，EWOULDBLOCK(Berkeley实现，客户中止连接), ECONNABORTED(posix实现，客户中止连接), EPROTO(serv4实现，客户中止连接)和EINTR(如果有信号被捕获)；

3. 服务器进程终止(崩溃)：

在客户端和服务器端建立连接之后，使用kill命令杀死服务器进程，进程终止会关闭所有打开的描述符，这导致了其向客户端发送了一个FIN，而客户端则响应了一个ack，这就完成了tcp连接终止的前半部分，只代表服务器不在发送数据了；但是客户端并不知道服务器端已经终止了，当客户端向服务器写数据的时候，由于服务器进程终止，所以响应了rst，如果我们使用select等方式，能够立即知道当前连接状态；如下：

(1) 如果对端tcp发送数据，那么套接字可读，并且read返回一个大于0的值(读入字节数)；

(2) 如果对端tcp发送了fin(对端进程终止)，那么该套接字变为可读，并且read返回0(EOF)；

(3) 如果对端tcp发送rst(对端主机崩溃并重启)，那么该套接字变为可读，并且read返回-1，errno中含有确切错误码；

4. sigpipe信号：

当一个进程向某个收到rst的套接字执行写操作的时候，内核向该进程发送一个SIGPIPE信号，该信号的默认行为是终止进程，因此进程必须捕获它以免不情愿的被终止；

不论进程是捕捉了该信号并从信号处理函数中返回，还是简单忽略该信号，写操作都讲返回EPIPE错误；

5. 服务器主机崩溃：

建立连接之后，服务器主机崩溃，此时如果客户端发送数据，会发现客户端会在一定时间内持续重传，视图从服务器端收到数据的ack，当重传时间超过指定时间后，服务器仍然没有响应，那么返回的是ETIMEDOUT；

6. 服务器主机不可达：

建立连接之后，服务器主机未崩溃，但是由于中间路由器故障灯，判定主机或网络不可达，此时如果客户端发送数据，会发现客户端会在一定时间内持续重传，视图从服务器端收到数据的ack，当重传时间超过指定时间后，服务器仍然没有响应，那么返回的是EHOSTUNREACH或ENETUNREACH；

7. 服务器主机崩溃后重启：

当服务器主机崩溃重启后，之前所有的tcp连接丢失，此时服务器若收到来自客户端的数据，会响应一个rst；客户端调用read将返回一个ECONNRESET错误；

8. 服务器主机关机：

系统关机时，init进程给所有进程发送SIGTERM信号，等待固定的时间，然后给所有仍在运行的进程发送SIGKILL信号，我们的进程会被SIGTERM或者SIGKILL信号终止，所以与前面服务器进程终止相同，进程关闭所有描述符，并发送fin，完成服务器端的半关闭；

转自：http://www.cnblogs.com/wanpengcoder/p/5356776.html