我们先熟悉一下 tcp 三次握手和四次挥手：

reset报文发送场景

RST的标志位，这个标识为在如下几种情况下会被设置，以下是我了解的情况，可能还有更多的场景，没有验证：

1. 当尝试和未开放的服务器端口建立tcp连接时，服务器tcp将会直接向客户端发送reset报文；

2. 双方之前已经正常建立了通信通道，也可能进行过了交互，当某一方在交互的过程中发生了异常，如崩溃等，异常的一方会向对端发送reset报文，通知对方将连接关闭；

3. 当收到TCP报文，但是发现该报文不是已建立的TCP连接列表可处理的，则其直接向对端发送reset报文；

4. ack报文丢失，并且超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。

“Connection reset by peer”和“Connection reset”是有区别的：

服务器返回了“RST”时，如果此时客户端正在从Socket套接字的输出流中读数据则会提示Connection reset”；

服务器返回了“RST”时，如果此时客户端正在往Socket套接字的输入流中写数据则会提示“Connection reset by peer”。

Connection reset Connection reset by peer

“connection reset by peer”和”broken pipe”出现的场景：

1）往一个对端已经close的通道写数据的时候，对方的tcp会收到这个报文，并且反馈一个reset报文。

当收到reset报文的时候，继续做select读数据的时候就会抛出Connect reset by peer的异常。

2）当第一次往一个对端已经close的通道写数据的时候会和上面的情况一样，会收到reset报文。

当再次往这个socket写数据的时候，就会抛出Broken pipe了 。

根据tcp的约定，当收到reset包的时候，上层必须要做出处理，调用将socket文件描述符进行关闭，其实也意味着pipe会关闭，因此会抛出这个顾名思义的异常。

参考

Orderly Versus Abortive Connection Release in Java

https://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html

关于Connection reset原因分析和解决方案

https://my.oschina.net/xionghui/blog/508758

从tcp原理角度理解Broken pipe和Connection Reset by Peer的区别

http://lovestblog.cn/blog/2014/05/20/tcp-broken-pipe

对TCP重传的进一步认识

http://blog.sina.com.cn/s/blog_4d276ac901011ee7.html

https://www.cnblogs.com/YXBLOGXYY/p/14243259.html