Browsed by
Category: Italian

Host 1e100.net: cosa sono?

Host 1e100.net: cosa sono?

Sono molto attento alle connessioni aperte dai miei pc, quindi ogni tanto mi metto a fare controlli con TCPDump o simili. Tempo fa avevo notato una valanga di connessioni verso hosts tipo:

fx-in-f83.1e100.net

fx-in-f147.1e100.net

fx-in-f118.1e100.net

La struttura dei nomi mi ha subito ricordato lo schema che usa Google per i suoi load balancers, ed un veloce controllo WHOIS e sugli IP ha confermato quello che avevo intuito: si trattava di un suo dominio “di servizio”. In rete, non avevo trovato nessuna informazione. Alla fine, mi è uscito dalla testa.

Ieri per caso ho trovato questo articolo su TheRegister.co.uk, ed ho scoperto il senso del nome 1e100.net (su cui non avevo fatto alcuna ricerca, credevo fosse totalmente casuale):

But on closer inspection, the domain is obviously Google’s, chosen with a mathematician’s wink at the search giant’s famously misspelled name. This mystery domain is 1e100.net. “1e100” would be scientific notation for 10 100, a one followed by 100 zeros, also known as a googol.

Il nome è quindi, come spiega TheRegister, la notazione scientifica di 10^100, 1 seguito da 100 zero, definito googol, da cui deriva il nome google.

E’ interessante notare la crescita delle visite verso il dominio, secondo Alexa:

Una linea verticale!

Giorgio

Fibre vs rame: 2010 vs 1960

Fibre vs rame: 2010 vs 1960

In questo periodo sto facendo test senza scopo tirando in mezzo cavi seriali, paralleli, ethernet e fibre, tecnologie vecchie di 30 anni, e ne sto misurando latenze e velocità. Credo pubblicherò un report completo a breve, ma qualche appunto preso “on the road” lo trovate già QUI.

Oggi parlando con un amico mi è venuto in mente un paragone, tecnicamente non proprio completo e rigoroso*, ma veramente utile per capire, con una tecnica che definirei “da fruttivendolo”, il progresso e gli enormi vantaggi portati dalle fibre ottiche.

Un cavo in fibra ottica può portare 160 lunghezze d’onda. Ognuna di queste lunghezze d’onda porta un segnale da 10 Gbps. Ci sono quindi 1600 Gbps disponibili**. Un cavo seriale porta, in totale, al massimo 115200 bps. Quindi:

Velocità max fibra ottica = MaxFC = 1600 Gbps = 1 600 000 Mbps

Velocità max cavo seriale = MaxSC = 115200 bps = 0.1152 Mbps

Calcoliamo quindi quanti cavi seriali ci servono per raggiungere la velocità di una fibra ottica:

Numero cavi seriali = NSC = MaxFC / MaxSC = 1 600 000 Mbps / 0.1152 Mbps = 13 888 889

Adesso arriva la perla: un metro di cavo seriale pesa 50 grammi. Un metro di fibra ottica ne pesa meno di 2:

Peso fibra ottica = PFC = 2 g

Peso cavo seriale = PSC = 50 g

Per finire dobbiamo quindi calcolare quanti Kg di cavi seriali ci servono per raggiungere la velocità di un singolo cavo in fibra, dal peso di 2 grammi (0.002 Kg):

PtotSC = NSC x PSC = 13 888 889 x 50 g = 694 444 450 g = 694 444 , 450 Kg

Concludendo: per sostituire un cavo in fibra ottica (dal peso, come già detto, di due soli grammi) utilizzato per connettere due punti ad una velocità di 1600 Gbps ed alla distanza di un metro, ci servirebbero 14 milioni di cavi seriali, che avrebbero un peso totale di circa 700 tonnellate. Per UN SOLO metro di distanza. Vi lascio solo immaginare cosa vorrebbe dire sostituire anche solo le fibre transatlantiche.

C’è un’altro dato interessante: la fibra ottica ha una latenza di 5 microsecondi al Km, mentre un cavo seriale ha una latenza di 5 millisecondi al metro.

Latenza fibra ottica = LFC = 5 microsec / Km = 0.005 ms / Km

Latenza cavo seriale = LSC = 5 ms / m = 5000 ms / Km

Immaginiamo di dover collegare Amsterdam a New York e consideriamo una distanza in linea retta tra le due città di circa 6000 Km (inutile dire che chiaramente quella reale percorsa dai cavi sarebbe maggiore). Calcoliamo quindi la latenza, ovvero il tempo impiegato per percorrere questa distanza sui due tipi di cavi:

Distanza = D = 6000 Km

Tempo di percorrenza fibra ottica = TFC = LFC x D = (0.005 ms / Km) * 6000 Km = 30  ms

Tempo di percorrenza cavo seriale = TSC = LSC x D = (5000 ms / Km) * 6000 Km = 30 000 000 ms = 30 000 secondi = 500 minuti = 8 ore e 30 minuti

Questo, in linea teorica. Perchè per percorrere distanze così enormi il segnale deve essere rigenerato, e questo introduce tremendi ritardi nella trasmissione. Ricordo che per percorrere questi 6000 Km il segnale sul cavo in fibra (che percorre 50 Km senza rigenerazione) dovrebbe essere rigenerato (amplificato) 120 volte, mentre quello seriale dovrebbe essere rigenerato ogni 8 metri, ovvero 750 000 volte.

Numero rigenerazioni fibra ottica = NrFC = 120

Numero rigenerazioni cavo seriale = NrSC = 750 000

Qui azzardo una serie di conti, di cui non garantisco l’accuratezza teorica. Quello che è certo, è che comunque i numeri che otterrò saranno inferiori a quelli reali:

Il tempo reale di percorrenza in fibra ottica della linea Amsterdam – New York è di circa 80 ms. Quello teorico calcolato in linea retta è di 30 ms, quindi sembra ragionevole calcolare 40 ms teorici sulla tratta realmente percorsa. Significa che abbiamo circa 40 ms (sottraggo i 40 di tempo teorico agli 80 di tempo reale misurato) di tempo perso nelle 120 rigenerazioni. Questo vuol dire che una rigenerazione del segnale in fibra ottica ritarda il tutto di 0.34 ms.

Tempo reale percorrenza fibra ottica = TpFC = 80 ms

Tempo totale rigenerazione fibra ottica = TtotrFC = 40 ms

Tempo rigenerazione fibra ottica = TrFC = 0.34 ms

Con questi dati, calcolo il tempo impiegato da una rigenerazione del segnale per un cavo seriale. Uso la relazione LFC : TrFC = LSC : TrSC, quindi:

Tempo rigenerazione cavo seriale = TrSC = (LSC x TrFC) / LFC = (5000 ms / Km x 0.34 ms) / (0.005 ms / Km) = 340 000 ms

Come già detto, per percorrere questa distanza, il segnale di un cavo seriale deve essere rigenerato 750 000 volte, quindi calcoliamo il tempo totale di rigenerazione:

Tempo totale rigenerazione cavo seriale = TtotrSC = TrSC * NrSC = 340 000 ms * 750 000 = 225 000 000 000 ms

Per concludere devo calcolare il tempo totale impiegato per la percorrenza di questa tratta tramite cavo seriale:

Tempo reale percorrenza cavo seriale = TpSC = TtotrSC + TSC = 255 000 000 000 ms + 30 000 000 ms = 255 030 000 000 ms = 255 030 000 secondi = 4 250 500 minuti = 70 842 ore = 2951 giorni = 8 anni.

In fibra ottica, andiamo da Amsterdam a New York in 80 millisecondi. Con un cavo seriale, impiegheremmo 8 anni. Probabilmente sarebbe molto più conveniente inviare una lettera invece che una mail.

Giorgio

* RS 232 non è stato concepito per comunicazioni a lunga distanza: era usato per collegare i modem o i nodi di un cluster, comunque entro pochi metri. La sua portata è intorno agli 8 metri, questo vuol dire che ogni 8 metri serve un rigeneratore di segnale. Le fibre vanno invece per 50 Km o più senza essere toccate. Per finire, ad oggi non esiste modo di connettere due singoli punti utilizzando tutta la banda disponibile su un cavo in fibra ottica. Allo stesso modo non esiste un modo per connettere due host con 14 milioni di cavi seriali.

** Metto lì un dato senza approfondirlo ulteriormente: abbiamo una velocità di 1600 Gbps per singolo cavo. Le linee transoceaniche sono però composte di fasci di 864 cavi, e di solito sono stese a coppie.

DNS resolvers: a quick reference

DNS resolvers: a quick reference

Ho una lista, ma puntualmente la perdo, quindi credo sia il caso di appuntarsi qui i vari servizi di risoluzione DNS ed i loro IP (in prima riga i primari, in seconda, se disponibili, i secondari):

