暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

【交易技术前沿】行情数据专线传输的分析和调优

上交所技术服务 2021-10-29
1587

本文选自《交易技术前沿》总第四十三期文章(2021年3月)

郑凡/ 方正证券股份有限公司 

zhengfan@foundersc.com

魏胜男/ 上证所信息网络有限公司 

snwei@sse.com.cn


       证券市场参与者往往选择使用专线网络作为证券市场行情数据传输的解决方案。本文将结合专线网络和证券市场行情数据的特点,深入讨论分析此类解决方案中需要考虑的重点问题,用真实数据验证描述问题的存在性,并试图根据分析结果给出关于此类解决方案的一系列最佳实践。

一、概述

       专线网络是由网络运营商提供的、通过指定甚至专用网络设备、形成专用路由的独享网络。通常专线网络是解决长距离、大数据量传输的首选解决方案。证券市场行情数据具有一系列特殊属性。首先,其自身数据特征包括:数据总体体量大、活跃数据集中、瞬时数据密度高等;其次,其消费者在地理上的分布广泛,集中度不高,导致数据需要传输的距离长;最后,市场参与者对其一般性需求包括:数据实时性要求高、数据缺损容忍度低等。上述特殊属性使得证券市场行情数据对其数据传输载体要求非常严格近乎苛刻。
       基于以上两方面,证券市场参与者往往选择使用专线网络作为证券市场行情数据传输的解决方案。本文将结合专线网络和证券市场行情数据的特点,深入讨论分析上述解决方案中需要考虑的重点问题,并试图根据分析结果给出关于此类解决方案的一系列最佳实践。

二、问题的提出

       当遇到大数据量传输需求时,人们通常会直观认为带宽是唯一需要解决的阻碍问题。然而这并非事实。如果数据传输的源头与目的地之间的传输延时超过一定范围,此延时本身也将成为传输过程中一个不可忽视的阻碍:这就是与长肥网络(Long Fat Networks, LFNs )及其相关的一系列问题。

(一)长肥网络问题:

       众所周知,TCP连接建连握手完成后,通信中数据的发送一方自发送第一个payload数据包开始,需要等待往复通信延迟(Round-Trip Time, RTT )时长,方可得到数据接收方确认,并获知数据接收方receive window的变动状况。
       在“往复通信延迟”时间段内,数据发送方对数据接收方状态完全无感。此情形可以类比于物理学中事件视界窗口(event horizon )概念。直观可知,数据发送方需要在事件视界窗口内盲发体量如带宽时延乘积(bandwidth-delay product,BDP )的数据。
       TCP是一个保障有效连接的协议,所以其在设计和实现过程中引入了流量控制算法,目的是当数据发送端已发送但尚未收到确认信息的数据体量超过数据接收端展示的可用窗口(Rwnd)大小时,TCP协议会暂缓发送后续数据。考虑带宽时延乘积大于Rwnd的情况。在此种情况下会发生上述由流量控制算法引发的发送端到接收端发送中断,并在发送端接收到一些ACK确认后恢复发送。其传输工作状态可参见下示意图:

图1:BDP远大于Rwnd的情况

       通过示意图,我们可以看到,上述带宽时延乘积较大的网络,其“竹节型”数据传输形态类似于相位控制状态机。传输效率低下是其最大问题。其最大传输率为:

其有效网络传输带宽的上限为:

需要说明的是,在现实情况中RTT的估值往往会因为数据连接的质量波动发生很大改变;而RTT和RTO估值改变又会进一步影响诸如拥塞控制算法的执行。这引入了额外的复杂性。所以上述公式中引用的RTT是一个理论值,或者是一个理想连接状态下的较稳定值。

(二)长肥网络条件下的丢包和乱序:

       通过TCP协议进行数据传输,其数据发送端获知传输过程中产生的丢包需要一个发现周期。在较原始TCP协议中,此发现周期用时依赖重传超时时间(Retransmission TimeOut, RTO)的定义;在TCP协议改进了快速重传(Fast Retransmit, FR)后,数据接收端通过重复应答(Duplicated Acknowledge, DA)表达数据丢包;重复应答发送频率取后续数据包到达间隔和时钟周期最小粒度二者的较小值。如证券市场行情这样的高流量数据连接,其后续数据接收的间隔通常较往复通信延迟要小若干数量级。所以此发现周期用时较接近一个往复通信延迟:


