一种基于STG服务器的T-Box传输方法及装置

技术领域

本申请涉及智能网联信息安全技术领域，具体涉及一种基于STG服务器的T-Box传输方法及装置。

背景技术

现阶段，在智能网联信息安全领域，尚未存在较为安全的信息传输技术方案，尤其是在公网传输架构中，若在于身份伪造、数据篡改和窃听等攻击，则极易造成信息泄露、数据错误等信息安全问题。

因此，基于信息传输的安全需求，现提供一种基于STG服务器的T-Box传输技术，以满足通信需求。

发明内容

本申请提供一种基于STG服务器的T-Box传输方法及装置，在服务端的防火墙与TSP集群之间配置一STG集群，将密文数据以及明文数据进行对应性转发，从而提高数据传输的安全稳定性。

为实现上述目的，本申请提供以下方案。

第一方面，本申请提供了一种基于STG服务器的T-Box传输方法，所述方法包括以下步骤：

在服务端的防火墙与TSP集群之间创建STG集群；

所述防火墙将终端发送的密文数据转发至所述STG集群；

所述STG集群对所述密文数据进行解密，并获得明文数据并转发至TSP集群中对应的TSP服务器。

进一步的，所述防火墙将终端发送的密文数据转发至所述STG集群中，包括以下步骤：

所述防火墙接收所述终端发送的所述密文数据，经过负载均衡处理后，将所述密文数据转发至所述STG集群中对应的STG服务器。

进一步的，所述获得明文数据并转发至TSP集群中对应的TSP服务器中，包括以下步骤：

所述STG集群获得所述明文数据后，经过负载均衡处理，将所述明文数据转发至对应的所述TSP服务器。

进一步的，所述方法还包括以下步骤；

所述服务端与所述终端进行双向身份验证；

待通过双向身份验证后，允许所述服务端接收所述终端发送的所述密文数据。

进一步的，所述方法还包括以下步骤：

在所述服务端与所述终端之间配置加密数据通道；其中，

所述密文数据基于所述加密数据通道在所述终端与所述服务端之间传输。

第二方面，本申请提供了一种基于STG服务器的T-Box传输装置，所述装置包括：

STG创建模块，其用于在服务端的防火墙与TSP集群之间创建STG集群；

密文转发模块，其用于基于所述防火墙将终端发送的密文数据转发至所述STG集群；

解密传输模块，其用于基于所述STG集群对所述密文数据进行解密，并获得明文数据并转发至TSP集群中对应的TSP服务器。

进一步的，所述密文转发模块还用于基于所述防火墙接收所述终端发送的所述密文数据，经过负载均衡处理后，将所述密文数据转发至所述STG集群中对应的STG服务器。

进一步的，所述解密传输模块还用于所述STG集群获得所述明文数据后，经过负载均衡处理，将所述明文数据转发至对应的所述TSP服务器。

进一步的，所述装置还包括：

身份验证模块，其用于对所述服务端与所述终端进行双向身份验证；

所述身份验证模块用于待通过双向身份验证后，允许所述服务端接收所述终端发送的所述密文数据。

进一步的，所述装置还包括：

通道增设模块，其用于在所述服务端与所述终端之间配置加密数据通道；其中，

所述密文数据基于所述加密数据通道在所述终端与所述服务端之间传输。

本申请提供的技术方案带来的有益效果包括：

本申请在服务端的防火墙与TSP集群之间配置一STG集群，将密文数据以及明文数据进行对应性转发，从而提高数据传输的安全稳定性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中提供的基于STG服务器的T-Box传输方法的步骤流程图；

图2为本申请实施例中提供的基于STG服务器的T-Box传输方法的系统结构框图；

图3为本申请实施例中提供的基于STG服务器的T-Box传输方法的网络部署示意图；

图4为本申请实施例中提供的基于STG服务器的T-Box传输方法中STG-Server系统的整体结构示意图；

图5为本申请实施例中提供的基于STG服务器的T-Box传输装置的结构框图。

具体实施方式

术语解释：

STG：Secure Transmission Gateway，安全传输网关；

