在处理Java相关工程时，你肯定遇到过这种异常：
java.net.SocketException: Broken pipe
于Java偏上层，日常开发接触系统底层的机会偏少，要搞清楚什么原因导致的这种异常，肯定是先要百度Goole一番了。
一搜，晚上真不少介绍这个错误的文章，欣喜地翻了一篇又一篇，但好像我依旧不明白具体什么原因导致的，云里雾里。
网上找不到满意的解释，那就硬着头皮翻翻讲解底层一点的书籍。
还真巧，在一本叫《UNIX网络编程卷1》中获得了一点灵感。
image.png
如下划线部分所说：向某个已收到RST的连接执行写操作时，将会返回EPIPE错误。
EPIPE！PIPE！第一百零一灵感告诉我这与Broken pipe错误有关系。
知识准备之RST报文
终止一个TCP连接的正常方式是发送FIN。
在发送缓冲区中所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失，但我们有时也可能发送一个RST报文段而不是FIN来中途关闭一个连接，这称为异常关闭。
现在知道RST报文的作用了，那就在大致列一下出现RST报文的场景：
1.connect一个不存在的端口；
2.向一个已经关掉的连接send数据；
3.向一个已经崩溃的对端发送数据（连接之前已经被建立）；
4.close(sockfd)时，直接丢弃接收缓冲区未读取的数据，并给对方发一个RST，这个是由SO_LINGER选项来控制的；
5.a重启，收到b的保活探针，a发rst，通知b。
模拟出现RST报文的场景，最简单地方法感觉就是使用SO_LINGER选项来控制，那接下来再了解下SO_LINGER选项。
知识准备之SO_LINGER参数
SO_LINGER是用来设置函数close()关闭TCP连接时的行为。
缺省close()的行为是，如果有数据残留在socket发送缓冲区中则系统将继续发送这些数据给对方，等待被确认，然后返回。
设置此选项并把超时时间设置为零，调用close()会立即关闭该连接，通过发送RST分组(而不是用正常的FIN|ACK|FIN|ACK四个分组)来关闭该连接。至于发送缓冲区中如果有未发送完的数据，则丢弃。
知识准备的差不多了，好了，准备开森的实验了。
实验验证
这里再将实验代码贴一份，跟上边的实验代码唯一的区别就是这里设置了SO_LINGER选项。
码逻辑比较简单吧，client向server发送请求，然后调用close()关闭连接，服务端收到请求打印到控制台，等待10秒(保证client关闭了连接)，然后继续向client发数据。
//client程序
public static void main(String[] args) {
try {
Socket s = new Socket();
s.setSoLinger(true,0);//设置调用close就发送RST
s.connect(new InetSocketAddress("127.0.0.1",3113));
OutputStream os = s.getOutputStream();
os.write("hello".getBytes());
s.close();
System.in.read();//防止程序退出
}catch (Exception e){
e.printStackTrace();
}
}
//server程序
public static void main(String[] args) {
try {
ServerSocket ss = new ServerSocket(3113);
Socket s = ss.accept();
InputStream is = s.getInputStream();
byte[] buf =new byte[1024];
int len = is.read(buf);
System.out.println("recv:"+new String(buf,0,len));
Thread.sleep(10000);
s.getOutputStream().write("hello".getBytes());
System.out.println("send over");
System.in.read();
}catch (Exception e){
e.printStackTrace();
}
}
看一下控制台的结果：
image.png
这次果不其然，终于遇到了期盼的异常。
你是不是也有点好奇，真的是设置了SO_LINGER产生了RST报文吗？
Client和Server之间到底进行了怎么样的交互呢？
想看清具体client和server期间进行了怎样的交互，那就只好抓包了。
就用tcpdump抓包看吧，不管你会不会用，它都是简单方便快捷的好工具，绝对是分析TCP的好帮手。
image.png
localhost.50387是client端，localhost.cs-auth-svr是server端。
第一行：client向server发送SYN请求建立连接
第二行：server向client发送SYN也请求建立连接
第三行：client向server返回ACK表示同意连接
第四行：server向client发送ack?什么？TCP三步握手建立连接怎么变成四步了？
第五行：看到Flags [P.]了吗，P是push的意思就是发数据，这里就是client向server发送数据，length 5就是client发送的hello的长度
第六行：这里是server向client发送ac表示已经接收了hello
第七行：这是重点，Flags[R.],R就代表RST报文，client向server发送了RST报文。
收到RST包，继续向对方写数据就一定会报Broken pipe吗？还真的被我试出个不会的情况。
这个特殊情况也很好理解，按照上边说的：向一个已经关掉的连接send数据时会收到对方的RST报文，此时再向其sends数据就不会报Broken pipe。
client向server发送了RST报文，但是服务器继续写也不会报错，毕竟谁让client之前就向server发送了FIN表示正常关闭呢。
网友评论