CN115883478B - 一种多标识网络体系中安全高效的传输控制方法及系统 - Google Patents

Abstract

本发明提供一种多标识网络体系中安全高效的传输控制方法及系统，包括：步骤S1，定义传输层推式语义通信包PTP；步骤S2，进行连接建立，并在连接建立过程中实现会话密钥的协商；步骤S3，通过流帧实现单个连接内部同时传输多个业务流，通过ACK流帧实现可靠传输；步骤S4，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；步骤S5，根据网络状态实时调整所述拥塞窗口的大小；步骤S6，根据安全传输机制建立交互过程。本发明结合多标识网络体系的特性，为多标识网络传输层设计了一种安全高效的传输控制方法，能够提供高效可靠的数据流交付服务，并达到具有更强的延展性、提升连接建立速度、支持基于流量的拥塞控制等技术效果。

Description

一种多标识网络体系中安全高效的传输控制方法及系统

技术领域

本发明涉及一种网络传输控制方法，尤其涉及一种多标识网络体系中安全高效的传输控制方法，并进一步涉及采用了该多标识网络体系中安全高效的传输控制方法的传输控制系统。

背景技术

当今正处于一个信息技术蓬勃发展的时代，互联网技术的快速发展让全球几十亿人受益。IP网络作为互联网通信的基础设施，对现代社会产生了巨大的影响。IP体系架构是一个以IP协议为细腰的沙漏结构，其设计理念是通信者可以根据IP地址从指定的主机中获取想要的数据。随着时代的不断发展，人们对于网络服务的需求逐渐多样化，IP体系架构逐渐显现出其局限性，如安全性不足、协议栈日趋复杂、移动场景下的传输性能差等。

二十世纪末开始，世界上的许多国家陆续提出多种新型网络体系架构，以期对IP网络架构下所显现出的问题做出更为根本性的解决。在这些新型网络中，有支持从IP网络逐步演进的架构，也有一些非常具有颠覆性的架构。其中，普遍公认的有较大创新性和影响力的新型网络体系架构有：表达型互联网架构（eXpressive Internet Architecture，XIA）、面向创新的互联网框架（Framework for Internet Innovation，FII）、命名数据网络（Named Data Networking，NDN）以及多标识网络（Mutil-Identifier Network，MIN）等。这些新型网络的设计宗旨各不相同，但都对探索未来网络的可能样式做出了巨大的贡献。

目前常用的一种现有技术是TCP，即传输控制协议（TCP，Transmission ControlProtocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。TCP是面向连接的运输层协议，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的，即一对一。TCP提供可靠交付的服务，通过TCP连接传送的数据，无差错、不丢失和不重复，并且按序到达。TCP提供全双工通信，TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接受缓存，用来临时存放双向通信的数据。TCP是面向字节流的，TCP中的“流”指的是流入到进程或从进程流出的字节序列。

这种现有技术的缺点在于：TCP被IP协议所承载和传输，并不能用于重新设计了网络分组格式的多标识网络中。同时也不支持身份标识与路由器级别的包签名与验签。

TCP连接的建立需要三次握手，连接建立的时间长，直观反映便是用户等待的时间久，体验不好。网络迁移需要重新建立TCP连接，一条TCP连接通过四元组，即通过源IP、源端口、目的IP和目的端口来唯一确定，当IP地址变化时，必须要断开连接，然后重新建立TCP连接。而建立连接的过程包含TCP三次握手、TLS四次握手的时延以及TCP慢启动的减速过程，会给用户带来网络卡顿的感觉，因此连接的迁移成本很高。

并且，TCP存在队头阻塞问题。TCP是字节流协议，TCP层必须保证收到的字节数据是完整且有序的，如果序列号较低的TCP段在网络传输中丢失了，即使序列号较高的TCP段已经被接收了，应用层也无法从内核中读取到这部分数据。

目前常用的另一种现有技术是QUIC，即谷歌制定的一种基于UDP的低时延的互联网传输层协议QUIC（Quick UDP Internet Connection）。QUIC是两个端点之间面向连接的协议。这些端点交换UDP数据报，这些UDP数据报包含QUIC数据包。QUIC端点使用QUIC数据包建立QUIC连接，这是这些端点之间的共享协议状态。

作为一种全新设计的传输协议，QUIC旨在从根本上提高HTTPS流量的性能，并实现快速部署和传输机制的持续发展。QUIC取代了大多数传统的HTTPS堆栈：HTTP/2，TLS和TCP。QUIC以UDP为基础进行用户空间传输。在用户空间中构建QUIC有助于将其部署为各种应用程序的一部分，并使迭代更改能够在应用程序更新时间尺度上发生。QUIC要求传输加密，即对数据包进行身份验证和加密。此外，QUIC通过使用轻量级的数据结构抽象流来消除行首阻塞延迟，这些流在单个连接中进行多路复用，因此单个数据包的丢失仅会阻塞该数据包中的数据流。

QUIC协议对数据包进行加密和认证，以避免中间人篡改并限制协议的僵化。它通过使用唯一的数据包编号避免重传歧义，以及在ACK中使用显式信令进行准确的RTT测量，它可以提高丢失率恢复。它提供流控制以限制在慢速接收器上缓冲的数据量，并通过使用流控制限制来确保单个流不会消耗所有接收器的缓冲区。

