Estoy tratando de descubrir cómo el RTD de los servidores de Google puede ser tan bajo:
$ ping google.com
PING google.com (173.194.113.64): 56 data bytes
64 bytes from 173.194.113.64: icmp_seq=0 ttl=57 time=28.166 ms
173.194.113.64Está registrado en Mountain View, CA y estoy en Alemania. Un ping a un host en California sería mucho más largo. Emitir un traceroute me da un nombre de host fra02s21-in-f0.1e100.net. Me pregunto qué técnicas están utilizando para redirigir mi solicitud.
Respuesta1
Tiene razón, el RTD no puede ser <30 ms para EE. UU. De Europa a EE. UU. debería ser de unos 60 ms (solo ida).
Entonces Google probablemente tenga algún servidor de caché en este lado del océano
(y acaba de registrarse en Mountain View cuando realmente está en Europa).
encontréEste artículoexplicándolo:
secreto de google
Google ha dificultado saber dónde guardan sus centros de datos y cuántos tienen. Una razón importante para esto es que casi todas las direcciones IP que utiliza Google (y hay muchas)están listados en su dirección de Mountain View, California, así que simplemente mirando las direcciones IP (con IP WHOIS o bases de datos de IP a ubicación)no le ayudará a determinar dónde están sus centros de datoso cuantos tienen.
Además de esto, Google normalmente solicita permisos para sus proyectos de centros de datos utilizando empresas (LLC) que no mencionan a Google en absoluto, por ejemplo Lapis LLC en Carolina del Norte y Tetra LLC en Iowa.
Dado que Google tiende a ser bastante reservado acerca de sus centros de datos en general, la información que hemos presentado aquí probablemente no esté 100% completa.
Enlace extra ;)Una mirada al interior de los Centros de Datos de Google.
Aquí estáotra fuente:
2) Las grandes empresas con oficinas en todo el mundo no comparten información sobre su ubicación real en whois.
- Ejemplo: Google Inc. tiene sus centros de datos en todo el mundo, pero whois siempre indica su sede en Mountain View (California, EE.UU.). En realidad, los usuarios de diferentes países serán enviados al centro de datos más cercano. Para un alemán, por ejemplo, la página principal se cargará desde el centro de datos alemán (74.125.39.104).
Editar:(tenga en cuenta que no soy un experto en este tema :)
Probablemente tenga razón acerca de que el "servidor de nombres autorizado" realiza algunas redirecciones. No estoy seguro si hay varios servidores detrásesoque hacen una mayor redirección. Puede hacer una verificación dig google.com +tracepara ver de qué servidor a qué servidor va su solicitud de DNS. (Leeraquísobre algunos conceptos básicos detrás de esto)
En cuanto al mecanismo detrás de la redirección. Mencionaste Akamai CDN. Google utiliza su propia CDN. Hubo algunos rumores sobre la compra de Akamai por parte de Google hace unos años, pero eso no sucedió. Creo que Apple usa Akamai CDN (entre algunos otros CND).
Enesta páginapuedes leer que Google usa la "extensión edns-client-subnet".
OpenDNS y Google DNS admiten la extensión edns-client-subnet desde hace mucho tiempo. Este mecanismo fue diseñado por Google específicamente para abordar este problema. Y funciona maravillosamente. Las CDN pueden enviar una redirección al mejor servidor sin importar qué solucionador utilice.
Con algo másgooglearPuedes aprender más sobre este mecanismo. Comoaquí:
Google, Bitgravity, CDNetworks, DNS.com y Edgecast han implementado soporte parasubred-cliente-edns. La idea es bastante simple. Pasa parte de su dirección IP (solo una parte para mantenerla semianónima) en la solicitud. Un servidor que admita esta extensión puede usarla para segmentar geográficamente y encontrar el nodo CDN más cercano a usted. Anteriormente lo mejor que se podía hacer era utilizar la ubicación del servidor DNS, que en muchos casos podía estar muy lejos.
Otra buena lectura sobre las CDN y la extensión edns-client-subnet eseste.
Suficiente material de lectura víaGoogle;)