Show HN: How did your computer reach my server?

Hi! I&#x27;m Lexi. I&#x27;m 17, and one of the things I&#x27;m interested in right now is gaining a deeper understanding of how computers work and showing that in new ways.<p>A few months ago I published <a href="https:&#x2F;&#x2F;cpu.land" rel="nofollow noreferrer">https:&#x2F;&#x2F;cpu.land</a> (discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37062422">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37062422</a>). After cpu.land, I felt a lot of pressure to make another Big Giant Thing but didn&#x27;t really have anything compelling. So I just hacked away on personal projects and, through some coincidental learning on how the Internet works, ended up hacking together a traceroute program that could live stream to a website from scratch!<p>I realized I had never seen this sort of thing on the web before, and it was actually a kind of cool and novel way of visualizing the structure of the Internet, so I polished it up and built a pretty site around it. In the process, I learned some really interesting things about how BGP and the structure of The Internet, so I melted the traceroute tool with an article sharing that knowledge.<p>I&#x27;m still hacking on this and I&#x27;m sure my code will manage to break somehow, so please let me know if you have any suggestions! :)<p>(Side note: why Rust? I don’t think programming language choice matters that much, but I wanted to quickly write a very dependable low-level program, and I really like Rust’s error handling primitives. Why do you care about this?)

&gt; BGP is the protocol that gives the Internet its shape, and you can’t directly speak it yourself.<p>It&#x27;s actually surprisingly easy to get an ASN for yourself and speak BGP. If you find building something like this tool interesting, you should give it a try. I wrote an introduction of sorts earlier (<a href="https:&#x2F;&#x2F;qt.ax&#x2F;asn" rel="nofollow noreferrer">https:&#x2F;&#x2F;qt.ax&#x2F;asn</a>) if that interests you.

This is &quot;how your server reaches my computer but reversed&quot; rather than &quot;how my computer reaches your server&quot;. The routing in each direction will most likely be very different.

Here&#x27;s a paper you might be interested in with regards to how traceroute works. One thing that many (non-network) folks miss is that traceroute is not necessarily symmetrical -- the return path may differ.<p><a href="https:&#x2F;&#x2F;archive.nanog.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;traceroute-2014.pdf" rel="nofollow noreferrer">https:&#x2F;&#x2F;archive.nanog.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;traceroute-201...</a>

&gt; WHOIS is actually an... interesting protocol to make a parser for.<p>It&#x27;s actually impossible. Responses are essentially free-form (if the server responds at all). I tried my hand at this; you can make an ad-hoc &quot;parser&quot; that works for 90% of addresses&#x2F;domains (or you could, ten years ago when I tried). But the remainder are intractable.<p>Nowadays it&#x27;s much worse; nearly everything is hidden behind privacy shields, which purport to protect PII. But WHOIS records aren&#x27;t supposed to contain personal information; they&#x27;re supposed to contain contact information for network operators.<p>This is ICANN&#x27;s doing, I&#x27;m afraid. ICANN had a rule that networks should provide public WHOIS servers. They never enforced the rule, and now they&#x27;ve scrapped it.

You can go one step further and instead of separate ICMP ECHO trace, use existing HTTP TCP connection between client&#x27;s browser and your web server. That way you can traverse client-side NAT and&#x2F;or stateful firewall.

Here&#x27;s some earlier work on reverse traceroute:<p><a href="https:&#x2F;&#x2F;research.cs.washington.edu&#x2F;networking&#x2F;astronomy&#x2F;reverse-traceroute.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;research.cs.washington.edu&#x2F;networking&#x2F;astronomy&#x2F;reve...</a><p>paper: <a href="http:&#x2F;&#x2F;www.cs.washington.edu&#x2F;homes&#x2F;ethan&#x2F;papers&#x2F;reverse_traceroute-nsdi10.pdf" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.cs.washington.edu&#x2F;homes&#x2F;ethan&#x2F;papers&#x2F;reverse_trac...</a><p>video: <a href="http:&#x2F;&#x2F;www.usenix.org&#x2F;multimedia&#x2F;nsdi10katz-bassett" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.usenix.org&#x2F;multimedia&#x2F;nsdi10katz-bassett</a>

You might be interested to know that many times, packets in a TCP session take asymmetric routes across the internet. In my experience, the most common reasons for this are business rules related to cost and human error.<p>If you think about how IP works, you’ll see that this doesn’t particularly matter but that it can make understanding the routing more difficult.

On my device, there are no intermediate steps shown between my device and the server. Just FYI.

I think it&#x27;s also worth mentioning mtr, which is what I use much more frequently than traceroute. It can help diagnose intermittent packet loss, and gives you an averaged sense of how things flow.<p>This article from APNIC explains more about mtr and how to read it (plus some interesting details about how MPLS can obscure true paths)<p><a href="https:&#x2F;&#x2F;blog.apnic.net&#x2F;2022&#x2F;03&#x2F;28&#x2F;how-to-properly-interpret-a-traceroute-or-mtr&#x2F;#:~:text=Traceroute%20is%20a%20one%2Dshot,is%20the%20tool%20to%20use" rel="nofollow noreferrer">https:&#x2F;&#x2F;blog.apnic.net&#x2F;2022&#x2F;03&#x2F;28&#x2F;how-to-properly-interpret-...</a>.<p>Also worth noting: It&#x27;s also sometimes useful to trace with UDP, and many routers will drop ICMP selectively under strain.<p>Nice article, and excellent presentation!

