0

Given that different operating systems may use different packet types (for example: UDP packets, TCP packets, ICMP echo requests), can I be certain that an active browser session will follow the same path that a traceroute call would follow?

In other words, if I am actively browsing www.stackexchange.com can I be certain my session is being routed through the nodes returned by traceroute to www.stackexchange.com concurrent to the active browser session?

2 Answers 2

2

If you don't already understand IP Routing, then the results from traceroute will not tell you anything. The route between two nodes over the wider Internet can change from second to second. And the route in one direction is not the same as the return route. And that's not even accounting for the fact that the specific case you mention uses a CDN, meaning that not only can the route change, but the actual machines you are talking to can be different.

Having said that, there is no guarantee that the route you get from traceroute is the same as your application is using. This can be for several reasons (probably more than a dozen, if you count obscure cases), including:

  • an ISP in the path that purposely routes traceroute packets differently to hide their topology

  • the topology changes in some way between the traceroute and the TCP SYN

  • there is some form of load balancer or CDN that purposely redirects some traffic

Those are the most likely ones that I can explain without delving deeper into how the net works.

And, by the way, your comment "different operating systems may use different packet types" is incorrect. Every system connected to The Internet uses all those packet types, you can't operate on the net without them.

5
  • I think I do understand the principles of IP routing - I've just been 'out of the game' for 4-5 years WRT various technology implementations currently used. I understand that each OS is capable of using TCP|UDP|ICMP (and more) - my question was driven to understand practical routing mechanisms for a project I'm working on. My 'different OS' comment was specific to the traceroute command as I'm sure you are cognizant.
    – TL7
    Jul 5, 2016 at 19:27
  • After further reading your response, I think you missed an important part of my original post: session. Load balancers and CDN's work within the context of establishing a session connection but should remain persistent until such time as the stateful components (TCP, BGP) of that session connection are terminated.
    – TL7
    Jul 5, 2016 at 20:23
  • The context (and level) of this topic is important. Whilst in theory (i.e., at a high level) packet routing through the Internet is very dynamic, for a specific (and finite) session connection, packet routing is not dynamic. Within this session context, the routing paths (outbound and inbound) are persistent - unless other routing technologies are 'inserted' into the session (for example, Tor browser).
    – TL7
    Jul 5, 2016 at 21:14
  • @TL7 You should probably update the question to at least fix the wording about Operating Systems and make it clear you really mean different implementations of traceroute and they may have different defaults but also have options to select. Also, it wasn't clear to me when I read it that you were doing your traceroute during the session. In rereading just now with that in mind I see it was intended, you may want to reword that part a little, too.
    – MAP
    Jul 6, 2016 at 0:11
  • @TL7 Once you have opened a TCP connection, subsequent packets in that same connection can still follow different routes. In many parts of the Internet core, there may be routing changes internal to an ISP that happen on the order of seconds. This is why some ISPs try to detect traceroute packets and route them specially, to hide their topology and internal routing. Also, a point you don't seem to be thinking about is asymmetric routing, which is very common. The return path from the far end may not be the same (usually the same ASes, but hot potato means handoff at different places).
    – MAP
    Jul 6, 2016 at 0:17
1

Normally, the traceroute will use ICMP message. If we use the TCP or UDP message, the traceroute can't know the services running on the destination computer, which means it's hard to determine the port in TCP or UDP message. But the ICMP message should be OK if there is no firewall blocking the ICMP message.

can I be certain that an active browser session will follow the same path that my traceroute call makes?

In brief, no. If there is a load balancer between your computer and the destination computer, the path may be different because the traceroute and the browser are using two sessions.(It depends on the rules on load balancer.)

2
  • Thanks for the input WRT traceroute. I'm not so much concerned about what happens 'inside' my target destination's firewall - I'm trying to understand how to identify/analyze the HTTP/HTTPS routing from a 'real world' perspective. Any suggested tools to use?
    – TL7
    Jul 5, 2016 at 19:48
  • Traceroute is best option. What I mean is that the traceroute may not shows the exactly same path with the browser. In most situation, the traceroute is able to show the path if there is no firewall restriction or load balancer. If there is a firewall and it blocks the ICMP message, there is no way to detect the path behind it. Because the traceroute relies on the ICMP message replied by the every nodes in the path. If the firewall blocks it, you'll get timeout. Jul 6, 2016 at 12:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .