请教UNIX下C高手，tcp套接字状态问题

我用C写了个solaris 10 下的套接字通讯程序
但是该程序在后台运行一段时间后，出现大量的如下的tcp State为IDLE状态，请问高手们，是我套接字变成造成的吗？
这种状态影响系统套接字的使用吗？或者有什么办法避免这种状态出现呢？
TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE
      *.*                  *.*                0      0 49152      0 IDLE

30 个解决方案

#1

没人知道？

#2

solaris手册说，这个状态是 "opened but not bound"。

你程序中关闭连接是怎么操作的，服务端和客户端分别怎么做的?

#3

我程序中所有函数返回或者线程返回，都会调用 if(sock >0 ) close(sock);
啦

#4

引用 2 楼 do_fork 的回复:

solaris手册说，这个状态是 "opened but not bound"。

你是说这个tcp连接，状态是打开的，但是并没绑定？是怎么出现这种情况呢？他还算是个tcp连接吗？
如果运行久了，系统的套接字资源要是否被他消耗完？

#5

socket打开但是没有连接就是那个状态，好好检查一下程序

#6

引用 5 楼 donntknow 的回复:

socket打开但是没有连接就是那个状态，好好检查一下程序

if((sock = accept(LinSock,(struct sockaddr *)&addrin,&add_size)) <= 0)

我这个sock都是在accept通过后才建立的，也就是讲如果没有连接，根本都不会产生sock.
我看到的这么大量的IDLE 状态都是在程序产生连接之后，之前是没有的。

#7

UNIX下还有IDLE这种状态啊。。学习了

#8

好像没有影响吧，idle状态你不用管吧。
epoll里就是根据是否为idle选择是否回调。说明肯定会存在大量idle状态啊

#9

引用 3 楼 jamesontan 的回复:

我程序中所有函数返回或者线程返回，都会调用 if(sock >0 ) close(sock);
啦

是客户端主动关闭，然后server关闭，还是说server直接close了?

#10

正常~~！

#11

Linux下是没有IDLE这个状态的，solaris内核我不懂。
从网上描述的看，似乎是从CLOSE_WAIT转变到IDLE的。

根据stevens的描述，
“close只是减少fd的引用计数，不会真正关闭这个fd，
只有fd引用计数为0的时候，才会关闭它”，
所以终止连接可以先 shutdown再close。

#12

属于正常状态，看看tcp的三次握手状态转换图中的关闭tcp部分

#13

引用 9 楼 do_fork 的回复:

是客户端主动关闭，然后server关闭，还是说server直接close了?

有客户端主动关闭，也有server端主动关闭，两种情况都有。

#14

引用 11 楼 do_fork 的回复:

Linux下是没有IDLE这个状态的，solaris内核我不懂。
从网上描述的看，似乎是从CLOSE_WAIT转变到IDLE的。

根据stevens的描述，
“close只是减少fd的引用计数，不会真正关闭这个fd，
只有fd引用计数为0的时候，才会关闭它”，
所以终止连接可以先 shutdown再close。

不能先shutdown,再close,否则系统会出现大量FIN_WAIT_1或者FIN_WAIT_2状态的tcp

#15

引用 10 楼 hqin6 的回复:

正常~~！

肯定是不正常的，solaris手册上有明确说明
Typically on Solaris, IDLE TCP connections are maintained indefinitely once created, even if no communication occurs between host systems
Note that keeping the connection open may consume host and/or application resources
通常在Solaris，空闲的TCP连接是无限期地保持下去一旦建立起来，
即使没有主机系统之间的通信发生。请注意，保持连接打开，可能会占用主机和/或应用程序资源。

#16

引用 14 楼 jamesontan 的回复:

引用 11 楼 do_fork 的回复:
Linux下是没有IDLE这个状态的，solaris内核我不懂。
从网上描述的看，似乎是从CLOSE_WAIT转变到IDLE的。

根据stevens的描述，
“close只是减少fd的引用计数，不会真正关闭这个fd，
只有fd引用计数为0的时候，才会关闭它”，
所以终止连接可以先 shutdown再close。

不能先shutdown,再close,否则系统会出现大量FIN_WAIT_1或者FIN_WAIT_2状态的tcp

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

#17

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

