According to its manual page on a Linux system, ss(8)
is "another utility to investigate sockets"; it's Linux-specific, part of iproute
, but seems to be similar in concept to the more mainstream netstat
.
This is a sample output from ss -i
:
# ss -i | head
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 173.xxx.xxx.xxx:46780 72.21.203.xx:www
cubic wscale:6,7 rto:276 rtt:76/38 cwnd:10 send 1.5Mbps rcv_space:14600
ESTAB 0 0 173.xxx.xxx.xxx:35674 208.71.121.xx:www
cubic rto:272 rtt:72/36 cwnd:10 send 1.6Mbps rcv_space:14600
ESTAB 0 0 173.xxx.xxx.xxx:33496 198.252.206.xx:https
cubic wscale:9,7 rto:274 rtt:74.875/2.25 ato:40 cwnd:10 send 1.5Mbps rcv_rtt:524913 rcv_space:29456
ESTAB 0 0 173.xxx.xxx.xxx:49605 205.251.242.xx:www
cubic wscale:6,7 rto:282 rtt:82.625/37.5 cwnd:10 send 1.4Mbps rcv_space:14600
As you can see, information about receive and send queue is available, just as with netstat
, but ss
goes further, and also provides additional info, all of which appears to revolve around the concept of TCP window scaling and buffer size of the socket, and around the concept of bandwidth-delay product.
So, this bandwidth that you're talking about is most likely calculated through the division of the send buffer size by rtt (round-trip time). Any such calculation is bound to be very coarse, imprecise and variable, so, when you see a value like 1.6Mbps
, there's not much point to know more decimal points, since the whole number is simply a moving target in the first place.
NETLINK_INET_DIAG
delivers.