股市数据源如何运作？
或从服务器到客户端的任何其他类型的实时数据馈送...我正在谈论从服务器到客户端的一堆实时数据。即每秒更新一次信息。
服务器是否神奇地将数据推送到客户端，或者客户端是否需要不断轮询服务器以获取更新？这通常在什么协议下工作？ （http、套接字通信等？）
or any other type of realtime data feed from server to client... I'm talking about a bunch of realtime data from server to client. i.e., an informational update every second.
Does the server magically push the data to the client, or does the client need to continuously poll the server for updates? And under what protocol does this usually work? (http, socket communication, etc?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在经纪商/银行等使用的服务器端金融应用程序中，市场数据（报价、交易等）是通过某些应用程序级协议（很可能不是 HTTP）通过 TCP 传输的。当然，没有民意调查。客户端正在与服务器建立TCP连接，服务器将数据推送给客户端。分发市场数据的常见方法之一是FIX。
汤森路透拥有大量从大型机时代开始的神秘专有协议来分发此类数据。
HTTP 可用于 SOAP/RESTful 传输/请求不太大容量的数据，例如商业新闻。
更新 实际上，在某些情况下，即使是 FIX 也是不够的，因为它的“文本”性质导致开销很大。大多数经纪商和交易所使用二进制格式协议（FAST 或某些专有协议）传输大容量流，例如报价。
In server-side financial applications used by brokers/banks etc. market data (quotes,trades etc) is transmitted over TCP via some application-level protocol which most probably won't be HTTP. Of course, there's no polling. Client is establishing TCP connection with server, server pushes data to client. One of common approaches to distribute market data is FIX.
Thomson-Reuters have bunch of cryptic proprietary protocols dating from mainframe days to distribute such data.
HTTP can be used for SOAP/RESTful to transmit/request data of not-so-large volume, like business news.
UPDATE Actually, even FIX is not enough in some cases, as it has big overhead because of it's "text" nature. Most brokers and exchanges transmit high-volume streams, such as quotes, using binary-format protocols (FAST or some proprietary).
在一个简单的例子中：
while(data = recv(socket))（伪代码）send(...)s 在插座上。您甚至可以通过 HTTP 实现此模式（HTTP 套接字没有真正的时间上限）。服务器甚至不需要从套接字读取 - 它可以仅尝试写入 Firehose。
通常采用 TCP 套接字 - 消息按顺序到达，并且尽力而为。如果延迟更重要并且丢弃或乱序不是问题，则可以使用 UDP。
In a simple case:
while(data = recv(socket))(pseudocode)send(...)s on the socket.You can even implement this pattern over HTTP (there is no real upper time limit to an HTTP socket). The server need not even read from the socket - it can be trying to write to the firehose only.
Usually a TCP socket is employed - messages arrive in order, and are best-effort. If latency is more important and dropped or out of order is not an issue, UDP can be used.