Perché spostare i tuoi file Javascript in un dominio principale diverso che possiedi anche tu?

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

Domanda

Ho notato che solo nell'ultimo anno, molti dei principali siti Web hanno apportato la stessa modifica al modo in cui sono strutturate le loro pagine. Ognuno ha spostato i propri file Javascript dall'hosting sullo stesso dominio della pagina stessa (o da un sottodominio), all'hosting su un dominio con nome diverso.

Non è semplicemente parallelizzazione

Ora esiste una tecnica ben nota per diffondere i componenti della tua pagina su più domini per parallelizzare il download. Yahoo lo consiglia come molti altri. Ad esempio, www.example.com è il luogo in cui è ospitato il tuo HTML, quindi metti immagini su images.example.com e javascript su scripts.example.com . Ciò aggira il fatto che la maggior parte dei browser limita il numero di connessioni simultanee per server al fine di essere buoni cittadini della rete.

Quanto sopra non è non di cosa sto parlando.

Non è semplicemente il reindirizzamento a una rete di distribuzione di contenuti (o forse lo è - vedi il fondo della domanda)

Quello di cui sto parlando è l'hosting di Javascripts specificamente su un dominio completamente diverso. Lasciami essere specifico. Proprio nell'ultimo anno o giù di lì ho notato che:

youtube.com ha spostato i suoi file .JS in ytimg.com

cnn.com ha spostato i suoi file .JS in cdn.turner.com

weather.com ha spostato i suoi file .JS in j.imwx.com

Ora sono a conoscenza di reti di distribuzione di contenuti come Akamai specializzati nell'outsourcing di questo per siti Web di grandi dimensioni. (Il nome "cdn" nello speciale dominio di Turner ci indica l'importanza di questo concetto qui).

Ma nota con questi esempi, ogni sito ha il suo dominio specificamente registrato per questo scopo, e non è il dominio di una rete di distribuzione di contenuti o di un altro fornitore di infrastrutture. In effetti, se si tenta di caricare la home page dalla maggior parte di questi domini di script, di solito reindirizzano al dominio principale dell'azienda. E se si inverte la ricerca degli IP coinvolti, a volte sembrano puntare ai server di una società CDN, a volte no.

Perché me ne importa?

Dopo aver lavorato in due diverse società di sicurezza, sono diventato paranoico di Javascripts dannosi.

Di conseguenza, seguo la pratica dei siti di whitelisting su cui consentirò l'esecuzione di Javascript (e di altri contenuti attivi come Java). Di conseguenza, per far funzionare correttamente un sito come cnn.com , devo inserire manualmente cnn.com in un elenco. È un dolore alle spalle, ma preferisco l'alternativa.

Quando la gente ha usato cose come scripts.cnn.com per parallelizzare, ha funzionato bene con i caratteri jolly appropriati. E quando le persone usavano i sottodomini al di fuori dei domini dell'azienda CDN, potevo semplicemente consentire al dominio principale dell'azienda CDN anche un jolly di fronte e uccidere molti uccelli con una fava (come * .edgesuite.net e * .akamai.com).

Ora ho scoperto che (dal 2008) questo non è abbastanza. Ora devo cercare il codice sorgente di una pagina che voglio inserire nella whitelist e capire quale "segreto" è dominio (o domini) utilizzato dal sito per archiviare i loro Javascripts. In alcuni casi ho scoperto che devo consentire a tre domini diversi di far funzionare un sito.

Perché tutti questi siti principali hanno iniziato a farlo?

EDIT: OK come " onebyone " sottolineato , sembra essere correlato alla consegna dei contenuti della CDN. Vorrei quindi modificare leggermente la domanda in base alla sua ricerca ...

Perché weather.com utilizza j.imwx.com invece di twc.vo.llnwd.net ?

Perché youtube.com utilizza s.ytimg.com invece di static.cache.l.google.com ?

C'è un ragionamento dietro questo.

È stato utile?

Soluzione

La tua domanda di follow-up è essenzialmente: supponendo che un sito Web popolare stia utilizzando un CDN, perché dovrebbero usare il proprio TLD come imwx.com anziché un sottodominio (static.weather.com) o il dominio del CDN?