QUIC协议选择了UDP，因为UDP本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了TCP的可靠性，TLS的安全性，HTTP2的并发性，只需要用户端和服务端的应用程序支持QUIC协议，完全避开了操作系统和中间设备的限制。

但是，QUIC协议同样存在以下问题：QUIC被IP协议所承载和传输，并不能用于重新设计了网络分组格式的多标识网络中。同时也不支持身份标识与路由器级别的包签名与验签。

QUIC基于UDP而不是IP，这是因为IP报文中包含8位协议字段，是用来表示IP报文承载的上层传输协议类型。这个8bit的字段，理论上可以支持255种协议。NAT网络设备是用来完成网络地址转换工作的，因此NAT设备必须要能够认识并理解对应的协议，但是，大部分普通NAT设备只能够识别TCP和UDP这两种传输协议，这就意味着，当使用SCTP协议从一个内网向公网发送报文时，SCTP报文会被NAT网络设备丢弃，连接无法建立，通信无法进行。UDP和IP层并无本质区别，都是提供包发送服务，由于在IP层上面去定义自己的新协议有NAT网络设备的兼容问题，因此只能在UDP报文之上去实现，因此，QUIC基于UDP而不是IP，事实上是对现有互联网体系进行妥协和过渡的协议。

发明内容

本发明所要解决的技术问题是需要提供一种多标识网络体系中安全高效的传输控制方法，旨在提供高效可靠的数据流交付服务，并达到具有更强的延展性、提升连接建立速度、支持基于流量的拥塞控制以及在在网络层的进行身份鉴权和数据溯源的技术效果。在此基础上，还进一步提供采用了该多标识网络体系中安全高效的传输控制方法的传输控制系统。

对此，本发明提供一种多标识网络体系中安全高效的传输控制方法，包括以下步骤：

步骤S1，定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头和流帧，并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；

步骤S2，进行连接建立，并在连接建立过程中实现会话密钥的协商；

步骤S3，通过流帧实现单个连接内部同时传输多个业务流，通过ACK流帧实现可靠传输；

步骤S4，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

步骤S5，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

步骤S6，根据安全传输机制建立交互过程。

本发明的进一步改进在于，所述步骤S1中，所述传输层包头Data Header包括连接ID、包序号和流数量，所述流帧包括帧头部和帧包，所述帧头部包括流类型、流ID、偏移量、帧长度和帧控制参数。

本发明的进一步改进在于，所述步骤S1中，通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分，划分为三个区间；第一个区间为Type字段，用于表示当前数据块的类型；第二个区间为Length字段，用于表示Value字段的长度；第三个区间为Value字段，用于保存实际承载的数据内容，或嵌套地保存若干个TLV编码的数据块。

本发明的进一步改进在于，所述步骤S2包括以下子步骤：

步骤S201，客户端Client首先发送一个初始握手包到服务端Server，该初始握手包中携带客户端Client的元数据信息，所述客户端Client的元数据信息包括用于流量控制的最大传输数据量；

步骤S202，服务端Server响应一个握手包，该握手包携带服务端Server的元数据信息，所述服务端Server的元数据信息包括用于流量控制的最大传输数据量以及用于密钥协商的加密套件；

步骤S203，客户端Client收到握手回复后处于连接建立成功状态，发送一个握手结束包，并且在该握手结束包中携带数据；

步骤S204，服务端Server收到客户端Client的握手结束包之后，服务端Server处理连接建立成功的状态，然后响应一个握手结束包给客户端Client，并且在该握手结束包中携带数据。

本发明的进一步改进在于，所述步骤S2在连接建立过程中，以一个64位的随机数作为连接ID，当用户网络切换时，所建立连接的连接ID保持不变。

本发明的进一步改进之处在于，所述步骤S3中，通过业务流（Stream）来区分不同业务的流量，通过流ID（StreamID）来唯一标识不同的业务流。每个业务流在单个传输层推式语义通信包PTP中传输的数据称为一个流帧。不同业务可以共享同一个连接，并各自独立进行流量控制与拥塞控制。同时，负责实现可靠传输的ACK流帧以流为基本单元，不同的业务流之间的可靠传输不会相互干扰，即当单个业务流发生传输错误时，不会影响其他业务流正常向上层应用交付数据，防止发生队头阻塞。

本发明的进一步改进在于，所述步骤S3中所述ACK流帧的格式包括帧类型FrameType、接收到的最大包序号Largest Acknowledged、从收到通用推式包到发出ACK的延时ACK Delay、ACK流帧中ACK块字段的数目ACK Range Count、在最大确认数之前正在被确认的连续的数据包的数量First ACK Range、比ACK块中的最小数据包号之前连续未被确认数据包的数目Gap以及空档确定的最小数据包号之前连续被确认数据包的数目ACK Range。本发明的进一步改进在于，所述步骤S4中，在连接建立的过程中，发送端节点相互告知接收端的每个业务流的最大可接收的数据量MaxStreamSize和所有整个连接的可接收数据量MaxDataSize，以字节为单位；发送端已发出未确认的数据不能超过所述最大可接收的数据量MaxStreamSize以及可接收数据量MaxDataSize的上限值。

本发明的进一步改进在于，所述步骤S5中，当收到未标记的包时，所述拥塞窗口根据预设规则进行增大；当收到携带拥塞标记的包或客户端定时器超时时，所述拥塞窗口根据预设规则进行缩小。

