How to Trace TCP Socket TCP_INFO tcpi_rcv_rtt in Linux Using eBPF

In standard TCP diagnostic workflows, round-trip time (RTT) measurements typically reflect sender-side telemetry: the sender timestamps outgoing segments and calculates RTT when acknowledgements return. However, in asymmetric network topologies, server-push architectures, or download-heavy proxy nodes, the local server functions primarily as a TCP receiver. Measuring how quickly the remote sender responds from the perspective of an inbound data receiver is critical for diagnosing reverse-path latency and client connection quality.

The Linux kernel tracks the receiver’s estimated round-trip time in struct tcp_info as tcpi_rcv_rtt. Using extended Berkeley Packet Filter (eBPF) and bpftrace, systems engineers can trace tcpi_rcv_rtt directly within the kernel networking stack to measure inbound peer latency non-invasively.

Understanding tcpi_rcv_rtt in the Linux Kernel

Inside the Linux TCP subsystem (defined in include/uapi/linux/tcp.h), struct tcp_info provides receiver-specific RTT metrics:

struct tcp_info {
    /* ... state fields ... */
    __u32   tcpi_rtt;       /* Sender smoothed RTT (us) */
    __u32   tcpi_rttvar;    /* Sender RTT variance (us) */
    __u32   tcpi_rcv_rtt;   /* Receiver estimated RTT (us) */
    __u32   tcpi_rcv_space; /* Receiver window clamping space */
};

The tcpi_rcv_rtt measurement is computed during packet reception using TCP timestamp options (RFC 7323) or interval spacing between consecutive data segments. Unlike sender RTT, which requires active data transmission, tcpi_rcv_rtt allows passive monitoring of incoming data streams.

Authoring the bpftrace Receiver RTT Probe

The following bpftrace script monitors tcp_rcv_established() to sample rcv_rtt across incoming connections:

#!/usr/bin/env bpftrace

#include <net/sock.h>
#include <linux/tcp.h>

kprobe:tcp_rcv_established
{
    $sk = (struct sock *)arg0;
    $inet = (struct inet_sock *)$sk;
    $tp = (struct tcp_sock *)$sk;

    $daddr = ntop($inet->inet_daddr);
    $saddr = ntop($inet->inet_saddr);
    $dport = bswap($inet->inet_dport);
    $rcv_rtt_us = $tp->rcv_rtt_est.rtt_us;

    // Report inbound connections where estimated RTT exceeds 80ms
    if ($rcv_rtt_us > 80000) {
        time("%H:%M:%S ");
        printf("HIGH INBOUND LATENCY | %s <- %s:%d | Rcv_RTT: %d ms | Adv_Wnd: %d\n",
            $saddr, $daddr, $dport, $rcv_rtt_us / 1000, $tp->rcv_wnd);
    }
}

Running the Trace and Diagnosing Asymmetric Paths

Execute the bpftrace script with root privileges:

sudo bpftrace trace_rcv_rtt.bt

The trace stream outputs live diagnostics when high peer latency occurs:

21:10:04 HIGH INBOUND LATENCY | 10.0.1.5 <- 198.51.100.22:443 | Rcv_RTT: 142 ms | Adv_Wnd: 65536
21:10:08 HIGH INBOUND LATENCY | 10.0.1.5 <- 203.0.113.89:8080 | Rcv_RTT: 215 ms | Adv_Wnd: 32768

This output demonstrates how receiver RTT tracking pinpoints remote peers suffering from satellite latency, long-haul transatlantic routing, or mobile cellular backhaul delays.

Production Applications and Monitoring

Tracking tcpi_rcv_rtt via eBPF enables web platforms to:

1. Dynamically tune HTTP/2 and HTTP/3 stream concurrency for clients experiencing elevated reverse-path latency.
2. Identify ISP routing asymmetry where outbound traffic travels via direct peering but inbound traffic routes through congested transit paths.
3. Correlate receiver latency spikes with user-perceived Core Web Vitals (such as Interaction to Next Paint).