Google Public DNS:

8.8.8.8, 8.8.4.4

Level3 DNS (Unofficial*):

4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

4.2.2.5, 4.2.2.6

OpenDNS:

208.67.222.222, 208.67.220.220

208.67.222.220, 208.67.220.222

DNSAdvantage (UltraDNS):

156.154.70.1, 156.154.71.1

* Il servizio non è mai stato reso pubblico. Questi resolver funzionano, funzionano perfettamente, ma Level3 li ha mai resi disponibili al pubblico ufficialmente.

Spamassassin e il bug di capodanno

Spamassassin e il bug di capodanno

Stavo notando un improvviso incremento dello spam, senza notare un incremento del numero totale di mail ricevute su alcuni server che gestisco. Cosa chiaramente anomala.

Con un pò di smanettamenti ho notato che le email che venivano falciate risultavano positive per “FH_DATE_PAST_20XX”.

Con ulteriori smanettamenti sono arrivato qui:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

In pratica il test verifica se l’header “Date:” è palesemente nel futuro. Come fa? Controlla se è tra il 2010 e il 2099. Con conseguenze catastrofiche visto che ormai siamo veramente nel 2010.

Mi sembra strano che nessuno ne parli, son l’unico pistola che lo ha notato?

Al momento comunque l’unica soluzione credo sia inserire nel local.cf questo:

score FH_DATE_PAST_20XX 0.0

Giorgio

No al low-cost: davvero una scelta?

No al low-cost: davvero una scelta?

Eh si. Questa è la domanda.

Mi ricordo un post su un blog che ho letto tempo fa, TANTO tempo fa, quando il low-cost come lo intendiamo oggi (per intenderci, parlo dell’era “tophost” non dell’era “aruba”) era ancora agli inizi. Non ricordo le parole precise e non riesco a ritrovarlo (la rete è grande), ma diceva qualcosa tipo:

“Per offrire hosting a 30 € annui servono un server e una licenza Plesk. Per offrire hosting a 10 o 1200 € serve una infrastruttura.”

La frase può sembrare banale, ma racchiude una interessante distinzione. In pratica, offrire un servizio a 10 € è complicato e richiede investimenti come un servizio di alto livello. Non a caso, e qui il riscontro è immediato, tutte le aziende che nascono in questi anni, si stabilizzano su quella fascia di offerte e prezzi, non sul low-cost estremo o sull’alto livello.

Le realtà che offrono low-cost estremo, come lo ho definito, infatti, quali sono, in italia? Tophost, che ha una infrastruttura leggendaria e che sicuramente ha alzato all’infinito i costi di startup. Netsons che ha potuto lanciare questo tipo di servizi solo dopo 3 anni di esperienza sull’hosting gratuito. OVH, che non è proprio l’ultima arrivata (qui però va fatto notare che il loro pacchetto gratuito e quello a 14 €/anno sono spariti da qualche mese). Per ultimo, in ordine di tempo, Web4Web, che nasce dalla decennale esperienza della Guest SRL. Così, a memoria, altri non me ne vengono.

I motivi? Prima di tutto, va minimizzato l’intervento umano, perchè far fare una cosa ad un umano costa. Far far la stessa cosa ad una macchina, nella maggior parte dei casi, ha un costo trascurabile. Questo significa studiare un sistema di gestione clienti automatico, creare una buona KB per i clienti, semplificare e minimizzare le procedure.

Il secondo problema è relativo alle macchine stesse. In questo tipo di low-cost si arriva a toccarne i limiti. Mettere 10 000 siti a carico 0 su un server non è semplice come lo è metterne 300 molto frequentati: servono sistemi di gestione e di controllo del carico, perchè il minimo overload, il minimo bug di uno script o un semplice errore di un utente possono, in ambienti normali, far volare giù la macchina, creando disagi agli altri 9999 clienti.

Insomma, parliamo di problemi non indifferenti, che richiedono soluzioni non indifferenti che hanno costi non indifferenti. Siamo abbastanza lontani dall’ordinare un server da ovh, installarci plesk, aprire una partita IVA e iniziare a rivendere hosting.

Alla luce di tutto questo discorso la domanda è: le realtà di piccola/media grandezza, che dichiarano di “non voler entrare nel low-cost”, lo fanno per reale scelta o perchè, semplicemente, non possono entrarci?

Credo che la mia risposta sia chiara dopo questo articolo :), però sarebbe interessante avere altri pareri.

Giorgio