TSP：Telematics Service Provider，汽车远程服务提供商；

VIP，Virtual IP Address，虚拟IP地址；

DIP，Data Integration Point，数据融合点；

LVS：Linux Virtual Server，Linux虚拟服务器；

TLS：Transport Layer Security，安全传输层协议；

RA：Routing Area，路由区；

CA：Certificattion Authority，数字证书认证中心；

MAC：即MAC地址，Media Access Control Address，物理地址或硬件地址。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图对本申请的实施例作进一步详细说明。

本申请实施例提供一种基于STG服务器的T-Box传输方法及装置，在服务端的防火墙与TSP集群之间配置一STG集群，将密文数据以及明文数据进行对应性转发，从而提高数据传输的安全稳定性。

为达到上述技术效果，本申请的总体思路如下：

一种基于STG服务器的T-Box传输方法，该方法包括以下步骤：

S1、在服务端的防火墙与TSP集群之间创建STG集群；

S2、防火墙将终端发送的密文数据转发至STG集群；

S3、STG集群对密文数据进行解密，并获得明文数据并转发至TSP集群中对应的TSP服务器。

以下结合附图对本申请的实施例作进一步详细说明。

第一方面，本申请实施例提供一种基于STG服务器的T-Box传输方法，该方法包括以下步骤：

S1、在服务端的防火墙与TSP集群之间创建STG集群；

S2、防火墙将终端发送的密文数据转发至STG集群；

S3、STG集群对密文数据进行解密，并获得明文数据并转发至TSP集群中对应的TSP服务器。

本申请实施例，在公网传输架构中存在身份伪造、数据篡改和窃听等攻击，根据以上业务需求，引入安全传输方案。

本申请实施例的技术方案在架构上为C/S架构，分为安全传输网关STG和终端STG-Client两部分，在原车载终端上部署STG-Client，负责传输数据的加密转发；

在原服务端的基础上，增加部署安全传输网关STG，负责接收加密数据，并将数据解密后转发到原后台服务器；

在安全性能上：使用安全性能突出的TLSv1.2安全传输协议。采用双向认证，STG-Client与STG相互认证；

综上，本申请实施例的技术方案，在服务端的防火墙与TSP集群之间配置一STG集群，将密文数据以及明文数据进行对应性转发，从而提高数据传输的安全稳定性。

如说明书附图的图2所示，其为基于STG服务器的T-Box传输方法的系统结构框图，基于该结构框图，本申请的技术方案至少包括以下技术关键点：

1)在服务端，需要将STG部署在防火墙负载均衡之后，后台TSP集群之前。

2)终端上报的密文应先经过防火墙负载均衡发送给STG；其中，

负载均衡的具体原理为：服务器负载均衡技术将多个服务器组成服务器集群，对外体现为一台逻辑上的服务器，并保证了流量可以比较平均的分配到各个服务器上，避免出现一个服务器满负荷运行而另一个服务器却空闲的情况。

3)每台STG中也有负载均衡配置，将防火墙发来的密文数据解密为明文后，STG与后台TSP建立连接，将数据转发给原后台TSP服务器进行业务数据处理，其中；

加密解密流程中，在建立连接的过程中协商通信过程使用的加解密密钥，用于数据加密和完整性校验，从而确保传输安全。

4)输入：车载终端上报的密文。

5)输出：车载终端上报的明文；

安全传输网关STG承载来自终端的加密数据流，要求STG对终端提供安全传输服务和其他服务。

另外，本申请实施例的技术方案中，还包括安全传输服务，所述安全传输服务包括：

1)身份认证：身份认证为双向认证，伪造的终端身份不能通过系统认证。

2)建立安全传输通道：安全传输通道由车载终端发起，STG响应并建立安全连接，对连接内的业务数据提供数据的机密性，完整性和不可否认性支持。

3)数字证书管理：提供数字证书签发和周期更新机制。

4)数字证书和密钥安全存储。

5)提供安全随机数服务，随机数不可预测。

6)传输协议支持TLS1.2。

另外，本申请实施例的技术方案中，还包括其他服务，诸如：STG对后端服务器提供负载均衡服务。

