What is the best way to measure latency via a "telnet to port" test, preferably with built-in Linux tools?

Question

I'm writing a Graphite/Diamond collector measuring network latency. Specifically it should measure the time it takes to open up a connection to a port on a remote server. And it needs to work via script, i.e. no humans on the keyboard running this interactively.

To give an example with a fictional parameter to telnet which would do exactly what I need.

time telnet --close-connection-immediately-after-established somehost.somedomain.com 1234

Trying somehost.somedomain.com...
Connected to somehost.somedomain.com.
Escape character is '^]'.
Connection closed automatically after established.

real    0m3.978s
user    0m0.001s
sys 0m0.003s

Basically, what's a command-line way to output 3.978 given the example above using only builtin tools?

You could wrap the telnet in an expect script I suppose and have it issue:

^]
close

... but that seems rather ugly. Any ideas?

Solution 1

What about :

time nc -zw30 <host> <port>

Solution 2

Just use ping or configure a client-server setup and use one of the established unix network benchmarking tools:
https://www.binarytides.com/linux-commands-monitor-network/
https://access.redhat.com/solutions/2122681

--

While time+nc is useful in getting ballpark estimation on latency, it should not be used as a fact in production connections evaluation.

For example, instantiation and running of extra processes (like time) costs, well, time. For example, I got 15-20ms results with time+nc, while with traditional ping/ICMP echo, results were on the side of 3-5ms. For quick test, ping seemed to do the job, for more elaborate results, one usually needs a client-server setup.

Comments

[alexus]

I think using expect probably is your best bet...

[Bert]

{ time nc -v -z r300.isovega.net 22; } |& grep real | awk '{print $2}'

[Xavier Lucas]

Network latency has nothing to do with the time taken for a connection to be in the TCP state ESTABLISHED. And that's also off-topic.

[r3cgm]

Nicely done! That's perfect.

[Teja Vemulapalli]

In case of error nc: invalid option — 'z': use solution mentioned in this answer

[straville]

Using time incurs extra process instantiations and executions, compared to the natural state of using e.g. a socket connection, and as such doesn't give accurate picture of the network latency. See my answer for details

[r3cgm]

Thanks for the response. To clarify, the intent of the original question was to measure as you describe, not just network latency but all the overhead time for the remote server to negotiate a port connection request. The client-server setup was already in place.

[duality_]

Additionally, not all servers allow for ping.