代码很简单，就是在任何线程结束时，
if(sock >= 0)
close(sock);
return 0;

#18

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

#19

那会不会有些socket需要再线程结束前关闭？或者你是不是曾经强制结束线程，从而导致这段代码没有机会被调用

引用 17 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

代码很简单，就是在任何线程结束时，
if(sock >= 0)
close(sock);
return 0;

#20

引用 18 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

SO_LINGER设置了吗?
仅仅看这么一个片段，很难看出问题

#21

引用 19 楼 arong1234 的回复:

那会不会有些socket需要再线程结束前关闭？或者你是不是曾经强制结束线程，从而导致这段代码没有机会被调用

这种情况绝对不会，就算出现没有关闭的套接字，那么建立的tcp状态就会是ESTABLISHED
而不会是IDLE

#22

引用 20 楼 do_fork 的回复:

SO_LINGER设置了吗?
仅仅看这么一个片段，很难看出问题

设置了的

#23

引用 18 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

关键是寻求这种状态产生的原因，以及解决办法。

#24

引用 23 楼 jamesontan 的回复:

引用 18 楼 jamesontan 的回复:
引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

关键是寻求这种状态产生的原因，以及解决办法。

blogspot上有人提出过这个问题，借着g.cn的cache看到了这个被gfw盾的网页。

两种情况，可能会引起你的那种IDEL state.
    1 client中断了连接，但是没有notify the server
    2 clietn 和 server之间的网络出现故障
我觉得1的可能性比较大

解决方法是：
TCP keepalive option on Solaris

TCP keepalive is a feature provided by many TCP implementations, including Solaris, as a way to clean up idle connections in situations like the ones mentioned above. Applications must enable this feature with the SO_KEEPALIVE socket option via the setsockopt(3SOCKET) socket call. Once enabled, a keepalive probe packet is sent to the other end of the socket provided the connection has remained in the ESTABLISHED state and has been idle for the specified time frame. This time frame is the value specified by the TCP tunable tcp_keepalive_interval.

A keepalive probe packet is handled just like any other TCP packet which requires an acknowledgment (ACK) from the other end of the socket connection. It will be retransmitted per the standard retransmission backoff algorithm. If no response is received by the time specified for the other TCP tunable, tcp_ip_abort_interval, the connection is terminated, as would be the case for any other unacknowledged packet. Hence the actual maximum idle time of a connection utilizing TCP keepalive, which has no responding peer will therefore be:

           tcp_keepalive_interval + tcp_ip_abort_interval

.
To set the relevant TCP tunables on Solaris, run:

/usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval <value in milliseconds>
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval <value in milliseconds>

The above parameters are global and will affect the entire system. Keep in mind that TCP keepalive probes have no effect on inactive connections as long as the remote host is still responding to probes. However care should be taken to ensure the above parameters remain at a high enough value to avoid unnecessary traffic and other issues such as prematurely closing active connections in situations where a few packets have gone missing.

#25

引用 24 楼 do_fork 的回复:

blogspot上有人提出过这个问题，借着g.cn的cache看到了这个被gfw盾的网页。

两种情况，可能会引起你的那种IDEL state.
    1 client中断了连接，但是没有notify the server
    2 clietn 和 server之间的网络出现故障
我觉得1的可能性比较大

解决方法是：
TCP keepalive option on Solaris

TCP keepalive is a feature provided by many TCP implementations, including Solaris, as a way to clean up idle connections in situations like the ones mentioned above. Applications must enable this feature with the SO_KEEPALIVE socket option via the setsockopt(3SOCKET) socket call. Once enabled, a keepalive probe packet is sent to the other end of the socket provided the connection has remained in the ESTABLISHED state and has been idle for the specified time frame. This time frame is the value specified by the TCP tunable tcp_keepalive_interval.

A keepalive probe packet is handled just like any other TCP packet which requires an acknowledgment (ACK) from the other end of the socket connection. It will be retransmitted per the standard retransmission backoff algorithm. If no response is received by the time specified for the other TCP tunable, tcp_ip_abort_interval, the connection is terminated, as would be the case for any other unacknowledged packet. Hence the actual maximum idle time of a connection utilizing TCP keepalive, which has no responding peer will therefore be:

          tcp_keepalive_interval + tcp_ip_abort_interval