进一步的，所述防火墙将终端发送的密文数据转发至所述STG集群中，包括以下步骤：

所述防火墙接收所述终端发送的所述密文数据，经过负载均衡处理后，将所述密文数据转发至所述STG集群中对应的STG服务器。

进一步的，所述获得明文数据并转发至TSP集群中对应的TSP服务器中，包括以下步骤：

所述STG集群获得所述明文数据后，经过负载均衡处理，将所述明文数据转发至对应的所述TSP服务器。

进一步的，所述方法还包括以下步骤；

所述服务端与所述终端进行双向身份验证；

待通过双向身份验证后，允许所述服务端接收所述终端发送的所述密文数据。

进一步的，所述方法还包括以下步骤：

在所述服务端与所述终端之间配置加密数据通道；其中，

所述密文数据基于所述加密数据通道在所述终端与所述服务端之间传输。

如说明书附图的图3所示，其为本申请实施例的技术方案对应的网络部署示意图，示意图的左半部分为TSP原有网络拓扑，示意图的右半部分为新增的加密数据链路，具体的该网络部署包括以下技术细节：

1)原有网络拓扑保持不变，新增加密数据通道，非加密数据按照原有链路上报，加密数据使用新的加密链路，经过STG解密后发送给原TSP网关。

2)STG服务器前端需要负载均衡策略。在无F5硬件负载设备的前提下，需要搭建目前TSP使用的LVS负载均衡服务器，LVS采用DR模式，负载调度策略为最小连接，即LeastConnections；

最小连接算法：将客户端的业务流量分配到并发连接数最小，即负载最小的服务器上，解决了轮询算法没有考虑到每个服务器上实际负载量的问题，适用于服务器性能相近，每条流对服务器造成的业务负载大致相等，但是每条流的会话存活时间不同，例如Http服务器。

其中，在lvs+keepalived环境里面，lvs主要的工作是提供调度算法，把客户端请求按照需求调度在real服务器，keepalived主要的工作是提供lvs控制器的一个冗余，并且对real服务器做健康检查，检查其是否还能提供服务，发现不健康的real服务器，就把它从lvs集群中剔除，real服务器只负责提供服务；

具体操作是存活信号通常以一定的时间间隔发出,若一端在信号发出后未收到回复，则可判定数据链路离线并将之后的数据包重新路由到其他链路，直到旧链路重新上线为止。存活信号也可表示保留连接状态。若无存活信号，启用网络地址转换的路由器将于超时后中断连接。

3)STG做反向代理，按TSP团队要求，STG对网关负载使用ip_hash模式；

在ip_hash模式下，旨在保障用户访问能够请求到上游服务中的固定的服务器，当然，前提是用户ip没有发生更改。

4)STG使用RIP(真实IP)与网关RIP建立socket连接。需要网关监听RIP指定端口的连接，并将反馈数据发送到STG。

5)加密链路中，位于STG服务器后方的服务器无法获取车辆真实IP，仅可见STG的RIP。

另外，考虑防单点故障及双机热备，STG集群需至少部署两台STG，其中一台发生故障后，确保终端重新建立的连接，能连接到正常工作的STG设备上。

根据项目实际情况，STG可以部署在云端环境，也可以部署在数据中心的物理机中。当部署在数据中心时，独立服务器或虚拟机均可，只需要保证网络拓扑中，STG位于后台服务器的前端即可。

需要说明的是，STG-Server系统分为两个部分：传输模块以及证书服务模块，即Transport Module和Cert Service Module。

说明书附图的图4为STG集群，即STG-Server系统的整体结构示意图；其中，

传输模块：以Nginx-TLS引擎模块和数据转发模块(Stream)为核心模块，在其它模块(包括配置管理模块、OS系统资源模块等)配合下，对外提供TLS传输代理服务(TLS proxyservice)；

TLS传输代理服务是STG-Server系统对外提供的服务，处理STG-Client端的TLS连接请求以及数据的加解密转发，实现安全传输服务端功能。

