Come funzionano i servizi URL brevi?

Come funzionano i servizi come TinyURL o Metamark ?
Associano semplicemente la piccola chiave URL con una pagina web [virtuale?] Che fornisce semplicemente un “reindirizzamento HTTP” all’URL originale? o c’è più “magia” in esso?

[testo originale] Uso spesso servizi di abbreviazione di URL come TinyURL, Metamark e altri, ma ogni volta che lo faccio, mi chiedo come funzionano questi servizi. Creano un nuovo file che reindirizzerà a un’altra pagina o utilizza i sottodomini?

No, non usano i file. Quando fai clic su un link del genere, una richiesta HTTP viene inviata al loro server con l’URL completo, come http://bit.ly/duSk8wK (link a questa domanda). duSk8wK parte del percorso (qui duSk8wK ), che esegue il mapping al loro database. Nel database, trovano una descrizione (a volte), il tuo nome (a volte) e l’URL reale. Quindi emettono un reindirizzamento, che è una risposta HTTP 302 e l’URL di destinazione nell’intestazione.

Questo reindirizzamento diretto è importante. Se dovessi utilizzare i file o prima caricare HTML e quindi redirect, il browser aggiungerà TinyUrl alla cronologia, che non è ciò che desideri. Inoltre, il sito che viene reindirizzato vedrà il referrer (il sito da cui provenite originariamente) come il sito su cui è in atto il collegamento TinyUrl (cioè, twitter.com, il tuo sito, ovunque sia il collegamento). Questo è altrettanto importante, in modo che i proprietari dei siti possano vedere da dove provengono le persone. Anche questo, non funzionerebbe se una pagina viene caricata che reindirizza.

PS: ci sono più tipi di reindirizzamento. HTTP 301 significa: reindirizzamento permanente. Se ciò accadesse, il browser non richiederà più il sito bit.ly o TinyUrl e quei siti vogliono contare gli hit. Ecco perché viene utilizzato HTTP 302, che è un reindirizzamento temporaneo. Il browser chiederà a TinyUrl.com o bit.ly di nuovo ogni volta, il che rende ansible contare gli hit per te (alcuni servizi di url minuscoli offrono questo).

Altri hanno risposto a come funzionano i reindirizzamenti, ma dovresti anche sapere come generano i loro piccoli URL. Sentirai per errore che creano un hash dell’URL per generare quel codice univoco per l’URL abbreviato. Questo non è corretto nella maggior parte dei casi, non stanno usando un algoritmo di hashing (dove potresti potenzialmente avere collisioni).

La maggior parte dei popolari servizi di abbreviazione URL prende semplicemente l’ID nel database dell’URL e quindi lo converte in Base 36 [a-z0-9] (senza distinzione tra maiuscole e minuscole) o Base 62 (sensibile a maiuscole e minuscole).

Un esempio semplificato di una tabella di database TinyURL:

 ID URL VisitCount 1 www.google.com 26 2 www.stackoverflow.com 2048 3 www.reddit.com 64 ... 20103 www.digg.com 201 20104 www.4chan.com 20 

I Web Framework che consentono il routing flessibile rendono la gestione degli URL in arrivo davvero facile (Ruby, ASP.NET MVC, ecc.).

Quindi, sul tuo server web potresti avere un’azione di route che assomiglia (pseudo codice):

 Route: www.mytinyurl.com/{UrlID} Route Action: RouteURL(UrlID); 

Che indirizza qualsiasi richiesta in entrata al tuo server che ha un testo dopo il tuo dominio http://www.mytinyurl.com al tuo metodo associato, RouteURL. Fornisce il testo che viene passato dopo la barra in avanti nel tuo URL per quel metodo.

Quindi, diciamo che hai richiesto: http://www.mytinyurl.com/fif

“fif” verrebbe quindi passato al metodo, RouteURL (String UrlID). RouteURL convertirà quindi “fif” al suo equivalente base10, 20103, e verrà effettuata una richiesta al database per redirect a qualsiasi URL memorizzato sotto l’ID 20103 (in questo caso, http://www.digg.com). Aumenterai anche il numero di visite per Digg di uno prima di redirect all’URL corretto.

Questo è un esempio veramente semplificato ma dovresti essere in grado di ottenere l’idea generale.

Come estensione della risposta @A Salcedo:

Alcuni servizi di abbreviazione di url (Tinyarro.ws) vanno all’estremo usando Unicode (UTF-8) per codificare i caratteri in url abbreviato – che consente una maggiore quantità di siti Web prima di dover aggiungere un simbolo aggiuntivo. Dal momento che la maggior parte di UTF-8 è accettata per l’uso ( (IRI) RFC 3987 gestita dalla maggior parte dei browser ), ciò 1,112,064 urto da 62 siti per simbolo a ~ 1,112,064 .

Per mettere in prospettiva si possono codificare 1.2366863e + 12 siti con 2 simboli ( 1,112,064*1,112,064 ) – nel novembre 2009, i collegamenti abbreviati su bit.ly sono stati acceduti a 2.1 miliardi di volte (in quel periodo, bit.ly e TinyURL erano i più diffusi usato servizi di abbreviazione di URL. ) che è ~ 600 volte inferiore a quello che si può inserire in soli 2 simboli, quindi per la piena durata dell’esistenza di tutti i servizi di accorciamento dell’URL dovrebbe durare almeno altri 20 anni fino ad aggiungere un terzo simbolo.

In parole semplici, shortener URL esegue il mapping di una lunga sequenza arbitraria di caratteri (originale, lungo URL crappy) in una sequenza di personaggi breve e chiara. Questo non è altro che Hashing, che è più comunemente usato per creare tabelle di ricerca, HashMap, hash md5 per scopi crittografici ecc.

Per comprendere il processo di abbreviazione URL ho creato un progetto demo su GitHub e anche un post sul blog. Fai riferimento a questo e fammi sapere se è stato utile.

Post del blog: accorciamento dell’URL