【证券行情交流篇】行情推流选择 Websocket 还是 Socket？

0x01 缘起

现在很多证券数据供应商都会提供Websocket、HTTP 接入方式，但是这两种方式的作用范围我个人感觉有待深入研究，什么应用场景适合哪种方式来进行对接。

• 很早之前我们一个市场数据接入方提出了一个问题，传输协议为什么采用了Websocket协议而不是更加简单轻量级的协议，当时我内心在想不是大多数的数据供应商都是Websocket吗？这种方式不是更好去对接更好兼容对接方的应用程序吗？

• 后面我深入分析了一下Websocket的这种协议，我发现它的应用场景在证券行情这种高频数据上它的缺陷还是很多的。当然相比HTTP这种交互方式还是有很大的一个提升，不管在用户体验上还是资源消耗上已经是一个飞跃了。

0x02 区别

HTTP 和 Websocket 对比网上的文章实在太多了，这里就不赘述了。咱们就针对证券这个行业来进行分析吧。

证券行业针对行情数据方面，各家追求的都是延迟低、响应快，针对这两点我进行一下思考：

1. Websocket 连接过程中只经历一次 TCP 握手过程就可以进行数据交互流程，相比HTTP 则每次请求都需要经历TCP握手和挥手的流程。在一个用户获取行情数据的过程中是不是可以减少这种握手挥手的交互。

2. Websocket 相比HTTP拉数据的方式好了很多，Websocket这种全双工通讯的方式能够实时接收服务器推送的行情数据。相比数据拉取的方式减少了行情数据延迟和服务器发起请求消耗的大量资源。

大家可以通过这篇文章来对比下两者的区别 Websocket 协议简介

0x03 场景

在证券App上的使用场景，我总结了一些使用场景：

1. 针对ToC的报价数据这种用户可能会存在 高频 请求的完全可以采用WS来进行实时推送，当然现在市面上很多都是采用的这种方式，总体来看在用户体验上还是很不错的。
2. 应用客户群体不是 T0短线 交易者，在历史数据方面我们可以退一步用HTTP的方式来拉取数据，这部分数据量相对来说比较大。如果我们用户群体大部分是短线的话，我们需要将K线和分时线的最后一根进行实时推流。
3. 现在市面上有很多数据分析，像大笔买入、大笔卖出、加速拉升等一些智能盯盘的功能，这种数据都是瞬时数据，采用HTTP的方式可能会导致用户错过一些投资机会。
4. 针对 少量行情 订阅采用Websocket的这种方式无疑是比较好的选择，现在很多数据需求从原来的订阅少量证券获取数据演变成了 全量行情 数据的一个需求。针对全量数据的一个推送 Websocket 可能不是一个很好的选择。

综上几点，采用 HTTP 还是 Websocket 取决于针对我们的用户体验和服务资源上，另外也取决你的数据供应商能给你提供到什么程度。很多时候我们的想法经常会受限于我们上游数据的支持程度，一些老牌的数据供应商的提供的数据源只能满足简单的一些需求，但是目前证券市场也处于百花齐放的时代，不管是大陆还是香港的券商都在更新迭代，不进步也终将被取代！

0x04 优化

在 Websocket 行情推送中，不同的数据供应商有不同的做法。以下是我们目前行情供应商数据输出的一些思考：

针对于在一个App应用展示C端用户进到我们应用程序后，例如是一个个股详情界面，我们需要在这个时间获取到数据的快照，然后发起行情订阅，这样其实就变成了我们需要先进行一次HTTP的行情拉取，然后进行订阅，从而接收最新的报价，但是为什么我们不能把这一次HTTP的行情拉取去掉呢？

所以在我们编写行情推送服务端的时候需要考虑一点，如何去减少掉这一次HTTP的数据调用，我们需要在我们行情推送服务端记录一份最新的行情快照，当C端用户进行订阅的时候我们通过Websocket 将C端用户订阅的那份快照数据先推送给用户，那么客户端就不需要再进行请求了，那么整个行情报价的获取将全部由我们Websocket服务端来进行提供！

针对有全量行情数据需求的用户，我们是否能采用Websocket这种协议来进行传输呢？

针对这类用户，我们优先考虑的将是我们带宽情况。Websocket作为应用层的一个传输协议，在数据传输过程中有很多针对行情推送来说是无意义的消息，然而这类消息也将会占用我们数据传输的带宽。所以，针对我们简化我们传输带宽，我们可能要考虑更优的一个方案。

这个内容我们下篇文章再讲。