本发明的进一步改进在于，所述步骤S6中，根据安全传输机制建立交互过程包括以下子步骤：

步骤S601，客户端Client发起连接请求，请求的内容包括客户端Client的加密配置、所支持的加密算法套件以及额外的扩展配置；

步骤S602，服务端Server收到客户端Client发送的连接初始化消息，选择对应的加密算法套件，生成服务端Server的私钥和公钥信息，根据密钥协商算法计算得到相应的公开参数，发送给客户端Client；

步骤S603，客户端Client收到服务端Server回复的连接初始化请求后，根据服务端选取的算法套件生成客户端Client的私钥和公钥信息，然后根据服务端Server发送的公开参数，使用密钥协商算法计算出相应的加密密钥；

步骤S604，客户端Client生成公开参数，在发送参数的同时发送加密的应用数据；

步骤S605，服务端Server收到客户端Client的公开参数后，计算出加密密钥，解密客户端Client发送的数据内容。

本发明还提供一种多标识网络体系中安全高效的传输控制系统，采用了如上所述的多标识网络体系中安全高效的传输控制方法，并包括：

传输层包格式定义模块，用于定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头和流帧，并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；

连接建立模块，用于进行连接建立，并在连接建立过程中实现会话密钥的协商；

连接复用模块，通过流帧实现单个连接内部同时传输多个业务流；

可靠传输模块，通过ACK流帧实现可靠传输；

流量控制模块，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

窗口调整模块，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

安全传输模块，根据安全传输机制建立交互过程。

与现有技术相比，本发明的有益效果在于：结合多标识网络体系的特性，为多标识网络传输层设计了一种安全高效的传输控制方法，进而使得整体方案具有更强的延展性，在后续协议升级需要添加新字段时，传输层网络包结构无需修改；采用流帧作为数据传输的基本单位，支持连接的多流复用并同时解决了队头阻塞问题，且在传输层建立连接时，初次建立连接仅需一次握手，后续建立连接无需握手便可传输加密数据，有效地提升了连接建立的速度；支持基于流量的拥塞控制，使得传输控制过程更为灵活且高效；在多标识网络的传输层设计了安全传输机制，并结合多标识网络体系的特点，能够在网络层进行身份鉴权和数据溯源，使得传输层的数据通信更加安全和可靠。

附图说明

图1是多标识网络协议栈的设计原理示意图；

图2是本发明在网络协议栈中的位置示意图；

图3是本发明一种实施例的工作流程示意图；

图4是本发明一种实施例的传输层推式语义通信包的格式示意图；

图5是本发明一种实施例的连接建立过程示意图；

图6是本发明一种实施例的可靠传输示意图；

图7是本发明一种实施例的流量控制示意图；

图8是本发明一种实施例的安全传输建立交互过程示意图；

图9是本发明一种实施例的0 RTT交互流程示意图。

实施方式

多标识网络是一种新型网络体系，即Mutil-Identifier Network，简称MIN。多标识网络旨在支持一个多边共管、共治和共享的网络空间，同时具有较好的兼容性和可演进性，并在安全性、传输效率等网络标准度量方面优于传统的IP网络。多标识网络在架构上大体上可以划分为管理面和数据面两个层次。数据面主要支持对身份标识、内容标识和地址标识等多种网络标识的解析操作，并可基于异构标识完成高效、可扩展的路由寻址及转发功能。数据面的功能由多标识路由器（Multi-Identifier Router，MIR）来承载。管理面主要支持对多种标识的生成及管理。管理面的监管节点通过共识算法校验标识数据，在达成共识后，将其归属信息和操作信息记录在区块链上，从而实现了信息的不可篡改性和可追溯性。管理面的功能由多标识管理系统（Multi-Identifier System，MIS）来承载。

与IP网络和其它新型网络相比，多标识网络有如下特点：（1）多标识网络以身份标识为中心，支持身份、内容、IP及地空等多种网络寻址标识共存。这种设计让它具有极好的兼容性，十分有利于多标识网络的演进。（2）多标识网络支持直接部署在现有的IP网络之上。（3）多标识网络融合了区块链技术，以实现去中心化的标识生成、管理及解析。（4）在网络安全机制的设计方面，多标识网络直接聚焦于数据本身，设计了一整套基于密码学、身份认证等技术的安全防护机制，最大限度地保证了网络数据的安全。

多标识网络体系协议栈如图1所示，各层协议栈功能如下：

链路层：此处的链路层不是传统OSI/ISO七层模型里面的链路层，而是针对多标识网络层抽象出来的虚拟链路层，底层可以通过真实的物理链路或者TCP、UDP和Unix隧道进行传输。该层向上抽象出逻辑接口，屏蔽底层通信链路的不同，方便在网络层中对数据的收发进行统一的操作，而不必关心底层的链路差异。

网络层：为支持“推送式”和“拉取式”通信模式，在网络层定义了三种不同类型的网络包，其中通用推式包（General Push Packet，GPPkt）用于支持推式通信，兴趣包（Interest）和数据包（Data）用于支持拉式通信。网络层基于该包格式定义来完成网络分组的路由和转发。

传输层：为向运行在不同主机上的应用进程之间的通信提供通用的数据传输服务，应用程序利用该服务传送应用层报文。

应用层：基于传输层提供的统一编程接口（Unified Application ProgrammingInterface, U-API），针对不同业务的通信需求开发应用层程序。

