Linux下查看Nginx的并发连接数和连接状态

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 (处理完毕,等待超时结束的请求数)
  1. 其他参数说明:

CLOSED:无连接是活动的或正在进行

LISTEN:服务器在等待进入呼叫

SYN_RECV:一个连接请求已经到达,等待确认

SYN_SENT:应用已经开始,打开一个连接

ESTABLISHED:正常数据传输状态

FIN_WAIT1:应用说它已经完成

FIN_WAIT2:另一边已同意释放

ITMED_WAIT:等待所有分组死掉

CLOSING:两边同时尝试关闭

TIME_WAIT:另一边已初始化一个释放

LAST_ACK:等待所有分组死掉

  1. 常用的三个状态是:

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。

  1. 为什么需要 TIME_WAIT 状态?

假设最终的ACK丢失,server将重发FIN,client必须维护TCP状态信息以便可以重发最终的ACK,否则会发送RST,结果server认为发生错误。TCP实现必须可靠地终止连接的两个方向(全双工关闭),client必须进入 TIME_WAIT 状态,因为client可能面 临重发最终ACK的情形。

  1. 为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间?

如果 TIME_WAIT状态保持时间不足够长(比如小于2MSL),第一个连接就正常终止了。第二个拥有相同相关五元组的连接出现,而第一个连接的重复报文到达,干扰了第二个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现,所以让TIME_WAIT状态保持时间足够长(2MSL),连接相应方向上的TCP报文要么完全响应完毕,要么被丢弃。建立第二个连接的时候,不会混淆。

  1. TIME_WAIT 和CLOSE_WAIT状态socket过多

如果服务器出了异常,百分之八九十都是下面两种情况:

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态,简单来说CLOSE_WAIT数目过大是由于被动关闭连接处理不当导致的。

因为linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,Tomcat崩溃。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏武军超python专栏

2018年8月16日TCP中三次握手和四次挥手详解

 上图中有几个字段需要重点介绍下:         (1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。...

9120
来自专栏我就是马云飞

注意!是TCP不是HTTP的3次握手与4次挥手

11830
来自专栏JetpropelledSnake

Python Web学习笔记之TCP的3次握手与4次挥手过程

前言 尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务。TCP提供一种面向连接的、可靠的字节流服务。 面向连接意味...

422100
来自专栏积累沉淀

TCP连接的建立(三次握手)和释放(四次挥手)

所谓三次握手(Three-way Handshake),是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。  三次握手的目的是连接服务器指定端口,建...

242100
来自专栏LanceToBigData

TCP/IP中你不得不知的十大秘密

这段时间 有一点心很浮躁,不过希望自己马上要矫正过来。好好学习编程!这段时间我想好好地研究一下TCP/IP协议和网络传输这块!加油 一、TCP/IP模型 TCP...

25560
来自专栏全栈之路

android studio 使用第三方模拟器连接方法

73520
来自专栏mukekeheart的iOS之旅

TCP/IP协议学习笔记

计算机网络基础知识复习汇总:计算机网络基础知识复习 HTTP协议的解析:剖析 HTTP 协议 一个系列的解析文章: TCP/IP详解学习笔记(1)-- 概述 T...

44750
来自专栏Golang语言社区

linux服务器开发三(网络编程) --一

网络基础协议的概念什么是协议 从应用的角度出发,协议可理解为“规则”,是数据传输和数据的解释的规则。 假设,A、B双方欲传输文件。规定: 第一次,传输文件名,接...

544130
来自专栏即时通讯技术

理论经典:TCP协议的3次握手与4次挥手过程详解

尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务。TCP提供一种面向连接的、可靠的字节流服务。

10320
来自专栏我的博客

TCP/IP三次握手

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN...

34370

扫码关注云+社区

领取腾讯云代金券