Pros y contras de un servidor de imágenes separado (por ejemplo, images.mydomain.com)?

Tenemos varias imágenes y documentos PDF que están disponibles a través de nuestro sitio web. Estas imágenes y documentos se almacenan en control de fuente y se copian el contenido en la implementación. Estamos considerando crear un servidor de imágenes separado para poner nuestras imágenes en stock y documentos en PDF, disminuyendo de manera significativa la mayor parte de nuestro paquete de implementación.Pros y contras de un servidor de imágenes separado (por ejemplo, images.mydomain.com)?

¿Alguien tiene experiencia con este enfoque?

Me pregunto acerca de cualquier "problema", como problemas con XSS y/o problemas con el navegador al entregar contenido desde el subdominio alternativo?

Fuente

2009-05-26 condiosluzverde

Pro:

Muchos navegadores sólo se asignarán dos zócalos para la descarga de los activos desde un único host. Por lo tanto, si index.html se descarga desde www.domain.com y hace referencia a 6 archivos de imagen, 3 archivos de JavaScript y 3 archivos de CSS (todo en www.dominio.com), el navegador los descargará de 2 en 2, con el otro bloqueo hasta que un socket esté libre.

Si extrae los 6 archivos de imagen en un host diferente, digamos images.domain.com, obtendrá dos sockets adicionales dedicados a descargar sus imágenes. Esto paraleliza el proceso de descarga de activos, por lo que, en teoría, su página podría rendir el doble de rápido.

contra:

Si está utilizando SSL, lo que tendría que o bien obtener un certificado SSL adicional de un solo host para images.domain.com o un certificado SSL comodín para * .dominio.com (coincide con cualquier subdominio). De lo contrario, se generará una advertencia en el navegador que indica que la página contiene contenido mixto seguro e inseguro.

Fuente

2009-05-26 23:56:06

Si estuviera realmente preocupado por el rendimiento y tuviera una gran descarga de recursos, podría ponerlos en un dominio con un * en el dns, y luego aleatorizar el subdominio en la llamada a recursos, como http (s): // .imagesomain.com/image.gif, etc. Esto podría darle tantas tomas de corriente como recursos y acelerar su carga bastante. – Eli

En realidad, no desea llevar esto demasiado lejos o puede ver una pérdida neta en el rendimiento. No utilizaría más de 4 hosts de activos estáticos (es decir, "images1.domain.com", "images2.domain.com", "images3.domain.com", "images4.domain.com") para la mayoría de los sitios. Los problemas principales degradarán el rendimiento a medida que aumente la cantidad de hosts de activos que están almacenando en caché y HTTP keep-alives. El mismo archivo descargado de un host de activos no se considerará cobrado en otro host de activos. Y las alertas de HTTP permiten reutilizar la misma conexión TCP para múltiples solicitudes. 1 a 4 hosts te da un buen equilibrio. –

Vengan los certificados SSL de enero emitidos por Let's Encrypt deben admitir subdominios además del apex simultáneamente. Y los navegadores modernos ahora rompen alegremente con decenas de descargas de activos paralelas, no solo de a dos por vez. –

Pros:

-load equilibrio

-isolating una funcionalidad diferente

Contras:

-más de trabajo (cuando se crea una página en el sitio principal que tendría que mantener los recursos en el servidor separado)

Cosas como XSS es un problema de código que no desinfecta la entrada (o salida para el caso). El único problema que podría surgir es si tiene cookies específicas del subdominio que se utilizan para la autenticación ... pero eso es realmente una solución trivial.

Fuente

2009-05-26 23:12:27

Si está sirviendo HTTPS y sirve una imagen de un dominio HTTP, aparecerá advertencias de alerta de seguridad del navegador cuando lo use.

Así que si lo hace HTTPS, tendrá que comprar HTTPS para su awell dominio de la imagen si no quiere molestar a la mierda de sus usuarios :)

Hay otras maneras de evitar esto, pero no está particularmente en el alcance de esta respuesta, ¡fue solo una advertencia!

Fuente

2009-05-26 23:41:58 joshcomley

Si James dice lo que creo que es, que la imagen se entrega realmente por script que genera el contenido (es decir, content-type: image/jpeg); entonces, siempre que el script esté en el servidor seguro (https://secure.domain.com/somescript.php?i=4567aldh), esto no debería ser un problema. Por otra parte, podría ser el que malinterpretó la configuración .... –

(¡Vaya, se olvidó de escapar de la parte https. Lo convirtió en un enlace. Lo siento.: /) –

El "Hay otras formas de evitar esto" se refería exactamente eso: una secuencia de comandos en HTTPS que recupera las imágenes del otro servidor. ¡Así que tienes toda la razón, no es un problema real! – joshcomley

Además, con un dominio diferente, no enviará los datos de las cookies con cada solicitud. Esto puede aumentar el rendimiento.

Fuente

2009-05-27 00:02:47 alex

Otra cosa que aún no se menciona es que puede usar diferentes servidores web para servir diferentes tipos de contenido. Por ejemplo, su contenido estático podría ser servido a través de lighttpd o nginx mientras todavía se sirve su contenido dinámico de Apache.

Fuente

2009-05-27 02:28:29 ceejayoz

Pros y contras de un servidor de imágenes separado (por ejemplo, images.mydomain.com)?

Respuesta

Cuestiones relacionadas