Comment fonctionnent les services d'URL courtes?

Comment fonctionnent les services comme TinyURL ou Metamark ?
Associent-ils simplement la minuscule clé URL à une page Web [virtuelle?] Qui fournit simplement une "redirection HTTP" vers l'URL d'origine? ou y a-t-il plus de «magie»?

[libellé original] J'utilise souvent des services de raccourcissement d'URL comme TinyURL, Metamark et autres, mais chaque fois que je le fais, je me demande comment ces services fonctionnent. Créent-ils un nouveau fichier qui redirigera vers une autre page ou utilisent-ils des sous-domaines?

Non, ils n'utilisent pas de fichiers. Lorsque vous cliquez sur un lien comme celui-ci, une requête HTTP est envoyée à leur serveur avec l'URL complète, comme http://bit.ly/duSk8wK (liens vers cette question). Ils lisent la partie chemin (ici duSk8wK), qui correspond à leur base de données. Dans la base de données, ils trouvent une description (parfois), votre nom (parfois) et l'URL réelle. Ensuite, ils émettent une redirection, qui est une réponse HTTP 302 et l'URL cible dans l'en-tête.

Cette redirection directe est importante. Si vous deviez utiliser des fichiers ou charger d'abord du HTML, puis rediriger, le navigateur ajouterait TinyUrl à l'historique, ce qui n'est pas ce que vous voulez. De plus, le site vers lequel est redirigé verra le référent (le site dont vous venez à l'origine) comme étant le site sur lequel se trouve le lien TinyUrl (c'est-à-dire, twitter.com, votre propre site, où que se trouve le lien). Ceci est tout aussi important, afin que les propriétaires de sites puissent voir d'où viennent les gens. Cela aussi, ne fonctionnerait pas si une page est chargée qui redirige.

PS: il existe plus de types de redirection. HTTP 301 signifie: redirection permanente. Si cela se produit, le navigateur ne demandera plus le site bit.ly ou TinyUrl et ces sites veulent compter les visites. C'est pourquoi HTTP 302 est utilisé, qui est une redirection temporaire. Le navigateur demandera à nouveau à TinyUrl.com ou bit.ly, ce qui permet de compter les hits pour vous (certains petits services d'URL offrent cela).

D'autres ont répondu au fonctionnement des redirections, mais vous devez également savoir comment elles génèrent leurs minuscules URL. Vous entendrez à tort qu'ils créent un hachage de l'URL afin de générer ce code unique pour l'URL raccourcie. Ceci est incorrect dans la plupart des cas, ils n'utilisent pas d'algorithme de hachage (où vous pourriez potentiellement avoir des collisions).

La plupart des services de raccourcissement d'URL populaires prennent simplement l'ID dans la base de données de l'URL, puis le convertissent en Base 36 [a-z0-9] (insensible à la casse) ou en Base 62 (sensible à la casse).

Un exemple simplifié de table de base de données 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

Les frameworks Web qui permettent un routage flexible facilitent la gestion des URL entrantes (Ruby, ASP.NET MVC, etc.).

Ainsi, sur votre serveur Web, vous pouvez avoir une action d'itinéraire qui ressemble à (pseudo code):

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

Qui achemine toute demande entrante vers votre serveur contenant du texte après votre domaine www.mytinyurl.com vers votre méthode associée, RouteURL. Il fournit le texte qui est passé après la barre oblique dans votre URL à cette méthode.

Alors, disons que vous avez demandé: www.mytinyurl.com/fif

"fif" serait alors passé à votre méthode, RouteURL (String UrlID). RouteURL convertirait alors "fif" en son équivalent base10, 20103, et une requête de base de données sera faite pour rediriger vers n'importe quelle URL stockée sous l'ID 20103 (dans ce cas, www.digg.com). Vous augmenteriez également le nombre de visites pour Digg de un avant de rediriger vers l'URL correcte.

C'est un exemple vraiment simplifié, mais vous devriez pouvoir vous faire une idée générale.

Comme extension de la réponse @A Salcedo:

Certains services de raccourcissement d'url (Tinyarro.ws) vont à l'extrême en utilisant Unicode (UTF-8) pour encoder des caractères dans une URL raccourcie - ce qui permet un plus grand nombre de sites Web avant d'avoir à ajouter un symbole supplémentaire. Étant donné que la plupart des UTF-8 sont acceptés pour une utilisation ( (IRI) RFC 3987 gérée par la plupart des navigateurs ), cela passe des 62sites par symbole à ~ 1,112,064.

Pour mettre en perspective, on peut encoder 1.2366863e + 12 sites avec 2 symboles ( 1,112,064*1,112,064) - en novembre 2009, des liens raccourcis sur bit.lyont été consultés des 2.1milliards de fois (à cette époque, bit.ly et TinyURL étaient les services de raccourcissement d'URL les plus utilisés. ) ce qui est ~ 600 fois moins que ce que vous pouvez insérer dans seulement 2 symboles, donc pendant toute la durée d'existence de tous les services de raccourcissement d'url, cela devrait durer encore 20 ans au minimum jusqu'à l'ajout du troisième symbole.

En termes simples, le raccourcisseur d'URL mappe une longue séquence arbitraire de caractères (URL originale, longue et merdique) en une séquence courte et lisse de caractères. Ce n'est rien d'autre que du hachage, qui est le plus couramment utilisé pour créer des tables de recherche, HashMap, md5 Hash à des fins cryptographiques, etc.

Pour comprendre le processus de raccourcissement d'URL, j'ai créé un projet de démonstration sur GitHub ainsi qu'un article de blog. Reportez-vous à ceci et faites-moi savoir si cela a été utile.

Article de blog: Raccourcissement d'URL