实时推送Url的token

凌晨两点，推送我在调试WebSocket连接时抓包，推送发现服务器推送的推送URL里藏着一个token参数。这个token每十分钟失效一次，推送而客户端居然还在用旧的推送。用户那边看到的推送，就是推送页面数据突然卡死，必须手动刷新才能恢复。推送

这事挺典型的推送。很多团队做实时推送，推送只想着把数据推下去，推送却忘了URL里的推送token也在跟着时间轴跑。token不是推送静态的身份证，它是推送有生命周期的，过期了就得换。推送可推送通道往往建立得早，token那时候还是新鲜的，等数据真正推过来，可能已经过了半小时。

我见过一个更极端的案例。某家做行情软件的，服务器端每五秒推送一次股票价格，URL里带着用户鉴权token。结果到了下午开盘高峰，token过期导致大量连接被服务器主动断开。用户看到的不是行情，而是一堆"重新连接中"的提示。他们的运维排查了半天，最后发现是token刷新逻辑写在了业务线程里，而业务线程在高并发下被阻塞了，token根本没机会更新。

要解决这个问题，得把token的刷新跟推送通道解耦。别在业务回调里做token更新，单独起一个定时器，在token过期前三十秒主动刷新。刷新完以后，直接更新推送URL里的参数。这里有个细节容易踩坑——如果你用的是长连接，比如WebSocket，URL在握手时就固定了，后面改参数根本没用。那怎么办？只能在业务层自己加一层鉴权，比如在推送消息体里带上短期token，客户端收到以后校验一次。

还有一种做法，干脆别把token放URL里。放到请求头里，或者放到消息体里。URL会被服务器日志记录，会被浏览器历史保存，token放那儿本身就是个安全隐患。实时推送场景下，token放在WebSocket的握手请求头里，或者放在自定义协议的消息头里，都比放在URL里强得多。

我自己的习惯是，如果非要放URL，那就用一次性token。每次推送前，服务器生成一个短时效的token，附带在推送消息里，客户端下次请求时带上这个新token。这样即使URL被截获，token也已经失效了。代价是每次推送都得做一次加解密，性能上会有一点损耗，但换来的是安全性。

说回那个凌晨的调试。我最后把token刷新逻辑从业务线程里抽出来，放到独立的调度器里，每五分钟检查一次剩余有效期。同时把推送URL里的token改成了短时效的，过期前自动换新。改完之后，连接稳定了，用户不用再手动刷新了。

实时推送的URL带token，看着像个小问题，实则牵一发动全身。token的生命周期管理，推送通道的建立时机，鉴权方式的选择，这三件事没理清楚，线上迟早要出乱子。别等到用户骂娘了才回头查日志，一开始就把token的刷新机制设计好，比什么都强。