Linux服务器上用netstat查看的11种网络状态及长连接讨论

5 篇文章 0 订阅
4 篇文章 0 订阅


一、Linux服务器上11种网络连接状态
通常情况下:一个正常的TCP连接,都会有三个阶段:1TCP三次握手;2、数据传送;3TCP四次挥手 
:以下说明最好能结合:TCP的状态机来理解。 
SYN:(同步序列编号,Synchronize Sequence Numbers)该标志仅在三次握手建立TCP连接时有效。表示一个新的TCP连接请求。 
ACK:( 确认编号 ,Acknowledgement Number) 是对 TCP 请求的确认标志 , 同时提示对端系统已经成功接收所有数据。  
FIN:( 结束标志 ,FINish) 用来结束一个 TCP 回话 . 但对应端口仍处于开放状态 , 准备接收后续数据。  

1)LISTEN:首先服务端需要打开一个socket进行监听,状态为LISTEN. /* The socket is listening for incoming connections. 侦听来自远方TCP端口的连接请求 */ 

2)SYN_SENT:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT. /*The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 */ 

3)SYN_RECV:服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN. 之后状态置为SYN_RECV /* A connection request has been received from the network. 在收到和发送一个连接请求后等待对连接请求的确认 */ 

4)ESTABLISHED: 代表一个打开的连接,双方可以进行或已经在数据交互了。/* The socket has an established connection. 代表一个打开的连接,数据可以传送给用户 */ 

5)FIN_WAIT1:主动关闭(active close)端应用程序调用close,于是其TCP发出FIN请求主动关闭连接,之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求,或先前的连接中断请求的确认 */ 

6)CLOSE_WAIT:被动关闭(passive close)TCP接到FIN后,就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 */ 
  
7)
FIN_WAIT2:主动关闭端接到ACK后,就进入了FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待连接中断请求 */ 

8)LAST_ACK:被动关闭端一段时间后,接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认 */ 

9)TIME_WAIT:在主动关闭端接收到FIN后,TCP就发送ACK包,并进入TIME-WAIT状态。/* The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到连接中断请求的确认 */

10)CLOSING: 比较少见./* Both sockets are shut down but we still don't have all our data sent. 等待远程TCP对连接中断的确认 */ 

11)CLOSED: 被动关闭端在接受到ACK包后,就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态 */ 

TIME_WAIT状态的形成只发生在主动关闭连接的一方。 

    主动关闭方在接收到被动关闭方的FIN请求后,发送成功给对方一个ACK,将自己的状态由FIN_WAIT2修改为TIME_WAIT,而必须再等2 MSL(Maximum Segment Lifetime,MSL是一个数据报在internetwork中能存在的时间)时间之后双方才能把状态 都改为CLOSED以关闭连接。目前RHEL里保持TIME_WAIT状态的时间为60秒。 
  

当然上述很多TCP状态在系统里都有对应的解释或设置,可见man tcp 

二、关于长连接和短连接

       通俗点讲:短连接就是一次TCP请求得到结果后,连接马上结束.而长连接并不马上断开,而一直保持着,直到长连接TIMEOUT(具体程序都有相关参数说明).长连接可以避免不断的进行TCP三次握手和四次挥手

       长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED.目前http 1.1版本里默认都是keepalive(1.0版本默认是不keepalive)ie6/7/8firefox都默认用的是http 1.1版本了(如何查看当前浏览器用的是哪个版本,这里不再赘述)Apache,java    

一个应用至于到底是该使用短连接还是长连接,应该视具体情况而定。一般的应用应该使用长连接。


Netstat 状态分析

etstat状态分类

用netstat -an命令查看!再stat下面有一些英文,简单说一下这些英文具体都代表什么:

LISTEN:(Listening for a connection.)侦听来自远方的TCP端口的连接请求

SYN-SENT:(Active; sent SYN. Waiting for a matching connection request after having sent a connection request.)再发送连接请求后等待匹配的连接请求