Bene, la ragione per usare un dominio che controllano rispetto al dominio della CDN è che mantengono il controllo: potrebbero persino cambiare completamente le CDN e devono solo cambiare un record DNS, invece di dover aggiornare i collegamenti in migliaia di pagine / applicazioni.

Quindi, perché usare nomi di dominio senza senso? Bene, una cosa importante con i file di supporto come .js e .css è che vuoi che vengano memorizzati nella cache a valle da proxy e browser delle persone il più possibile. Se una persona colpisce gmail.com e tutti i file .js vengono caricati dalla cache del browser, il sito appare molto più scattante e salva anche la larghezza di banda sull'estremità del server (tutti vincono). Il problema è che una volta che invii le intestazioni HTTP per una cache veramente aggressiva (cioè memorizzami nella cache per una settimana o un anno o per sempre), questi file non vengono più caricati in modo affidabile dal server e non puoi apportare modifiche / correzioni perché le cose si romperanno nei browser delle persone.

Quindi, ciò che le aziende devono fare è mettere in scena questi cambiamenti e in realtà cambiare gli URL di tutti questi file per forzare i browser delle persone a ricaricarli. Scorrere i domini come " a.imwx.com " ;, " b.imwx.com " ecc. è come si fa.

Usando un nome di dominio senza senso, gli sviluppatori Javascript e le loro controparti di collegamento sysadmin / CDN Javascript possono avere il proprio nome di dominio / DNS per il quale stanno facendo passare questi cambiamenti, per i quali sono responsabili / autonomi.

Quindi, se qualsiasi tipo di blocco dei cookie o di blocco degli script inizia a verificarsi sul TLD, cambiano semplicemente da un TLD senza senso a kyxmlek.com o altro. Non devono preoccuparsi di fare accidentalmente qualcosa di malvagio che ha effetti collaterali contromisure su tutto * .google.com.

Altri suggerimenti

Limitare il traffico dei cookie?

Dopo aver impostato un cookie su un dominio specifico, ogni richiesta a quel dominio riceverà il cookie rispedito al server. Ogni richiesta!

Che può sommarsi rapidamente.

Molte ragioni:

CDN: un nome DNS diverso semplifica lo spostamento di risorse statiche in una rete di distribuzione dei contenuti

Parallelismo: immagini, fogli di stile e javascript statici utilizzano altre due connessioni che non bloccano altre richieste, come callback ajax o immagini dinamiche

Traffico di cookie - esattamente corretto - specialmente con siti che hanno l'abitudine di archiviare molto più di un semplice ID di sessione nei cookie

Shaping del carico: anche senza CDN ci sono ancora buoni motivi per ospitare le risorse statiche su un minor numero di server Web ottimizzati per rispondere in modo estremamente rapido a un numero enorme di richieste di url di file, mentre il resto del sito è ospitato su un numero maggiore di server che rispondono a richieste dinamiche a più intenso utilizzo di processore

aggiornamento: due motivi per cui non si utilizza il nome DNS della CDN. Il nome DNS del client funge da chiave per il corretto "alveare" delle risorse che la CDN sta memorizzando nella cache. Inoltre, poiché la tua CDN è un servizio di base, puoi cambiare il fornitore modificando il record DNS - in modo da evitare qualsiasi cambiamento di pagina, riconfigurazione o ridistribuzione sul tuo sito.

Penso che ci sia qualcosa nella teoria della CDN:

Ad esempio: 

$ 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 è un CDN.

Nel frattempo: 

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

Suppongo che si tratti di una CDN per contenuti statici gestiti internamente da Google. 

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

Ah bene, non posso vincerli tutti.

A proposito, se si utilizza Firefox con il componente aggiuntivo NoScript, automatizzerà il processo di ricerca del codice sorgente e la GUI eseguirà il processo di whitelisting. Fondamentalmente, fai clic sull'icona NoScript nella barra di stato, ti viene fornito un elenco di domini con opzioni per la whitelist temporanea o permanente, incluso " tutto in questa pagina " ;.

Ho implementato questa soluzione circa due o tre anni fa presso un precedente datore di lavoro, quando il sito Web ha iniziato a essere sovraccarico a causa dell'implementazione di un server Web legacy. Spostando i CSS e le immagini di layout su un server Apache, abbiamo ridotto il carico sul server principale e aumentato la velocità senza fine.

