小實驗:Broken pipe和Connection Reset by Peer
阿新 • • 發佈:2019-01-10
網路開發常遇到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
若所言有誤,歡迎大神們批評指點