Netstat recv-q and Send-q detailed

http://blog.csdn.net/sjin_1314/article/details/9853163

The current connection status of the machine can be viewed by NETSTAT-ANP:

 active Internet connections (servers and established) Proto recv-q send-q Local Address         & nbsp Foreign Address         State       Pid/program nametcp        0 &N Bsp    0 0.0.0.0:8139            0.0.0.0:*             and nbsp LISTEN      -              tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -              tcp        0      0 0.0.0.0:26837           0.0.0.0:*           &NBSP ;   LISTEN      -              tcp        0 &nbsP    0 0.0.0.0:1046            0.0.0.0:*             and nbsp LISTEN      -              tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -              TCP6       0 &nbs P  910 10.100.83.145:57142     10.100.83.140:80        established 7072/java   &nbs P   TCP6       0      0 10.100.83.145:57114     10.100.83.140:80   &N Bsp    established 7072/java       TCP6       0    914 10.100.83.145:57 117     10.100.83.140:80        established 7072/java       TCP6       0    910 10.100.83.145:57126     10.100.83.140:80        established 7072/j Ava       TCP6       0      0 10.100.83.145:57159     10.100.8 3.140:80        established 7072/java       TCP6       0   &NB Sp  0 10.100.83.145:57128     10.100.83.140:80        established 7072/java   Proto,localaddress and so on are better understand, which recv-q send-q specific what is the meaning of it? Why is the send-q time not 0? Doesn't 0 mean that the network exits are blocked? The relevant information was checked against the problem.   A more detailed explanation is: what It Means
"Proto" is a short to protocol, which is either TCP or UDP. "Recv-q" and "send-q" mean receiving queue and sending queue. These should always be zero; If they ' re not might has a problem. Packets should not being piling up in either queue, except briefly, as this example shows:
TCP 0 593 192.168.1.5:34321 VENUS.EUAO.COM:SMTP established
That happened when I hits the "Check Mail" button in KMail; A brief queuing of outgoing packets is normal behavior. If the receiving queue is consistently jamming up, you are might be experiencing a denial-of-service attack. If the sending queue does not clear quickly, you might has an application that's sending them out too fast, or the RECEI Ver cannot accept them quickly enough.
The "Local address" is either your IP and port number, or IP and the name of a service. The "Foreign address" is the hostname and service of connected to. The asterisk is a placeholder for IP addresses, which of course cannot be known until a remote host connects. The current status of the connection. Any TCP state can is displayed here, but these three is the ones you want to see. Reference: http://hi.baidu.com/woshiceo2015/item/f0130d3190b0e9c51a969661 The approximate meaning is: The Recv-q send-q represents the network receive queue, sends the queue respectively. Q is the abbreviation of the queue.

These two values should typically be 0 if not 0 may be problematic. Packets should not have a stacking state in two queues. can accept short-term non-0 cases. As the example in this article, a short send-q queue is sent pakets non 0 is the normal state.

If the receive queue Recv-q has been in a blocking state, it may have suffered a denial of service Denial-of-service attack. If the Send queue Send-q cannot be cleared quickly, it is possible that an application is sending packets out too quickly, or that the other party is not fast enough to receive the packets.

Recv-q: Indicates that the received data has received a buffer locally, but how much has not been taken away by the process, RECV ()

SEND-Q: No data received by the other party, or no ACK, or a local buffer.

By netstat these two values can be simple to determine whether the program received the package is not the package or the package is not recv by the process.

Netstat recv-q and send-q detailed