小实验:Broken pipe和Connection Reset by Peer

网络开发常遇到

Broken pipe

和

Connection Reset by Peer

两个错误,一直没有深究其差别,只是笼统的知道是对方关闭了socket,做好异常处理就行.这两天刚好组员问到,猛地发现我竟无力解释,决定深究深究

1.基本原理

要说原理嘛,大家都能知道,就是TCP的

三次握手

和

四次挥手

,关于这个网上图形解说一大把,随意搜索,简述

三次握手

client说 SYN, J
server说 SYN, ACK J+1, K
client说 ACK K+1
说人话:client发个随机数J,server返回J+1,并且server发送随机数K,client返回K+1.

四次挥手

client说 FIN M
server说 ACK M+1
server说 FIN N
client说 ACK N+1
说人话:client说结束,发个随机数M,server回答可以,回答M+1.此时server已经知道了即将关闭,但是client不知道server收到没,不会进入关闭动作.为了防止client傻等,server也会说结束,发个随机数N,客户端说太好了,就等你回复呢,回答N+1

2.reset报文发送场景

尝试连接未开放的服务器端口,会被直接返回reset
正常交互的双方,在某个时刻,一方出现异常,会向对方发送reset,通知对方关闭链接
收到TCP报文,但不是TCP连接列表可处理的,直接返回reset(可以理解为直接reset莫名其妙的TCP报文,懒得被干扰)
ack报文丢失,并且重试超过最大尝试次数,会向对方发送reset,让对方关闭连接(可以理解为,网络太差,我放弃了,你就别挣扎了,咋们断开连接吧)

3.glibc怎么说的?

#. TRANS Broken pipe; there is no process reading from the other end of a pipe.
#. TRANS Every library function that returns this error code also generates a
#. TRANS @code{SIGPIPE} signal; this signal terminates the program if not handled
#. TRANS or blocked.  Thus, your program will never actually see @code{EPIPE}
#. TRANS unless it has handled or blocked @code{SIGPIPE}.
#: sysdeps/generic/siglist.h:39 sysdeps/gnu/errlist.c:359
#: sysdeps/unix/siglist.c:39
msgid "Broken pipe"
msgstr "断开的管道"

#. TRANS A network connection was closed for reasons outside the control of the
#. TRANS local host, such as by the remote machine rebooting or an unrecoverable
#. TRANS protocol violation.
#: sysdeps/gnu/errlist.c:614
msgid "Connection reset by peer"
msgstr ""

4.看不懂glibc,那就动手实验

写个socket server, 每次读取客户端数据之后,sleep 2秒(时间随意,别太短,给客户端留时间关闭连接就行).

写个socket client,这个client不干好事,专门向服务器发送一条数据,立即抛异常退出(不走正常的close socket,直接进程退出,故意留给服务器一个坏死的连接)

服务器读完数据后,继续读数据(不断读) 此时,抛异常

Connection reset by peer

socket.error: [Errno 104] Connection reset by peer

服务器读完数据后,连续十次向客户端写数据(读完,就不停写) 此时,抛异常

Broken pipe

IOError: [Errno 32] Broken pipe

5.结论

对方已经关闭连接(可能意外,也可能正常关闭,总之是关闭了)

尝试继续读取,就会

Connection reset by peer

尝试继续写入,就会

Broken pipe

若所言有误,欢迎大神们批评指点