Broken pipe错误终极解释

  • 叙述

    想必或多或少在Java的服务器都会遇到过这种异常,如下图
    
    由于Java偏上层,日常开发接触系统底层的机会偏少,要搞清楚什么原因导致的这种异常,肯定是先要百度google一番。

  • 网络解释云里雾里

    百度+google下,巴拉巴拉还真不少介绍这个错误的文章。欣喜地翻了一篇又一篇,但好像我依旧不明白具体什么原因导致的,云里雾里啊。好吧,举两个例子:
    例子一:
      
    这上边说的好像有点道理,写个代码做个试验验证下吧!直接上代码:
    

//client程序
public static void main(String[] args) {
        try {
            Socket s = new Socket();

            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();
        }
    }

    代码逻辑比较简单吧,client向server发送请求,然后调用close()关闭连接,服务端收到请求打印到控制台,等待10秒(保证client关闭了连接),然后继续向client发数据。看一下控制台的结果:
    
    挺讨厌,就是不报Broken pipe异常。上边的文章,想说相信你真的好难啊!那再看另一篇文章吧
    例二:
      
    这篇文章倒列举了好几种原因,点击了stop按钮?被tomcat停掉?线程机制产生jvm出错?真不知他妈的在说什么,难道就不能再具体点吗?
    这样的文章看不上几篇就烦了。

  • 意外发现

     网上找不到满意的解释,那就硬着头皮翻翻讲解底层一点的书籍吧。还真巧,在一本叫《UNIX网络编程卷1》中获得了一点灵感。如下截图:
    
    如下划线部分所说:向某个已收到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程序
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();
        }
    }
这次果不其然,终于遇到了期盼的异常。不信?那我截图你看:

这下你信了吧。这时你是不是也有点好奇,真的是设置了SO_LINGER产生了RST报文吗?client和server之间到底进行了怎么样的交互呢?
想看清具体client和server期间进行了怎样的交互,那就只好抓包了。就用tcpdump抓包看吧,不管你会不会用,它都是简单方便快捷的好工具,绝对是分析TCP的好帮手。
  • 抓包分析

    就按照上边的实验程序抓个包吧,又大又清晰地截图^_^


    简单解释下:localhost.50387是client端,localhost.cs-auth-svr是server端。
                      第一行:client向server发送SYN请求建立连接
                      第二行:server向client发送SYN也请求建立连接
                      第三行:client向server返回ACK表示同意连接
                      第四行:server向client发送ack?什么?TCP三步握手建立连接怎么变成四步了?啥时候的事啊咋没通知我啊?难道我的mac不在状态手滑了就发出去了?算了先不care这个问题了,知道的可以告诉下我。
                      第五行:看到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程序
public static void main(String[] args) {
        try {
            Socket s = new Socket();
            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());

            s.getOutputStream().write("hello2".getBytes());

            System.out.println("send over");
            System.in.read();
        }catch (Exception e){
            e.printStackTrace();
        }
    }
client调用close向server发送FIN,server向client发送hello,然后收到client的RST报文,继续向client发送hello2。

   上边流程可以看到,client向server发送了RST报文,但是服务器继续写也不会报错,毕竟谁让client之前就向server发送了FIN表示正常关闭呢。

  • 尾言

    分析到这里,Broken pipe错误的原因应该很清楚了吧。但是还需要强调,上边的实验分析过程是在UNIX(MAC)下完成的,这个实验对windows不成立,咱们Java都是跑在linux上可以先不care。Linux应该跟UNIX差不多,当然这里我没有测验,测出差异来的可以分享下。就这样吧

posted @ 2017-03-17 13:05  永志  阅读(164983)  评论(8编辑  收藏  举报