I'm wondering whether there is a programmatic way to obtain a measure of the full bandwidth used when sending data through a TCP stream. Since I cannot seem to know how the network stack would divide the stream into packets, or when it sends a TCP SYN or ACK or many of the things it does in the background for you, I can only get a rough estimate for this.
The only solution I can think of is to actually sniff the interface, but I would like to think that the stack can already collect this stats for me.
This is running in Java under either Windows or Linux (of course, a portable solution would be preferred), but I can JNI-ize a C/C++ answer so that (and OS API calls) is a fine answer too. Thank you!
[Windows specific answer]
On Windows you can consider looking at ETW (Event Tracing for Windows). In general, ETW is the technology used to provide tracing/logging information on Windows, and most Microsoft software is already instrumented with ETW providers that you can use. In your case, I think the Microsoft-Windows-TCPIP provider has information (e.g. local/remote address and port, operation, bytes sent/received, etc) that might be helpful for you.
For example, I was able to start collecting the TCPIP events to a file using the command:
logman start MyTcpipLog -p Microsoft-Windows-TCPIP -ets
And stop with
logman stop MyTcpipLog -ets
Then the MyTcipipLog.etl file can be opened using a number of different tools (e.g. xperf), but there are APIs that you can use to parse this file yourself.
If you wanted to be doing this at runtime, you can create a "real-time" ETW session to process the events as they come in.
If you're new to ETW, here's a helpful article on MSDN that I used.
Can't speak for Windows, but the Linux kernel, as of 2.6.37, is not collecting the statistics you are looking for. Per-socket stats would have to be in struct sock or its descendants and I am not seeing any transmit/receive counters there:
On Linux, this is fairly trivial information for root to get (simply create a netfilter chain matching your traffic, you can use a process id match, for example, later read the counters associated with the chain). Doing it with limited permissions may well be impossible.
Not sure for Windows.
It should be possible to use conntrack accounting to measure packets and bytes on a per connection basis. Then the information should be queried using netlink sockets. Get the information about your socket with getsockname and getpeername, and use this information to look up the connection tracking entry.
This requires recent enough kernel, conntrack module loaded and libnetfilter_conntrack.
Also, the same information is available in /proc/net/nf_conntrack, but that file shouldn't be parsed too frequently.
And there's a tool named "conntrack" that gives you access to this information from the command line.
You could look into consuming Perfmon counters. The Network Interface/Current Bandwidth counter might be what you need. You can create and consume performance counters from .NET code.
Well TCP is a fixed data gram which is specified by the MTU. If you know your MTU, you can figure out how many data grams you have to transmit and TCP follows a standard model for acknowledgment.
Here is a good article on that help figure out the overhead of data transmission, which includes the overhead of Ethernet and the other layers of the stack.
If this TCP stream is the only thing going through your interface, you could just query the interface statistics (bytes sent/received) and measure the time yourself (+do the math).
来源：https://stackoverflow.com/questions/2193321/how-to-measure-the-tcp-ip-overhead-without-sniffing