接下来发送端需要解决通过重发来丢包问题。在乐观情况(丢包重发没有再次丢包)下,确定得知重发成功需要一个解决周期,时长为往复通信延迟:


TCP解决单个数据包单次丢包的过程示意图如下:

图2:单个数据包单次丢包

       TCP解决单个数据包单次丢包的时间成本为:

        参考上面图 2考虑丢包时发送端对数据传输状态的观察过程。从packet 2发送完毕到最终确定解决packet 2的丢包问题,唯一确认发送成功一个packet 2,共消耗时间成本为2RTT。换言之在此丢包发生瞬间的实际带宽为:

进一步考虑单个数据包反复丢包情况。在悲观情况(丢包重发再次丢包)下,发现再次丢包周期时长为重传超时时间:  
      
TCP解决单个数据包反复丢包过程示意图如下:

图3:单个数据包反复丢包

       考虑到针对单个数据包反复丢包的概率较低,对此过程不做进一步分析。考虑一个RTT时间段内多个数据包丢包情况。TCP协议的处理过程示意图如下:

图4:多个数据包丢包

       假设此数据连接中一个数据包丢包概率为PPacketLost,单位时间RTT内的发包总数为N;则单位时间RTT内丢包总数为:
        

可得到此数据连接关于丢包的平均恢复时间:

        可以看到上述TotalDuration窗口期的长度一方面与丢包总数量线性相关,另一方面与通信线路的RTT数值成正比关系。
       在此TotalDuration过程中,数据发送端可确认发送成功包的数量与丢包在此过程的分布有关。按照最优情况即丢包均匀发生于TotalDuration全过程来计算,则有:
        

而按照最劣情况即丢包全部发生于TotalDuration最早期来计算,则有:
        

平均情况为(考虑到概率计算,此处使用几何平均):
        

进一步可推算出,在TotalDuration窗口期内的平均实际带宽为:
        需要强调的是,此处计算得到实际带宽是TotalDuration范围内的平均值。考虑到TotalDuration与RTT的线性关系,当实际丢包数非常小的时候,此方法计算出的带宽可视为丢包时刻的瞬时带宽平均值。这带来一网络传输状态数据观测困境,即:考虑到过度频繁的观测行为对数据传输过程本身造成的性能下降,实际工程中需要将网络数据传输的观测和取样的间隔设置在一个合理范围,通常为1秒。很直观的是,当下列情况发生时上面带宽计算结果必然与真实采样数据有较大的偏差:
       1.当单位时间内的发包总数很少,数据生产非常稀疏的情况;
       2.当单位时间内的丢包总数很少的情况;

包乱序的处理过程与丢包类似,此处不做赘述。

(三)长肥网络对拥塞预测的扰动:

       如前一章节所述,此处引用的变量RTT是一个理论值,或者是一个理想连接状态下的较稳定值。在现实情况中,丢包与乱序对于数据连接的传输能力还会造成数据连接RTO和RTT估计值的陡增,进而影响拥塞窗口cwnd和ssthreth;其结果是一旦出现丢包和乱序,数据连接传输能力更大幅度的下降。

三、问题的分析

       前文从网络数据传输的理论角度入手,对长肥网络问题做了定性阐述。为了能够更精确的分析并解决问题,有必要对长肥网络问题进行定比或定量分析。其中的首要问题是:长肥网络问题的相关理论是否可以预测长距离传输证券市场行情数据可能出现的网络质量问题。如上述长肥网络理论的一系列结论不能对市场行情数据的专线传输状况做出较预测,则意味着长肥网络理论并不适用于行情数据传输过程。

(一)根据长肥网络的定义进行预测:

       期望通过给出一个理论RTT值,或者是一个理想连接状态下的较稳定RTT值,以及收集到的网络流量数据,计算给出连接质量的预测;进而通过对预测结果的验证,来证明长肥网络对行情数据传输的影响。实验方式如下:

1.收集多日的对照2组数据连接网络流量数据;
2.收集理想连接状态下的较稳定RTT值;
3.预测对照组双方的数据连接状况;
4.根据实际连接状况数据验证预测结果;
数据实验的公共设置如下:
1.深圳证券交易所行情数据;
2.上游为部署于深圳交易所证通南方机房(东莞)MDGW服务器;
3.下游为部署于湖南省长沙市证券大厦机房数据接收服务器;
4.接收端Rwnd使用TCP协议默认值65535字节计算 ;

       表1统计了2021年3月3日至2021年3月8日间深圳证券交易所当日市场成交情况和BINARY协议LEVEL2-1数据连接流量采样:

表1:20210303-20210308深圳LEVEL2-1流量采样

        如下第一组对照数据,选取通过网络运营商A40Mbits专线连接传输:

表2统计了2021年3月3日至2021年3月8日间数据发送端(证通南方机房MDGW服务器)的理想连接稳定RTT数据采样: 

表2:20210303-20210308网络运营商A专线理想RTT采样

        通过前文给出公式计算可得到对应日期的带宽时延乘积(见表3):

表3:20210303-20210308网络运营商A专线BDP

        并据此预测对应日期的最大传输率和有效网络传输带宽的上限(见表4):

表4:20210303-20210308网络运营商A专线预测连接质量

        如下第二组对照数据,选取通过网络运营商B40Mbits专线连接传输:

       表5统计了2021年3月3日至2021年3月8日间数据发送端的理想连接稳定RTT数据采样:

表5:20210303-20210308网络运营商B专线理想RTT采样

        通过前文给出公式计算可得到对应日期的带宽时延乘积(见表6):

表6:20210303-20210308网络运营商B专线BDP

        并据此预测对应日期的最大传输率和有效网络传输带宽的上限(见表7):

表7:20210303-20210308网络运营商B专线预测连接质量

        比较表 4和表 7中网络运营商A、网络运营商B数据专线的预测数据可以发现:其双方在数据传输峰值时段(通常为上午开盘时段)的有效带宽上限和最大传输状态均将会非常糟糕;随着数据流量趋缓,双方网络质量将会出现较明显的差异:网络运营商A专线网络质量在一般流量状态下将可以基本满足数据传输需求;但是网络运营商B专线的网络质量将依然差强人意,依然只能满足部分数据传输需求。
       预测网络运营商A专线和网络运营商B专线的连接状态表现:

  1. 网络运营商A专线的有效带宽上限应约为2.188MBps-2.275MBps(17.5Mbps-18.2Mbps)  

  2. 网络运营商B专线的有效带宽上限应约为1.60MBps-1.61MBps(12.8Mbps-12.9Mbps)      

  3. 早盘阶段,网络运营商A和网络运营商B专线在早盘数据峰值阶段将会出现若干次拥塞,从而引发深圳交易所行情数据网关的连接关闭; 

  4. 早盘数据峰值过后,网络运营商A专线相对稳定,出现拥塞甚至断连可能性低; 

  5.   早盘数据峰值过后,网络运营商B专线不稳定,出现拥塞甚至断连可能性高; 

       预测检验:

       以深圳证券交易所2021年3月9日行情数据传输为例。通过收集得到如下连接数据(见图5):

图5:深交所20210309 行情数据流量

       在图5中,蓝色曲线为网络运营商A专线数据流量统计,绿色曲线为网络运营商B专线数据流量统计;紫色曲线为对照数据发送流量;从图5可以看到;

  1.  网络运营商A专线的有效带宽上限接近2.2MBps;网络运营商B专线有效带宽上限接近1.7MBps;  

  2.  深圳证券交易所2021年3月9日行情数据峰值出现在09:30-10:02之间; 

  3. 从网络运营商A专线对应MDGW日志中可以发现,网络运营商A专线传输共出现过21次因为传输质量抖动导致断连的记录,均发生在09:30:-10:00之间; 

  4. 从网络运营商B专线对应MDGW日志中可以发现,网络运营商B专线传输共出现过42次因为传输质量抖动导致断连的记录,其中31次发生于09:30-10:00之间,10次发生于10:00-10:10之间,1次发生于13:10分。 

       可以看到:上述深交所20210309行情数据传输状况较为精确地符合了预测;证明了长肥网络问题对证券市场行情数据远距离传输存在明确影响。

(二) 长肥网络丢包的影响

       参考2021年3月9日网络运营商B专线的数据传输日志中丢包相关记录如下表:

表 8:观测带宽与根据丢包计算的预测带宽

        预测带宽使用MaxSegmentSize=635 ,以及理想RTT均值进行计算。上述观测带宽基本符合预测带宽。由此证明了长肥网络丢包对行情数据传输的实际影响。

