微博把长链接转换成自己的短连接有什么用

1：无论多长的微博，都能够转成固定长短的短链，防止某些连接太长影响用户输入其他内容。

2：所有短链在算法上无法直接解链，必须经过新浪的服务器，把链接系统控制到自己的手上。这对网络内容审察来说作用极其大，如果有人发的微博包含敏感内容，新浪就不予中转。

3：重新组织链接网页的内容，方便用户在手机端查看。

4：由于长链中可能会包含#或者@这些特殊字符，给客户端的字符串处理带来压力，编码可以消除这些特殊符号。

5：由于所有链接都要经新浪的服务器，因此服务器保存有所有的链接，方便进行数据挖掘和统计分析。

望采纳，谢谢！

tcn短网址如何生成？首先我们需要去获取新浪tcn短网址生成接口或者在线工具，然后再请求接口或者使用工具即可将一个冗长的链接缩短生成10个字符以内的tcn格式的短网址。

tcn短链接的应用场景很广，譬如短信营销、邮件推广、微信营销、QQ营销、自媒体推广、渠道推广等，都会用到短链接。究其原因是在于短网址可以降低推广成本、用户记忆成本，提高用户点击率；在特定的场景下推广还能规避关键词，防止域名被屏蔽、被拦截，隐藏真实地址等。

1、请求方式

POST 

2、返回格式

直接返回 “https://tcn/xxxx”

3、使用方法

① 在线使用

只需将 “http://wwwbaiducom” 换成需要缩短的长网址（要带http(s)://），然后复制整串链接前往浏览器打开即可生成。

② 请求接口

设置服务器请求接口生成，每请求一次返回一个结果，相关请求示例如下。

4、请求示例

① PHP：

② Java：

③ Python：

平时我们在上网的时候，印象最深刻的有一次是短链接的服务。例如：平时在微信上看一个网页的时候，如果我们选择在浏览器打开的时候，会看到很长的URL，我们分享的时候，会看到一个很短URL，这就是本次所说的短链接的应用之一。

长链接示例： https://mpweixinqqcom/s__biz=MzAxNzMwOTQ0NA==&mid=2653355437&idx=1&sn=5901826ea638462ff71b7f2d06c6331d&chksm=8035d7c6b7425ed06661866af60657414bb71765d2ce915d14726736fa1e72ea8a529331c947&scene=0&key=34df968fd24033237ff036c7de8b6745e1968de9564cf2a8db689025dd0c3682848381771dab960824f506e6f9d484614746f9c0eecb48b884ce4320bb86470a77ce811cc5b401a8800b6fd6b36be097&ascene=0&uin=ODU5NDQ1NjI1&devicetype=iMac+MacBookAir6%2C2+OSX+OSX+10126+build(16G29)&version=12020810&nettype=WIFI&fontScale=100&pass_ticket=IvPqxUmCJqZg9%2B3GfAIQSbQ4IGRIHx796D0UwlCyUCu4b5P4bSsjlN89A0eRzSfL

我用短链接系统生成的（长期会失效）： https://0x9me/FAKcm

废话少说，短链接就是我们很短的链接。我们的目的是要把长链接转换成短链接。接下来我要提出一个问题：怎么把长链接转换成短链接呢？

1压缩

实现一种算法，将长地址转换成短地址。然后再实现一种逆运算，将短地址转换成原来的地址。其实仔细的想一下，这是不可能的。

2Hash算法

可能是大多数人都会想到的一种方法。有人会提出，将一个长URL进行Hash运算，然后将Hash值作为这个长链接的唯一标示。但是通常容易想到的不一定是最优的，我们知道Hash有可能产生碰撞，Hash碰撞的解决，会增强短链接系统的复杂度。

顾名思义这个系统的第一个请求过来了，我们以微博为例，短链接系统的第一个请求我们可以给变为tcn/0，第二个tcn/1等等；

实现的方式也会很简单

1、小型的系统用MySQL的自增索引就可以满足。

2、大型系统可以考虑分布式key-value系统。

发号策略是这样的，当一个新的链接过来时，发号器发一个号与之对应。往后只要有新链接过来，发号器不停发号就好。举个例子，第一个进来的链接发号器发0号，对应的短链接为 xxxxx/0，第二个进来的链接发号器发1号，对应的短链接为 xxxxx/1，以此类推。

