linux下查看nginx等的并发连接数和连接状态。
1、查看web服务器（nginx apache）的并发请求数及其tcp连接状态： 
netstat -n | awk '/^tcp/ {++s[$nf]} end {for(a in s) print a, s[a]}'
或者：
netstat -n | awk '/^tcp/ {++state[$nf]} end {for(key in state) print key,"t",state[key]}'返回结果一般如下：
last_ack 5 （正在等待处理的请求数） syn_recv 30 established 1597 （正常数据传输状态） fin_wait1 51 fin_wait2 504 time_wait 1057 （处理完毕，等待超时结束的请求数）
其他参数说明： 
closed：无连接是活动的或正在进行
listen：服务器在等待进入呼叫 
syn_recv：一个连接请求已经到达，等待确认 
syn_sent：应用已经开始，打开一个连接 
established：正常数据传输状态 
fin_wait1：应用说它已经完成 
fin_wait2：另一边已同意释放 
itmed_wait：等待所有分组死掉 
closing：两边同时尝试关闭 
time_wait：另一边已初始化一个释放 
last_ack：等待所有分组死掉 
常用的三个状态是：established 表示正在通信，time_wait 表示主动关闭，close_wait 表示被动关闭。
tcp协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多tcp状态中，最值得注意的状态有两个：close_wait和time_wait。  
time_wait 
time_wait 是主动关闭链接时形成的，等待2msl时间，约4分钟。主要是防止最后一个ack丢失。  由于time_wait 的时间会非常长，因此server端应尽量减少主动关闭连接
close_wait
close_wait是被动关闭连接是形成的。根据tcp状态机，服务器端收到客户端发送的fin，则按照tcp实现发送ack，因此进入close_wait状态。但如果服务器端不执行close()，就不能由close_wait迁移到last_ack，则系统中会存在很多close_wait状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到fin的连接，进行close。此时，recv/read已收到fin的连接socket，会返回0。
为什么需要 time_wait 状态？
假设最终的ack丢失，server将重发fin，client必须维护tcp状态信息以便可以重发最终的ack，否则会发送rst，结果server认为发生错误。tcp实现必须可靠地终止连接的两个方向(全双工关闭)，client必须进入 time_wait 状态，因为client可能面 临重发最终ack的情形。
为什么 time_wait 状态需要保持 2msl 这么长的时间？
如果 time_wait 状态保持时间不足够长(比如小于2msl)，第一个连接就正常终止了。第二个拥有相同相关五元组的连接出现，而第一个连接的重复报文到达，干扰了第二个连接。tcp实现必须防止某个连接的重复报文在连接终止后出现，所以让time_wait状态保持时间足够长(2msl)，连接相应方向上的tcp报文要么完全响应完毕，要么被 丢弃。建立第二个连接的时候，不会混淆。
 time_wait 和close_wait状态socket过多
如果服务器出了异常，百分之八九十都是下面两种情况：
1.服务器保持了大量time_wait状态
2.服务器保持了大量close_wait状态，简单来说close_wait数目过大是由于被动关闭连接处理不当导致的。
因为linux分配给一个用户的文件句柄是有限的，而time_wait和close_wait两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了，接着就是大量too many open files异常，tomcat崩溃。
以上就是关于linux下如何查看nginx的并发连接数和连接状态的详细介绍 的详细内容。