证书服务模块：以Nginx模块为核心，依赖TLS安全协议及安全算法，实现数字证书的签发和更新机制。其中包括RA模块(负责用户身份信息管理及TLS密钥的管理)和CA模块(负责证书的签发和更新)，对外提供证书服务(Cert service)；

证书服务属于STG-Server系统对外提供的服务，用于接收处理STG-Client端的证书请求，签发证书并发送回STG-Client端。

STG-Server系统依赖于TLS协议模块，TLS模块包含安全协议库、安全算法库。

STG-Server系统还需要依赖于数据库，处理证书的签发和更新服务，本申请实施例中数据库使用的是MariaDB数据库管理系统。

另外，如说明书附图的图4所示，其为DR模式的示意图。

重点将请求报文的目标MAC地址设定为挑选出的RS的MAC地址，当RS接收到这个数据包之后，将源MAC替换成自己的MAC，目标MAC地址为客户端地址。

(1)当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链；

此时报文的源IP为CIP，目标IP为VIP，MAC地址一次为各自的MAC地址。

(2)PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。

(3)IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址。

(4)由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。

(5)RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。此时的源IP地址为VIP，目标IP为CIP，并且将源MAC地址改为自己的MAC，目标MAC改为客户端MAC。

(6)响应报文最终送达至客户端。

需要说明的是，本申请技术方案的网络拓扑，具体情况如下：

根据项目实际情况，STG应与后台TSP部署在同一个网络环境内，可以部署在云端环境，也可以部署在数据中心的物理机中；

当部署在数据中心时，独立服务器或虚拟机均可，只需要保证网络拓扑中，STG位于防火墙之后、后台TSP服务器之前。

需要说明的是，本申请技术方案的工作环境及STG数量的对应情况如下：

需与TSP环境对应，区分生产环境及测试环境共计4台STG；

考虑防单点故障双机热备，正式环境需至少部署2台STG，测试环境申请2台STG；

若TSP还有其他环境需求，需提出并确认是否添加额外的STG环境。

另外，本申请技术方案对原环境影响的具体情况如下：

在明密文车辆同时存在的情况下：

第一点，防火墙端：

(1)需要新开放端口，用于终端上报密文数据；

(2)做负载均衡策略，将密文端口的数据连接分发给两台STG。

第二点，TSP端：

提供全部IP及端口，接收从STG发来的明文业务数据。

综上，本申请实施例的技术方案存在以下技术优势：

原有网络拓扑保持不变，新增加密数据通道，非加密数据按照原有链路上报，加密数据使用新的加密链路，可允许明密文车辆同时存在；

原链路和新链路分开传输，便于故障排查。

第二方面，基于与方法实施例相同的发明构思，本申请实施例提供一种基于STG服务器的T-Box传输装置，该装置包括：

STG创建模块，其用于在服务端的防火墙与TSP集群之间创建STG集群；

密文转发模块，其用于基于所述防火墙将终端发送的密文数据转发至所述STG集群；

解密传输模块，其用于基于所述STG集群对所述密文数据进行解密，并获得明文数据并转发至TSP集群中对应的TSP服务器。

本申请实施例，在公网传输架构中存在身份伪造、数据篡改和窃听等攻击，根据以上业务需求，引入安全传输方案。

本申请实施例的技术方案在架构上为C/S架构，分为安全传输网关STG和终端STG-Client两部分，在原车载终端上部署STG-Client，负责传输数据的加密转发；

在原服务端的基础上，增加部署安全传输网关STG，负责接收加密数据，并将数据解密后转发到原后台服务器；

在安全性能上：使用安全性能突出的TLSv1.2安全传输协议。采用双向认证，STG-Client与STG相互认证；

综上，本申请实施例的技术方案，在服务端的防火墙与TSP集群之间配置一STG集群，将密文数据以及明文数据进行对应性转发，从而提高数据传输的安全稳定性。

本申请的技术方案至少包括以下技术关键点：

1)在服务端，需要将STG部署在防火墙负载均衡之后，后台TSP集群之前。

2)终端上报的密文应先经过防火墙负载均衡发送给STG；其中，

