Some tools like tcpdump or ss are mentioned, but those tools are not really comparable to what's described here. What I'd like to see would be a rough comparison with the existing web100 set of kernel patches https://web10g.org/ which is used for many many years in conjunction with the Network Diagnostic Tool (NDT) from Internet2. It provides userland visibility into some of the TCP kernel parameters of each connection via a documented interface that can be used e.g. by a special web server that does performance measurements. Also see http://www.measurementlab.net/.
Similar results could theoretically be obtained with the TCP Dtrace provider, which was added in Solaris 11 if memory serves. I am not aware whether FreeBSD or MacOSX have any similar providers, but my info could be outdated.
The idea behind all these approaches is basically to target a specific TCP connection and generate an event each time a TCP packet arrives. For each of those events, a rolling estimation of the RTT is generated by the kernel and is used as a basis for calculations for the congestion window, which limits how many bytes can be subsequently sent. Various timeouts can probably trigger similar events and so on.
Similar results could theoretically be obtained with the TCP Dtrace provider, which was added in Solaris 11 if memory serves. I am not aware whether FreeBSD or MacOSX have any similar providers, but my info could be outdated.
The idea behind all these approaches is basically to target a specific TCP connection and generate an event each time a TCP packet arrives. For each of those events, a rolling estimation of the RTT is generated by the kernel and is used as a basis for calculations for the congestion window, which limits how many bytes can be subsequently sent. Various timeouts can probably trigger similar events and so on.
(edit: s/packets/bytes/)