.
To set the relevant TCP tunables on Solaris, run:

你的意思是设置套接字keepalive属性吧？这个也设置了啊，但是还是出现大量IDLE状态啊

#26

没人碰见和解决这样的问题？

#27

sloaris高手们都去哪里了啊？

#28

引用 27 楼 jamesontan 的回复:

sloaris高手们都去哪里了啊？

1. CSDN了解windows之外OS的人本身就不多
2. 不用Linux和BSD用Solaris的更少
3. 遇到过你这个问题的，可能没几个人了
4. 遇到的人里面，看到这个帖子的，还能有几个

没代码，别人很难想象的，这个状态只有solaris有，别的OS没有，
公布完整代码，或者自己翻solaris TCP协议源码，或者继续这么等下去

#29

引用 28 楼 do_fork 的回复:

引用 27 楼 jamesontan 的回复:
sloaris高手们都去哪里了啊？

1. CSDN了解windows之外OS的人本身就不多
2. 不用Linux和BSD用Solaris的更少
3. 遇到过你这个问题的，可能没几个人了
4. 遇到的人里面，看到这个帖子的，还能有几个

没代码，别人很难想象的，这个状态只有solaris有，别的OS没有，
公布完整代码，或者自己翻solaris TCP协议源码，或者继续这么等下去

代码有10000多行，只怕公布不了哦，你说的也有道理，请问你对shell脚本熟悉吗？
#! /sbin/sh

ndd /dev/tcp tcp_status | nawk '{print $1 " " $2 " " $16 $17 " " $18}' | \
egrep 'IDLE' | cut -d' ' -f1 | while read tcpb_addr
do
adb -kw /dev/ksyms /dev/mem < < NSFOCUS_EOF
$tcpb_addr+0x30/Z 0t6
$tcpb_addr+0x40/W -6
\$q
NSFOCUS_EOF
done

