3 网络断开，一方等待着另一方发送数据
这种情况下，等待数据的一方将一直等待下去。接收方无法直接知道网络已经断开，一般是设置一个超时时间，超时时间到就判断为网络已断开。发送
数据的一方的反应如2所述。
4 一方crash，另一方继续发送/接收数据
这依赖于TCP协议栈对crash的反应。与系统相关性很大，例如：
在windows下：按ctrl+c结束程序，会发送RST段。而在linux下，按ctrl+c结束程序，会调用close。
在wind7下，如果没有调用close而结束程序，TCP会发送RST。而Ubuntu12.10上，则会发送FIN段。
1.crash的一端发送FIN，相当于调用了close
没有crash的一端接收数据，具体的反应与系统有关，例如
linux 3.8.0-29-generic调用recv返回-1，errno被设置为22，Invalid argument，而linux3.3.6-030306-generic调用recv返回0.在TCP内部，调用recv时，发送FIN，终止连接(Linux)。
windows情况以此不同，recv返回0，表示对方调用了shutdown。TCP内部发送一个RST。
但共同点是recv都会立即返回失败。
没有crash的一端发送数据
第一次调用send返回成功，数据会被发送到crash的一端，crash的一端会回应一个RST，再次调用send返回-1， errno被设置为32， Broken pipe。 注意：这会向应用程序发送SIGPIPE信号，你的程序会莫名其妙退出。这是因为程序对SIGPIPE的默认处理就是结束程序。
这是编写服务器程序是最需要注意的一个问题。最简单的处理方法是忽略该信号 -- signal(SIGPIPE,SIG_IGN);
windows下行为是一样的， 不同的是返回的错误是10053 - WSAECONNABORTED， 由于软件错误，造成一个已经建立的连接被取消。
共同点第一次send成功，之后就出错。
2.crash的一端发送RST
没有crash的一端接收数据
调用recv返回-1，errno被设置为104， Connection reset by peer。在TCP内部，当收到RST时，把错误号设为ECONNRESET。
没有crash的一端发送数据
调用send返回-1，errno被设置为104， Connection reset by peer。在TCP内部，当收到RST时，把错误号设为ECONNRESET
3.crash的一端即没发送FIN也没发送RST
没有crash的一端接收数据
调用recv会一直阻塞等待数据到来
没有crash的一端发送数据
重传一定次数后，返回connection time out。
5 一端关闭连接
这种情况与一端crash并发送FIN 的情况相同，参看4.1
总结
上面分析的目的是：当程序出现网络异常时，能够知道问题的原因在哪？
作为开发者，我们主要关心应用层面的返回状态。一般出错的地方是调用connect, recv, send的时候。
下面做一个总结
connect函数返回状态及其原因
recv函数返回状态及其原因
send函数返回状态及其原因
各种不同步的状态，都是通过发送RST来恢复的，理解这些状况的关键在于理解何时产生RST，以及在各种状态下，对RST段如何处理。