How do I get the number of packages transmitted per TCP connection?
I am using Java, but i know I will have to fetch the number from the underlying OS, so this quastion applies to Linux and Windows operating systems and will have different answers for each of them, I assume.
I need this information to profile the network load of an application which seems to send too many small packages by flushing the socket str开发者_开发技巧eams too often.
I think that pure java API does not allow you to do this. As a workaround I'd recommend you to try JPcap.
Looks like you can get it (as root) by either examining /proc/net/nf_conntrack, or running the "conntrack" utility with appropriate parameters.
This assumes that netfilter connection tracking is enabled and you have the utility.
You'll have to find the right connection yourself - but you should be able to identify it by the src/dst/sport/dport
However, I would start by checking your code uses buffering correctly. Is Nagle is left on, the OS will coalesce these writes together even if you send one byte at a time. If Nagle is off, your NIC driver could still coalesce data together. Using tcpdump/windump will confirm the actual packet sizes sent.
How often the application flushes the stream will have little impact on how often the OS sends the data. You could also use a profiler like yourkit or a system tool like strace which can monitor the number of OS calls.
Access to a TCP connection profiler would give this info at the local or server connection level. The number of packets is normally higher than expected for several reasons: header packets and frame packets, connection establish and ack or response packets, secure protocol negotiate and control packets, packets small enough to be processed through POTS phone line equipment in some types of connection, cryptography identity and algorithm control packets, the data transmit protocol in use going through the tcp connection acting as a lower transport layer, actual user or application data in packetised and framed form, connection disconnect packets and responses. The streams may be flushed often if there is a multithread or multiuser situation and every connected user cannot recieve any data characters from the output stream which have just been transmitted to another user.
精彩评论