(三) 长肥网络对拥塞预测的扰动

       进一步观察RTT观测值的分布。如下两张图分别是网络运营商A专线和网络运营商B专线数据连接2021年3月3日RTT观测值的分布图:

图6:网络运营商A专线RTT观测值分布图

图7:网络运营商B专线RTT观测值分布图

       可以看到从分布的形态来看,网络运营商B专线和网络运营商A专线RTT采样值的区别在于:

  1.  网络运营商B专线RTT主要分布区间位于35.5-35.7ms之间;网络运营商A专线RTT主要分布区间位于27.3-28.0ms之间;意味着网络运营商A专线的最优传输能力好于网络运营商B专线; 

  2. 似乎网络运营商A专线RTT分布形态更接近于泊松分布;从网络运营商B专线RTT中心分布的数据来看更陡峭,似乎标准差应该更小;但是事实上其分布的尾部更长;其尾部中后段还有一段出现了比较明显的反弹;可能是传输过程中某些尚不明确干扰因素造成的扰动。 

       结合上述专线的丢包情况:

  1.  网络运营商A专线全日丢包记录2次,共丢包18个;其网络传输质量波动可以被归因于阻塞退避算法cwnd和ssthresth对RTT数据波动的响应;基本处于良性波动范围之内;  

  2. 网络运营商B专线全日丢包记录775次,共丢包125723个;其网络传输质量波动部分源于RTT波动,部分源于丢包对拥塞算法的重置(重新进入慢启动 过程);其网络质量波动已经接近不良范围; 

四、问题的解决

       事实上长肥网络问题作为一个存在已久的数据传输问题,工业界已经为之提供了很多成熟的解决方案,其中不乏针对数据传输协议的改造和优化。而另一方面,金融证券行情数据传输又具有一些比较特殊的行业特征。这些行业特征导致上述通用解决方案在应用于证券市场行情传输场景时需要进行一定取舍和改造。这一节将从运维手段、研发设计和架构策略三个方面归纳、列举和评价这些方案。

(一) 运维调优手段 :

1、TCP窗口调优

  • 数据接收端开启接收窗口扩展net.ipv4.tcp_window_scaling ; 

  • 数据发送端增大数据发送缓存大小,包括:

  • net.core.wmem_max; 

  • net.core.wmem_default; 

  • net.ipv4.tcp_wmem; 

  • 数据接收端增大数据接受缓存大小,包括: 

  • net.core.rmem_max;

  • net.core.wmem_default; 

  • net.ipv4.tcp_wmem; 

  • 内存压力策略配置net.ipv4.tcp_mem; 

       TCP窗口调优是业界公认解决长肥网络问题最基本方法。其从根本上避免了长肥网络带来的“竹节型”、“相位式”传输问题。但需要说明的是,如何实现TCP窗口调优存在争议。因为上述运维层面调优手段需要更改Linux操作系统的协议栈缓存配置,其结果是在此操作系统中所有已建立的连接都会分配缓存大小内存。如果此操作系统上部署了没有对连接数量限制的服务端应用,此服务器的内存资源会被迅速耗尽。

       但是考虑到通常行情数据接入服务器的高性能和专用性,这样的系统设置是可以接受的。同时考虑到很多行情数据接入方使用外购第三方产品工具接入行情数据;这些三方产品工具未必提供针对上述网络调优的配置能力。综合上述因素,推荐基于系统运维配置手段进行TCP窗口调优。

  通常针对长肥网络的调优,建议将其缓存大小设置为BDP大小。其并未考虑丢包率对带宽的影响。考虑到行情数据网关MDGW对数据传输压力的敏感性,调优应该考虑丢包问题。具体值设置的原则应如下:

1.接收端接收缓存应最大可容纳其所连接专线峰值丢包率带来的延迟时长中所生产的所有数据,计算公式如下:

2.接收端接收缓存应不小于发送端的发送缓存大小;
      3.缓存设置并非越大越好。考虑到资源开销和缓存带来的延迟问题,缓存大小设置应存在上限;
       通常针对长肥网络的调优,会同时建议增加net.ipv4.tcp_mem。此配置项用来约定系统内存使用压力状况的边界值;操作系统处在不同压力状况下,会使用不同的TCP协议栈内存策略,比如不同的丢包策略和窗口大小等。考虑到交易市场行情数据接入所使用的一般都是高配置高性能的专用服务器,对net.ipv4.tcp_mem可以更大一些。需要注意的是,net.ipv4.tcp_mem的单位是内存页(通常为4K字节)而非字节。

       下表列出目前收集到的部分国内主要城市间不同运营商专线RTT数据可供参考:

表9:主要城市间主要运营商专线RTT采样

以网络运营商B专线为例,经计算其调优配置如下:

       长沙证券大厦机房行情数据接收服务器:
       net.core.rmem_max=134217728
       net.core.rmem_default=33554432
       net.ipv4.tcp_rmem=“4096 33554432 134217728”
       net.ipv4.tcp_mem=“524288 1048576 2097152”
       net.ipv4.tcp_window_scaling=1

       深圳交易所东莞机房MDGW服务器:
       net.core.wmem_max=134217728
       net.core.wmem_default=33554432
       net.ipv4.tcp_wmem=“98304 33554432 134217728”
       net.ipv4.tcp_mem=“524288 1048576 2097152”

2、启用TCP协议栈确认响应优化

  • 启用快速重传fack   

  • 启用选择性确认sack   

  • 启用重复选择性确认dsack   

       fack、sack和dsack是三个关于数据接收确认的优化。其中fack是快速重传的开关;sack可以有效避免单位时间内多个丢包造成的延迟膨胀问题;dsack在sack的基础上尝试兼容乱序;作为需要通过TCP报文内容表达的数据,此类优化选项需要在数据发送端和接收端同时开启才能生效。

       值得一提的是:2019年6月份曾经爆出一个redhat操作系统与sack相关的远程安全漏洞“sack恐慌” 。客户端可以利用特定编制的sack数据段使得tcp协议栈陷入逻辑死锁,最因资源耗尽导致服务拒绝(DoS);当时安全业界提出最简单方便的解决方案是禁用sack。然而对于长肥网络的丢包问题来说,开启sack是不可或缺的调优手段。考虑到行情传输服务器的专用性和高安全等级(限制访问ip白名单,限制端口访问等),上述sack panic不会对行情服务造成安全隐患;上述安全漏洞补丁已经提供下载。
       调优配置如下:
       net.ipv4.tcp_fack=1
       net.ipv4.tcp_sack=1
       net.ipv4.tcp_dsack=1

3、 启用TCP协议栈时间戳

  • 启用TCP报文时间戳timestamps   

       开启timestamps的一个重要目的是提供更为精确的RTT。从前文可以看出,长肥网络的所有问题都和RTT有关。更为精确的RTT可以避免拥塞算法对网络传输质量过度悲观或者过度乐观,更高效的利用网络传输能力。
       调优配置如下:
       net.ipv4.tcp_timestamps=1

4、 启用TCP协议栈拥塞退避BBR算法

Bottleneck Bandwidth and roud-trip time congestion control algorithm,BBRxiii-是google公司于2016年提出的新一代拥塞退避算法。其与之前退避算法最大的不同是它弱化丢包影响而更为关注传输延迟。数据表明BBR对于长肥网络问题有比较明显的改善能力。BBR一个潜在的问题是,有研究表明其对与之共享专线的其他使用了非BBR退避算法连接(比如CUBIC)不公平,有比较明显的侵占和剥夺 。

       调优步骤如下:
       升级Linux Kernel到4.9.1及之后版本;
       net.core.default_qdisc=fq
       net.ipv4.tcp_congestion_control=bbr

(二)开发调优设计:

  1. 禁用TCP协议栈Nagle 算法和禁用delayed ack    

       Nagle算法是数据发送端通过降低小数据包发送频率,将一段时间积累的数据包集中发送,来达到减少发送数据包发送数量、增加TCP协议传输性能的算法。类似的,延迟确认delayed ack则是在数据接收端合并数据确认,以达到降低数据发送数量、增加传输性能的配置。上述算法和设置有可能会进一步恶化长肥网络的严重程度;同时也由于市场行情数据传输的实时性要求更高,所以在行情传输的场景中,此类延迟设置应被禁用。

       TCP_QUICKACK=true
       TCP_NODELAY=true

       另外所有关于TCP窗口调优的手段,都可以用于开发调优。

(三)架构调优策略:

