Instant Domain Search es rápido porque mantiene en memoria un índice de varios archivos de zona de nombres de dominio y se ejecuta en servidores rápidos. Cada consulta de zona se resuelve en microsegundos. La parte más lenta de la búsqueda de dominios es la conexión entre el cliente y el servidor. Esto resulta especialmente cierto en las redes móviles. Nos obsesiona la rapidez y siempre buscamos formas de hacer que este sitio sea aún más rápido.
Si quieres aprender a crear tu propia CDN con AWS, sigue leyendo para ver cómo estructuramos una para Instant Domain Search. Hasta hace poco, crear una CDN desde cero era difícil, pero las nuevas tecnologías lo han puesto al alcance de cualquiera.
Cómo crear un CDN
Hace unos años empezamos a usar JavaScript para determinar qué servidor estaba más cerca de ti. Esta técnica mejoró considerablemente el rendimiento de las búsquedas, pero no acelera la carga inicial de la página. Hace poco empezamos a servir todas las páginas mediante HTTPS de forma predeterminada. Esto añade aún más latencia a la carga inicial porque tenemos que negociar una conexión HTTPS antes de que el navegador sepa dónde descargar recursos estáticos como CSS y JavaScript.
Alojar el sitio en una red de distribución de contenido (CDN) puede dificultar la propagación de cambios y el uso de reglas de redirección personalizadas, y resultar caro si usas tu propio certificado de seguridad. También queríamos implementar HTTP/2 (antes SPDY). El protocolo HTTP/2 es mucho más eficiente que el HTTPS tradicional porque puede negociar una conexión segura con menos viajes de ida y vuelta por la red. Google ha demostrado que HTTP/2 es un 23 % más rápido que HTTPS en redes móviles.
Las ventajas de un CDN
Una CDN funciona almacenando copias de tus recursos en caché en centros de datos de todo el mundo. Son los servidores perimetrales. Estos suelen almacenar el contenido bajo demanda. Esto significa que la CDN obtiene los datos de tu servidor (el servidor de origen) para guardarlos en un servidor perimetral solo cuando los solicita un cliente cercano. Si tu sitio tiene relativamente poco tráfico, como este, es probable que tus datos se eliminen con frecuencia de la caché. Esto puede introducir algo más de latencia cuando el servidor perimetral de la CDN obtiene datos nuevos del servidor de origen.
El servicio Route 53 de Amazon incorporó el enrutamiento basado en latencia en marzo de 2012. Esto significa que puedes alojar servidores en varios centros de datos de Amazon y Route 53 usará DNS para conectar a los usuarios con el más cercano. CloudFront hace algo similar para conectar a los usuarios con el nodo perimetral más próximo. Increíble, ¿verdad? Por eso tiene tanto sentido alojar tu propia CDN.
Comparativa de velocidad
Durante 30 días, usamos Pingdom para medir la latencia de una URL de CloudFront que servía una versión comprimida con gzip de nuestra página de inicio mediante HTTPS. Pingdom utiliza servidores repartidos por todo el mundo para supervisar la disponibilidad y generar informes de latencia. Durante el mismo periodo, servimos la misma página por HTTPS y dejamos que el enrutamiento por latencia de Route 53 dirigiera la carga a uno de nuestros servidores en Virginia, California, Singapur o Irlanda. En conjunto, nuestra CDN personalizada es aproximadamente tan rápida como CloudFront:
| CloudFront | CDN personalizada | |
|---|---|---|
| General | 195ms | 193ms |
| Más rápido | 166ms | 175ms |
| Más lento | 241ms | 234ms |
Aunque hay muchos más nodos perimetrales de CloudFront que servidores de Instant Domain Search, seguimos pudiendo situar servidores relativamente cerca de la mayoría de nuestros usuarios. Route 53 solo envía tráfico a servidores que están en línea. Desde que cambiamos a este sistema, Pingdom indica que hemos tenido un 100,00 % de disponibilidad en nuestra página de inicio, contenido estático e interfaz de búsqueda.
Cuando crees tu propia red CDN, dedica tiempo a comparar tus cifras como hemos hecho aquí y a supervisarlas a distintas horas y en varios días. Así tendrás una visión clara del funcionamiento de tus servidores CDN.
Menos complejidad = resultados más rápidos
Al servir todo desde un mismo dominio, podemos eliminar la consulta DNS, la conexión TCP y la negociación TLS/SSL con la CDN. Estos intercambios de red añaden latencia a una parte fundamental de la experiencia: la primera carga de la página. Cuando un usuario empieza a buscar, sigue comunicándose con el servidor más cercano. Esto elimina la necesidad del truco de JavaScript que usábamos antes. Optimizamos aún más la gestión de conexiones mediante técnicas de streaming JSON para reducir el número de conexiones HTTPS por consulta.
Es increíble que un sitio relativamente pequeño como el nuestro tenga acceso a la infraestructura global de AWS. Pudimos crear una CDN personalizada desde la línea de comandos, algo que solo estaba al alcance de los mayores proveedores y a un coste elevado cuando este sitio se lanzó en 2005.
Como ves, no hacen falta demasiados pasos para crear tu propio servidor CDN. Esperamos que este artículo haga que te resulte menos intimidante si nunca lo has intentado. Una vez que tengas configurado y en marcha un dominio CDN, te alegrarás de haberlo hecho.