标签：天都 比较 应用程序 分享图片 wait web服务 代码检查 动向 资料
最近接连听说一台线上服务器总是不响应客户端请求。
登录服务器后查询iis状态，发现应用程序池状态变为已停止。
按经验想，重启后应该就ok，第一次遇到也确实起了作用，当时完全没在意，以为是其他人无意把服务关闭了而已。
但是之后几天几乎每天都出现问题，应用程序池再次成为 已停止 状态。这个情况显然有问题。于是开始排查设置。
线上环境很简单，iis + API应用，数据库在内网上，没有反向代理。
出问题的应用程序池承载了一个基础数据API，查询量极小，数据量也极小，只是因为同事做实现时提过，查询很麻烦，所以我让他同时也检查代码的查询是否过于繁琐产生超出设置上限的资源占用。
但根据同事检查结果，这个情况不存在，数据库查询响应非常快，服务器的资源监控上看相关进程也没有出现明显的资源飙升。因此判断服务端代码应该没有问题。
经验路线在这里就走不通了，只能尝试在设置上找原因。 iis对应用程序池的设置里最可能影响服务的是回收策略的设置。为了避免影响其他服务，部署时设置了这个api的专用内存上限到1GB。当然，既然代码检查没有问题，测试运行也没发现资源飙升的情况，回收的专用内存上限应该不会轻易触发。但是还是检查了设置，毕竟从前有同事设置时把1GB给成了100M，除了登录之外执行不了任何请求。
最终想到用netstat检查端口情况。起初的怀疑是端口被其他进程无意占用导致问题。
启动netstat后，让测试发了几次请求，顺利看到进程出现在列表，且没有端口冲突，对端地址经查证是来自app。当然，也注意到服务器状态是一堆 Close_Wait.
当然我经验少，Close_Wait还真是第一次见。不过既然状态不是Established，这个应该就是问题的原因了。开始查资料，学习Close_Wait状态是什么情况。
对于 服务器的连接状态而言，一般有三种比较常见的： Established、 Time_Wait、Close_Wait。
从别人博客上扒了一张原理图：
通过原理图，我们知道了CLOSE_WAIT是被动关闭的状态。什么意思呢？比如客户端发了个请求，正常情况下是会收到服务器响应一个状态的，即Response。当客户端读取了这个返回后，会主动告诉服务器收到了，关闭连接。
由于是客户端发起关闭连接的请求，在TCP协议下双方需要通过四个包的互发完成双向确认工作，才能最终关闭这个连接。
客户端要求关闭，此时客户端状态为 FIN_WAIT_1，同时向服务器发送了 FIN 包，服务器状态变更为CLOSE_WAIT；
当然，服务器需要对收到FIN包向客户端确认，于是服务器向客户端发送了 ACK 包，客户端因此变更状态为FIN_WAIT_2；
服务器处理了这个确认后，再次主动向客户端发送FIN包，同时自己状态变更为LAST_ACK，收到来自服务器FIN包的客户端也将自己状态变更为TIME_WAIT；
最后一步，客户端会对来自服务器的FIN包回复确认，服务器收到该ACK包后，将自己状态置为CLOSED，如此，整个关闭过程结束。
简单说就是，客户端 -》 服务器，我要关闭，服务器回复OK，并开始处理后续；服务器后续处理好后，再告诉客户端我可以关闭了，客户端确认，服务端关闭。
所以，出现CLOSE_WAIT状态的原因是，服务器一端因故没有向客户端发出FIN包，即服务端的LAST_ACK -- FIN -->客户端这步没能执行。
因此，看到CLOSE_WAIT状态后，那么可以确定服务器没有执行后续动作，即调用socket.Close()。
举一反三，即谁被动关闭，则谁的连接释放代码有问题。
但是socket.Close()的调用应当是由web服务器自己完成呀，所以问题还没确定。写api的同事轻描淡写提了一下说代码没关闭链接，但越想越不对。到底什么原因导致没有进行socket.Close(),还需要具体从代码入手。
不过，虽然没有真正搞明白我们遇到的原因，但是原理清楚了，排查的时候还顺手看到客户端的代码存在的问题。后续搞清楚了再更。
相关资料：
http://blog.csdn.net/shootyou/article/details/6622226
http://mp.weixin.qq.com/s?__biz=MzI4MjA4ODU0Ng==&mid=402163560&idx=1&sn=5269044286ce1d142cca1b5fed3efab1&3rd=MzA3MDU4NTYzMw==&scene=6#rd
感谢以上优秀的技术文章。
标签：天都 比较 应用程序 分享图片 wait web服务 代码检查 动向 资料
原文地址：http://www.cnblogs.com/DannielZhang/p/8000496.html