发号器发出的10进制号需要转换成62进制，这样可以大大缩短号码转换成字符串后的长度。比如发号器发出 10,000,000,000 这个号码，如果不转换成62进制，直接拼接在域名后面，得到这样一个链接 xxxxx/10000000000。将上面的号码转换成62进制，结果为AOYKUa，长度只有6位，拼接得到的链接为 xxxxx/AOYKUa。可以看得出，进制转换后得到的短链接长度变短了一些。6位62进制数，对应的号码空间为626，约等于568亿，所以基本上不用担心发号器无号可发的情况。

上面设计看起来有一个单点，那就是发号器。如果做成分布式的，那么多节点要保持同步加1，多点同时写入。这样难以避免产生单点性能瓶颈。因此我们可以考虑将单点变为多点。我们可以引入多个机器，我们可以设定机器A发号只发向100取余等于0的数字100n，同理机器B只发向100取余等于1数字 100n+1，以此类推，各个机器相互独立互不干扰，我们可以随时扩展我们的机器了。

同一长链接，每次转成的短链接不一定一样，原因在于如果查询缓存时，如果未命中，发号器会发新号给这个链接。需要说明的是，缓存应该缓存经常转换的热门链接，假设设定缓存过期时间为一小时，如果某个链接很活跃的话，缓存查询命中后，缓存会刷新这个链接的存活时间，重新计时，这个链接就会长久存在缓存中。

我们也可以引入LRU算法。进行淘汰我们不经常使用到的链接。

选取301，还是302？

301是永久重定向，302是临时重定向。

如果选择301 ：短地址生成以后就不会变化，所以用301是符合http语义的。同时对服务器压力也会有一定减少。这样一来，我们就无法统计到短地址被点击的次数了。

如果选择302 ：选择302虽然会增加服务器压力，但是可以统计到短地址被点击的次数了，我可以针对点击的次数来进行后期的大数据处理，机器学习，以及推荐算法。

选择302还是301，想必读者心中有肯定有数了。

目前，几乎所有的3～4个字母的单词com域名都已被注册，这并非是巧合。甚至5个字母的单词域名也在快速消失。短通常易记，也容易拼凑出域名的含义，所以短域名通常受欢迎。

要知道，相当多的网民根本不用书签。他们只是记住最喜欢的网站的域名，上网的时候就敲出它们。可以想象，如果你的域名非常复杂而难以记忆的话，你不知要损失多少这样的访客呢。仅此一点，你就输掉了。

另外，短域名的访问速度更快，一个域名下的二级域名，三级域名也许有很多个，如果服务器需要解析域名下的所有二级，三级域名，那么这时候，短域名的好处就会比较明显。因为服务器需要对域名中的每一个字符检测，然后再进行解析，之后用户就能够访问页面，那么在域名越短的情况下，访问速度应该会更快了。

再者，短域名的可用性更强。有时候域名会被使用到某些素材上，例如是网站宣传，网站LOGO等等。那么这时候短域名就可以轻易在或LOGO上完整显示了，并且美观，宣传品牌的同时也能宣传网站，岂不是一举两得？！

短连接

连接->传输数据->关闭连接 

比如HTTP是无状态的的短链接，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

具体就是：浏览器client发起并建立TCP连接 -> client发送HttpRequest报文 -> server接收到报文->server handle并发送HttpResponse报文给前端,发送完毕之后立即调用socketclose方法

->client接收response报文->client最终会收到server端断开TCP连接的信号->client 端断开TCP连接，具体就是调用close方法。

也可以这样说：短连接是指SOCKET连接后，发送接收完数据后马上断开连接。

因为连接后接收了数据就断开了，所以每次数据接受处理不会有联系。 这也是HTTP协议无状态的原因之一。

长连接

连接->传输数据->保持连接 -> 传输数据-> ->直到一方关闭连接，多是客户端关闭连接。 

长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

HTTP在短链接和长连接上的选择：

HTTP是无状态的 ，也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话

HTTP11和HTTP10相比较而言，最大的区别就是增加了持久连接支持(貌似最新的HTTP11 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。

如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive 

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了带宽。

实现长连接要客户端和服务端都支持长连接。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。

每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。

例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

总之，长连接和短连接的选择要视情况而定。