Google.com is not one computer. Google spreads their locations all over the world including pops in many ISP's.
https://peering.google.com/#/ On 20 November 2016 at 19:18, shimi <linux...@shimi.net> wrote: > > > On Sun, Nov 20, 2016 at 9:38 AM, Shlomo Solomon <shlomo.solo...@gmail.com> > wrote: > >> On Sun, 20 Nov 2016 08:25:18 +0200 >> shimi <linux...@shimi.net> wrote: >> >> > I believe it's called a CDN and/or local compute clusters and the >> > purpose of it is to give you a better user experience, which is a >> > Good Thing (TM). >> > >> snip ... snip ... snip >> > >> > Why do you think it's a problem and are trying to avoid it? >> > >> >> Thanks. I agree that this is "normally" a Good Thing (TM). So I guess I >> have to explain my problem. For a course I'm doing, I had to write >> traceroute in Python - re-invent the wheel :-) >> >> My program works, but I noticed it never reaches www.google.com so I >> checked the "real" traceroute and found the same behaviour. >> >> It seems that neither my program nor the real traceroute handle this >> properly - i.e. they never report that they've reached the final hop. >> I've included traceroute www.godaddy.com and traceroute www.google.com >> for comparison. You can see that traceroute www.google.com never >> reaches the address it's trying to reach - 213.57.24.49 >> >> > I do not believe the fact that you "can't reach it" has anything to do > with www.google.com resolving to an IP in Israel. > > Since I am assuming that for your re-inventing the wheel exercise, you did > learn and understood what traceroute does; But let me explain it anyway for > the answer to your question lies within... > > What traceroute does is essentially send packets to the destination IP by > certain protocol. Popular choices include UDP (I believe that's what the > Linux one does by default), ICMP (I believe that's what the Windows one > does by default) and TCP. > > However, it doesn't send the packet as one normally would, with a large > TTL (Time To Live) value which is expected to reach anywhere on the > Internet (typical values: >= 64), rather than it starts of with setting a > minimal value for TTL, for the purpose of _not_ getting into the target IP, > rather than the packet being dropped by the very first router (hop) on the > chain, resulting in error in packet delivery. > > Per the IP specification, such a packet discarding SHOULD produce an ICMP > (Internet > Control Message Protocol) message being sent by the hop that has discarded > the packet towards the originator of the original packet, telling it that > "TTL expired in transit". The original idea was to avoid packets travelling > to infinitum in routing loops - by decreasing the TTL by 1 on every hop the > packet passes, eventually it will zero out, and the packet will be > discarded, not causing a bandwidth storm. > > So, I said SHOULD. Does it always? Well, no. Some hosts on the Internet > employ something called "a firewall", which blocks ICMP for various reasons > (you'll hear the word "security" in some places); As a regular user who > opens his browser and types in 'https://www.google.com/' - you don't > really care. ICMP is not typically used when establishing a connection to a > server on the Internet (well, that's not accurate; lack of PMTU discovery > is an excellent way to get your IT people to pull some hairs out when any > tunnel is involved, including dialup and Israeli "MPLS" connections, a.k.a. > "dialer-less HOT"... but for the sake of discussion and to explain how did > they ended up deciding to filter those packets and affect you - probably > not knowing what else they break - then "it's not typically used") > > Sometimes the filtering is not of ICMP at all, rather than the original > protocol you're trying to probe with; A random UDP port at the area of > 30,000 typically has no business traversing their network, so your original > packet (if you're using UDP packets for your traceroute program) may have > been firewalled and never reached a router to lower its TTL by 1 and expire > it in transit to produce the ICMP message you're expecting... In that case, > where ICMP is not actually block, rather your UDP connection is, you might > find out that running: > > traceroute -I 213.57.24.49 > > (I for ICMP Echo based traceroute) > > Does actually get you to the target. However, you'll have to run this as > root, because generating ICMP packets is not something the regular user can > do. Of course, you can opt to chmod +s your traceroute binary... > > Hope this helps, > > -- Shimi > > > > _______________________________________________ > Linux-il mailing list > Linux-il@cs.huji.ac.il > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il > > -- <http://au.linkedin.com/in/gliderflyer>
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