1.根据数据带宽和RTT采样决策网络架构和参数配置

       从本文描述的各种情况可以看到网络连接问题的复杂性,以及对应解决方案的多样性。即使同属于长肥网络问题,不同发送端所在地、不同接收端所在地、不同流量需求、不同运营商专线服务的不同数据连接,也很难给出统一的万能配置方案。还需要根据当前面所对状况给出定制化设计。这就需要决策者认真收集并分析当前网络状况的各个方面数据。在各种纷繁复杂的数据中,建议重点关注的是数据占用带宽情况和专线RTT采样。掌握了这些数据,结合本文给出的一些分析方法应可以给出所面对问题的正确有效且廉价的解决方案。

2.带宽申请应充分考虑瞬时流量冲击

       深圳交易所建议的LEVEL2-1行情数据流量线路带宽是13Mbps 。前文表1中观测数据证明,这应该是可用的下限值;可以预测的是:

  1. 此带宽不能支撑开盘阶段的瞬时流量冲击; 

  2. 此带宽难以支撑对于交易活跃(如交易金额破万亿)的单日全天流量; 

       同样根据前文表1的观测数据,30Mbps的带宽可以在较大概率上处理瞬时流量冲击问题。

       同理也可按照上述方法对深圳交易所LEVEL2-2行情接入做出带宽预测。

3.协调多路共用专线

       前文介绍运维调优手段部分推荐了使用拥塞退避算法BBR。其存在潜在问题是:对于同线路传输的、未使用BBR算法的其他数据连接存在“侵占和剥夺”。这使得决策者在考虑使用BBR的时候,需要考虑进行如下协调工作:

  1. 是否存在同线路传输的其他数据链路; 

  2.  是否会对同线路传输的其他数据链路造成冲击; 

  3.  是否可以都升级使用BBR; 

       同时,如果是同质化同周期的数据(即同一数据的不同副本。对于证券市场行情,存在展示和非展示两种行情数据授权。其内容是同质化、同流量周期数据)共享一条专线,如两路行情数据传输,还需要充分考虑瞬时流量冲击的叠加效应。

五、问题的拓展

       上述章节介绍了行情数据和专线传输这一课题中,有较为明确判断和结论的部分。除此之外,还存在一些结论尚不明确但值得深入研究讨论的问题。将这些问题记录于本文最后,供思考和讨论。

(一)跨运营商多路动态负载均衡的适用性

       当使用多个运营商提供的专线进行网络数据传输时,通常会考虑进行跨运营商专线间的多线路动态负载均衡。毫无疑问,这样的设计对于去除应用层和HA层面的设计复杂性、支撑短时线路闪断以及提高线路利用效率等方面极具价值。

       然而从前文可以看到,即使针对相同地理空间上传输,不同运营商提供的专线服务性能也不尽相同,甚至差别巨大。所以根据动态负载均衡要求分流的数据很难保证在接收端的接收顺序。而丢包和收包乱序是长肥网络中最因避免的情况。

       所以跨运营商专线间的多线路动态负载均衡是否适合应用于证券市场行情数据传输值得商榷。在还未形成一套具备预测能力的、可量化的适用性评价标准之前,建议在处理行情数据长距离传输场景下避免使用跨运营商多路动态负载均衡。

(二)行情数据远距离传输的上限问题

       从上文可知,数据传输带宽和距离共同影响甚至决定了数据传输的效率。这意味着,当前网络传输和协议设计不能满足传输带宽和传输距离的无限增长。对于超过阈值带宽和距离的数据,不应考虑进行网络传输。

       此阈值相关因素可能包含数据瞬时流量、总体流量、传输距离、设备延迟、数据发送端对积压的容忍程度,数据接收端对延迟的容忍程度等等。

       找到此阈值和上限是很有价值的,将对形成正确决策具有很大的指导意义。


 
  免责声明    

本公众号内容仅供参考。对任何因直接或间接使用本公众号内容而造成的损失,包括但不限于因有关内容不准确、不完整而导致的损失,本公众号不承担任何法律责任。如有问题请反馈至tech_support@sse.com.cn。



--------------------------
上海证券交易所为证券公司、基金管理公司等市场参与者及相关行业机构提供交易技术支持与服务,包括日常交易技术支持、技术交流研讨、市场调查反馈、证券信息技术知识库、测试等服务。

文章转载自上交所技术服务,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论