SYN-RECEIVED:(Sent and received SYN. Waiting for a confirming connection request acknowledgment after having both received and sent connection requests.)再收到和发送一个连接请求后等待对方对连接请求的确认

ESTABLISHED:(Connection established.)代表一个打开的连接

FIN-WAIT-1:(Closed; sent FIN.)等待远程TCP连接中断请求,或先前的连接中断请求的确认

FIN-WAIT-2:(Closed; FIN is acknowledged; awaiting FIN.)从远程TCP等待连接中断请求

CLOSE-WAIT:(Received FIN; waiting to receive CLOSE.)等待从本地用户发来的连接中断请求

CLOSING:(Closed; exchanged FIN; waiting for FIN.)等待远程TCP对连接中断的确认

LAST-ACK:(Received FIN and CLOSE; waiting for FIN ACK.)等待原来的发向远程TCP的连接中断请求的确认

TIME-WAIT:(In 2 MSL (twice the maximum segment length) quiet wait after close. )等待足够的时间以确保远程TCP接收到连接中断请求的确认

CLOSED:(Connection is closed.)没有任何连接状态

TCP连接建立

首先要说明的是要明确TCP连接建立的过程需要3次握手,下面举例说明各种状态存在的时刻:

1. 首先在服务器A上开启FTP服务,开始侦听来自远端TCP端口的连接请求,这个时候查看服务器A状态为:LISTENING

2. 在客户端B上向A发送FTP连接请求,这个时候数据包同步位置1,这是TCP三次握手的第一步。在发送后没收到确认时,在客户端B上其状态为:SYN-SENT。此时客户端B启动连接定时器。如果在75秒内没有收到应答,则放弃连接建立。

3. 在服务器A上收到从B上发送的SYN同步包后,确认,然后再向B发送SYN的同步包,此数据包同时将TCP标记中的同步位和确认位置1,它既对第一步中的客户端同步数据包进行确认,表示愿意与客户端同步,同时再对客户端主机进行同步请求,这是TCP连接的第一步。这个时候在服务器A上,状态为:SYN-RECEIVED。此时服务器A启动连接定时器。如果在75秒内没有收到应答,则放弃连接建立。

4. 在客户端B上接收到从A上发过来的确认同步包后进行确认,此数据包中将TCP标记中的确认位置1,表示这是一个确认数据包,此时在客户端B状态转换为:ESTABLISHED

5. 服务器A接收到从B发过来的确认包后,状态转换为:ESTABLISHED

此时TCP连接正式建立。
TCP连接关闭

6. 应用程序在在连接不需要的时候,通过客户端B向服务器A发送的终止信息的FIN包后,客户端B处于FIN-WAIT-1状态。

7. 从服务器A接收到客户端B发送的终止数据包,它告诉客户端B已成功接收客户端的上数据包,此时等待应用程序来关闭连接,此时服务器A进入CLOSE_WAIT状态。

8. 客户端B接收到带有确认位的数据包后,对此进行确认,同意关闭TCP连接此时客户端B转移到FIN-WAIT-2状态。当连接从FIN-WAIT-1状态转移到FIN-WAIT-2状态时,将一个FIN-WAIT-2定时器设置为10分钟。

9. 服务器A在应用程序同意终止连接后,向客户端B发送终止FIN包,此时服务器状态转为LAST-ACT。

10. 客户端B在接收到从服务器A发送的终止包后,同意终止连接,然后再向服务器端发送确认信息,此时客户端B转向TIME-WAIT状态。当连接进入TIME-WAIT状态时,该定时器被激活。

11. 服务端A在收到客户端B的确认后,关闭连接,服务器A状态转向CLOSED。

12. 客户端B在TIME-WAIT定时器超时时,与该连接相关的内核数据块被删除,连接终止,转向CLOSED状态。

此时TCP连接正式关闭。
备注

1. 一个由客户端发起的关闭TCP连接的示意图:

2. 连接终止请求对与建立连接的双方是可以同时发出的,在发出终止请求后,双方都进入FIN-WAIT-1状态,随着定时器的超时,双方都进入CLOSING状态,在这个定时器再次超时后,均转入TIME-WAIT状态,在TIME-WAIT的定时器超时后,双方均放弃这次连接,连接转为CLOSE状态。如图示:



tomcat的CLOSE_WAIT原因

CLOSE_WAIT狀態的生成原因

如果是CLIENT端主動斷掉當前連接的話,那麼雙方關閉這個TCP連接共需要四個packet:

Client ---> FIN ---> Server 

Client <--- ACK <--- Server 

這時候Client端處於FIN_WAIT_2狀態;而Server 程序處於CLOSE_WAIT狀態。

Client <--- FIN <--- Server 

這時Server 發送FIN給Client,Server 就成為LAST_ACK狀態。

Client ---> ACK ---> Server 

Client回應了ACK,那麼Server 才會成為CLOSED狀態。

******************************************************************************
解決方法:
1.(暫時生效,重新啓動 linux 後,會還原成預設值)
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_keepalive_time=1800
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2

2.(永久生效)
vi /etc/sysctl.conf
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 30
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800
# 探測次數
net.ipv4.tcp_keepalive_probes=2
# 探測間隔秒數
net.ipv4.tcp_keepalive_intvl=2

編輯完 /etc/sysctl.conf,要重啓network 才會生效
[root@temp /]# /etc/rc.d/init.d/network restart
**********************************************************************************
PS: 發生CLOSE_WAIT 的原因,可能在於程式內 一端的Socket使用close後,另一端的Socket沒有使用close.檢查一下代碼內是否有 Server端在某些異常情況時,沒有關閉Socket,將之修改,應可改正此一問題


close_wait状态的产生原因及解决

最近需要上线的逻辑server由于需要与大量的后台server交互,今天突然发现有大量的close_wait产生,于是仔细研究了一下:
首先我们知道,如果我们的服务器程序处于CLOSE_WAIT状态的话,说明套接字是被动关闭的!
因为如果是CLIENT端主动断掉当前连接的话,那么双方关闭这个TCP连接共需要四个packet:

Client ---> FIN  ---> Server
Client <--- ACK  <--- Server
这时候Client端处于FIN_WAIT_2状态;而Server 程序处于CLOSE_WAIT状态。
Client <--- FIN  <--- Server
这时Server 发送FIN给Client,Server 就置为LAST_ACK状态。
Client ---> ACK  ---> Server
Client回应了ACK,那么Server 的套接字才会真正置为CLOSED状态。

Server 程序处于CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FIN给Client,那么可能是在关闭连接之前还有许多数据要发送或者其他事要做,导致没有发这个FIN packet。
通常来说,一个CLOSE_WAIT会维持至少2个小时的时间(这个时间外网服务器通常会做调整,要不然太危险了)。如果有个流氓特地写了个程序,给你造成一堆的CLOSE_WAIT,消耗
你的资源,那么通常是等不到释放那一刻,系统就已经解决崩溃了。
只能通过修改一下TCP/IP的参数,来缩短这个时间:修改tcp_keepalive_*系列参数有助于解决这个问题。

但是实际上,还是主要是因为我们的程序代码有问题,通常是如下问题:
比如被动关闭的是客户端。。。

当对方调用closesocket的时候,你的程序正在

int nRet = recv(s,....);
if (nRet == SOCKET_ERROR)
{
// closesocket(s);
return FALSE;
}

很多人就是忘记了那句closesocket,这种代码太常见了。

我的理解,当主动关闭的一方发送FIN到被动关闭这边后,被动关闭这边的TCP马上回应一个ACK过去,同时向上面应用程序提交一个ERROR,导 致上面的SOCKET的send或者recv返回SOCKET_ERROR,正常情况下,如果上面在返回SOCKET_ERROR后调用了 closesocket,那么被动关闭的者一方的TCP就会发送一个FIN过去,自己的状态就变迁到LAST_ACK.







  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值