多标识网络体系网络架构支持灵活多样的链路层数据链路，可以基于以太网，也可以基于已有的TCP通信链路（TCP隧道），UDP通信链路（UDP隧道）和Unix通信链路（Unix隧道）。目前的多标识网络体系缺乏一套高效可扩展的传输层协议设计，基于推式通信语义为不同流量提供可靠服务。此外，传输层的协议设计应为应用层提供一套统一的接口，其实现细节应对应用层透明，应用层只需根据自身的通信需求和特点，调用合适的通信接口即可。

本发明结合多标识网络的特性，为在多标识网络体系设计了一种安全高效的传输控制方法，以提供高效可靠的数据流交付服务。本发明作用于多标识网络的传输层，也负责数据通信的加密与安全，如图2所示。本发明支持可靠传输、流量控制、拥塞控制和加密通信。此外，还实现了连接的多路复用，同时还支持连接迁移，当底层的逻辑接口发生变动的时候，仍然可以保持上层的连接。传输层对其协议细节进行了封装，以便应用层无需关注底层的数据通信，重点进行业务逻辑的开发。

下面结合附图，对本发明的较优的实施例作进一步的详细说明。

如图1所示，本实施例提供一种多标识网络体系中安全高效的传输控制方法，包括以下步骤：

步骤S1，定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头（Data Header）和流帧（Stream Frame），并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；定义传输层推式语义通信包PTP指的是Push TransportPacket，简称PTP；

步骤S2，进行连接建立，并在连接建立过程中实现会话密钥的协商；

步骤S3，通过流帧实现单个连接内部同时传输多个业务流，通过ACK流帧实现可靠传输；

步骤S4，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

步骤S5，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

步骤S6，根据安全传输机制建立交互过程。

本实施例所述步骤S1用于实现传输层包格式定义，将两个通信节点在连接建立阶段构建的双向传输通路称为一条连接（Connection）；每个连接内部可以同时传输多条业务流（Stream），且多条业务流之间没有任何依赖关系，单条业务流发生丢包不影响其他业务流向上层交付数据。通过这种设计，本实施例实现了单个连接内部多个业务流之间的多路复用，并且有效的避免了队头阻塞问题。传输层数据包由多标识网络中的通用推式包（General Push Packet, GPPkt）承载，承载了传输层数据包的通用推式包被称为传输层推式语义通信包（Push Transport Packet，PTP），其格式如图4所示。

本实施例所述步骤S1中，所述传输层包头（Data Header）包括连接ID（ConnectionID）、包序号（PacketNum）和流数量（StreamNum）。流帧（Stream Frame）是传输的最小结构单位，一个PTP包可以包含多个流帧（Stream Frame）。对于每个流帧（StreamFrame）包括帧头部（Frame Header）和帧包（Frame Body），所述帧头部（Frame Header）包括流类型（Stream Type）、流ID（StreamID）、偏移量（Offset）、帧长度（Frame Length）和帧控制（Frame Control）参数，帧包（Frame Body）包括具体的数据内容。

本实施例所述步骤S1中，传输层推式语义通信包采用了TLV（Type-Length-Value）编码的技术方案，通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分，划分为三个区间；第一个区间为Type字段，用于表示当前数据块的类型；第二个区间为Length字段，用于表示Value字段的长度；第三个区间为Value字段，用于保存实际承载的数据内容，或嵌套地保存若干个TLV编码的数据块。

本实施例所述传输层推式语义通信包采用TLV编码的原因在于：第一，多标识网络采用TLV编码方案编码链路层网络包，本实施例在传输层采用TLV编码方案，能够保持设计的一致性。第二，TLV编码方案相对于TCP、UDP和IP等协议中使用的预定义的静态字段来说，具有更强的延展性，因此，能够为本实施例的升级和后续字段的扩充预留了空间。

本实施例所述步骤S2用于实现连接建立过程。

在面向连接的传输控制协议设计中，均存在一个初始化阶段称为连接建立，通过在两个通信节点之间交换一些元数据，来确认双方可达，并且为对方分配一定资源用于标记和处理两者的通信数据。本实施例将在步骤S2中对连接建立过程进行详细的介绍。

在传统的TCP/IP网络中，TCP是典型的面向连接的传输层协议，通过三次握手完成连接建立之后即可进行双向的可靠数据流传输，但是TCP本身并没有对数据进行加密，所以如果上层应用不对数据进行加密，则使用TCP传输的数据是以明文的形式在网络中传递的。因此通常IP体系下的应用层协议设计会通过加入TLS来支持加密通信，典型的就是HTTPS协议。使用HTTPS进行加密通信时，TCP连接建立过程和TLS密钥协商过程一共至少需要2个RTT才能完成安全通信链路的建立。而随着互联网的发展以及软硬件设备的优化，点对点的时延已经接近理论完美值，很难对单个RTT的时延进行优化，因此如何减少RTT次数是降低通信时延最有效手段。RTT指的是Round-Trip Time，是指从发送端发送数据开始到发送端收到来自接收端的确认总共经历的时延。

为解决上述问题，本实施例在连接建立过程中加入安全密钥协商机制，可以在连接建立过程中实现会话密钥的协商，在连接建立成功之后，可以直接进行安全加密通信。本实施例所述步骤S2记载了连接建立的完整过程，而关于密钥协商的实现过程将在后面的步骤S6进行详细介绍。如图5所示的是连接建立过程示意图。

