过快请求 /x/space 导致限流

[smdsbz]

过快地请求 /x/space 将导致一段时间内后续请求返回 421 Precondition Failed。

似乎是以5 分钟为周期在刷新请求次数，一旦超过 150 次就会锁死。锁死期间无法通过网页或 RESTful 方式访问空间（即使使用的 SESSDATA 不一样），但手机 APP 端仍然能够正常访问。

个人猜测 BB 空间使用的 API 是由其他 API 在服务器上拼接得到的，偏向前端，因此部署了限流策略，其他更原子的 API 暂未发现类似的情况。

[ProgramRipper]

个人猜测 BB 空间使用的 API 是由其他 API 在服务器上拼接得到的，偏向前端，因此部署了限流策略

我觉得应该是为了防止“人口普查”才做的限流。与用户信息有关的API是限制最严重的API，不仅有一定时间内请求次数限制，还有并发请求限制（一旦并发请求，立刻封禁API）

其他更原子的 API 暂未发现类似的情况

不知道类似的情况指的是限流，还是150次每5分钟的限制？如果是前者，几乎所有API都有，不过限制也许不同，我个人发现大多是1500次/10分钟（详见 #54 中的讨论）；如果是后者的话，的确，这是全站最严的限制。

[smdsbz]

感觉确实应该是只在这个 namespace 下做了更严格的限制。

我发现这个限制的场景是连续发起请求获取用户名，并同时通过请求 /x/relation 获取关注关系。但讲道理获取关注应该是比单纯获取用户信息更 expensive 的操作，但每次都是卡在 /x/space 上。推测应该是只在 /x/space 的代理实现上多加了规则。

但我觉得这也太严了，要求一个协程挂起 5 分钟已经属于不可用的范畴（VSCode 扩展运行时会直接把超过 1 分钟未调度的 Promise 鲨掉）。而且同比来说 /x/relation 的信息比 /x/space/acc/info 要值钱多了，毕竟四舍五入免费用屑站服务器做社交网络图计算 🤣。所以我能想到的理由只有这个 API “偏向前端”，毕竟打开 BB 空间就要调用这个 API，过于明显很容易被滥用。

这个 issue 我先关了，到处都限流没必要单开一个，只是说明一下使用上可能需要特别考虑，可以考虑在文档里面多一嘴。

[smdsbz]

现在改用 http://api.live.bilibili.com/live_user/v1/Master/info 来获取用户名和房间号了

笑死，根本不卡我

什么业务流量大不言而喻 😅

[landall]

现在改用 http://api.live.bilibili.com/live_user/v1/Master/info 来获取用户名和房间号了

笑死，根本不卡我

什么业务流量大不言而喻 😅

果然直播平台没人权。

[landall]

个人猜测 BB 空间使用的 API 是由其他 API 在服务器上拼接得到的，偏向前端，因此部署了限流策略

我觉得应该是为了防止“人口普查”才做的限流。与用户信息有关的API是限制最严重的API，不仅有一定时间内请求次数限制，还有并发请求限制（一旦并发请求，立刻封禁API）

其他更原子的 API 暂未发现类似的情况

不知道类似的情况指的是限流，还是150次每5分钟的限制？如果是前者，几乎所有API都有，不过限制也许不同，我个人发现大多是1500次/10分钟（详见 #54 中的讨论）；如果是后者的话，的确，这是全站最严的限制。

我请求空间的视频列表，大概220次左右就会被封。是按照空间的mid封杀IP的。同一IP请求其他人的空间首页好像是独立计算的。