H5推送，为什么都用WebSocket？

       大家好，我是石头~

       最近大盘在3000点附近磨蹭，我也随大众去网上浏览了下感兴趣的几只股票，看下行情怎样。
       看了一会，还是垃圾行情，不咋地，不过看着页面上的那些实时刷新分时图和五档行情，倒是想起公司以前就因为这个实时数据刷新的问题，差点引起一次生产事故。

HTTP轮询差点导致生产事故

       那是一个给用户展示实时数据的需求，产品的要求是用户数据发生变动，需要在30秒内给客户展示出来。

       当时由于数据展示的页面入口较深，负责的后端开发就让H5通过轮询调用的方式来实现数据刷新。

       然而，由于客户端开发的失误，将此页面在APP打开时就进行了初始化，导致数据请求量暴涨，服务端压力大增，差点就把服务端打爆了。

H5推送，应该用什么？

       既然用HTTP做实时数据刷新有风险，那么，应该用什么方式来实现？

       一般要实现服务端推送，都需要用到长连接，而能够做到长连接的只有WebSocket、UDP和TCP，而且，WebSocket是在TCP之上构建的一种高级应用层协议。大家觉得我们应该用哪一种？

       其实，大家只要网上查一下，基本都会被推荐使用WebSocket，那么，为什么要用WebSocket？

为什么要用WebSocket？

       这个我们可以从以下几个方面来看：

• 
  
• 易用性与兼容性：WebSocket兼容现代浏览器（HTML5标准），可以直接在H5页面中使用JavaScript API与后端进行交互，无需复杂的轮询机制，而且支持全双工通信。而TCP层级的通信通常不适合直接在纯浏览器环境中使用，因为浏览器API主要面向HTTP(S)协议栈，若要用TCP，往往需要借助Socket.IO、Flash Socket或其他插件，或者在服务器端代理并通过WebSocket、Comet等方式间接与客户端通信。
  
• 开发复杂度与维护成本：WebSocket已经封装好了一套完整的握手、心跳、断线重连机制，对于开发者而言，使用WebSocket API相对简单。而TCP 开发则需要处理更多的底层细节，包括但不限于连接管理、错误处理、协议设计等，这对于前端开发人员来说门槛较高。
  
• 资源消耗与性能：WebSocket 在建立连接之后可以保持持久连接，减少了每次请求都要建立连接和断开连接带来的资源消耗，提升了性能。而虽然TCP连接也可以维持长久，但如果是自定义TCP协议，由于没有WebSocket的标准化复用和优化机制，可能在大规模并发场景下，资源管理和性能控制更为复杂。
  
• 移动设备支持：WebSocket在移动端浏览器上的支持同样广泛，对于跨平台的H5应用兼容性较好。若采用原生TCP，移动设备上的兼容性和开发难度会进一步加大。
  

结论

       综上所述，H5实时数据推送建议使用WebSocket，但是在使用WebSocket的时候，大家对其安全机制要多关注，避免出现安全漏洞。