¿Por qué mover sus archivos de Javascript a un dominio principal diferente que también posee?

StackOverflow https://stackoverflow.com/questions/160376

Pregunta

Me he dado cuenta de que, solo en el último año, muchos de los principales sitios web han realizado el mismo cambio en la forma en que están estructuradas. Cada uno ha movido sus archivos de Javascript para que se alojen en el mismo dominio que la propia página (o un subdominio de eso), para que se alojen en un dominio con un nombre diferente.

No es simplemente paralelización

Ahora, existe una técnica bien conocida de distribuir los componentes de su página en múltiples dominios para paralelizar la descarga. Yahoo lo recomienda al igual que muchos otros. Por ejemplo, www.example.com es donde se aloja su HTML, luego coloca las imágenes en images.example.com y javascripts en scripts.example.com . Esto evita el hecho de que la mayoría de los navegadores limitan el número de conexiones simultáneas por servidor para ser buenos ciudadanos netos.

Lo anterior es no de lo que estoy hablando.

No es simplemente la redirección a una red de entrega de contenido (o tal vez lo sea, consulte la parte inferior de la pregunta)

De lo que estoy hablando es de alojar Javascripts específicamente en un dominio completamente diferente. Déjame ser específico. Apenas en el último año más o menos me he dado cuenta de que:

youtube.com ha movido sus archivos .JS a ytimg.com

cnn.com ha movido sus archivos .JS a cdn.turner.com

weather.com ha movido sus archivos .JS a j.imwx.com

Ahora, conozco redes de entrega de contenido como Akamai que se especializa en la subcontratación de esto para grandes sitios web. (El nombre " cdn " en el dominio especial de Turner nos indica la importancia de este concepto aquí).

Pero tenga en cuenta que con estos ejemplos, cada sitio tiene su propio dominio registrado específicamente para este propósito, y no es el dominio de una red de entrega de contenido u otro proveedor de infraestructura. De hecho, si intenta cargar la página de inicio en la mayoría de estos dominios de script, generalmente se redireccionan al dominio principal de la empresa. Y si revierte la búsqueda de las IPs involucradas, éstas a veces aparecen apuntando a los servidores de una compañía de CDN, a veces no.

¿Por qué me importa?

Habiendo trabajado anteriormente en dos compañías de seguridad diferentes, me han hecho paranoico de Javascripts maliciosos.

Como resultado, sigo la práctica de los sitios de la lista blanca en los que permitiré que se ejecute Javascript (y otro contenido activo como Java). Como resultado, para hacer que un sitio como cnn.com funcione correctamente, tengo que poner manualmente cnn.com en una lista. Es un dolor por detrás, pero lo prefiero por encima de la alternativa.

Cuando la gente usaba cosas como scripts.cnn.com para paralelizar, eso funcionaba bien con el comodín apropiado. Y cuando la gente usaba subdominios de los dominios de la compañía de CDN, podía simplemente permitir el dominio principal de la compañía de CDN con un comodín al frente y matar muchas aves con una piedra (como * .edgesuite.net y * .akamai.com).

Ahora he descubierto que (a partir de 2008) esto no es suficiente. Ahora tengo que buscar en el código fuente de una página que quiero incluir en la lista blanca, y descubrir qué " secreto " dominio (o dominios) que el sitio está utilizando para almacenar sus Javascripts en. En algunos casos, he descubierto que debo permitir que tres dominios diferentes hagan que un sitio funcione.

¿Por qué todos estos sitios importantes comenzaron a hacer esto?

EDITAR: OK como " onebyone " señalado , parece estar relacionado con la entrega de contenido de CDN. Así que permítame modificar la pregunta un poco basada en su investigación ...

¿Por qué weather.com utiliza j.imwx.com en lugar de twc.vo.llnwd.net ?

¿Por qué youtube.com utiliza s.ytimg.com en lugar de static.cache.l.google.com ?

Hay un razonamiento detrás de esto.

¿Fue útil?

Solución

Su pregunta de seguimiento es esencialmente: Suponiendo que un sitio web popular use un CDN, ¿por qué usarían su propio TLD como imwx.com en lugar de un subdominio (static.weather.com) o el dominio de CDN?

