3 ms·
One thing about traceroute that I doubt most casual users think about (maybe I'm wrong) is that its output only shows you the forward path. That is, it shows yo
by jvolkman 5y ago
One thing about traceroute that I doubt most casual users think about (maybe I'm wrong) is that its output only shows you the forward path. That is, it shows you the path your packet takes from when it leaves your machine to when it gets to the destination. The path that a response packet originating at that destination and travelling back to you can take a different path (sometimes wildly different) and - while you'd see that captured in latency - you wouldn't see it captured in the list of routers.
So a packet from Seattle to Hawaii may take the most direct undersea cable, but the response packet may be routed through California, adding significant geographic distance.
- kemals 5y agoThis comment is spot on. This is asynchronous nature of the computer networks. While it is easy to control the path within smaller or enterprise networks, it is very likely that the reverse path on the internet is going to be different compared to forwarding path. Following that, the real challenge is, in case that you are dealing with some issue, to detect where the issue is, given that it might be happening on the reverse path that you don't have visibility into.
- kloch 5y agoA similar mistake can easily be made when using iperf to measure throughput or identify performance problems. In TCP mode the results reflect a combination of forward and return path effects, though the return path usually has less effect on total throughput than forward path. Only with UDP mode can you accurately measure unidirectional path performance.