Як працюють сервіси коротких URL-адрес?

Як працюють такі сервіси, як TinyURL або Metamark ?
Вони просто пов'язують крихітний URL-ключ із [віртуальною?] Веб-сторінкою, яка лише надає "перенаправлення HTTP" до вихідної URL-адреси? чи є в ньому більше "магії"?

[оригінальне формулювання] Я часто використовую такі послуги для скорочення URL-адрес, як TinyURL, Metamark та інші, але кожен раз, коли я це роблю, я дивуюсь, як працюють ці служби. Чи створюють вони новий файл, який буде переспрямовано на іншу сторінку чи вони використовують піддомени?

Ні, вони не використовують файли. Коли ви натискаєте на таке посилання, HTTP-запит надсилається на їх сервер з повною URL-адресою, наприклад http://bit.ly/duSk8wK (посилання на це питання). Вони читають частину шляху (тутduSk8wK ), яка відображає їхню базу даних. У базі даних вони знаходять опис (іноді), ваше ім’я (іноді) та реальну URL-адресу. Потім вони видають переспрямування, яке є відповіддю HTTP 302 та цільовою URL-адресою в заголовку.

Ця пряма переадресація є важливою. Якби ви використовували файли або спочатку завантажували HTML, а потім переспрямовували, браузер додав би TinyUrl до історії, а це не те, що потрібно. Крім того, сайт, на який буде переспрямовано, буде бачити, що референс (сайт, з якого ви родом ви походили), як сайт, на який знаходиться посилання TinyUrl (тобто twitter.com, ваш власний сайт, де б не було посилання). Це так само важливо, щоб власники сайтів могли бачити, звідки беруться люди. Це теж не працює, якщо завантажується сторінка, яка перенаправляє.

PS: існує більше типів переадресації. HTTP 301 означає: постійне переадресація. Якщо це станеться, браузер більше не запитуватиме сайт bit.ly або TinyUrl, і ці сайти хочуть рахувати звернення. Ось чому використовується HTTP 302, що є тимчасовим перенаправленням. Веб-переглядач кожен раз запитуватиме TinyUrl.com або bit.ly, що дає змогу порахувати звернення за вас (деякі крихітні URL-адреси пропонують це).

Інші відповіли, як працюють переадресації, але ви також повинні знати, як вони генерують свої крихітні URL-адреси. Ви помилково почуєте, що вони створюють хеш URL-адреси, щоб генерувати той унікальний код для скороченої URL-адреси. Це в більшості випадків невірно, вони не використовують алгоритм хешування (де потенційно можуть виникнути зіткнення).

Більшість популярних служб скорочення URL-адрес просто беруть ідентифікатор у базі даних URL-адреси, а потім перетворюють його в Base 36 [a-z0-9] (нечутливий до регістру) або Base 62 (з урахуванням регістру).

Спрощений приклад таблиці бази даних 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

Веб-фрейми, які дозволяють гнучку маршрутизацію, роблять поводження з вхідною URL-адресою дуже просто (Ruby, ASP.NET MVC тощо).

Отже, на веб-сервері у вас може бути дія маршруту, яка має вигляд (псевдо-код):

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

Котрий спрямовує будь-який вхідний запит на ваш сервер, який містить будь-який текст після вашого домену www.mytinyurl.com, до вашого пов’язаного методу, RouteURL. Він доставляє текст, який передається після перекидання вперед у вашій URL-адресі до цього методу.

Отже, скажімо, що ви звернулися з проханням: www.mytinyurl.com/fif

Потім "п'ять" буде передана вашому методу, RouteURL (String UrlID). Потім RouteURL перетворить "п’ятірку" на його еквівалент base10, 20103, і ​​буде зроблено запит бази даних для переадресації на будь-яку URL-адресу, що зберігається під ідентифікатором 20103 (у цьому випадку www.digg.com). Ви також збільшите кількість відвідувань Digg на один, перш ніж перенаправитись на правильну URL-адресу.

Це дійсно спрощений приклад, але ви повинні мати можливість отримати загальне уявлення.

Як розширення до відповіді @A Сальседо:

Деякі служби скорочення URL-адрес (Tinyarro.ws) переходять до крайності, використовуючи Unicode (UTF-8) для кодування символів у скороченому URL-адресі - що дозволяє більшу кількість веб-сайтів, перш ніж потрібно вводити додатковий символ. Оскільки більша частина UTF-8 прийнята до використання ( (IRI) RFC 3987, якою обробляється більшість браузерів ), що стикається з 62сайтів за символом до ~ 1,112,064.

З точки зору перспективи, можна кодувати 1.2366863e + 12 сайтів з 2 символами ( 1,112,064*1,112,064) - у листопаді 2009 року скорочені посилання bit.lyбули доступні в 2.1мільярд разів (за цей час, bit.ly та TinyURL були найпоширенішими послугами скорочення URL-адрес. ) що приблизно в 600 разів менше, ніж ви можете вмістити всього в 2 символи, тому для повної тривалості існування всіх служб скорочення URL-адреси він повинен тривати ще мінімум 20 років до додавання третього символу.

Простими словами, укорочувач URL-адрес відображає довільну довгу послідовність символів (оригінал, довгий шалений URL) у коротку та гладку послідовність символів. Це не що інше, як Hashing, який найчастіше використовується для створення таблиць пошуку, HashMap, md5 Hash для криптографічних цілей тощо.

Щоб зрозуміти процес скорочення URL-адрес, я створив демонстраційний проект на GitHub, а також допис у блозі. Зверніться до цього і дайте мені знати, чи було це корисно.

Повідомлення в блозі: Скорочення URL-адрес