Tuttavia, ho sempre avuto l'impressione che le funzioni Javascript siano accessibili solo dallo stesso dominio della pagina stessa. I siti web più recenti non sembrano avere questa limitazione: come dici tu, molti hanno file Javascript su sottodomini separati o addirittura domini completamente separati.

Qualcuno può darmi un suggerimento sul perché questo è ora possibile, quando non è stato un paio di anni fa?

Non è solo javascript che puoi spostare in domini diversi, ma quante più risorse possibili produrranno miglioramenti delle prestazioni.

La maggior parte dei browser ha un limite al numero di connessioni simultanee che è possibile effettuare su un singolo dominio (penso che sia circa 4), quindi quando si hanno molte immagini, js, css, ecc. spesso si rompono nel download di ogni file .

Puoi usare qualcosa come YSlow e FireBug per visualizzare quando ogni file viene scaricato dal server.

Avendo risorse su domini separati si riduce il carico sul proprio primario e si possono avere connessioni più simultanee e scaricare più file in qualsiasi momento.

Di recente abbiamo lanciato un sito Web immobiliare che contiene molte immagini (delle case, duh: P) che utilizzano questo principio per le immagini, quindi è molto più veloce elencare i dati.

Lo abbiamo anche usato su molti altri siti Web che presentano un elevato volume di attività.

Penso che tu abbia risposto alla tua domanda.

Credo che il tuo problema sia legato alla sicurezza, piuttosto che PERCHÉ.

Forse è necessario un nuovo tag META che descriva CDN validi per la pagina in questione, quindi tutto ciò di cui abbiamo bisogno è un componente aggiuntivo del browser per leggerli e comportarsi di conseguenza.

Sarebbe a causa del blocco fatto da spam e filtri di contenuto? Se usano domini strani, è più difficile capire e / o finirai per bloccare qualcosa che desideri.

Non so, solo un pensiero.

Se fossi un grande nome, una società multimarca, penso che questo approccio avrebbe senso perché vuoi rendere disponibile il codice javascript come libreria. Vorrei che il maggior numero possibile di pagine fosse coerente nella gestione di cose come indirizzi, nomi di stato, codici postali. AJAX probabilmente mette in evidenza questa preoccupazione.

Nell'attuale modello di business di Internet, i domini sono marchi, non nomi di rete. Se ricevi marchi acquistati o spin-off, finisci con molte modifiche al dominio. Questo è un problema anche per i siti più importanti.

Esistono ancora collegamenti che rimandano a documenti utili in * .netscape.com e * .mcom.com che sono scomparsi da tempo.

Wikipedia per Netscape dice:

  

" Il 12 ottobre 2004, il famoso sito Web per sviluppatori Netscape DevEdge è stato chiuso da AOL. DevEdge era una risorsa importante per le tecnologie relative a Internet, mantenendo la documentazione definitiva sul browser Netscape, la documentazione sulle tecnologie associate come HTML e JavaScript e articoli popolari scritti da leader del settore e della tecnologia come Danny Goodman. Alcuni contenuti di DevEdge sono stati ripubblicati sul sito Web Mozilla. & Quot;

Quindi, sarebbe, in meno di un periodo di 10 anni:

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

Se inserisci il codice in un dominio che NON è un marchio, mantieni molta flessibilità e non devi refactoring di tutti i punti di ingresso, controllo degli accessi e riferimenti di codice quando i siti web vengono ri di nome.

Ho lavorato con un'azienda che lo fa. Sono in un datacenter con un peering abbastanza buono, quindi il ragionamento della CDN non è così grande per loro (forse sarebbe d'aiuto, ma non lo fanno per quel motivo). La loro ragione è che eseguono diversi server web in parallelo che gestiscono collettivamente le loro pagine dinamiche (script PHP) e servono immagini e alcuni javascript da un dominio separato su cui usano un server web veloce e leggero come lighttpd o thttpd per servire immagini e javascript statico.

PHP richiede PHP. Javascript e immagini statici no. Molto può essere rimosso da un server Web completo quando tutto ciò che devi fare è il minimo assoluto.

Certo, potrebbero probabilmente usare un proxy che reindirizza le richieste a una sottodirectory specifica su un server diverso, ma è più semplice gestire tutto il contenuto statico con un server diverso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top