SS Command and Recv-q and SEND-Q states

Ss

Used to display the socket information in the active state. The SS command can be used to get socket statistics, which can display and netstat similar content. But the advantage of the SS is that it can show more and more detailed information about TCP and connection status, and is faster and more efficient than netstat .

When the number of socket connections for a server becomes very large, either using the netstat command or direct cat /proc/net/tcp, the execution speed is slow. You may not have a personal feeling, but please believe me, when the server maintains a connection of tens of thousands of times, the use of netstat equals wasting life, and the SS is to save time.

The World martial arts only fast not broken. The secret of the SS Fast is that it leverages the Tcp_diagin the TCP protocol stack. Tcp_diag is a module for analyzing statistics that gives you first-hand information in the Linux kernel, which ensures that the SS is fast and efficient. Of course, if there is no tcp_diagin your system, theSS can run normally, but the efficiency will become slightly slower.

Options

-h: display help information;

-V: Display instruction version information;

-n: Do not resolve the service name and display it numerically;

-a: display all sockets;

-l: Display the socket in the listening state;

-o: display timer information;

-m: displays the memory usage of the socket;

-p: display process information using sockets;

-i: display internal TCP information;

-4: Only ipv4 sockets are displayed;

-6: Only the socket of ipv6 is displayed;

-t: only show tcp sockets;

-u: only shows udp sockets;

-d: Display only DCCP sockets;

-w: display only RAW sockets;

-x: Display only UNIX domain sockets.

Instance





Show TCP connections

[[email protected] ~]# ss -t -a
State       Recv-Q Send-Q                            Local Address:Port                                Peer Address:Port   
LISTEN      0      0                                             *:3306                                           *:*       
LISTEN      0      0                                             *:http                                           *:*       
LISTEN      0      0                                             *:ssh                                            *:*       
LISTEN      0      0                                     127.0.0.1:smtp                                           *:*       
ESTAB       0      0                                112.124.15.130:42071                              42.156.166.25:http    
ESTAB       0      0                                112.124.15.130:ssh                              121.229.196.235:33398 

Show Sockets Summary

[[email protected] ~]# ss -s
Total: 172 (kernel 189)
TCP:   10 (estab 2, closed 4, orphaned 0, synrecv 0, timewait 0/0), ports 5

Transport Total     ip        IPv6
*         189       -         -        
RAW       0         0         0        
UDP       5         5         0        
TCP       6         6         0        
INET      11        11        0        
FRAG      0         0         0   

Lists the current established, closed, orphaned, and waiting TCP sockets

View the socket used by the process

[[email protected] ~]# ss -pl
State       Recv-Q Send-Q                                Local Address:Port                                    Peer Address:Port   
LISTEN      0      128                                              :::ssh                                               :::*        users:(("sshd",1292,4))
LISTEN      0      128                                               *:ssh                                                *:*        users:(("sshd",1292,3))
LISTEN      0      128                                       127.0.0.1:ipp                                                *:*        users:(("cupsd",1165,7))
LISTEN      0      128                                             ::1:ipp                                               :::*        users:(("cupsd",1165,6))
LISTEN      0      128                                               *:32957                                              *:*        users:(("rpc.statd",1104,9))
LISTEN      0      128                                              :::57637                                             :::*        users:(("rpc.statd",1104,11))
LISTEN      0      80                                               :::mysql                                             :::*        users:(("mysqld",1528,17))
LISTEN      0      128                                               *:6379                                               *:*        users:(("redis-server",1672,5))
LISTEN      0      128                                              :::6379                                              :::*        users:(("redis-server",1672,4))
LISTEN      0      128                                              :::sunrpc                                            :::*        users:(("rpcbind",1084,11))
LISTEN      0      128                                               *:sunrpc                                             *:*        users:(("rpcbind",1084,8))
LISTEN      0      128                                               *:http                                               *:*        users:(("nginx",1685,13),("nginx",3698,13),("nginx",3699,13))

Find out the open socket/port application

 



 




[root@localhost ~]# ss -pl | grep 3306
0      0                            *:3306                          *:*        users:(("mysqld",1718,10))

refer to the Linux command network, while you can see the explanation of operational survival time https://www.ttlsa.com/linux-command/ss-replace-netstat/

