Heh - You _learn_ that Anycast isn't good for TCP, but LinkedIn proved differently. Their website uses TCP (obviously), works almost always, and gracefully recovers when Anycast throws a curve.
There's a great interview on Packet Pushers with LinkedIn Global Engineering: Packet Pushers: Show 286: Busting Anycast TCP Myths http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/ ...and a blog post: https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality -Mike Tewner On Fri, Nov 25, 2016 at 12:14 AM, Amos Shapira <amos.shap...@gmail.com> wrote: > Anycast is not suitable for TCP. > It IS fantastic for DNS (which uses UDP), which is the first thing a > client does most of the time to find the server. > Akamai control server groups by allocating per-customer per-object host > names, then these can be resolved using their very highly customised DNS > servers to the right server (also taking into account dynamic changes like > server cluster load or failure). > Since DNS uses UDP and the traffic consists on one packet in each > direction, Anycast is ideal for that scenario. > The actual content transfer (e.g. move streams, which is where I with > Akamai for stan.com.au) doesn't use Anycast. > > On 24 November 2016 at 04:06, Shachar Shemesh <shac...@shemesh.biz> wrote: > >> On 22/11/16 02:19, Amos Shapira wrote: >> >> On 21 November 2016 at 18:20, Shachar Shemesh <shac...@shemesh.biz> >> wrote: >> >>> The DNS resolving google.com guesses your gegraphical location, and >>> gives you an answer that is nearest where you are. If you use another DNS >>> to query the domain, you will get a different IP: >>> >> >> It's not always a "guess your geographic location". The smarter ones use >> Anycast to advertise the same IP address from multiple locations on the >> Internet and let BGP do its magic to route your packets to the nearest >> server, taking into account any congestion or other transient connection >> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The >> nice thing about it is that you get optimal response even at the host >> resolution stage. The DNS server can then take its knowledge of the DNS >> query source address into account when it decides which IP address to >> resolve to. >> >> It's pretty neat, personally I find it a fascinating trick: >> https://en.wikipedia.org/wiki/Anycast >> >> It is, quite fascinating. It is not, unfortunately, as useful as you make >> it out to be. Neither Google nor Akamai use it for web traffic, for example. >> >> The reason is twofold. First, anycast is poorly equipted to handle TCP >> connections. There is a (remote) possibility that the handler of your IP >> would change mid-request, which would not play nice with your connection. >> >> The second, more pertinent, reason is that , at least for Akamai, they >> would like to be able to control which server you reach when you make a >> request. The would like to be able to re-route your in case something bad >> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP >> routes have much longer settle times. >> >> Shachar >> > > > > -- > <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 > >
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
