支付场景下 获取结果的几种方式总结

参考：

Web 实时推送技术的总结 浅谈Websocket、Ajax轮询和长连接（long pull）

轮询

轮询是客户端和服务器之间会一直进行连接，每隔一段时间就询问一次。其缺点也很明显：连接数会很多，一个接受，一个发送。而且每次发送请求都会有Http的Header，会很耗流量，也会消耗CPU的利用率。

优点：实现简单，无需做过多的更改 缺点：轮询的间隔过长，会导致用户不能及时接收到更新的数据；轮询的间隔过短，会导致查询请求过多，增加服务器端的负担

长连接

长轮询是对轮询的改进版，客户端发送HTTP给服务器之后，看有没有新消息，如果没有新消息，就一直等待。当有新消息的时候，才会返回给客户端。在某种程度上减小了网络带宽和CPU利用率等问题。由于http数据包的头部数据量往往很大（通常有400多个字节），但是真正被服务器需要的数据却很少（有时只有10个字节左右），这样的数据包在网络上周期性的传输，难免对网络带宽是一种浪费。

优点：比 Polling 做了优化，有较好的时效性 缺点：保持连接会消耗资源; 服务器没有返回有效数据，程序超时。

websocket

支持双向通信，实时性更强 可以发送文本，也可以发送二进制数据 减少通信量：只要建立起WebSocket连接，就希望一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应减少了

，WebSocket是类似Socket的TCP长连接的通讯模式，一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发和客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

思路

支付场景推荐使用websocket ， 前端定时发送心跳（保活），服务器获取到支付结果推送给前端

Web 实时推送技术的比较

方式类型技术实现优点缺点适用场景轮询Pollingclient→server客户端循环请求1、实现简单 2、 支持跨域1、浪费带宽和服务器资源 2、 一次请求信息大半是无用（完整http头信息） 3、有延迟 4、大部分无效请求适于小型应用长轮询Long-Pollingclient→server服务器hold住连接，一直到有数据或者超时才返回，减少重复请求次数1、实现简单 2、不会频繁发请求 3、节省流量 4、延迟低1、服务器hold住连接，会消耗资源 2、一次请求信息大半是无用WebQQ、Hi网页版、Facebook IM长连接iframeclient→server在页面里嵌入一个隐蔵iframe，将这个 iframe 的 src 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。1、数据实时送达 2、不发无用请求，一次链接，多次“推送”1、服务器增加开销 2、无法准确知道连接状态 3、IE、chrome等一直会处于loading状态Gmail聊天WebSocketserver⇌clientnew WebSocket()1、支持双向通信，实时性更强 2、可发送二进制文件3、减少通信量1、浏览器支持程度不一致 2、不支持断开重连网络游戏、银行交互和支付