socket中close发生的事情,RST,pipe信号错误

1、server端close之后，client端write，导致server端发送RST（服务器关闭套接字）：对方已经关闭或者异常终止，但是client端，不知道，这个成为半打开

当server端close套接字的时候，假设此时server端的接受缓冲区没有数据了。则close发送的是FIN分节，client端如果收到FIN之后，调用read函数，是返回0的，因为FIN的接收，表明client端以后再无数据可以接收，因为对放发来FIN，就表明对方不在发送数据了。

然后client发送应答ack报文，表明收到FIN报文，server收到ack报文之后，就进去了FIN_WAIT_2阶段，根据tcp协议，向一个 FIN_WAIT2 状态的服务 TCP（已 ACK 响应 FIN 分节）写入数据不成问题，所以此时我们可以在client端调用write函数，写入client端的发送缓冲区，由tcp连接，发送到server的接收缓冲区。但是此时，由于server端已经关闭了socket，所以此时的接收缓冲区的内容都被抛弃，同时server端返回RST

收到RST的client端，如果调用read函数，读取，是返回RST错误的。。

如果我们的client对这个RST错误，不采取处理，继续调用write，会发生epipe错误。

这种情况一般发生在客户进程不理会（或未及时处理）Socket 错误，继续向服务 TCP 写入更多数据时，内核将向客户进程发送 SIGPIPE 信号，该信号默认会使进程终止（此时该前台进程未进行 core dump）。结合上边的 ECONNRESET 错误可知，向一个 FIN_WAIT2 状态的服务 TCP（已 ACK 响应 FIN 分节）写入数据不成问题，但是写一个已接收了 RST 的 Socket 则是一个错误。

接收到RST包的一端采取的操作：

异常关闭一个连接对应用程序来说有两个优点：

（1）丢弃任何待发的已经无意义的 数据，并立即发送RST报文段；

（2）RST的接收方利用关闭方式来 区分另一端执行的是异常关闭还是正常关闭（通过read操作的返回值，正常的返回读取字节或者堵塞，RST的返回错误）

值得注意的是RST报文段不会导致另一端产生任何响应（不用发送ack响应分节），另一端根本不进行确认。收到RST的一方将终止该连接。程序行为如下：

阻塞模型下，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层对端RST。

非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错RST。

2、server端close套接字，此时server端的接收缓冲区还有数据，没有被读取，则此时server端发送RST给client端，接收缓冲区的数据丢失，服务器server提前关闭socket

3、到不存在的端口连接请求

client端发起连接请求，发送了SYN报文，由于server端的套接字没有listen端口，则向cllient发送RST

4、同时主动打开connect（）

5、同时主动关闭close()