转载:https://www.cnblogs.com/kkshaq/p/4456453.html
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()