生產環境中一臺2核4G的linux伺服器TCP連線數時常保持在5-7w間徘徊，檢視日誌每秒的請求數也就100-200，怎麼會產生這麼大的TCP連線數。檢查了下客戶端上行的HTTP協議，Connection 頭欄位是Keep-Alive，並且客戶端在請求完之後沒有立即關閉連線。而服務端的設計也是根據客戶端來的，客戶端上行如果Connection:Keep-Alive，服務端是不會主動關閉連線的。在客戶端與服務端互動比較頻繁的時候，這樣的設計還是比較合理的，可以減少TCP的重複握手。顯然如果只互動一次，就沒有這個必要了。我們的生產環境就屬於這種情況。客戶端在請求響應完之後就得立即釋放連線，上程式碼:

  public static void send(request req){
	  InputStream input=null;
	  ByteArrayOutputStream out=null;
	  HttpClient client=new DefaultHttpClient();
	  try{
		  HttpPost post=new HttpPost("http://ip:port");
		  post.setHeader("User-Agent", "Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1");
		  post.setHeader("Expect", "100-continue");
		  post.setHeader("Client_IP", "ip");
		  post.addHeader("Connection","close");
		  
		  HttpEntity entity=new ByteArrayEntity(encoder.encodeXip(req));
		  post.setEntity(entity);
		  HttpResponse resp=client.execute(post);
		  HttpEntity content = resp.getEntity();
		  input=content.getContent();
		  out=new ByteArrayOutputStream();
		  byte by[]=new byte[1024];
		  int len=0;
		  while((len=input.read(by))!=-1){
			  out.write(by, 0, len);
		  }
	     System.out.println(new String(out.toByteArray()));
		 
	  }catch(Exception e){
		  e.printStackTrace();
		  return null;
	  }finally{
		  try {
			out.close();
			input.close();
			client.getConnectionManager().shutdown();//主動釋放連線
		} catch (IOException e) {
			e.printStackTrace();
		}
	  }
  }
 

解決方法好像很簡單。但現實環境是客戶端有很多版本，並且已經執行在客戶手中了，改客戶端來減少伺服器TCP連線數，是一件比較耗時間的活。沒有辦法只能從服務端自身解決，解決方法只能從服務端主動關閉TCP連線。

一開始不要著急從程式層面去看問題，從作業系統角度看能否解決問題，簡單為linux核心增加了一些keep-alive的引數，發現也能降低一些TCP連線數。操作很簡單，往 /etc/sysctl.conf 配置檔案裡增加如下引數:

net.ipv4.tcp_keepalive_intvl = 3
net.ipv4.tcp_keepalive_probes = 2
net.ipv4.tcp_keepalive_time = 6
 

最後 sysctl -p 使之生效。

上面引數的意思是說，客戶端與服務端空閒時間達到6秒之後，服務端每隔3秒檢測下客戶端存活情況，一共檢測兩次，如果在6+3*2=12之內客戶端程序退出了，服務端就會主動關閉該連線。服務端檢測客戶端存活是通過傳送基於TCP的keep alive報文，客戶端程序如果沒有退出，就會發送確認keep alive的響應報文。如圖wireshark中報文:

剛調整引數的那幾天沒有注意，後來才發現這樣的操作會帶來頻寬的嚴重浪費，以前只要1M左右的響應頻寬，現在要5M左右，都是成本啊，雖然是公司出錢。

因為我們的客戶端存活時間比較長，TCP的keep alive保活機制能回收的TCP連線數是比較有限的，但是每隔6秒的報文卻能讓伺服器頻寬翻上好幾倍，得不償失啊。

沒辦法只能從程式設計方面在想想辦法，調整服務端的設計，原先服務端不主動去關閉連線，而是根據客戶端上行Connection的狀態決定是否關閉，新的設計方案就是服務端可以配置連線的狀態，如果服務端配置了Connection:close，服務端優先採用配置資訊，如果沒有配置，則還是由客戶端上行來決定連線狀態。

服務端是java寫的，基於netty的通訊框架。netty裡keep alive相關的引數只有一個選項配置，相關程式碼如下：

    this.bootstrap.setPipelineFactory(new ChannelPipelineFactory()
    {
      public ChannelPipeline getPipeline()
        throws Exception
      {
        ChannelPipeline pipeline = new DefaultChannelPipeline();
        
        pipeline.addLast("codec", new HttpServerCodec());
        pipeline.addLast("aggregator", new HttpChunkAggregator(maxContentLength));
        pipeline.addLast("handler", new HttpRequestHandler());
        return pipeline;
      }
    });
    this.bootstrap.setOption("allIdleTime", Integer.valueOf(this.idleTime));
    this.bootstrap.setOption("child.keepAlive", Boolean.valueOf(true));
    this.bootstrap.setOption("child.tcpNoDelay", Boolean.valueOf(true));
    this.bootstrap.setOption("child.soLinger", Integer.valueOf(-1));
    this.bootstrap.setOption("child.sendBufferSize", Integer.valueOf(-1));

this.bootstrap.setOption("child.keepAlive", Boolean.valueOf(true));  這行程式碼只配置是否啟用TCP保活檢測，如果啟用了，多久檢測一次還是取決於作業系統本身。說白了，還是跟編輯  sysctl.conf檔案的效果一樣，因為它們都是從TCP層的檢測。netty從應用層主動關閉連線的話，可以簡單增加一個監聽器，程式碼如下：

    ChannelFuture future = channel.write(response);
    if ((!HttpHeaders.isKeepAlive(response)) || (!response.containsHeader("Content-Length"))) {
      future.addListener(ChannelFutureListener.CLOSE);
    }

當channel write操作完成時，CLOSE監聽器主動close掉channel。
問題基本解決，後來發現其實也可以通過增加一層nginx代理解決問題，nginx通過短連線與後端進行互動，與前端保持長連線，不過不是很清楚nginx長連線的檢測機制，但根據生產環境表現出的現象，肯定不是用作業系統引數。

TCP保活機制可以引數這篇文章 http://www.blogjava.net/yongboy/archive/2015/04/14/424413.html