关于URL缩短器以及互联网上其他地方的stackoverflow,这里有很多问题,例如
http://www.codinghorror.com/blog/2007/08/url-shortening-hashes-in-practice.html
但是,有一件事我不明白.例如,http://goo.gl目前使用四个字符.但是,他们声称他们的短网址不会过期.正如关于编码恐怖的文章所述,如果他们无法回收URL,唯一可能的解决方案是在某一点上添加一个额外的角色.
好的,到目前为止一切顺利.4个字符表示大约1500万个唯一地址.对于像谷歌地图这样的东西,我认为这不是很多,如果你不能回收,我猜他们很快就用完了可用的地址.
现在对于我没有得到的部分.在分发地址时,它们开始耗尽未使用的地址.他们必须检查是否尚未发布新生成的地址.这种情况发生的可能性和地址已经在使用中增加了.当然,直接的解决方案是一遍又一遍地生成一个新的URL,直到他们找到一个免费的URL,或直到他们生成了所有150万个替代品.然而,这肯定不是他们实际上如何做到这一点,因为这将是非常耗时的.那么他们如何管理呢？
此外,可能有几个访问者同时要求一个简短的URL,因此他们也必须进行一些同步.但是当需要添加第五个角色时应该如何管理这种情况？
最后,在对http://goo.gl中的URL如何工作进行一些研究时,我当然多次在Google地图上为地图请求了一个简短的URL.它们都不会被使用.但是,当Google严格执行一旦发布的URL未到期的策略时,这意味着系统中存在大量的休眠URL.我再次假设谷歌(以及其他服务)也提出了解决这个问题的方法.我可以设想一个清理服务,它可以回收创建后48小时内未访问过的URL,或者在第一周内回收不到10次的URL.我希望有人也能对这个问题有所了解.
简而言之,我得到了URL缩短器的一般原则,但是当这些URL无法过期时,我发现了几个问题.有谁知道上面提到的问题是如何解决的,还有其他问题吗？
编辑
好吧,所以这篇博客文章揭示了一些事情.这些服务不会随机生成任何内容.它们依赖于底层数据库的自动增量功能,并对结果id应用简单转换.这消除了检查id是否已经存在(它没有)并且数据库处理同步的需要.这仍然使我的三个问题中的一个没有答案.这些服务如何"知道"链接是否在创建后实际使用？
Mic*_*lin 32
我确实写过TinyURL(十年前)给我一个我不需要的条目.他们的回答让我意识到我是多么荒谬:他们告诉我" 只需创建你需要的所有网址 ".这些数字说明了一切:
A -随着26低的情况下+ 26个大写字母+ 10个数字(合理位点的选择),使用一个字符给你62点的位置(即,62缩短的URL),然后每个附加炭乘以 62的位置编号:
B - 实际上,需求和用途低于人们的预期.很少有人创建短网址,每个人创建的网址很少.在大多数情况下,原始URL就足够了.结果是,经过多年的努力,最受欢迎的缩短产品仍然只需4或5个字符即可满足今天的需求,而在需要时添加另一个产品将几乎为零.显然goo.gl和goo.gl/maps每个都使用5个字符,youtube使用11个字符(使用上面的62个字符,加上破折号和其他几个字符).
C - 托管(存储+运营)URL的成本,例如,1Trabyte每年1000美元,每个TB能够包含50亿个URL,因此1个URL的成本为0.2微美元/年.然而,Shortener的好处也非常薄,因此业务不是很强劲.对于用户来说,URL的好处很难评估,但错过的链接将比托管成本高得多.
D - 如果用户有可能在未来几年内失效,那么用户就没有必要创建一个短网址,因此持久性是Shortener的主要吸引力,严重的Shortener可能永远不会停止为他们服务,除非他们被迫破产; 然而这种情况已经发生了,无论如何短网址都有其缺点和好处,在维基百科"URL缩短"(各种黑客攻击,针对用户,目标网站或Shortener的风险)中都有解释;例如人们可以通过机器人请求giga数量的URL来攻击Shortener,大多数Shorteners肯定会阻止这种威胁.
Versailles,2013年3月12日星期二20:48:00 +0100,编辑21:01:25