负载均衡的具体原理为：服务器负载均衡技术将多个服务器组成服务器集群，对外体现为一台逻辑上的服务器，并保证了流量可以比较平均的分配到各个服务器上，避免出现一个服务器满负荷运行而另一个服务器却空闲的情况。

3)每台STG中也有负载均衡配置，将防火墙发来的密文数据解密为明文后，STG与后台TSP建立连接，将数据转发给原后台TSP服务器进行业务数据处理，其中；

加密解密流程中，在建立连接的过程中协商通信过程使用的加解密密钥，用于数据加密和完整性校验，从而确保传输安全。

4)输入：车载终端上报的密文。

5)输出：车载终端上报的明文；

安全传输网关STG承载来自终端的加密数据流，要求STG对终端提供安全传输服务和其他服务。

另外，本申请实施例的技术方案中，还包括安全传输服务，所述安全传输服务包括：

1)身份认证：身份认证为双向认证，伪造的终端身份不能通过系统认证。

2)建立安全传输通道：安全传输通道由车载终端发起，STG响应并建立安全连接，对连接内的业务数据提供数据的机密性，完整性和不可否认性支持。

3)数字证书管理：提供数字证书签发和周期更新机制。

4)数字证书和密钥安全存储。

5)提供安全随机数服务，随机数不可预测。

6)传输协议支持TLS1.2。

另外，本申请实施例的技术方案中，还包括其他服务，诸如：STG对后端服务器提供负载均衡服务。

进一步的，所述密文转发模块还用于基于所述防火墙接收所述终端发送的所述密文数据，经过负载均衡处理后，将所述密文数据转发至所述STG集群中对应的STG服务器。

进一步的，所述解密传输模块还用于所述STG集群获得所述明文数据后，经过负载均衡处理，将所述明文数据转发至对应的所述TSP服务器。

进一步的，该基于STG服务器的T-Box传输装置还包括：

身份验证模块，其用于对所述服务端与所述终端进行双向身份验证；

所述身份验证模块用于待通过双向身份验证后，允许所述服务端接收所述终端发送的所述密文数据。

进一步的，该基于STG服务器的T-Box传输装置还包括：

通道增设模块，其用于在所述服务端与所述终端之间配置加密数据通道；其中，

所述密文数据基于所述加密数据通道在所述终端与所述服务端之间传输。

如说明书附图的图3所示，其为本申请实施例的技术方案对应的网络部署示意图，示意图的左半部分为TSP原有网络拓扑，示意图的右半部分为新增的加密数据链路，具体的该网络部署包括以下技术细节：

1)原有网络拓扑保持不变，新增加密数据通道，非加密数据按照原有链路上报，加密数据使用新的加密链路，经过STG解密后发送给原TSP网关。

2)STG服务器前端需要负载均衡策略。在无F5硬件负载设备的前提下，需要搭建目前TSP使用的LVS负载均衡服务器，LVS采用DR模式，负载调度策略为最小连接，即LeastConnections；

最小连接算法：将客户端的业务流量分配到并发连接数最小，即负载最小的服务器上，解决了轮询算法没有考虑到每个服务器上实际负载量的问题，适用于服务器性能相近，每条流对服务器造成的业务负载大致相等，但是每条流的会话存活时间不同，例如Http服务器。

其中，在lvs+keepalived环境里面，lvs主要的工作是提供调度算法，把客户端请求按照需求调度在real服务器，keepalived主要的工作是提供lvs控制器的一个冗余，并且对real服务器做健康检查，检查其是否还能提供服务，发现不健康的real服务器，就把它从lvs集群中剔除，real服务器只负责提供服务；

具体操作是存活信号通常以一定的时间间隔发出,若一端在信号发出后未收到回复，则可判定数据链路离线并将之后的数据包重新路由到其他链路，直到旧链路重新上线为止。存活信号也可表示保留连接状态。若无存活信号，启用网络地址转换的路由器将于超时后中断连接。

3)STG做反向代理，按TSP团队要求，STG对网关负载使用ip_hash模式；

在ip_hash模式下，旨在保障用户访问能够请求到上游服务中的固定的服务器，当然，前提是用户ip没有发生更改。