About Recv-q and Send-q states

On the Internet a search for most of the claims are like this:

RECV-Q represents the network receive queue
Indicates that the received data has received buffering locally, but how much has not been taken away by the process, recv ()
If the receive queue Recv-q has been in a blocking state, it may have suffered a denial of service Denial-of-service attack.

SEND-Q indicates a network send queue
No data received by the other party, or no ACK, or a local buffer.
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.

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.

for the above statement can not be said wrong, but at least not completely correct, I feel that the bottom is the positive solution, from: Some problems with TCP queue.

1. When the client sends a SYN packet to the server via connect, the client maintains a socket waiting queue, and the server maintains a SYN queue.

2. At this time, enter the state of the semi-link. If the socket waits for the queue to be full, the server will discard, and the client will return the connection time out; as long as the client does not receive the SYN+ACK, after 3s, the client will send again. If it is still not received, it will continue to be sent after 9s.

3. The length of the semi-join syn queue is max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog).

4. When the server receives the SYN packet of the client, it will return SYN, the ACK packet will be confirmed, and the client's TCP protocol stack will wake up the socket waiting queue and issue a connect call.

5.client returns the ACK packet, the server will enter a new queue called accept, the length of the queue is min (backlog, somaxconn), by default, the value of somaxconn is 128, indicating that there are up to 129 ESTAB connections. Wait for accept(), and the value of backlog is specified by the second parameter in int listen(int sockfd, int backlog). The meaning of the backlog in listen is shown here. It's important to note that some Linux hairstyle versions may have truncating methods for somaxcon errors.

6.When the accept queue is full, even if the client continues to send ACK packets to the server, it will not be corresponding. At this time, the server decides how to return by /proc/sys/net/ipv4/tcp_abort_on_overflow, and 0 means discarding directly. ACK, 1 means to send RST to notify client; correspondingly, client will return read timeout or connection reset by peer respectively. The above is just a theory. If the server does not call accept() in time, when the queue is full, the server will not respond to the SYN and return ETIMEDOUT as described in the theory. According to the description of this document, the actual situation is not the case, the server will randomly ignore the received SYN, the number of connections established can be increased indefinitely, but the client will encounter delays and timeouts....

As you can see, the entire TCP stack is like the next two queues:
1. One is the half open (SYN queue) queue (max (Tcp_max_syn_backlog, 64)), which is used to hold syn_sent and SYN_RECV information.
2. The other one is the Accept queue (min (somaxconn)), which saves the state of Estab, but calls accept ().

Note that I had some errors with Recv-q/send-q's understanding before, and the meaning expressed in the LISTEN state and non-LISTEN state was different with the Recv-q/send-q obtained by using SS. the difference between the two can be seen from the TCP_DIAG.C source code:

LISTEN Status: Recv-q represents the current waiting server call accept to complete the three handshake LISTEN backlog value, that is, when the client through connect () to connect the server is LISTEN (), these connections will remain in this que The UE is inside until the server accept (), Send-q represents the largest listen backlog value, this is the above mentioned min (backlog, somaxconn) value.
Remaining states: No problems were understood before the LISTEN state. Recv-q represents the number of bytes in the Receive queue; Send-q represents the bytes value in the Send queue.

SS Command and Recv-q and SEND-Q states

Alibaba Cloud Hot Products
Elastic Compute Service (ECS)	Dedicated Host (DDH)	ApsaraDB RDS for MySQL (RDS)	ApsaraDB for PolarDB(PolarDB)	AnalyticDB for PostgreSQL (ADB for PG)
AnalyticDB for MySQL(ADB for MySQL)	Data Transmission Service (DTS)	Server Load Balancer (SLB)	Global Accelerator (GA)	Cloud Enterprise Network (CEN)
Object Storage Service (OSS)	Content Delivery Network (CDN)	Short Message Service (SMS)	Container Service for Kubernetes (ACK)	Data Lake Analytics (DLA)
ApsaraDB for Redis (Redis)	ApsaraDB for MongoDB (MongoDB)	NAT Gateway	VPN Gateway	Cloud Firewall
Anti-DDoS	Web Application Firewall (WAF)	Log Service	DataWorks	MaxCompute
Elastic MapReduce (EMR)	Elasticsearch