去年(2014年)公司决定服务框架改用Finagle(后续文章详细介绍),but 公司业务系统大部分是C#写的，然后 finagle只提供了 scala/java 的Client 于是 只能自己动手丰衣足食了，项目中使用了 zookpeerClient+ThriftClient 然后自己封装了 client loadBlance 部分 和 failover 部分.

　　使用场景：web服务器 (window iis 挂载 mvc4的网站,mvc4中使用封装的Client)访问 finagle服务器(linux集群)

　　现象：web服务大量的通讯端口time-wait 使用导致web用户无法访问(端口不够)

　　分析: time-wait 产生原因是 tcp短链接时 主动关闭的一方 ,然后看下封装的finagle client中的thrift client 底层使用tcpclient 然后每次 都是 open close 导致整个问题。

　　解决：1：window服务器修改 time-wait 时间 but 不靠谱 (万一以后新部署的服务器忘了修改怎么办)

　　　　　2: 修改client 改后pool 模式 正好 最近阅读 redis client 有感觉 https://github.com/ServiceStack/ServiceStack.Redis

　　补充：根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证

　　补充2：linux服务器 也会存在问题，很多人通过修改 核心参数解决 but 也会引发其他问题。 连接：http://blog.csdn.net/dog250/article/details/13760985

　　补充3: 开起 keep-alive 解决 nginx time-wait 问题 http://www.cnblogs.com/QLeelulu/p/3601499.html

　　写在最后：1年前的事 最近才找到原因。而且已经从公司离职了惭愧啊。