As it was mentioned above, you are not measuring connection from the client to the server, but from the server to the client. It can be a completely different route, and internal routing behind the IP is hidden. You should try 0trace to get the real route

Very cool way to present this. Obviously there&#x27;s a lot of legwork here, but for major ISPs you could probably use some heuristics to give a little more detail on internal network structure. Comcast, for example, has their core network under ibone.comcast.net, but their HFC infrastructure directly under comcast.net. So you can tell when traffic makes the jump from their HFC consumer ISP network to their backbone. At one point I had some notes on patterns like this for a number of the majors but I think I&#x27;ve lost it. :(

&gt; My claim that this website’s traceroute was the path your packets took to reach my server was a bit of a white lie. To calculate that, I would’ve had to be able to run a traceroute to my server from your computer. Instead, I ran the traceroute from my server to your computer and just reversed it. That’s also why the traceroute at the top seemingly loads in reverse order.<p>I was wondering if we&#x27;d address this. That was my first thought - how can you do this without initiating ICMP from my side?<p>&gt; Does running a “reverse traceroute” sacrifice accuracy? A little, actually.<p>&gt; As I said when describing Internet routing, each device a packet traverses makes a decision about where to send the packet next until it reaches its final destination. If you send a packet in the other direction, the devices might make different routing decisions… and if one device makes one different decision, the rest of the path will certainly be different.<p>&gt; This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.<p>Sure... But it&#x27;s pretty common for multi pathed AS&#x27; to traverse in all sorts of different ways. My experience (non residential) is that more often than not, the trace and reverse trace were different. Your upstreams and my upstreams have very different commercial agreements, and both peer and transit in multiple places.<p>Still cool though, well done!

SQUIRREL!!!<p>How did you manage to tilt the section header text? I&#x27;ve not seen that done before.

Akami blocks the return trace which is no fun. But regarless a cool project.<p>9 a23-203-147-39.deploy.static.akamaitechnologies.com (23.203.147.39) 36.707 ms 36.783 ms 40.110 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * *

IPv6 support would be great for this. I run my own AS (AS200676) and one of my prefixes is actually announced at my home. I&#x27;m really curious as to what would the auto-generated green text say about that route.<p>I announce only IPv6, because I don&#x27;t currently have access to any v4 blocks, they are expensive and I have little need for one.

There should be a traceroute protocol whereby a &quot;specially marked packet&quot; is understood to be traceroute, and generates an ICMP response even though its TTL is still positive. The ICMP response will carry the observed TTL value.<p>Then one packet will get all the echoes in one go instead of having to send a tirade of packets with increasing TTL values.

Great write up, thank you for making this! From a learning design perspective, the blend of static and dynamic prose based on my own packet’s journey was super cool, not something I’ve seen done quite that way before.<p>Makes me imagine an online programming textbook that could to walk you through what your own custom code is doing. Very cool!

Doesn&#x27;t work at all with Enhanced Tracking Protection enabled in Firefox, and times out when it is disabled.<p>I guess it&#x27;s supposed to do something like this: <a href="https:&#x2F;&#x2F;dnschecker.org&#x2F;online-traceroute.php" rel="nofollow noreferrer">https:&#x2F;&#x2F;dnschecker.org&#x2F;online-traceroute.php</a>

NANOG relevant talk (PDF): <a href="https:&#x2F;&#x2F;archive.nanog.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;10_Roisman_Traceroute.pdf" rel="nofollow noreferrer">https:&#x2F;&#x2F;archive.nanog.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;10_Roisman_Tra...</a>

There&#x27;s no possible way to guarantee that traceroute is accurate. The same route is not taken both directions.<p>A Practical Guide to (Correctly) Troubleshooting with Traceroute by Richard A Steenbergen explains it well

&gt; <i>&quot;Hi! I&#x27;m Lexi. I&#x27;m 17...&quot;</i><p>Holy shit. This girl&#x27;s going places. I just skimmed <a href="https:&#x2F;&#x2F;kognise.dev" rel="nofollow noreferrer">https:&#x2F;&#x2F;kognise.dev</a> and saw that in addition to the deep understanding of TCP&#x2F;IP and all 7 layers of the OSI model she appears to posses, she also does front- and back-end development, embedded hardware, mobile apps, and compilers. She also rock climbs, can pilot a Cessna (all by herself), build robots, plays (<i>and</i> composes music for) the cello (since she was 5 years old apparently).<p>Do I need to keep going? This is nothing short of incredible. If I did 1&#x2F;10 of the things this kid&#x27;s already done by the time I kick the bucket I would have lived a full life.

Do the h3 heading tags look like they&#x27;re tilted a little bit? CSS&#x2F;font trickery? Just me?

Note, I geo-block IP&#x27;s not from Australia for my home network. This is why it failed for me.

I might not now an y better, but this implementation seems so cool.<p>Can I trace the location of an AS?

You can even use traceroute to send short hidden messages! :D

Love the looooong furret in your header image! :D

It would be cool to add a map of the hops.