Bueno, la razón para usar un dominio que controlan en comparación con el dominio de la CDN es que retienen el control; incluso podrían cambiar las CDN por completo y solo tienen que cambiar un registro de DNS, en lugar de tener que actualizar los enlaces en miles de páginas / aplicaciones.

Entonces, ¿por qué usar nombres de dominio sin sentido? Bueno, una gran cosa con los archivos de ayuda como .js y .css es que desea que los servidores proxy y los navegadores de las personas los almacenen en caché de forma descendente. Si una persona accede a gmail.com y todos los archivos .js se cargan de la memoria caché del navegador, el sitio les parece mucho más ágil y también guarda el ancho de banda en el extremo del servidor (todos ganan). El problema es que una vez que envía encabezados HTTP para un almacenamiento en caché realmente agresivo (es decir, que me almacene en caché durante una semana o un año o para siempre), estos archivos ya no se cargan de forma confiable desde el servidor y no puede realizar cambios / correcciones a ellos porque las cosas se romperán en los navegadores de las personas.

Por lo tanto, lo que las empresas deben hacer es implementar estos cambios y cambiar las URL de todos estos archivos para obligar a los navegadores a recargarlos. Recorrer cíclicamente dominios como " a.imwx.com " ;, " b.imwx.com " etc. es cómo se hace esto.

Al usar un nombre de dominio sin sentido, los desarrolladores de Javascript y sus homólogos de enlace sysadmin / CDN de Javascript pueden tener su propio nombre de dominio / DNS a través del cual están impulsando estos cambios, de los que son responsables / autónomos.

Luego, si algún tipo de bloqueo de cookies o de secuencias de comandos comienza a suceder en el TLD, simplemente cambian de un TLD sin sentido a kyxmlek.com o lo que sea. No tienen que preocuparse por hacer algo malo que tenga efectos secundarios de contramedida en todos * .google.com.

Otros consejos

¿Limitar el tráfico de cookies?

Después de configurar una cookie en un dominio específico, cada solicitud a ese dominio tendrá la cookie enviada de nuevo al servidor. Cada solicitud!

Eso puede sumarse rápidamente.

Muchas razones:

CDN: un nombre dns diferente facilita la transferencia de activos estáticos a una red de distribución de contenido

Paralelismo: las imágenes, las hojas de estilo y el javascript estático están usando otras dos conexiones que no bloquearán otras solicitudes, como devoluciones de llamada ajax o imágenes dinámicas

Tráfico de cookies: exactamente correcto, especialmente en sitios que tienen el hábito de almacenar mucho más que un simple ID de sesión en cookies

Modelado de la carga: incluso sin un CDN, todavía hay buenas razones para alojar los activos estáticos en menos servidores web optimizados para responder extremadamente rápido a una gran cantidad de solicitudes de URL de archivos, mientras que el resto del sitio está alojado en un número mayor de servidores que responden a solicitudes dinámicas más intensivas de procesador

actualización: dos razones por las que no usa el nombre dns del CDN. El nombre del cliente dns actúa como una clave para la " sección correspondiente " " de los activos el CDN es el almacenamiento en caché. Además, dado que su CDN es un servicio básico, puede cambiar de proveedor modificando el registro de DNS, para evitar cualquier cambio de página, reconfiguración o redistribución en su sitio.

Creo que hay algo en la teoría CDN:

Por ejemplo: 

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

Limelight es un CDN.

Mientras tanto: 

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

Supongo que este es un CDN para contenido estático ejecutado internamente por Google. 

$ host cdn.turner.com
cdn.turner.com A record currently not present

Ah, bueno, no puedo ganarlos todos.

Por cierto, si usa Firefox con el complemento NoScript, automatizará el proceso de búsqueda en la fuente y GUI-fy el proceso de creación de listas blancas. Básicamente, haga clic en el ícono de NoScript en la barra de estado, se le dará una lista de dominios con opciones para la lista blanca temporal o permanente, incluyendo " todo en esta página " ;.

Implementé esta solución hace unos dos o tres años en un empleador anterior, cuando el sitio web comenzó a sobrecargarse debido a una implementación de servidor web heredado. Al trasladar las imágenes de diseño y CSS a un servidor Apache, redujimos la carga en el servidor principal y aumentamos la velocidad sin fin.

