Как работают службы коротких 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

Затем "fif" будет передан вашему методу RouteURL (String UrlID). RouteURL затем преобразует «fif» в его эквивалент base10, 20103, и будет сделан запрос к базе данных для перенаправления на любой URL-адрес, хранящийся под идентификатором 20103 (в данном случае www.digg.com). Вы также должны увеличить количество посещений Digg на единицу перед перенаправлением на правильный URL.

Это действительно упрощенный пример, но вы сможете получить общее представление.

Как расширение ответа @A Salcedo:

Некоторые службы сокращения 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миллиард раз (в то время наиболее широко используемыми сервисами сокращения URL-адресов были bit.ly и TinyURL ). что в ~ 600 раз меньше, чем вы можете уместить всего 2 символа, поэтому на протяжении всего срока существования всех сервисов сокращения URL-адресов он должен длиться как минимум еще 20 лет до добавления третьего символа.

Проще говоря, программа сокращения URL-адресов преобразует произвольную длинную последовательность символов (исходный, длинный дрянной URL-адрес) в короткую и гладкую последовательность символов. Это не что иное, как хеширование, которое чаще всего используется для создания таблиц поиска, HashMap, md5 Hash для криптографических целей и т. Д.

Чтобы понять процесс сокращения URL-адресов, я создал демонстрационный проект на GitHub, а также сообщение в блоге. Обязательно обратитесь к этому и дайте мне знать, было ли это полезно.

Сообщение в блоге: сокращение URL