半夜看球，最烦的不是主队输球，而是比分比隔壁群慢半拍。有次我盯着手机等一个进球推送，群里都刷屏了，我这儿还停在0比0，那种感觉，懂的都懂。后来我才开始认真琢磨雷速体育websocket这套东西——不是替谁打广告，纯粹是被延迟逼出来的好奇心。
先说结论：你看到的每一次比分跳动、每一张红黄牌弹窗，背后大概率是一条一直开着的长连接在推数据，而不是你手机每隔几秒去问一次服务器。这个差别，听起来很技术，用起来很体感。
websocket到底解决了个啥问题
传统做法叫轮询。客户端隔一段时间发个请求：比分变了没？变了没？变了没？大部分时候答案是没变，但请求照发，服务器照回。人一多，服务器就跟被一群人围着问“到了吗”的出租车司机一样，烦，还费油。
websocket不一样。握手一次，连接保持住，之后是双向的，服务器那边一有变化直接推给你。雷速体育websocket这种用法，本质上就是把“你去问”变成“我来告”。听起来简单，但在比分这种高频、低容错、又特别吃实时性的场景里，这个转变挺关键的。
当然，我不是说轮询就一无是处，很多场景它够用，也简单，别一听轮询就摇头。
写到这儿突然想起个事。早些年看文字直播，网页得手动刷新，后来有了自动刷新，再后来是那种每隔几秒跳一下的比分条。那会儿觉得已经很快了。现在回头想，那不就是轮询么。技术在往前走，人的耐心反而越来越短，这大概是我们这代看球人的通病。
所以我一直觉得，雷速体育websocket真正的价值不是“快”这一个字，是连接的稳定性。快谁都能做到，堆服务器、缩短间隔就行；但连接不断、断了能自己接回来、推过来的数据不乱序——这些才是脏活累活。再说一遍，稳定性比快重要，因为快是锦上添花，断线是当场劝退。
跟一个做后端的朋友聊过，他说这类服务最难的不是推，是断线重连和心跳。手机锁屏、切后台、地铁进隧道，连接说断就断。用户感知不到，是因为后台在默默重连。你看到的“无感”，其实是别人把一堆异常都吞了。
具体推送频率我不太确定，好像是一秒一次还是更快，反正肉眼看球是跟得上的。太频繁也没意义，人眼和网络都有极限，推得再密，手机该卡还是卡。
- 连接要保持，心跳不能停
- 断线要自动重连，别让用户手动刷新
- 数据要按顺序，进球和红牌不能倒着来
这三点看着朴素，真要做到不出岔子，得花不少功夫。我用了几年这类比分应用，偶尔也遇到过卡住的时候，但多数情况下它确实在后台把问题处理掉了，只是我没察觉。
先这样吧，再写下去就成技术文档了。你们看球的时候有没有被延迟坑过？评论区聊聊。
