关于 URL 短链这类问题的思考

大家好，我是晨光，5 年前端开发，现在携程担任高级前端开发。今天聊一聊 url 转为短链接，有一些疑问，也做了一些思考，希望和大家探讨一下～

什么是短链，我们平常收到的一些短信中，会有很短的那种链接，只有一个域名加一串字母的那种链接，就是短链。当我们点击短链，在浏览器中打开，会发现浏览器中的 url 是非常长的，这是什么为什么呢，大家有没有好奇呢。

一、短链的好处

对于用户来说，短链比较简洁，便于传播，方便记忆。

对于开发者来着，短链的字符数少，节约代码行数，增加代码可读性。

当然也有一种情况，比如在某些平台发表内容，会限制字符数，例如最多可输入500字，可能要分享的内容中包含 url，而 url 有450字符，只剩50个字，可能无法描述清楚我们想要表达的观点。

并且这种超长的链接对其他浏览的用户也不友好，假如出现满屏看不懂的字符，肯定会很抓狂。此时采用短链就可以大大节约字符数，用户体验也会更友好。

二、短链的实现方案

昨天查看了大量的资料，都显示，需要服务端做数据支持才可以实现。毕竟我们生成短链的目的还是为了让用户分享和点击，假如服务端没有做类似的缓存，用户访问的时候，肯定会404，因此基于这种情况，需要服务端进行支持。

想要实现一个简单的短链接，很简单，使用随机数什么的就可以实现，但是要考虑到高并发，高稳定，高可靠性，肯定会用到后端存储，至于为什么，晨光考虑的也不是很全面，感兴趣的话，大家也可以思考思考。

具体的生成短链的流程

图片来自稀土掘金

三、字符串压缩

上面讲的是针对 url 做压缩生成短链，接下来想要讨论下有关字符串的压缩。

我们可以把 url 当作普通的字符串，对其进行压缩，还要保证解压后和原来的字符串相同。

应用场景：

h5 或小程序页面跳转，如果 url 超长会被浏览器截断，或直接跳转到 error 页，具体限制的字符数是多少，可能是 2000，3000 或者 5000。为了保证能够正常跳转，可以将 URL 上带的参数进行长度压缩，在使用参数的地方再进行解压。

对于这个点，晨光提出了一些疑问

疑问1:

1、前端这样做的收益有多大

2、假如有1000个人点击了同一个页面，url一样，那么每个用户都会做压缩和解压

3、同一个用户，多次点击同一个链接，也会多次压缩解压这样看下来的话，是不是做在服务端会好一些

答：每个用户点都是在自己的设备上实现计算，如果放在服务端，那所有的压力都会在服务端了，所以放在前端做会好一些

疑问2：

假如 1000 个用户点击 1000 个不同的 url，服务器只用做 1000 次计算，每个用户也只用做 1000 次计算，但所有的用户加起来，共计做了1000*1000次压缩和解压，资源是否有些浪费？

答：不能这样算呀，这里要考虑的是单个用户的开销和服务器的开销，把多个用户的开销加起来没有意义，而且这样的开销对于用户来说是可以忽略不计的。假如有1000个用户点击同一个页面，那么服务端可能要做1000次压缩和解压

疑问3：

服务端是不是会把计算过的 url 缓存下来，用户再次请求相同的url时，就不用再次压缩和解压，所以是不是 1000 个用户点击同一个页面就其实也是只计算一次。

疑问4:

假如 1000 个用户访问了 1000 个不同的页面，那么服务器其实也还是会做 1000 次压缩和解压，当另外的用户访问时，应该只会做查找工作吧。

疑问 3 和疑问 4 暂时没有答案，感兴趣的小伙伴可以大开脑洞，反正晨光现在是无解的。

四、字符串压缩方案

经过大量的资料搜索，最终确定了 shrink-string 和 pako 这两个包可以使用。

shrink-string 对于越长的字符串压缩效果越明显，较短的字符串压缩后的长度可能比压缩前的长度长。

pako 压缩后的内容为 Unit8Array，尝试了传参，无法转为字符串，但是应该也是可以起到压缩效果的吧。

以上就是今天的内容了，欢迎在评论区交流～