更为具体的，本实施例所述步骤S2包括以下子步骤：

步骤S201，客户端Client首先发送一个初始握手包（Client Initial Handshake）到服务端Server，该初始握手包（Client Initial Handshake）中携带客户端Client的元数据信息，所述客户端Client的元数据信息包括用于流量控制的最大传输数据量等；

步骤S202，服务端Server响应一个握手包（Server Initial Handshake），该握手包（Server Initial Handshake）携带服务端Server的元数据信息，所述服务端Server的元数据信息包括用于流量控制的最大传输数据量以及用于密钥协商的加密套件等；

步骤S203，客户端Client收到握手回复后处于连接建立成功状态，发送一个握手结束包（Client Handshake Encrypted Data），并且可以在该握手结束包（ClientHandshake Encrypted Data）中携带数据；

步骤S204，服务端Server收到客户端Client的握手结束包（Client HandshakeEncrypted Data）之后，服务端Server处理连接建立成功的状态，然后响应一个握手结束包（Server Handshake Encrypted Data）给客户端Client，并且可以在该握手结束包（ServerHandshake Encrypted Data）中携带数据。

经过上述连接建立流程后，客户端Client和服务端Server之间即可进行双向可靠数据流交付。

值得说明的是，除了低时延的连接建立机制外，本实施例还支持连接迁移。在日常通信过程中，网络连接经常会在Wi-Fi和蜂窝网络中进行切换，网络切换过程中出现的中断无疑将非常影响用户体验。传统IP网络中的TCP连接是通过源IP地址、源端口号、目的IP地址、目的端口号以及协议号组成的唯一五元组，一旦其中某一项发生变化，则需要重新创建新的TCP连接。为解决此技术问题，在本实施例所述步骤S2在连接建立过程中，以一个64位的随机数作为连接ID，当用户网络切换时，所建立连接的连接ID保持不变，因此，本实施例无需重新创建连接，使网络切换具有用户无感知的特性，以便带来良好的用户体验。

客户端Client和服务端Server都可以充当发送端和接收端，在本实施例中，客户端Client默认作为发送端，服务端Server默认作为接收端。

本实施例所述步骤S3用于实现可靠连接。为实现传输层的可靠传输，即保障数据完整无误的传输到目的节点，本实施例在步骤S3中优选设计了一套可靠传输保障机制。

本实施例所述步骤S3中，通过业务流（Stream）来区分不同业务的流量，通过流ID（StreamID）来唯一标识不同的业务流。每个业务流在单个传输层推式语义通信包PTP中传输的数据称为一个流帧。不同业务可以共享同一个连接，并各自独立进行流量控制与拥塞控制。同时，负责实现可靠传输的ACK流帧以流为基本单元，不同的业务流之间的可靠传输不会相互干扰，即当单个业务流发生传输错误时，不会影响其他业务流正常向上层应用交付数据，防止发生队头阻塞。

在通信过程中，沿用TCP中经典的超时定时器+ACK机制的思想设计的可靠传输机制，但与TCP协议不同的是，在本实施例所设计的传输控制方法中，每个连接可同时传输多个业务流（Stream），因此ACK也不再是针对每个连接的，而是针对每个业务流的。具体地，本实施例的每个ACK都是一个特殊的流帧（Stream Frame），称为ACK流帧（ACK StreamFrame），与普通流帧不同的是，ACK流帧的头部没有Stream ID和offset字段。每个ACK流帧的数据部分包含如下表所示的字段：

表1 ACK流帧格式定义

字段名	字段描述
		Frame Type	帧类型，值为ACK
Largest Acknowledged	接收到的最大包序号
		ACK Delay	从收到通用推式包到发出ACK的延时
ACK Range Count	表示ACK帧中ACK块字段的数目
		First ACK Range	表示在最大确认数之前正在被确认的连续的数据包的数量
Gap	表示比前述ACK块中的最小数据包号之前连续未被确认数据包的数目
		ACK Range	表示先前空档确定的最小数据包号之前连续被确认数据包的数目

因此，本实施例所述步骤S3中所述ACK流帧的格式包括帧类型Frame Type、接收到的最大包序号Largest Acknowledged、从收到通用推式包到发出ACK的延时ACK Delay、ACK流帧中ACK块字段的数目ACK Range Count、在最大确认数之前正在被确认的连续的数据包的数量First ACK Range、比ACK块中的最小数据包号之前连续未被确认数据包的数目Gap以及空档确定的最小数据包号之前连续被确认数据包的数目ACK Range。

为了更好的展示可靠传输过程，接下来以一个实际的传输示例对该过程进行描述。如图6所示的是基于ACK机制实现的可靠传输通信过程示意图：发送端向接收端发送了编号为10-20的通用推式包，其中10、11、15、16、18、19号包到达了接收端，其他包发生了丢包。此时，接收端回复的ACK包中将会携带以下信息：

Largest Acknowledge为19，代表接受到的最大包序号为19；

Delay为20，代表服务端Server从收到19号推式包到回复ACK的延迟是20ms；

Range Count为3，代表有三个ACK块；

First ACK Range为1，代表19号推式包前有一个包已收到，即18号包已收到；

Gap为1，代表18号包前一个包未收到，即17号包未收到；

ACK Range为2，代表17号前两个包已收到，即15、16号包已收到；

