最近看服务器设计方面的文章的时候,watchmen 整理了一篇关于服务器异常处理的文章感觉不错分享给大家。 服务器的几种异常终止 1.在accept函数返回前连接夭折这种情况发生在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(次信号不可捕获)给仍然在运行的程序,这时就和服务器进程终止一样了。 |
行业聚焦 面试交流 职位推荐 开发视频 技术交流 腾讯微博 新浪微博
友情链接:课课家教育 阿里云 鲜果 W3Cfuns前端网 中国企业家 环球企业家 投资界 传媒梦工场 MSN中文网 Android开发者社区 cnbeta 投资中国网 又拍云存储 美通说传播 IT茶馆 网商在线 商业评论网 TechOrange IT时代周刊 3W创新传媒 开源中国社区 二维工坊 Iconfans 推酷 智能电视网 FreeBuf黑客与极客 财经网 DoNews 凤凰财经 新财富 eoe移动开发者社区 i黑马 网易科技 新浪科技 搜狐IT 创业家 创业邦 腾讯财经 福布斯中文网 天下网商 TechWeb 雷锋网 新浪创业 和讯科技 品途O2O 极客公园 艾瑞网 抽屉新热榜 卖家网 人民网通信频道 拉勾网 创新派 简单云主机
手机版|黑名单|守望者 成才网 在线教育 linux 高级程序设计 C/C++ 大数据
( 蜀ICP备14029946号 )
成都守望者科技有限公司 © 2013-2016 All Rights Reserved