一、问题：
hudson一个应用打包部署一直不成功，检查报错
检查项目的JOB配置，开始以为是SVN的问题，但是重启SVN后问题一直存在
二、分析：
TCP协议中，关闭TCP连接的是Server端（当然，关闭都可以由任意一方发起），当Server端发起关闭连接请求时，向Client端发送一个FIN报文，Client端收到FIN报文时，很可能还有数据需要发送，所以并不会立即关闭SOCKET，所以先回复一个ACK报文，告诉Server端，“你发的FIN报文我收到了”。当Client端的所有报文都发送完毕之后，Client端向Server端发送一个FIN报文，此时Client端进入关闭状态，不在发送数据。
Server端收到FIN报文后，就知道可以关闭连接了，但是网络是不可靠的，Client端并不知道Server端要关闭，所以Server端发送ACK后进入TIME_WAIT状态，如果Client端没有收到ACK则Server段可以重新发送。Client端收到ACK后，就知道可以断开连接了。Server端等待了2MSL（Max Segment Lifetime，最大报文生存时间）后依然没有收到回复，则证明Client端已正常断开，此时，Server端也可以断开连接了。2MSL的TIME_WAIT等待时间就是由此而来
三、解决：
1.查了资料发现是进程虽然结束了，但是有很多TIME_WAIT状态的连接未释放
2 查看hudson所在的windows服务器上
①IME_WAIT的自动关闭时间（默认4分钟）
②windows下的大端口服务（虽然系统总共可使用的Ports有65536个，但从本机连到外部网路(Outbound Connections)的连线埠最多只会使用到5000个而已【此为系统默认值】）
操作如下：
3.重启
四、结论
由于大量的TIME_WAIT连接未被释放，导致占用的端口资源一直未被回收，出现了缓冲区空间不足的问题，应用也总是自动断线。
附：LINUX更改socket连接数与TIMEOUT时间
修改系统socket最大连接数
在文件/etc/security/limits.conf最后加入下面两行：
* soft nofile 32768
* hard nofile 32768
缩小2MSL的时长、允许重用处于TIME_WAIT状态的TCP连接、快速回收处于 TIME_WAIT状态的TCP连接
修改/etc/sysctl.conf，添加如下几行：
#改系統默认的TIMEOUT时间
net.ipv4.tcp_fin_timeout=2
#启重用，允许将TIME_WAIT sockets重新用于新的TCP连接 默认为0表示关闭
net.ipv4.tcp_tw_reuse=1
#开启TCP连接中TIME_WAIT sockets的快速回收 默认为0 表示关闭
net.ipv4.tcp_tw_recycle=1