solairs下shell执行该脚本总是报错误：
test.sh: syntax error at line 12: `end of file' unexpected

帮我看看，另外20分页会送上，谢谢！

#30

该回复于2009-11-23 09:09:09被版主删除

#1

没人知道？

#2

solaris手册说，这个状态是 "opened but not bound"。

你程序中关闭连接是怎么操作的，服务端和客户端分别怎么做的?

#3

我程序中所有函数返回或者线程返回，都会调用 if(sock >0 ) close(sock);
啦

#4

引用 2 楼 do_fork 的回复:

solaris手册说，这个状态是 "opened but not bound"。

#5

socket打开但是没有连接就是那个状态，好好检查一下程序

#6

引用 5 楼 donntknow 的回复:

socket打开但是没有连接就是那个状态，好好检查一下程序

#7

UNIX下还有IDLE这种状态啊。。学习了

#8

好像没有影响吧，idle状态你不用管吧。
epoll里就是根据是否为idle选择是否回调。说明肯定会存在大量idle状态啊

#9

引用 3 楼 jamesontan 的回复:

我程序中所有函数返回或者线程返回，都会调用 if(sock >0 ) close(sock);
啦

是客户端主动关闭，然后server关闭，还是说server直接close了?

#10

正常~~！

#11

#12

属于正常状态，看看tcp的三次握手状态转换图中的关闭tcp部分

#13

引用 9 楼 do_fork 的回复:

是客户端主动关闭，然后server关闭，还是说server直接close了?

有客户端主动关闭，也有server端主动关闭，两种情况都有。

#14

引用 11 楼 do_fork 的回复:

Linux下是没有IDLE这个状态的，solaris内核我不懂。
从网上描述的看，似乎是从CLOSE_WAIT转变到IDLE的。

根据stevens的描述，
“close只是减少fd的引用计数，不会真正关闭这个fd，
只有fd引用计数为0的时候，才会关闭它”，
所以终止连接可以先 shutdown再close。

不能先shutdown,再close,否则系统会出现大量FIN_WAIT_1或者FIN_WAIT_2状态的tcp

#15

引用 10 楼 hqin6 的回复:

正常~~！

#16

引用 14 楼 jamesontan 的回复:

引用 11 楼 do_fork 的回复:
Linux下是没有IDLE这个状态的，solaris内核我不懂。
从网上描述的看，似乎是从CLOSE_WAIT转变到IDLE的。

根据stevens的描述，
“close只是减少fd的引用计数，不会真正关闭这个fd，
只有fd引用计数为0的时候，才会关闭它”，
所以终止连接可以先 shutdown再close。

不能先shutdown,再close,否则系统会出现大量FIN_WAIT_1或者FIN_WAIT_2状态的tcp

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

#17

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

代码很简单，就是在任何线程结束时，
if(sock >= 0)
close(sock);
return 0;

#18

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

#19

那会不会有些socket需要再线程结束前关闭？或者你是不是曾经强制结束线程，从而导致这段代码没有机会被调用

引用 17 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:

出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

代码很简单，就是在任何线程结束时，
if(sock >= 0)
close(sock);
return 0;

#20

引用 18 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

SO_LINGER设置了吗?
仅仅看这么一个片段，很难看出问题

#21

引用 19 楼 arong1234 的回复:

那会不会有些socket需要再线程结束前关闭？或者你是不是曾经强制结束线程，从而导致这段代码没有机会被调用

这种情况绝对不会，就算出现没有关闭的套接字，那么建立的tcp状态就会是ESTABLISHED
而不会是IDLE

#22

引用 20 楼 do_fork 的回复:

SO_LINGER设置了吗?
仅仅看这么一个片段，很难看出问题

设置了的

#23

引用 18 楼 jamesontan 的回复:

引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

关键是寻求这种状态产生的原因，以及解决办法。

#24

引用 23 楼 jamesontan 的回复:

引用 18 楼 jamesontan 的回复:
引用 16 楼 do_fork 的回复:
出现大量FIN_WAIT，正好从另一个角度反应了问题，
正常情况下，先shutdown再close，2MSL之后，连接就关闭了。

最好把代码贴出来看看

为何不是先close后shutdown呢？
另外一个角度又什么问题呢?

关键是寻求这种状态产生的原因，以及解决办法。

#25

引用 24 楼 do_fork 的回复:

blogspot上有人提出过这个问题，借着g.cn的cache看到了这个被gfw盾的网页。

两种情况，可能会引起你的那种IDEL state.
    1 client中断了连接，但是没有notify the server
    2 clietn 和 server之间的网络出现故障
我觉得1的可能性比较大

解决方法是：
TCP keepalive option on Solaris

TCP keepalive is a feature provided by many TCP implementations, including Solaris, as a way to clean up idle connections in situations like the ones mentioned above. Applications must enable this feature with the SO_KEEPALIVE socket option via the setsockopt(3SOCKET) socket call. Once enabled, a keepalive probe packet is sent to the other end of the socket provided the connection has remained in the ESTABLISHED state and has been idle for the specified time frame. This time frame is the value specified by the TCP tunable tcp_keepalive_interval.

A keepalive probe packet is handled just like any other TCP packet which requires an acknowledgment (ACK) from the other end of the socket connection. It will be retransmitted per the standard retransmission backoff algorithm. If no response is received by the time specified for the other TCP tunable, tcp_ip_abort_interval, the connection is terminated, as would be the case for any other unacknowledged packet. Hence the actual maximum idle time of a connection utilizing TCP keepalive, which has no responding peer will therefore be:

          tcp_keepalive_interval + tcp_ip_abort_interval

.
To set the relevant TCP tunables on Solaris, run:

你的意思是设置套接字keepalive属性吧？这个也设置了啊，但是还是出现大量IDLE状态啊

#26

没人碰见和解决这样的问题？

#27

sloaris高手们都去哪里了啊？

#28

引用 27 楼 jamesontan 的回复:

sloaris高手们都去哪里了啊？

#29

引用 28 楼 do_fork 的回复:

引用 27 楼 jamesontan 的回复:
sloaris高手们都去哪里了啊？

1. CSDN了解windows之外OS的人本身就不多
2. 不用Linux和BSD用Solaris的更少
3. 遇到过你这个问题的，可能没几个人了
4. 遇到的人里面，看到这个帖子的，还能有几个

没代码，别人很难想象的，这个状态只有solaris有，别的OS没有，
公布完整代码，或者自己翻solaris TCP协议源码，或者继续这么等下去

#30

该回复于2009-11-23 09:09:09被版主删除

请教UNIX下C高手，tcp套接字状态问题

30 个解决方案

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

相关文章