Gap为3，代表15号包前3个未收到，即12、13、14号包未收到；

ACK Range为2，代表12号包前2个包已收到，即10、11号包已收到；

Gap为0，代表10号包没有未收到的包。

通过如上ACK过程，接收端向发送端告知了自己已经收到10、11、15、16、18、19号包的信息，同时告知了发送端自己的ACK延迟为20ms。

值得说明的是，在支持可靠传输的同时，本实施例也支持不可靠传输，即尽力而为的传输。不可靠数据和可靠数据一样，以流帧为基本单位，二者共用加密套件和拥塞控制套件。不可靠传输与可靠传输的不同之处在于：不可靠数据的流帧无需确认，也不要求重传。

本实施例所述步骤S4用于实现流量控制。

在数据传输的过程中，如果接收端处理过慢，则会导致大量的数据在接收队列里面堆积，进而导致丢包。对此，需设计流量控制机制来应对该问题，接收端将接收队列或接收窗口的剩余容量反馈给发送端，发送端根据获取到的接收端处理能力信息合理的调整发包的速率。

在本实施例中，由于单个连接中存在多条业务流，所以需要从两个方面来设计流量控制机制。因此，本实施例在所述步骤S4中，首先针对每条业务流的流量控制，需要对单条业务流的发送速率进行限制，防止单条业务流独占整个连接的情况；其次是针对整个连接的流量控制，即限制同一个连接内所有业务流的传输速率进行限制，防止接收端的缓存溢出。具体的，本实施例在连接建立的过程中，接收端节点告知发送端节点接收端的每个业务流的最大可接收的数据量（MaxStreamSize）和所有整个连接的可接收数据量（MaxDataSize），以字节为单位；发送端已发出未确认的数据不能超过所述每个业务流的最大可接收的数据量（MaxStreamSize）以及整个连接的可接收数据量（MaxDataSize）。

如图7所示的是本实施例的流量控制过程示意图，具体过程如下：

1）场景一、若业务流Stream 2发送的偏移量超出了接收端最大可接收的数据量（MaxStreamSize），则此时发送端会发送 StreamDataBlocked 类型的流帧（Stream Frame）给接收端，这种类型的流帧为发送端发送给接收端，将发送端已发送单个业务流的最大可接收的数据量的信息发送给接收端。接收端接收到StreamDataBlocked 类型的流帧后，会回复一个新的最大可接收的数据量（MaxStreamSize）给发送端，根据接收能力更新业务流Stream 2的最大可接收数据量，恢复该条流的数据发送。该值大小受到接收端接收内存缓冲区大小的限制，也需要考虑不同业务流之间的公平性，一般可由以下公式确定。

。其中，新最大单流可接收数据量指的是新的最大可接收的数据量（MaxStreamSize）；原最大单流可接收数据量指的是更新之前的最大可接收的数据量。

2）场景二、若所有流发送的数据之和超出了接收端对于所有流的可接收数据量（MaxDataSize），则此时发送端会发送DataBlocked类型的流帧（Stream Frame）给接收端。这种类型的流帧为发送端发送给接收端，将发送端已发送所有业务流的最大可接收的数据量的信息发送给接收端。接收端根据自身的接收能力回复一个新的总可接收数据量（MaxDataSize）给发送端，发送端对所有流总的最大可接收数据量进行更新，并恢复所有流的数据发送。该值大小受到接收端接收内存缓冲区大小的限制，一般可由以下公式确定。

新最大总可接收数据量=原最大总可接收数据量+接收端空闲接收内存大小。其中，新最大总可接收数据量指的是整个连接的新的可接收数据量（MaxDataSize），原最大总可接收数据量指的是整个连接在更新之前的可接收数据量。

本实施例所述步骤S5用于实现窗口调整，也称可插拔的端侧/通信窗口调整。

在本实施例中，客户端为每条流维护一个拥塞窗口来发送包，根据网络状态实时调整所述拥塞窗口大小。在所述步骤S5中，当收到未标记的包时，所述拥塞窗口根据预设规则进行增大；当收到携带拥塞标记的包或客户端定时器超时时，所述拥塞窗口根据预设规则进行缩小。所述预设规则指的是预先自定义增大或缩小所述拥塞窗口的调整算法，以达到最优的发送速率，实现较高的吞吐率。

由于本实施例的拥塞控制方案实现在客户端，应用程序不需要停机和升级就能实现端侧窗口调整算法的变更。因此，在实际部署场景下，根据当前传输控制协议所适配的网络环境，所述预设规则可以选用多种TCP下经典的拥塞窗口调整算法来对客户端的拥塞窗口大小进行调整，例如Reno、New Reno、HTCP、BIC、CUBIC等，本实施例默认采用CUBIC算法。

本实施例所述步骤S6用于实现安全传输机制。

传统的TCP/IP协议栈中，传输层协议通常将安全保障工作留给应用层，传输层自身只负责数据传输的效率以及可靠性，并不保障数据本身的安全。这使得恶意攻击者可以通过嗅探、拦截等一系列攻击手段实现对传输内容的监听和篡改；此外，由于传输层对安全考虑的缺失，如果应用层不设计部署安全加密模块，则所有的数据都将是明文传输的，这是不被生产环境所接受的，因此传输层安全保障模块的缺失额外增加了应用层协议和软件开发的设计成本。

