在linux網絡編程中，我們經常會遇到這兩個錯誤。這兩個錯誤出現的情況有些類似，又有些不同。先看下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 ""
broken pipe：
broken pipe只出現在調用write的時候。broken pipe的意思是對端的管道已經斷開，往往發生在遠端把這個讀/寫管道關閉了，你無法在對這個管道進行讀寫操作。從tcp的四次揮手來講，遠端已經發送了FIN序號，告訴你我這個管道已經關閉，這時候，如果你繼續往管道里寫數據，第一次，你會收到一個遠端發送的RST信號，如果你繼續往管道里write數據，操作系統就會給你發送SIGPIPE的信號，並且將errno置為Broken pipe（32），如果你的程序默認沒有對SIGPIPE進行處理，那么程序會中斷退出。一般情況下，可以用signal(SIGPIPE,SIG_IGN)忽略這個信號，這樣的話程序不會退出，但是write會返回-1並且將errno置為Broken pipe（32）。broken pipe只會出現在往對端已經關閉的管道里寫數據的情況下（在收到對端的RST序號后第一次寫不會出現broke pipe，而是write返回-1，這時候正確的做法應該是本端也close這個管道，如果繼續write，那么就會出現這個錯誤）。
tcpdump截包情況如下：
connection reset by peer：
connection reset by peer在調用write或者read的時候都會出現。按照glibc的說法，是such as by the remote machine rebooting or an unrecoverable protocol violation。從字面意義上來看，是表示遠端機器重啟或者發生不可恢復的錯誤。從我的測試來看，目前只出現在對端直接kill掉進程的情況。這兩種情況有什么不同呢？對比tcpdump的截包圖來看，直接kill掉遠端進程的話，遠端並沒有發送FIN序號，來告訴對方，我已經關閉管道，而是直接發送了RST序號，而遠端如果調用close或者shutdown的話，是會發送FIN序號的。按照TCP的四次揮手來看，是需要FIN這個序號的。個人猜測，如果在本端沒有收到對方的FIN序號而直接收到了RST序號的話，表明對端出現了machine rebooting or an unrecoverable protocol violation，這時候對這個管道的IO操作，就會出現connection reset by peer錯誤。
tcpdump截包情況如下：
補充一下tcp的三次握手和四次揮手的過程圖片，幫助理解：
如果有不對的地方，望指正~