URG:紧急指针(urgent pointer)有效。
ACK:确认序号有效。
PSH:接收方应该尽快将这个报文交给应用层。
RST:重置连接。
SYN:发起一个新连接。
FIN:释放一个连接。
RST一般是在FIN之后才会出现为1的情况,表示的是连接重置。一般地,当出现FIN包或RST包时,我们便认为客户端与服务器端断开了连接。所以在客户端不知道的情况下,协议栈最有可能返回SYN
ECONNABORTED(WSAECONNABORTED)该错误被描述为“software caused connection abort”,即“软件引起的连接中止”。原因在于当服务和客户进程在完成用于 TCP 连接的“三次握手”后,客户 TCP 却发送了一个 RST (复位)分节,在服务进程看来,就在该连接已由 TCP 排队,等着服务进程调用 accept 的时候 RST 却到达了。POSIX 规定此时的 errno 值必须 ECONNABORTED。源自 Berkeley 的实现完全在内核中处理中止的连接,服务进程将永远不知道该中止的发生。服务器进程一般可以忽略该错误,直接再次调用accept。
这个tcp send引起的,一般是protocol stack重传超时或者protocol处理错误等。
ECONNABORTED通常发生在重传(一定次数)失败后,强制关闭套接字;
1
2
3
1
2
3
ECONNRESET(WSAECONNRESET)
ECONNRESET错误发生在对方意外关闭套接字后。
对于TCP
远程主机已强制关闭,发送数据,远程主机protocol stack回应RST。
1
1
对于UDP
在Windows系统上,双方正在进udp数据交互,另一端关闭了,发送方会收到“ICMP Port
1
1
Unreached",protocol向上报WSAECONNRESET。这时应用层一般不做关闭动作(除非有特殊的需求),因为这仅仅另外一端的
UDP socket不存在了,本端的udp socket还是完全合法的。
有一点要注意的是,在Linux上,应用层不会得到ECONNRESET。
1
1
该错误被描述为“connection reset by peer”,即“对方复位连接”,这种情况一般发生在服务进程较客户进程提前终止。当服务进程终止时会向客户 TCP 发送 FIN 分节,客户 TCP 回应 ACK,服务 TCP 将转入 FIN_WAIT2 状态。此时如果客户进程没有处理该 FIN (如阻塞在其它调用上而没有关闭 Socket 时),则客户 TCP 将处于 CLOSE_WAIT 状态。当客户进程再次向 FIN_WAIT2 状态的服务 TCP 发送数据时,则服务 TCP 将立刻响应 RST。一般来说,这种情况还可以会引发另外的应用程序异常,客户进程在发送完数据后,往往会等待从网络IO接收数据,很典型的如 read 或 readline 调用,此时由于执行时序的原因,如果该调用发生在 RST 分节收到前执行的话,那么结果是客户进程会得到一个非预期的 EOF 错误。此时一般会输出“server terminated prematurely”-“服务器过早终止”错误。
WOULDBOCK(WSAWOULDBLOCK)
对于nonblocking io,这个很常见了。发送数据的时候,socket sending
buffer没有空间了,得到这error code。简单做法是稍后重试,更好的做法是采用select/epoll之类的机制,注册一个WRITE
EVENT,当sending buffer有空间了,kernel通知应用程序。
ETIMEDOUT
错误被描述为“connect time out”,即“连接超时”,这种情况一般发生在服务器主机崩溃。此时客户 TCP 将在一定时间内(依具体实现)持续重发数据分节,试图从服务 TCP 获得一个 ACK 分节。当最终放弃尝试后(此时服务器未重新启动),内核将会向客户进程返回 ETIMEDOUT 错误。如果某个中间路由器判定该服务器主机已经不可达,则一般会响应“destination unreachable”-“目的地不可达”的ICMP消息,相应的客户进程返回的错误是 EHOSTUNREACH 或ENETUNREACH。当服务器重新启动后,由于 TCP 状态丢失,之前所有的连接信息也不存在了,此时对于客户端发来请求将回应 RST。如果客户进程对检测服务器主机是否崩溃很有必要,要求即使客户进程不主动发送数据也能检测出来,那么需要使用其它技术,如配置 SO_KEEPALIVE Socket 选项,或实现某些心跳函数。
EPIPE
错误被描述为“broken pipe”,即“管道破裂”,这种情况一般发生在客户进程不理会(或未及时处理)Socket 错误,继续向服务 TCP 写入更多数据时,内核将向客户进程发送 SIGPIPE 信号,该信号默认会使进程终止(此时该前台进程未进行 core dump)。结合上边的 ECONNRESET 错误可知,向一个 FIN_WAIT2 状态的服务 TCP(已 ACK 响应 FIN 分节)写入数据不成问题,但是写一个已接收了 RST 的 Socket 则是一个错误。
这种情况发生在TCP 3次握手刚好完成,服务器TCP将连接放入到已经建立好连接队列中,此时客户端给一个RST,接下来accept返回,不过这时accept返回的是ECONNECTABORT错误.这不是一个致命错误。2、服务器进程终止过程如下:a、kill掉服务进程,作为进程善后处理的部分,所有打开的文件描述符被关闭,这导致服务端TCP(注意"服务端"和"服务端TCP"是不同概念)发送FIN给客户端,客户端TCP响应以ACK。b、客户端此时正阻塞在scanf函数(基于上篇中提到的客户端模型),这导致客户端不知道服务端TCP已经关闭连接。c、客户端在scanf返回后调用write向服务端发数据,由于服务端已经被kill掉,所以服务端TCP会发送一个RST给客户端TCP.d、客户端在发送完数据后立即调用read读取数据,由于有第一步的FIN,read立即返回0(表示EOF),然而客户端希望的是收到刚才发送的数据而不是EOF。如果客户端接着往服务端发数据,将诱发服务端TCP向服务端发送SIGPIPE信号,因为向接收到RST的套接口写数据都会收到此信号.问题的本质在于客户端同时处理两个描述字--套接口和用户输入,程序被单纯地阻塞在一个源上了。这个问题可以通过1、设置非阻塞模式。2、采用select以及epoll处理。3、服务器主机崩溃在客户TCP发送数据后,由于接收不到ACK,它将试图一直重传,直到最后放弃,并返回给客户进程一个出错信息。ETIMEOUT表示没有相应,EHOSTUNREACH表示路由器判定主机不可达。4、服务器崩溃后重启由于服务端TCP丢失了以前的连接信息,这将导致服务端发送一个RST,而此时客户端阻塞在read函数,这将导致返回一个ECONNECTRESET错误.5、服务器关机服务器关机时init进程会先发送SIGTERM(此信号可捕获)给所有进程,再过一段时间发送SIGKILL(次信号不可捕获)给仍然在运行的程序,这时就和服务器进程终止一样了。欢迎分享,转载请注明来源:夏雨云
评论列表(0条)