2009-05-26 12 views
9

Abbiamo diverse immagini e documenti PDF che sono disponibili tramite il nostro sito web. Queste immagini e questi documenti sono archiviati nel controllo del codice sorgente e vengono copiati sul contenuto della distribuzione. Stiamo prendendo in considerazione la creazione di un server di immagini separato per inserire le nostre immagini stock e documenti PDF, riducendo così in modo significativo la maggior parte del nostro pacchetto di implementazione.Pro e contro di un server di immagini separato (ad esempio images.mydomain.com)?

Qualcuno ha esperienza con questo approccio?

Mi chiedo di eventuali "trucchi" - come problemi XSS e/o problemi con il browser che forniscono contenuti dal sottodominio alternativo?

risposta

20

Pro:

Molti browser allocare solo due prese per il download di beni da un singolo host. Quindi se index.html è scaricato da www.domain.com e fa riferimento a 6 file di immagine, 3 file javascript e 3 file CSS (tutti su www.domain.com), il browser li scaricherà 2 alla volta, con il altro blocco fino a quando un socket è libero.

Se si estrae i 6 file di immagine su un host separato, ad esempio images.dominio.com, si ottengono due socket aggiuntivi dedicati al download delle immagini. Questo parallelizza il processo di download degli asset quindi, in teoria, la tua pagina potrebbe essere visualizzata due volte più velocemente.

Con:

Se si utilizza SSL, si avrebbe bisogno di ottenere sia un ulteriore certificato SSL single-host per images.domain.com o di un certificato SSL jolly per * .dominio.com (corrisponde a qualsiasi sottodominio). In caso contrario, verrà generato un avviso nel browser che indica che la pagina contiene contenuti misti sicuri e non protetti.

+0

Se si fosse veramente interessati alle prestazioni e si fossero scaricate grandi risorse, è possibile inserirle in un dominio con * nel dns e quindi randomizzare il sottodominio nella chiamata alla risorsa, come http (s): // .imagesomain.com/image.gif, ecc. Questo potrebbe darti tante prese quante sono le risorse e accelerare un po 'il tuo carico. – Eli

+3

In realtà non si vuole prendere questo troppo lontano o si può assistere a una perdita netta in termini di prestazioni. Non utilizzerei più di 4 host di asset statici (ad esempio "images1.domain.com", "images2.domain.com", "images3.domain.com", "images4.domain.com") per la maggior parte dei siti. I problemi principali peggioreranno le prestazioni man mano che aumenti il ​​numero di host della risorsa che memorizzano nella cache e keep-alive HTTP. Lo stesso file scaricato da un host di asset non verrà considerato incassato su un altro host di asset. E i keep-alive HTTP consentono di riutilizzare la stessa connessione TCP per più richieste. Da 1 a 4 host ti danno un buon equilibrio. –

+0

Come gennaio I certificati SSL rilasciati da Let's Encrypt dovrebbero supportare i sottodomini in aggiunta all'apice simultaneamente. E i moderni browser ora strappano allegramente decine di download di risorse parallele, non solo due alla volta. –

3

Pro:

-load bilanciamento

-isolating una funzionalità diversa

Contro:

-più di lavoro (quando si crea una pagina sul sito principale che avrebbe dovuto mantenere la le risorse sul server separato)

Le cose come XSS sono un problema di codice che non disinfetta l'input (o l'output per quella materia). L'unico problema che potrebbe sorgere è se si dispone di cookie specifici del sottodominio che vengono utilizzati per l'autenticazione .. ma questa è davvero una soluzione banale.

2

Se si sta servendo HTTPS e si fornisce un'immagine da un dominio HTTP, verrà visualizzato un avviso di sicurezza del browser quando lo si utilizza.

quindi se HTTPS, avrete bisogno di acquistare HTTPS per l'immagine awell dominio se non si vuole infastidire l'inferno fuori dei vostri utenti :)

Ci sono altri modi per aggirare questo, ma non è particolarmente nella portata di questa risposta - era solo un avvertimento!

+1

Se James sta dicendo quello che penso che sia, ovvero che l'immagine sia effettivamente consegnata dallo script che emette il contenuto (ad esempio, content-type: image/jpeg); fino a quando lo script si trova sul server sicuro (https://secure.domain.com/somescript.php?i=4567aldh), questo non dovrebbe essere un problema. Poi di nuovo, potrei essere io a fraintendere il setup ... –

+0

(oops, ho dimenticato di sfuggire alla parte https. Lo ha trasformato in un link. Sorry.: /) –

+1

Il "Ci sono altri modi per aggirare questo" era riferito esattamente quello - uno script sul HTTPS che recupera le immagini dall'altro server. Quindi hai assolutamente ragione, non è un vero problema! – joshcomley

7

Inoltre, con un dominio diverso, non invierà i dati dei cookie ad ogni richiesta. Questo può aumentare le prestazioni.

5

Un'altra cosa non ancora menzionata è che è possibile utilizzare diversi server Web per servire diversi tipi di contenuto. Ad esempio, il contenuto statico potrebbe essere pubblicato tramite lighttpd o nginx mentre al contempo serve il contenuto dinamico da Apache.

Problemi correlati