深入浅出:在线短链接工具开发原理与源码分享

举报
M1.FIT 发表于 2021/11/29 15:55:28 2021/11/29
【摘要】 微博和Twitter都有140字数的限制,如果分享一个长网址,很容易就超出限制,同时长链接也占用了太多的字符空间,无法编辑更多的内容。另外,如国内微信、淘宝等等很多平台都是无法互通,平台之间都或多或少存在相互屏蔽的行为。同时,还有一个比较重要的因素,在我们日常网络营销中,当营销活动推出后,却很难去追踪用户与效果,基于这些种种的因素,才最终导致了如今短链接的盛行。

一、使用场景(Scenario)

微博和Twitter都有140字数的限制,如果分享一个长网址,很容易就超出限制,同时长链接也占用了太多的字符空间,无法编辑更多的内容。另外,如国内微信、淘宝等等很多平台都是无法互通,平台之间都或多或少存在相互屏蔽的行为。同时,还有一个比较重要的因素,在我们日常网络营销中,当营销活动推出后,却很难去追踪用户与效果,基于这些种种的因素,才最终导致了如今短链接的盛行。

 

二、短链接多短才合适

短链接既然这么重要,那么,究竟多短才合适呢?目前全球拥有70亿人口,假设每人拥有一个网页的基数,那么已有70亿个网页链接。目前,如果按照2进制32的字符来算的话,2^{32}=4294967296232,这个数据对于70亿是远远不够,但远远小于64位的上限值,那么用一个64位就足够了。微博的短网址服务用长度为7的字符串,这个字符串可以看做是62进制的数,那么最大能表示{62}^7=3521614606208627=3521614606208个网址,远远大于70亿的上限,7位字符串是目前短链接比较通用的标准。

 

三、如何转换成字符串

一个64位整数如何转化为字符串,假设我们只用大小写字母加数字,那么可以看作是62进制数,log_{62{(2^{64}-1)=10.7log62(264−1)=10.7,即字符串最长11就足够了。但实际,还可以再短一点,比如新浪微博采用的长度就是7,因为 62^7=3521614606208627=3521614606208,这个量级远远超过互联网上的URL总数了,有足够的冗余空间。如今的web服务器(例如Apache, Nginx)大部分都区分URL里的大小写,所以用大小写字母来区分不同的URL是完全没问题的。因此,长度不超过7的字符串,由大小写字母加数字共62个字母组成。

 

四、核心算法与原理介绍

核心算法是10进制转62进制: 

function from10to62($dec) {

$dict = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';

$result = '';

 do {

$result = $dict[$dec % 62] . $result;

$dec = intval($dec / 62);

} while ($dec != 0);

return $result;

}

  

原理:以0ut为例: 先以我的文章链接为例!

长链接:https://bbs.huaweicloud.com/blogs/313750

在经过0ut短链压缩后,生成短链接: https://m1.fit/1p4b5

这是如何实现的呢?下面为大家讲解下短链接生成原理:生成短链接-1.png

请求短链接,跳转到原链接的流程图:

定位原链接图-2.png


 五、如何存储

如果存储短网址和长网址的对应关系?以短网址为 primary key, 长网址为value, 可以用传统的关系数据库存起来,例如MySQL,PostgreSQL,也可以用任意一个分布式KV数据库,例如Redis, LevelDB。

如果你手痒想要手工设计这个存储,那就是另一个话题了,你需要完整地造一个KV存储引擎轮子。当前流行的KV存储引擎有LevelDB何RockDB,可以去了解它们的源码。

 

六、短链接重定向

这是个有趣的问题,主要看你对301和302的理解,以及浏览器缓存机制的理解程度,301是永久重定向,302是临时重定向。短链接一经生成就不会变化,所以用301是符合http语义的。但是如果用了301, Google、百度这些搜索引擎,搜索的时候会直接展示真实地址,那我们就无法统计到短地址被点击的次数了,也无法收集用户的Cookie、User Agent等信息,这些信息可以用来做很多有意义的大数据分析,也是短网址服务商的主要盈利来源,所以,应该选择302重定向。

在这里,有兴趣的朋友可以去看看https://m1.fit/这个短链接平台是怎么做的,大家可以看看新浪微博的短链接,通过抓包看看返回的结果,就可以知道新浪微博用的就是302临时重定向。

 

七、如何预防攻击

如果一些别有用心的黑客,短时间内向TinyURL服务器发送大量的请求,会迅速耗光ID,怎么办呢?

首先,限制IP的单日请求总数,超过阈值则直接拒绝服务。当然,光限制IP的请求数量肯定不够,因为黑客一般手里有上百万台肉鸡的,拥有海量的IP地址池,所以光限制IP作用不大。

我们可以用一台Redis作为缓存服务器,存储的不是 ID->长网址,而是 长网址->ID,仅存储一天以内的数据,用LRU机制进行淘汰。这样,如果黑客大量发同一个长网址过来,直接从缓存服务器里返回短网址即可,他就无法耗光我们的ID了。当然,我们还可以设置更多的安全机制来预防被攻击,这都是可以灵活运用的。

根据上面的简单叙述,相信大家对在短链接生成器这样一个短链接平台应该有所了解,其实只要弄懂了原理,我们都可以自己做一套属于自己的短链接生成器短网址平台。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。