为此，在本实施例中，一方面依托于多标识网络，在网络层构建了基于身份的安全保障机制，以实现网络层的身份鉴权和数据溯源，为传输层的数据通信建立安全壁垒；另一方面，通过步骤S6在传输层设计了安全传输机制，基于密钥协商算法、非对称加密以及对称加密技术对传输数据进行加密，保障数据传输的高安全和高可靠。

加密手段通常分为对称加密和非对称加密，其中，常见的对称加密算法有SM4、AES等，非对称加密算法有SM2、RSA等。在非对称加密算法中，将数据用公钥进行加密后，只有拥有私钥的对象才能够解密，不需要交换密钥；而在对称加密算法中，需要双方拥有相同的密钥之后才能进行加密通信，因此，双方如何安全的获得相同的密钥是一个问题。此外，非对称加密算法的加密速度要远远慢于对称加密算法，直接使用非对称加密来通信对于算力以及通信实时性的影响较大，通常不采用这种方式。密钥协商算法（例如ECDHE、DH等）采用相对高效的对称加密方式，能够让通信双方安全交换密钥信息以获得相同的密钥，即使密钥交换通信过程被窃听，窃听者也无法直接根据窃听到的内容计算出密钥。但是该类密钥协商算法无法验证通信双方的身份，还需要使用非对称加密的签名验签来认证通信双方的身份。因此，为实现安全可靠的数据传输，需要结合密钥协商算法、非对称加密以及对称加密算法来实现安全通信。

如图8所示，本实施例所述步骤S6中，根据安全传输机制建立交互过程包括以下子步骤：

步骤S601，客户端Client发起连接请求，请求的内容包括客户端Client的加密配置、所支持的加密算法套件以及额外的扩展配置等；在多标识网络中默认的加密算法套件为ECDHE_SM2_SM4；

步骤S602，服务端Server收到客户端Client发送的连接初始化消息，选择对应的加密算法套件，生成服务端Server的私钥和公钥信息，根据密钥协商算法计算得到相应的公开参数，发送给客户端Client；

步骤S603，客户端Client收到服务端Server回复的连接初始化请求后，根据服务端选取的算法套件生成客户端Client的私钥和公钥信息，然后根据服务端Server发送的公开参数，使用密钥协商算法计算出相应的加密密钥；

步骤S604，客户端Client生成公开参数，此时客户端Client已计算出加密密钥，可以在发送参数的同时发送加密的应用数据；

步骤S605，服务端Server收到客户端Client的公开参数后，计算出加密密钥，解密客户端Client发送的数据内容。

通过上述安全机制可以保证数据传输前向安全，每次的密钥协商过程客户端Client和服务端Server都重新生成公私钥，如果本次连接的私钥发生了泄露，只会影响本次连接的数据，之前的通信数据仍然具备安全保障。

因此，本实施例在这种安全机制的握手过程中，只需一次RTT就可完成该密钥的协商，进入加密通信流程。对于之后再次发起的请求，由于之前已协商过加密配置信息，可直接使用保存的配置信息进入密钥协商过程，从而减少了一次RTT的交互，做到了0 RTT，如图9所示的是0 RTT的交互流程，即无需再次RTT的交互流程。

本实施例还提供一种多标识网络体系中安全高效的传输控制系统，采用了如上所述的多标识网络体系中安全高效的传输控制方法，并包括：

传输层包格式定义模块，用于定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头和流帧，并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；

连接建立模块，用于进行连接建立，并在连接建立过程中实现会话密钥的协商；

连接复用模块，通过流帧实现单个连接内部同时传输多个业务流；

可靠传输模块，通过ACK流帧实现可靠传输；

流量控制模块，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

窗口调整模块，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

安全传输模块，根据安全传输机制建立交互过程。

综上所述，首先，本实施例在所述步骤S1中实现了一种基于TLV编码格式的可扩展的传输层网络分组编码方案，并以此为基础实现了所述多标识网络体系中安全高效的传输控制方法，相比于现在主流的TCP、QUIC协议中使用的不可更改的静态字段来说，本实施例结合多标识网络体系的特性，具有更强的延展性，在后续协议升级需要添加新字段时，传输层网络包结构无需修改。

在此基础上，本实施例基于多标识网络体系实现了安全高效的传输控制方法，采用流帧作为数据传输的基本单位，支持连接的多流复用并同时解决了队头阻塞问题。并且，在传输层建立连接时，初次建立连接仅需一次握手，后续建立连接无需握手便可传输加密数据，有效地提升了连接建立的速度；引入超时重传和ACK机制实现了可靠传输，同时也提供数据包的不可靠传输服务；此外，还支持基于流量的拥塞控制，支持流量控制和可插拔的端侧拥塞控制，使得传输控制过程更为灵活且高效。

加之，本实施例在多标识网络的传输层设计了安全传输机制，基于密钥协商算法、非对称加密以及对称加密技术对传输数据进行加密，保障数据传输的高安全和高可靠。本发明还结合多标识网络体系的特点，依托的多标识网络体系本身在网络层构建了基于身份的安全保障机制，能够在网络层进行身份鉴权和数据溯源，使得传输层的数据通信更加安全和可靠。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (8)

1.一种多标识网络体系中安全高效的传输控制方法，其特征在于，包括以下步骤：

步骤S1，定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头和流帧，并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；

