2

I want to find out how many bytes are transmitted on a tcp socket (I'm using Ubuntu 18.04, by the way). I tried the ss command, but it seems ss can only show the bytes_received, not bytes_sent. So is there any way to show bytes_sent for a socket? And why is this number not shown in ss? I think bytes_received and bytes_sent are closely related.

> ss -ti

ESTAB    0   0   host1:ssh              host2:7703
     cubic wscale:2,8 rto:384 rtt:181.622/16.823 ato:40 mss:1452 cwnd:10 
     ssthresh:118 bytes_acked:120873541 bytes_received:1151501 segs_out:87562 
     segs_in:39194 send 639.6Kbps lastsnd:11732 lastrcv:11564 lastack:11564 
     pacing_rate 1.3Mbps retrans:0/203 reordering:56 rcv_rtt:11516 rcv_space:71360
Victor Chen
  • 21
  • 1
  • 2
  • 1
    From a programming perspective or from an OS perspective? – tadman Jan 07 '19 at 16:08
  • "*I think bytes_received and bytes_sent are closely related.*" - From the perspective of the socket, the number of bytes received and the number sent are not related at all. I'm not presently sure whether the system tracks the statistic you want on a per-socket basis. – John Bollinger Jan 07 '19 at 16:30
  • @tadman OS perspective. And now I think bytes_acked may be what I want, but not sure. bytes_acked, in my opinion, means the number of bytes a socket has sent and been acked by the peer – Victor Chen Jan 07 '19 at 16:45
  • If this is OS-level then it's a question for [SuperUser](https://superuser.com), as Stack Overflow is for programming questions and this is off-topic. – tadman Jan 07 '19 at 16:49
  • The tracking is probably related to the TCP sequence number, which requires tracking the number of payload bytes communicated. However, it is supposed to start from a random initial sequence number (ISN). Might be interesting to look through the implementing kernel code, it may be that the ISN is saved such that the actual bytes can be determined, And you may see what interfaces if any are available to export it. – Chris Stratton Jan 07 '19 at 16:53
  • ...except that sequence numbers are 32 bit and wrap. One might think that would take a long time or 4 GB of data, but with the random start, it may not. – Chris Stratton Jan 07 '19 at 16:55
  • `bytes_acked` (`.tcpi_bytes_acked` in the `struct tcp_info` in ``, obtained using `struct tcp_info info;` via `getsockopt(descriptor, IPPROTO_TCP, TCP_INFO, &info, sizeof info)`) is the number of bytes the other end of the TCP connection has acknowledged it has received correctly, and `bytes_received` (`.tcpi_bytes_received`) is the number of bytes this end of the connection has acknowledged having received correctly. They are a symmetric pair of counters, and probably what OP wants to refer to. These counts do not include retransmissions et cetera. – Nominal Animal Jan 07 '19 at 21:15

1 Answers1

3

I've been looking into this same issue, and have reached the conclusion that it depends on the kernel you are using.

From my tests, I have been able to get bytes_sent, bytes_acked, and bytes_recieved on Linux kernels 4.xx and 5.xx, but not on 3.xx. See example below on Debian GNU/Linux with kernel 4.19.0-6-amd64:

$ ss -itpn

State           Recv-Q           Send-Q                      Local Address:Port                      Peer Address:Port
ESTAB           0                0                          172.16.177.135:22                        172.16.177.1:60928            
users:(("sshd",pid=700,fd=4))
    bytes_sent:50872 bytes_acked:50872 bytes_received:11165

*I cut out the other info that wasn't relevant to this issue

After digging through sock_diag and ss's source code, it looks like ss uses INET_DIAG_INFO of type struct tcp_info to get this info.

I hope this helps and will let you know if I figure anything else out.