4)STG使用RIP(真实IP)与网关RIP建立socket连接。需要网关监听RIP指定端口的连接，并将反馈数据发送到STG。

5)加密链路中，位于STG服务器后方的服务器无法获取车辆真实IP，仅可见STGRIP。

另外，考虑防单点故障及双机热备，STG集群需至少部署两台STG，其中一台发生故障后，确保终端重新建立的连接，能连接到正常工作的STG设备上。

根据项目实际情况，STG可以部署在云端环境，也可以部署在数据中心的物理机中。当部署在数据中心时，独立服务器或虚拟机均可，只需要保证网络拓扑中，STG位于后台服务器的前端即可。

需要说明的是，STG-Server系统分为两个部分：传输模块以及证书服务模块，即Transport Module和Cert Service Module。

说明书附图的图4为STG集群，即STG-Server系统的整体结构示意图；其中，

传输模块：以Nginx-TLS引擎模块和数据转发模块(Stream)为核心模块，在其它模块(包括配置管理模块、OS系统资源模块等)配合下，对外提供TLS传输代理服务(TLS proxyservice)；

TLS传输代理服务是STG-Server系统对外提供的服务，处理STG-Client端的TLS连接请求以及数据的加解密转发，实现安全传输服务端功能。

证书服务模块：以Nginx模块为核心，依赖TLS安全协议及安全算法，实现数字证书的签发和更新机制。其中包括RA模块(负责用户身份信息管理及TLS密钥的管理)和CA模块(负责证书的签发和更新)，对外提供证书服务(Cert service)；

证书服务属于STG-Server系统对外提供的服务，用于接收处理STG-Client端的证书请求，签发证书并发送回STG-Client端。

STG-Server系统依赖于TLS协议模块。TLS模块包含安全协议库、安全算法库。

STG-Server系统还需要依赖于数据库，处理证书的签发和更新服务，本申请实施例中数据库使用的是MariaDB数据库管理系统。

另外，如说明书附图的图4所示，其为DR模式的示意图。

重点将请求报文的目标MAC地址设定为挑选出的RS的MAC地址，当RS接收到这个数据包之后，将源MAC替换成自己的MAC，目标MAC地址为客户端地址。

(1)当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链；

此时报文的源IP为CIP，目标IP为VIP，MAC地址一次为各自的MAC地址。

(2)PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。

(3)IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址。

(4)由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。

(5)RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。此时的源IP地址为VIP，目标IP为CIP，并且将源MAC地址改为自己的MAC，目标MAC改为客户端MAC。

(6)响应报文最终送达至客户端。

需要说明的是，本申请技术方案的网络拓扑，具体情况如下：

根据项目实际情况，STG应与后台TSP部署在同一个网络环境内，可以部署在云端环境，也可以部署在数据中心的物理机中；

当部署在数据中心时，独立服务器或虚拟机均可，只需要保证网络拓扑中，STG位于防火墙之后、后台TSP服务器之前。

需要说明的是，本申请技术方案的工作环境及STG数量的对应情况如下：

需与TSP环境对应，区分生产环境及测试环境共计4台STG；

考虑防单点故障双机热备，正式环境需至少部署2台STG，测试环境申请2台STG；

若TSP还有其他环境需求，需提出并确认是否添加额外的STG环境。

另外，本申请技术方案对原环境影响的具体情况如下：

在明密文车辆同时存在的情况下：

第一点，防火墙端：

(1)需要新开放端口，用于终端上报密文数据；

(2)做负载均衡策略，将密文端口的数据连接分发给两台STG。

第二点，TSP端：

提供全部IP及端口，接收从STG发来的明文业务数据。

综上，本申请实施例的技术方案存在以下技术优势：

原有网络拓扑保持不变，新增加密数据通道，非加密数据按照原有链路上报，加密数据使用新的加密链路，可允许明密文车辆同时存在；

原链路和新链路分开传输，便于故障排查。

需要说明的是，本申请实施例提供的基于STG服务器的T-Box传输装置，其对应的技术问题、技术手段以及技术效果，从原理层面与基于STG服务器的T-Box传输方法的原理类似。

需要说明的是，在本申请中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。