步骤S2，进行连接建立，并在连接建立过程中实现会话密钥的协商；

步骤S3，通过流帧实现单个连接内部同时传输多个业务流，通过ACK流帧实现可靠传输；

步骤S4，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

步骤S5，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

步骤S6，根据安全传输机制建立交互过程，结合密钥协商算法、非对称加密以及对称加密算法来实现安全通信，所述密钥协商算法包括ECDHE算法或DH算法；

所述步骤S1中，所述传输层包头Data Header包括连接ID、包序号和流数量，所述流帧包括帧头部和帧包，所述帧头部包括流类型、流ID、偏移量、帧长度和帧控制参数；

所述步骤S3中，通过业务流来区分不同业务的流量，通过流ID来唯一标识不同的业务流；每个业务流在单个传输层推式语义通信包PTP中传输的数据称为一个流帧；不同业务共享同一个连接，并各自独立进行流量控制与拥塞控制；负责实现可靠传输的ACK流帧以流为基本单元；

所述步骤S3中，每个连接可同时传输多个业务流，通过ACK流帧对应每个业务流，所述ACK流帧的格式包括帧类型Frame Type、接收到的最大包序号Largest Acknowledged、从收到通用推式包到发出ACK的延时ACK Delay、ACK流帧中ACK块字段的数目ACK Range Count、在最大确认数之前正在被确认的连续的数据包的数量First ACK Range、在ACK块中的最小数据包号之前连续未被确认数据包的数目Gap以及空档确定的最小数据包号之前连续被确认数据包的数目ACK Range。

2.根据权利要求1所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S1中，通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分，划分为三个区间；第一个区间为Type字段，用于表示当前数据块的类型；第二个区间为Length字段，用于表示Value字段的长度；第三个区间为Value字段，用于保存实际承载的数据内容，或嵌套地保存若干个TLV编码的数据块。

3.根据权利要求1或2所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S2包括以下子步骤：

步骤S201，客户端Client首先发送一个初始握手包到服务端Server，该初始握手包中携带客户端Client的元数据信息，所述客户端Client的元数据信息包括用于流量控制的最大传输数据量；

步骤S202，服务端Server响应一个握手包，该握手包携带服务端Server的元数据信息，所述服务端Server的元数据信息包括用于流量控制的最大传输数据量以及用于密钥协商的加密套件；

步骤S203，客户端Client收到握手回复后处于连接建立成功状态，发送一个握手结束包，并且在该握手结束包中携带数据；

步骤S204，服务端Server收到客户端Client的握手结束包之后，服务端Server处理连接建立成功的状态，然后响应一个握手结束包给客户端Client，并且在该握手结束包中携带数据。

4.根据权利要求1或2所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S2在连接建立过程中，以一个64位的随机数作为连接ID，当用户网络切换时，所建立连接的连接ID保持不变。

5.根据权利要求1或2所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S4中，在连接建立的过程中，发送端节点相互告知接收端的每个业务流的最大可接收的数据量MaxStreamSize和所有整个连接的可接收数据量MaxDataSize，以字节为单位；发送端已发出未确认的数据不能超过所述最大可接收的数据量MaxStreamSize以及可接收数据量MaxDataSize的上限值。

6.根据权利要求1或2所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S5中，当收到未标记的包时，所述拥塞窗口根据预设规则进行增大；当收到携带拥塞标记的包或客户端定时器超时时，所述拥塞窗口根据预设规则进行缩小。

7.根据权利要求1或2所述的多标识网络体系中安全高效的传输控制方法，其特征在于，所述步骤S6中，根据安全传输机制建立交互过程包括以下子步骤：

步骤S601，客户端Client发起连接请求，请求的内容包括客户端Client的加密配置、所支持的加密算法套件以及额外的扩展配置；

步骤S602，服务端Server收到客户端Client发送的连接初始化消息，选择对应的加密算法套件，生成服务端Server的私钥和公钥信息，根据密钥协商算法计算得到相应的公开参数，发送给客户端Client；

步骤S603，客户端Client收到服务端Server回复的连接初始化请求后，根据服务端选取的算法套件生成客户端Client的私钥和公钥信息，然后根据服务端Server发送的公开参数，使用密钥协商算法计算出相应的加密密钥；

步骤S604，客户端Client生成公开参数，在发送参数的同时发送加密的应用数据；

步骤S605，服务端Server收到客户端Client的公开参数后，计算出加密密钥，解密客户端Client发送的数据内容。

8.一种多标识网络体系中安全高效的传输控制系统，其特征在于，采用了如权利要求1至7任意一项所述的多标识网络体系中安全高效的传输控制方法，并包括：

传输层包格式定义模块，用于定义传输层推式语义通信包PTP，所述传输层推式语义通信包PTP包括传输层包头和流帧，并通过TLV编码将所述定义传输层推式语义通信包PTP的数据块进行划分；

连接建立模块，用于进行连接建立，并在连接建立过程中实现会话密钥的协商；

连接复用模块，通过流帧实现单个连接内部同时传输多个业务流；

可靠传输模块，通过ACK流帧实现可靠传输；

流量控制模块，通过对每条业务流的流量控制以及对整个连接的流量控制实现流量控制；

窗口调整模块，根据接收到的业务流为其维护拥塞窗口来发送包，并根据网络状态实时调整所述拥塞窗口的大小；

安全传输模块，根据安全传输机制建立交互过程。