短链接原理及设计

短链接原理及设计

经常看到社交app以及短信中出现推销的链接很短。
那么这是如何做到的呢?还有为什么要将长链接做短呢?
这篇文章就探索一下什么是短链接,短链接的原理是什么,以及如何设计一个高性能的短链接。

什么是短链接

例子

这是一个真实的短链接:

https://dwz.cn/4kuYDdGu

点击跳转后其真实的长链接为:

https://app.smzdm.com/xiazai/?json=%7B%22url%22%3A%22https%3A%2F%2Ftest.smzdm.com%2Fp%2F10192%2F%3Futm_source%3D083002%26utm_medium%3D083002%26utm_campaign%3D083002%22%2C%22channel_name%22%3A%22test%22%2C%22article_id%22%3A%2210192%22%2C%22linkVal%22%3A%2210192%22%2C%22frompage%22%3A%22message%22%2C%22targetpage%22%3A%22test%22%2C%22roll_type%22%3A%222%22%2C%22download%22%3A%220%22%2C%22open_from%22%3A%22message%22%2C%22open_target%22%3A%22test%22%7D

优点

发现了什么?

原本的长链接真的太长了!有没有?

故而,短链接的优点就是短,所以经常出现在对链接长度有限制的平台比如微博。
其实短链接还有其他的优点,不过都是基于短链接长度短而来的衍生优势。

缺点

那么问题来了,短链接带来的缺点又有什么?
是响应时间的变长,其实短链接是靠时间换空间的一个东西。

原理

我们分析一下刚才点击短链接到最终得到真实链接的过程:

原理

客户端点击短链接后访问短链接服务器,服务器302暂时重定向到真实的url。
所以说短链接是用时间换空间。

那么服务器用301还是302呢?
用302。为什么?

  • 301,代表 永久重定向,也就是说第一次请求拿到长链接后,下次浏览器再去请求短链的话,不会向短网址服务器请求了,而是直接从浏览器的缓存里拿,这样在 server 层面就无法获取到短网址的点击数了,如果这个链接刚好是某个活动的链接,也就无法分析此活动的效果。所以我们一般不采用 301。
  • 302,代表 临时重定向,也就是说每次去请求短链都会去请求短网址服务器(除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存),这样就便于 server 统计点击数,所以虽然用 302 会给 server 增加一点压力,但在数据异常重要的今天,这点代码是值得的,所以推荐使用 302!

短链接的设计

哈希算法

我们对比长链接和短链接,发现有一个共同点:都是由域名+域名后面一串字符构成。
其实也就是将长链接域名后面的一长串映射成为了短链接的一短串。
也就是说,我们的任务就是将长的那一串经可能变短。

想到了什么?
对,哈希算法可以做到。
不过常见的md5、sha系列的输出都太长,md5输出是128bit,sha1已经是输出最短的了也有160bit的输出。
这个长度的输出太长了,而且md5,sha等哈希算法都是加密算法,所以对服务器的性能消耗较高,故而不适合作为长链接映射为短链接的哈希算法。

MurmurHash算法是一种非加密型哈希函数,适用于一般的哈希检索操作。与其它流行的哈希函数相比,对于规律性较强的 key,MurmurHash的随机分布特征表现更良好,非加密也就意味着MurmurHash的性能比md5等好得多。

MurmurHash算法可选两种长度:32bit和128bit。
32bit已经很够用了。

MurmurHash的输出是一串十进制数,可以将其转为62进制从而进一步压缩。

短链接工具

  1. https://sina.lt/
  2. http://tool.chinaz.com/tools/dwz.aspx

参考

  1. 高性能短链接设计:长链接
  2. 高性能短链接设计:短链接

怎么样?打开短链接是不是感觉比长链接要慢一点?

评论