Sin embargo, siempre he tenido la impresión de que solo se puede acceder a las funciones de Javascript desde el mismo dominio que la propia página. Los sitios web más nuevos no parecen tener esta limitación: como mencionas, muchos tienen archivos de Javascript en subdominios separados o incluso dominios completamente separados.

¿Puede alguien darme un indicador de por qué esto es posible ahora, cuando no fue hace un par de años?

No es solo javascript que puedes moverte a diferentes dominios, sino que tantos activos como sea posible producirán mejoras de rendimiento.

La mayoría de los navegadores tienen un límite en el número de conexiones simultáneas que puede realizar a un solo dominio (creo que es alrededor de 4), por lo que cuando tiene muchas imágenes, js, css, etc., a menudo se demora en descargar cada archivo. .

Puedes usar algo como YSlow y FireBug para ver cuándo se descarga cada archivo desde el servidor.

Al tener activos en dominios separados, disminuye la carga en su servidor primario y puede tener más conexiones simultáneas y descargar más archivos en un momento dado.

Recientemente lanzamos un sitio web de bienes raíces que contiene muchas imágenes (de las casas, duh: P) que utiliza este principio para las imágenes, por lo que es mucho más rápido enumerar los datos.

También hemos utilizado esto en muchos otros sitios web que tienen un gran volumen de activos.

Creo que respondiste tu propia pregunta.

Creo que su problema está relacionado con la seguridad, en lugar de POR QUÉ.

Quizás una nueva etiqueta META esté en orden para describir CDN válidos para la página en cuestión, entonces todo lo que necesitamos es un complemento del navegador para leerlos y comportarse en consecuencia.

¿Sería debido al bloqueo realizado por los filtros de contenido y spam? Si usan dominios extraños, es más difícil descifrarlo y / o terminarás bloqueando algo que deseas.

No sé, solo un pensamiento.

Si yo fuera una empresa de marcas múltiples y de gran nombre, creo que este enfoque tendría sentido porque desea que el código javascript esté disponible como una biblioteca. Me gustaría hacer que tantas páginas sean lo más coherentes posible en el manejo de cosas como direcciones, nombres de estados, códigos postales. AJAX probablemente hace esta preocupación prominente.

En el modelo de negocio actual de Internet, los dominios son marcas, no nombres de red. Si obtiene marcas compradas o derivadas, terminará con muchos cambios de dominio. Este es un problema incluso para los sitios más destacados.

Todavía hay enlaces que apuntan a documentos útiles en * .netscape.com y * .mcom.com que han desaparecido hace mucho tiempo.

Wikipedia para Netscape dice:

  

" El 12 de octubre de 2004, el popular sitio web para desarrolladores Netscape DevEdge fue cerrado por AOL. DevEdge fue un recurso importante para las tecnologías relacionadas con Internet, ya que mantiene la documentación definitiva en el navegador Netscape, la documentación sobre tecnologías asociadas como HTML y JavaScript, y artículos populares escritos por líderes de la industria y la tecnología como Danny Goodman. Parte del contenido de DevEdge se ha vuelto a publicar en el sitio web de Mozilla. & Quot;

Entonces, eso sería, en menos de un período de 10 años:

  • Mosaic Communications Corporation
  • Netscape Communications Corporation
  • AOL
  • AOL Time Warner
  • Time Warner

Si coloca el código en un dominio que NO es un nombre de marca, conserva mucha flexibilidad y no tiene que refactorizar todos los puntos de entrada, control de acceso y referencias de código cuando los sitios web se renuevan. nombrado.

He trabajado con una empresa que hace esto. Están en un centro de datos con un par de miradas bastante bueno, por lo que el razonamiento de CDN no es tan grande para ellos (quizás ayudaría, pero no lo hacen por esa razón). La razón es que ejecutan varios servidores web en paralelo que manejan colectivamente sus páginas dinámicas (scripts PHP), y sirven imágenes y algunos javascript de un dominio separado en el que usan un servidor web rápido y ligero como lighttpd o thttpd para servir. Imágenes y javascript estático.

PHP requiere PHP. Javascript estático y las imágenes no. Se puede eliminar mucho de un servidor web completo cuando todo lo que necesita hacer es el mínimo absoluto.

Claro, probablemente podrían usar un proxy que redirige las solicitudes a un subdirectorio específico a un servidor diferente, pero es más fácil manejar todo el contenido estático con un servidor diferente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top