短网址服务如何运作？答案

【问题标题】：How do short URLs services work?短网址服务如何运作？
【发布时间】：2010-12-06 10:48:00
【问题描述】：

TinyURL 或 Metamark 等服务如何工作？
他们是否只是简单地将微小的 URL 键与 [虚拟？] 网页相关联，该网页仅提供对原始 URL 的“HTTP 重定向”？还是有更多的“魔力”？

[原文] 我经常使用 TinyURL、Metamark 等 URL 缩短服务，但每次使用时，我都想知道这些服务是如何工作的。他们是创建一个将重定向到另一个页面的新文件还是使用子域？

【问题讨论】：

改写 [non-] 问题：“像 TinyURL 这样的服务是如何工作的？它们是否只是将微小的 URL 键与 [虚拟？] 网页相关联，该网页仅提供“HTTP 重定向”到原始网址？这是您要问的吗？
缩短的网址会过期吗？（即，这些 URL 的数据库条目已从服务器中删除）
@thd：是的，但它可能取决于（每日）点击量，以及短网址服务提供商的政策。他们也可能允许永不过期，有些人为此要求会员资格。
How does a URL Shortener work?的可能重复

标签： web-services url url-shortener bit.ly short-url

【解决方案1】：

不，他们不使用文件。当您单击这样的链接时，将使用完整的 URL 将 HTTP 请求发送到他们的服务器，例如 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 服务提供此功能）。

【讨论】：

其实我认为，Bit.ly 使用的是 HTTP 301 而不是 302（我最后听说的）
由于 bit.ly 不允许您更改其中一个 URL 指向的位置，因此 301 是有意义的。无需记住bit.ly版本并重新检查。
@KennyCason / @Joost Schuur：确实使用的是 HTTP 301，但是带有时间戳。这会将其变成Moved 而不是Moved Permanently。这是一个微妙的区别。通过添加时间戳，浏览器认为它应该在达到此超时时检查资源是否已更改。其他的，比如 is.gd，使用普通的301 Moved Permanently 并且浏览器不需要重新检查（但经常会）。最后，像 url4.eu 这样的服务根本不会重定向，而是首先向您显示广告。使用 301 服务仍然可以计算唯一身份访问者，但不能计算所有点击次数。
示例 bitly URL 现在是一个真实的 URL，实际上重定向回这个问题 ;-) 有关信息页面，请参见 bitly.com/duSk8wK+。
@Costa：统计点击的方法有很多种，有可能它会跟踪你的网卡ID，这是一种跟踪请求是否来自同一台计算机的方法。可以伪造或更改该 ID，这不是万无一失的。此外，它可能会跟踪或使用之前在不同浏览器上为同一用户设置的第三方 cookie，您可以通过清除所有会话数据并使用匿名浏览器来检查。

【解决方案2】：

其他人已经回答了重定向的工作原理，但您也应该知道它们如何生成他们的小 URL。您会错误地听到他们创建了 URL 的哈希值，以便为缩短的 URL 生成唯一的代码。在大多数情况下这是不正确的，它们没有使用散列算法（您可能会发生冲突）。

大多数流行的 URL 缩短服务只是获取 URL 数据库中的 ID，然后将其转换为 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

允许灵活路由的 Web 框架使处理传入 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，并且将发出一个数据库请求以重定向到存储在 ID 20103 下的任何 URL（在本例中为 www.digg.com）。在重定向到正确的 URL 之前，您还可以将 Digg 的访问次数增加一。

这是一个非常简化的示例，但您应该能够大致了解。

【讨论】：

感谢您的精彩解释。那么当有人试图为已经存在的长 URL 创建一个短 URL 时会发生什么？他们是否对数据库执行全文搜索？我不这么认为，因为它会耗费太多时间。基于散列或消息摘要的方法看起来更实用。
@PiyushKansal 您可以在内部使用哈希值进行O(1) 查找以查找重复项；然后为此路由现有的微小 URL，或者可以选择生成一个新 URL。据我所知，goo.gl 重复使用相同 URL 的小 URL；在你的页面上试试这个：你明白了吗>>goo.gl/8gVb8X？
他们如何处理url参数？例如 www.digg.com?filter=123

【解决方案3】：

作为@A Salcedo 答案的扩展：

一些 url 缩短服务 (Tinyarro.ws) 通过使用 Unicode (UTF-8) 对缩短的 url 中的字符进行编码来达到极端 - 这允许在必须添加额外符号之前有更多的网站。由于大多数UTF-8 is accepted for use ((IRI) RFC 3987 handled by most browsers) 从每个符号的62 站点跳到~1,112,064。

从角度来看，可以用 2 个符号 (1,112,064*1,112,064) 对 1.2366863e+12 个站点进行编码 - 2009 年 11 月，bit.ly 上的缩短链接被访问 2.1 十亿次 (Around that time, bit.ly and TinyURL were the most widely used URL-shortening services.)，约为 600比你只能放入 2 个符号的时间要少，因此在所有 url 缩短服务存在的整个持续时间内，它应该至少再持续 20 年，直到添加第三个符号。

【讨论】：

【解决方案4】：

简单来说，URL 缩短器将任意长的字符序列（原始的、长的、糟糕的 url）映射为短而流畅的字符序列。这只不过是 Hashing，它最常用于创建查找表、HashMap、用于加密目的的 md5 Hash 等。

为了理解 URL-Shortening 的过程，我在 GitHub 上创建了一个演示项目以及一篇博文。请参考此内容，如果有帮助请告诉我。

博文：URL Shortening

【讨论】：

有了Hashmap，我们不会面临潜在的冲突吗？