一、問題：
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