CN116436864B - 一种基于quic协议的部分可靠多路径传输方法 - Google Patents

一种基于quic协议的部分可靠多路径传输方法 Download PDF

Info

Publication number
CN116436864B
CN116436864B CN202310292771.1A CN202310292771A CN116436864B CN 116436864 B CN116436864 B CN 116436864B CN 202310292771 A CN202310292771 A CN 202310292771A CN 116436864 B CN116436864 B CN 116436864B
Authority
CN
China
Prior art keywords
module
data
datagram
client
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202310292771.1A
Other languages
English (en)
Other versions
CN116436864A (zh
Inventor
韩彪
李亚辉
宋丛溪
计晓岚
兰唯
韩雪强
徐草
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National University of Defense Technology
Original Assignee
National University of Defense Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National University of Defense Technology filed Critical National University of Defense Technology
Priority to CN202310292771.1A priority Critical patent/CN116436864B/zh
Publication of CN116436864A publication Critical patent/CN116436864A/zh
Application granted granted Critical
Publication of CN116436864B publication Critical patent/CN116436864B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H04L47/527—Quantum based scheduling, e.g. credit or deficit based scheduling or token bank
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种基于QUIC协议的部分可靠多路径传输方法，目的是在同一个网络会话中同时传输可靠的数据流和不可靠的数据报，拓宽多路径QUIC的适用场景。技术方案是构建基于多路径QUI C协议的部分可靠传输系统；基于多路径QUIC的部分可靠传输系统的客户端的握手模块A与服务器的握手模块B进行通信，建立多路径QUIC会话，完成握手；发送方向接收方传输数据；接收方接收数据报文，对数据报文进行处理并重组成完整的文件或数据单元。采用本发明可减小数据报的交付时间、减少网络资源浪费，在同一个网络会话中同时传输可靠的数据流和不可靠的数据报，拓宽多路径QUIC的适用场景。

Description

一种基于QUIC协议的部分可靠多路径传输方法
技术领域
本发明属于信息技术系统中的计算机通信技术领域，具体涉及一种基于QUIC(Quick UDP Internet Connection，UDP协议的快速网络连接)协议的部分可靠多路径传输方法。
背景技术
QUIC协议是由Google公司于2013年公开的一种基于UDP(User DatagramProtocol，用户数据报协议)的可靠的传输协议，其出发点是为了突破内核态实现的TCP(Transmission Control Protocol，传输控制协议)协议的桎梏，在用户态以UDP协议为基础实现TCP协议可靠传输、拥塞控制等核心能力，并在此基础上提供了对多流复用(Streammultiplex)的支持。2017年，谷歌百分之三十的入口流量使用QUIC传输。截止2020年，Meta百分之七十五的入口流量使用QUIC协议传输。因此，微软、阿里等相继跟进、实现并发布了自己的QUIC版本。随着QUIC技术的发展，QUIC不再局限于完全可靠的传输模式，其出发点在于完全可靠的传输模式并非对所有的应用都有益，完全可靠的传输模式需要重传丢失的数据报文，重传带来额外的延迟。一些应用需要不可靠的传输模式(比如实时视频传输、实时交互式游戏)来满足应用对低延迟的需求，另外一些应用在一个网络会话中甚至同时需要两种传输模式：不可靠传输和可靠传输，既部分可靠传输模式。比如在线视频会议中视频数据的内容可以采用不可靠传输的模式，而文字性互动信息需要可靠传输的模式。
另外，近年来由于短视频、在线会议、直播等业务的蓬勃发展，给网络传输协议提出了更高带宽、更低时延、更可靠的需求。作为一种并行传输技术，多路径传输具有带宽聚合、提升传输可靠性和链路利用率的优势。为了提高QUIC协议的传输能力以支持高吞吐量的需求，多路径QUIC协议应运而生。需要明晰的一点是，多路径QUIC协议可以理解为是QUIC协议的一种分支版本。相比单路径QUIC，多路径QUIC协议提供的核心能力是支持将传输的数据报文调度到多个物理接口上(比如手机端上的WiFi接口和5G蜂窝接口)，以达到传输速率的最大化。
如图1所示，传统的基于QUIC协议的多路径传输架构由服务端、客户端构成，客户端上安装有握手模块A、数据发送模块A、接收模块A、乱序重排模块A；数据发送模块A包括数据流模块A、数据加密模块A、调度模块A；服务端上安装有握手模块B、数据发送模块B、接收模块B、乱序重排模块B；数据发送模块B包括数据流模块B、数据加密模块B、调度模块B；
客户端的握手模块A与服务端的握手模块B、客户端的数据发送模块A相连。客户端的握手模块A向服务器的握手模块B发送探测报文，探测报文包含了客户端的QUIC协议版本号、密钥信息、客户端的端口信息。客户端的握手模块A还从服务端的握手模块B接收成功响应报文或失败响应报文。成功响应报文包含了握手成功后建立的路径信息，以及供客户端和服务端加解密数据使用的密钥；会话信息A与成功响应报文包含的内容相同，路径信息中包含了所有可以发送报文的路径以及各条路径的往返延迟RTT(Round-Trip Time)和各条路径的拥塞窗口CWND(CongestionWindow)，调度模块A选择其中的路径进行报文调度，密钥用于数据加密模块A对数据进行加密、接收模块A对接收的数据报文解密；失败响应报文包含的信息为握手失败的错误代码。如果接收的是成功响应报文，会话建立，生成会话信息A，客户端的握手模块A将会话信息A的握手成功后建立的路径信息发送给数据发送模块A的调度模块A，握手模块A同时将会话信息A的密钥发送给接收模块A和数据发送模块A的数据加密模块A；如果是失败响应报文，则建立会话失败。
服务端的握手模块B与客户端的握手模块A、服务端的数据发送模块B相连。服务端的握手模块B收到客户端握手模块A的探测报文，根据其中的客户端QUIC协议版本号决定响应报文的类型。如果客户端QUIC协议版本号与服务端的QUIC协议版本号一致，则握手模块B根据探测报文中的客户端的端口信息和本服务端的端口信息生成路径信息，根据探测报文中密钥信息生成用于加解密数据的密钥，填入成功响应报文，发送到客户端的握手模块A。如果客户端的QUIC协议版本号与服务端的所使用的QUIC协议版本号不一致，则握手模块B将错误代码填入失败响应报文，发送到客户端的握手模块A。若握手模块B发送的是成功响应报文，则生成会话信息B，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B。会话信息B包含的内容和成功响应报文相同，路径信息中包含了所有可以发送报文的路径，调度模块B选择其中的路径进行报文调度，密钥用于数据加密模块B对数据进行加密、接收模块B对接收的数据报文解密。
客户端的数据流模块A与数据加密模块A相连，用于发送客户端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块A。
服务端的数据流模块B与数据加密模块B相连，用于发送服务端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块B。
客户端的数据加密模块A接收数据流模块A发出的切割后的数据段，使用从握手模块A接收到的会话信息A中的密钥对切割后的数据段加密，之后封装成数据报文输出到调度模块A。
服务端的数据加密模块B接收数据流模块B发出的切割后的数据段，使用从握手模块B接收到的会话信息B中的密钥对切割后的数据段加密，之后封装成数据报文输出到调度模块B。
客户端的调度模块A接收数据加密模块A发出的数据报文，从握手模块A接收会话信息A中的握手成功后建立的路径信息，调度模块A使用调度算法从多条路径中选择一条路径发送该数据报文到服务端的接收模块B。
服务端的调度模块B接收数据加密模块B发出的数据报文，从握手模块B接收会话信息B中的握手成功后建立的路径信息，调度模块B使用调度算法从多条路径中选择一条路径发送该数据报文到客户端的接收模块A。
客户端的接收模块A与服务端的调度模块B、客户端的乱序重排模块A相连，客户端的接收模块A从服务端的调度模块B接收数据报文，从握手模块A接收会话信息A中的密钥，将数据报文解封装，取出数据段，使用密钥解密后输出到乱序重排模块A。服务端的接收模块B与客户端的调度模块A、服务端的乱序重排模块B相连，服务端的接收模块B从客户端调度模块A接收数据报文，从握手模块B接收会话信息B中的密钥，将数据报文解封装，取出数据段，使用密钥解密后输出到乱序重排模块B。
客户端的乱序重排模块A与客户端的接收模块A、客户端的应用软件相连，客户端的乱序重排模块A从接收模块A接收数据段，对数据段重排序成完整的文件，然后输出给客户端中需要使用该完整文件的应用软件。乱序重排模块A是数据缓冲区，大小一般为1MB到16MB，优先值为2MB。
服务端的乱序重排模块B与服务端的接收模块B、服务端的应用软件相连，服务端的乱序重排模块B从接收模块B接收数据段，对数据段重排序成完整的文件，然后输出给服务端中需要使用该完整文件的应用软件。乱序重排模块B是数据缓冲区，大小一般为1MB到16MB，优先值为2MB。
传统的基于QUIC协议的多路径传输方法首先使用握手模块进行握手，之后发送方(既可以是客户端也可以是服务端)使用数据发送模块发送文件，接收方(既可以是客户端也可以是服务端)使用接收模块接收发送方发送模块发出的数据报文，经乱序重排模块重排后得到完整的文件。方法如下:
第一步，客户端的握手模块A与服务器的握手模块B进行通信，尝试建立多路径QUIC会话，完成握手：
1.1客户端的握手模块A向服务器的握手模块B发送探测报文。
1.2服务端的握手模块B从客户端的握手模块A接收探测报文。
1.3服务端的握手模块B识别探测报文中的信息，若探测报文中客户端QUIC协议版本号与服务端的QUIC协议版本号一致，则生成成功响应报文(成功响应报文包含了握手成功后建立的路径信息，以及双方加解密数据使用的统一密钥)和会话信息B(内容和成功响应报文相同)，向客户端的握手模块A发送成功响应报文，同时将建立的会话信息B中的路径信息发送给数据发送模块B的调度模块B，将密钥信息发送给数据加密模块B和接收模块B，转步骤1.4。否则，生成失败响应报文(包含握手失败的错误代码)并向客户端的握手模块A发送失败响应报文，转步骤1.6。
1.4客户端的握手模块A接收服务端握手模块B发出的成功响应报文，提取其中的密钥信息发送给数据加密模块A、接收模块A，并将路径信息发送给调度模块A，握手完成，转1.5。
1.5一旦握手完成，进入数据传输阶段，将发送数据报文的一端定义为发送端，将接收数据的一端定义为接收端。客户端既可以作为发送方，也可以是接收方；服务端既可以作为发送方，也可以是接收方；如果客户端为发送方，服务端为接收方，则客户端的数据发送模块A定义为发送方的数据发送模块、数据流模块A定义为发送方的数据流模块、数据加密模块A定义为发送方的数据加密模块、调度模块A定义为发送方的调度模块。服务端的接收模块B定义为接收方的接收模块B、乱序重排模块B定义为接收方的乱序重排模块。假设客户端为发送方，服务端为接收方。发送方转第二步发送报文，同时接收方转第三步接收报文。
1.6客户端的握手模块A接收服务端失败响应报文，转步骤1.1。
第二步，发送方向接收方传输数据，方法是：
2.1发送方的数据发送模块从发送方的握手模块获取会话信息A；
2.2应用软件获取需要发送的文件后，将该文件传递到发送端的数据流模块；
2.3发送方的数据流模块对将要发送的文件生成对应的一个数据流，并将该文件切割成N个属于该数据流的数据段，并按序为数据段标记序号，将切割后的N个数据段发送到发送方的数据加密模块。
2.3发送方的数据加密模块使用会话信息A中的密钥将从发送方的数据流模块接收的N个数据段加密，并封装成N个数据报文，将N个数据报文输出到发送方的调度模块。
2.4令数据报文序号n＝1；
2.5.发送方的调度模块A使用调度算法(如ECF(Earliest Completion First)调度算法)根据路径信息在多路径中选择一条路径将第n个数据报文发出，若未有空闲的路径，则转2.5等待空闲路径；若有合适路径，转2.6；
2.6发送方的调度模块A通过选择的空闲路径将第n个数据报文发出，令n＝n+1，如果n≤N，转2.5，。如果n>N，说明该数据流的所有数据段发送完毕，转2.2等待应用发送下一个文件(数据流)。
第三步：接收方接收发送方发出的数据报文，对其进行解析，方法是：
3.1令i＝0，一共需要接收N个数据报文；
3.2服务端的接收模块B从路径信息中的多条路径等待从某条路径接收数据报文，未接收到数据报文，转3.2等待；若接收到数据报文，转3.3。
3.3令i＝i+1,服务端的接收模块B解封装收到的第i个数据报文，取出数据段，使用会话信息B中的密钥对该数据段进行解密。若i<N，转3.2等待接收后续的报文。若i≥N，则将N个数据段输出到乱序重排模块，转3.4；
3.4接收方的乱序重排模块根据数据段的序号对N个数据段进行重排序，得到完整的接收的文件，交付给需要用该文件的应用软件，转3.1，等待接收下一个文件的报文(数据流)。
传统的基于QUIC协议的多路径传输方法使用多条路径发送数据报文很难达到理想的聚合效果，比如1Mbps的一条路径加上另一条2Mbps传输速率的路径难以聚合成3Mbps，因为在发送方发送数据报文的整个过程中，会受到图1中接收方的乱序重排模块的数据报文缓冲区大小的限制(一般为2MB)，以防止短时间内发送过多的数据报文导致接收方乱序重排模块数据报文缓冲区不够容纳过多的数据报文，导致数据报文被丢弃。
与此同时，由于不同路径具有不同的特性(延迟、丢包率、带宽)，接收方的乱序重排模块的数据报文缓冲区经常会产生空缺，接收方必须等待空缺的数据报文到达。产生空缺的主要原因是不同路径的延迟不同。比如，在具有较小延迟的路径上发送的数据报文会较早到达，然后等待经较大延迟路径发送的数据报文(即空缺)。一旦空缺产生，较早到达的数据报文无法交付给应用层。然而接收方的缓冲区大小是有限的，已经接收到的数据报文在等待空缺数据报文时占据了已有缓存空间，没有更多的空间继续接收新的数据报文，这一现象称为队首阻塞问题(HeadofLineBlocking)，队首阻塞问题会导致多路径QUIC的聚合能力下降，无法完全发挥多条路径的传输能力。
因此，发送方的调度模块采用调度算法将数据报文调度到多条路径上，减少队首阻塞的发生以提高多路径的聚合效果，使得传输内容更快在接收方被接收。其中典型的调度算法包括RR(RoundRobin)算法，该算法将报文以循环的方式平均调度到每一条路径上；Raiciu等人提出的最小往返延迟调度算法minRTT(C.Raiciu,C.Paasch,etal.How hardcan it be？designing and implementing a deployable multipath TCP[C]//9thUSENIX symposium on networked systems design and implementation.2012:399–412.译为：设计并部署一种多路径TCP的可能性)，将数据报文优先调度在具有最小往返时间延迟的路径上；Ferlin等人提出了基于阻塞估计的调度算法BLEST(Ferlin S,MehaniO,et al.BLEST:Blocking estimation-based MPTCP scheduler for heterogeneousnetworks[C]//2016IFIP networking conference(IFIP networking)andworkshops.IEEE,2016:431-439.译为：基于阻塞估计的异构网络MPTCP调度策略)，通过估计慢路上发送的数据报文是否会造成接收方阻塞，决定是否将数据报文调度在慢路上；Lim等人提出了最早完成时间优先算法ECF(Lim Y,Nahum E M,Towsley D,et al.ECF:AnMPTCPpath scheduler to manage heterogeneous paths[C]//Proceedings of the 13thinternational conference on emerging networking experiments andtechnologies.2017:147-159.译为：支持异构多路径的MPTCP调度方法)，通过计算慢路完成传输报文的时间是否会缩短整体的传输时间决定是否将报文在慢路上传输。
综上所述，当前的多路径QUIC存在两方面问题：
1)缺失不可靠的传输模式。
传统的基于QUIC协议的多路径传输方法只支持使用数据流(Stream)发送数据，数据流的特点是可靠的传输模式，即在承载数据流数据的某一个数据报文丢失后，发送方将重传该数据报文，重传的过程会带来额外的延迟，一些对延迟敏感的应用无法容忍。尽管单路径QUIC协议已经支持使用不可靠传输，但在多路径QUIC中难以适用，其原因如下：
a.传统的单路径QUIC的不可靠传输机制由应用将需要发送的具有交付时间的数据单元拆分成数据报文，使用不可靠传输机制发送后在接收方由应用将数据报文重组，是一种对应用不透明的不可靠传输模式，会为应用带来额外的开销。
b.使用传统的单路径QUIC的不可靠传输模式，多路径QUIC难以感知需要发送数据单元的整体大小，因此难以根据各条路径的状态信息在多条路径上分配数据报文，减少数据单元的交付时间，以达到及时交付的目的。
2)报文调度策略不能够适应不可靠的传输模式。
上述发送方的调度模块采用的调度算法是针对可靠传输数据流的队首阻塞问题设计的报文调度策略。为多路径QUIC引入不可靠传输模式后，传统的调度算法难以有效工作。其原因如下：
a.为多路径QUIC设计的不可靠传输模式传输数据单元时，具有明确的数据量大小和交付截止时间，前文所提到的调度算法并未考虑这些信息。
b.不可靠传输的调度策略应当计算在交付截止时间内是否能够完成该数据单元的交付。如果不能按时交付仍然传输该数据单元，一方面会造成网络资源的浪费，另一方面会影响后续数据单元的顺利交付。
c.不可靠的调度方法解决的问题不再是接收方的队首阻塞问题，而是数据单元在多条路径上的数据报文分配问题，以最大化网络带宽资源的利用，因为不可靠传输并不会受到接收方接收缓存大小的限制。因此将不可靠传输和多路径QUIC结合时，如何协调可靠数据报文和不可靠数据报文的调度是未解决的。
发明内容
本发明要解决的技术问题一是：单路径QUIC的不可靠传输模式对应用不透明，一方面为应用带来了额外的开销；另一方面多路径QUIC使用此模式难以通过在多路上调整数据单元的数据报文分配比例以减小整体交付时间。问题二是：传统的数据报文调度策略为可靠传输设计，其目的是为了减小接收方的队首阻塞以提高多路聚合效率，不适用于不可靠的传输模式。
本发明的技术方案是：一、为多路径QUIC协议设计一种对应用透明的数据报机制来发送对交付时间敏感的数据单元。二、为不可靠传输设计一种数据报文分配模块，以数据报为基本单位，综合考虑数据报传输数据单元的大小、交付截止时间、各条路径的带宽和延迟来决定在各条路径上分配数据段的比例。
本发明包括以下步骤：
第一步：构建基于多路径QUIC协议的部分可靠传输系统，方法是：
基于传统的基于QUIC协议的多路径传输架构，构建基于多路径QUIC协议的部分可靠传输系统，除了原有的数据流模块、数据加密模块和调度模块之外，在数据发送模块中添加数据报模块、数据报主动丢弃模块、数据报分配模块。即在数据发送模块A中添加数据报模块A、数据报主动丢弃模块A、数据报分配模块A；在数据发送模块B中添加数据报模块B、数据报主动丢弃模块B、数据报分配模块B；
客户端的握手模块A与服务端的握手模块B、客户端的数据发送模块A相连。客户端的握手模块A向服务端的握手模块B发送探测报文，探测报文包含客户端的QUIC协议版本号、密钥信息、客户端的端口信息。客户端的握手模块A还从服务端的握手模块B接收成功响应报文或失败响应报文。如果接收的是成功响应报文，会话建立，生成会话信息A，客户端的握手模块A将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，握手模块A同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A；如果是失败响应报文，则建立会话失败，失败响应报文包含的信息为握手失败的错误代码。
服务端的握手模块B与客户端的握手模块A、服务端的数据发送模块B相连。服务端的握手模块B收到客户端握手模块A的探测报文，根据其中的客户端QUIC协议版本号决定响应报文的类型。如果客户端QUIC协议版本号与服务端的QUIC协议版本号一致，则握手模块B根据探测报文中的客户端的端口信息和本服务端的端口数生成路径信息，根据探测报文中密钥信息生成加解密数据的密钥，填入成功响应报文，发送到客户端的握手模块A。如果客户端的QUIC协议版本号与服务端的所使用的QUIC协议版本号不一致，则握手模块B将错误代码填入失败响应报文，发送到客户端的握手模块A。若握手模块B发送的是成功响应报文，则生成会话信息B，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，会话信息B包含的内容和成功响应报文相同，路径信息中包含了所有可以发送数据报文的路径以用各条路径的往返延迟RTT和各条路径的拥塞窗口CWND，调度模块B选择其中的路径进行数据报文调度，密钥用于数据加解密模块B对数据进行加解密、接收模块B进行解密。
客户端的数据报模块A与客户端应用、客户端的数据报主动丢弃模块A相连，接收来自客户端应用要发送的数据单元和交付截止时间，该数据单元是应用发送的一个具有交付截止时间消息体，数据量通常比较小，为了与可靠传输区别，称为数据单元。数据报模块A根据数据单元生成数据报，然后将数据报和其交付截止时间(等于数据单元的交付截止时间)传输给客户端的数据报主动丢弃模块A。
服务端的数据报模块B与服务端应用、服务端的数据报主动丢弃模块B相连，接收来自服务端应用要发送的数据单元和交付截止时间，数据报模块B根据数据单元生成数据报，然后将数据报和其交付截止时间传输给服务端的数据报主动丢弃模块B。
客户端的数据报主动丢弃模块A与客户端的数据报模块A、客户端的数据报分配模块A相连，接收来自客户端数据报模块A的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态(该网络状态由调度模块A根据以往在每一条路径上发送的数据报文统计得到，包括每条路径的往返的时间延迟、带宽等信息)计算是否能够在交付截止时间之前交付到服务端。若能够交付，将该数据报输出到客户端的数据报分配模块A；若不能，则主动丢弃该数据报。
服务端的数据报主动丢弃模块B与服务端的数据报模块B、服务端的数据报分配模块B相连，接收来自服务端数据报模块B的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态计算是否能够在交付截止时间之前交付到客户端。若能够交付，将该数据报输出到服务端的数据报分配模块B；若不能，则主动丢弃该数据报。
客户端的数据报分配模块A与客户端的数据报主动丢弃模块A、客户端的调度模块A、客户端的数据加密模块A相连，将从客户端的数据报主动丢弃模块A接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例。并将该数据报在各条路径上分配的比例信息输出到客户端的调度模块A，将切割后的数据段输出到客户端的数据加密模块A。
服务端的数据报分配模块B与服务端的数据报主动丢弃模块B、服务端的调度模块B、服务端的数据加密模块B相连，将从服务端的数据报主动丢弃模块B接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例。并将该数据报在各条路径上分配的比例信息输出到服务端的调度模块B，将切割后的数据段输出到服务端的数据加密模块B。
客户端的数据流模块A与数据加密模块A相连，用于发送客户端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块A。
服务端的数据流模块B与数据加密模块B相连，用于发送服务端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块B。
客户端的数据加密模块A与客户端的数据报分配模块A、客户端的数据流模块A、客户端的调度模块A相连，接收客户端的数据流模块A或者客户端的数据报分配模块A发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块A。
服务端的数据加密模块B与服务端的数据报分配模块B、服务端的数据流模块B、服务端的调度模块B相连，接收服务端的数据流模块B或者服务端端的数据报分配模块B发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块B。
客户端的调度模块A与客户端的数据加密模块A、客户端的数据报分配模块A、服务端的接收模块B相连，接收来自客户端的数据加密模块A的数据报文，从客户端的数据报分配模块A接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自客户端的数据报分配模块A，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到服务端的接收模块B，然后将该路径上分配的比例减1。若该数据报文的数据来自客户端的数据流模块A，则使用调度算法(可以是背景技术的4种调度算法RR、ECF、BLEST、minRTT的任意一种)将该数据报文发送到服务端的接收模块B。
服务端的调度模块B与服务端的数据加密模块B、服务端的数据报分配模块B、客户端的接收模块A相连，接收来自服务端的数据加密模块B的数据报文，从服务端的数据报分配模块B接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自服务端的数据报分配模块B，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到客户端的接收模块A，然后将该路径上分配的比例减1。若该数据报文的数据来自服务端的数据流模块B，则使用调度算法(与客户端的调度模块A的调度算法相同)将该数据报文发送到服务端的接收模块B。
客户端的接收模块A与服务端的调度模块B、客户端的乱序重排模块A相连，从服务端的调度模块B接收其发出的数据报文，将数据报文解封装，取出数据段，使用密钥解密后输出到客户端的乱序重排模块A。
服务端的接收模块B与客户端的调度模块A、服务端的乱序重排模块B相连，从客户端的调度模块A接收其发出的数据报文，将数据报文解封装，取出数据段，使用密钥解密后输出到服务端的乱序重排模块B。
客户端的乱序重排模块A与客户端的接收模块A、客户端的应用软件相连，从客户端的接收模块A接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给客户端的应用软件。
服务端的乱序重排模块B与服务端的接收模块B、服务端的应用软件相连，从服务端接收模块B接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给服务端的应用软件。
第二步，基于多路径QUIC的部分可靠传输系统的客户端的握手模块A与服务器的握手模块B进行通信，建立多路径QUIC会话，完成握手：
2.1客户端的握手模块A向服务器的握手模块B发送探测报文。
2.2服务端的握手模块B从客户端的握手模块A接收探测报文。
2.3服务端的握手模块B识别探测报文中的信息，若探测报文中QUIC协议版本号与服务端的QUIC协议版本号一致，生成成功响应报文(成功响应报文包含了握手成功后建立的路径信息，以及双方加解密数据使用的统一密钥)和会话信息B(内容和成功响应报文相同)，向客户端的握手模块A发送成功响应报文，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，转步骤2.4。否则，生成失败响应报文(包含握手失败的错误代码)并向客户端的握手模块A发送失败响应报文，转步骤2.6。
2.4客户端的握手模块A接收服务端握手模块B发出的成功响应报文，提取其中的密钥和路径信息作为会话信息A发送给数据发送模块A，将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A。
2.5一旦握手完成，则进入数据传输阶段，将发送数据报文的一端定义为发送方，将接收数据的一端定义为接收方。客户端既可以作为发送方，也可以是接收方；服务器既可以作为发送方，也可以是接收方；为了描述方便，令客户端为发送方，服务端为接收方，则客户端的数据发送模块A定义为发送方的数据发送模块、数据流模块A定义为发送方的数据流模块、数据加密模块A定义为发送方的数据加密模块、调度模块A定义为发送方的调度模块、数据报模块A定义为发送方的数据报模块、数据报主动丢弃模块A定义为发送方的数据报主动丢弃模块、数据报分配模块A定义为发送方的数据报分配模块。服务端的接收模块B定义为接收方的接收模块B、乱序重排模块B定义为接收方的乱序重排模块。发送方转第三步发送报文，同时接收方转第四步接收报文(即第三步和第四步并行执行)。
2.6客户端的握手模块A接收服务端失败响应报文，转步骤2.1。
第三步，发送方向接收方传输数据，方法是：
3.1文件或数据单元发送由发送方的应用主动发起，发送方的数据发送模块(即客户端的数据发送模块A)从应用接收需要发送的文件或者数据单元及其交付截止时间，如果是文件则将该文件传输到发送方的数据流模块(即客户端的数据数据流模块A)，转步骤3.2；若是数据单元及其交付截止时间，则将数据单元及其交付截止时间传输到发送方的数据报模块(即客户端的数据报模块A)，转步骤3.3。
3.2客户端的数据流模块A发送文件，方法是：
3.2.1客户端的数据流模块A为将要发送的文件生成对应的一个数据流，并将该文件切割成N个属于该数据流的数据段，将切割后的N个数据段按照顺序依次发送到客户端的数据加密模块A。
3.2.2客户端的数据加密模块A对从客户端数据流模块A接收的N个数据段使用密钥将数据加密，并封装成N个数据报文。
3.2.3令变量n＝1；
3.2.4客户端数据加密模块A从N个数据报文取出第n个输出到客户端的调度模块A。
3.2.5客户端的调度模块A使用调度算法(可以是背景技术的4种调度算法RR、ECF、BLEST、minRTT的任意一种)根据路径信息在多路径中选择一条可用路径(这四种调度算法均选出唯一一条路径)，若没有可用的路径，则转3.2.5等待；若存在可用的路径，转3.2.6；
3.2.6将第n个数据报文从3.2.5选出的路径发出，令n＝n+1，如果n≤N，转3.2.4。如果n>N，该数据流对应的所有数据报文发送完毕，转3.1等待发送方应用发送下一个文件。
3.3客户端向数据报模块A发送数据单元及其交付截止时间，方法是：
3.3.1客户端的数据报模块A对数据单元生成一个对应的数据报block，并将block及其交付截止时间Deafline发送到客户端的数据报主动丢弃模块A。
3.3.2客户端的数据报主动丢弃模块A首先判断数据报block能否在交付截止时间Deadline前发送到服务端，方法是：
3.3.2.1数据报主动丢弃模块A计算数据报包含的数据段的数量num，使用公式一计算：
其中，DataSize为block的数据量大小(单位为字节)，MSS为数据报的一个数据段的大小，为1220字节。
3.3.2.2假设一共存在D条路径，D为正整数，数据报主动丢弃模块A计算一条路径每秒能够传输数据段的数量，其中第i条路径每秒能够传输数据段的数量ppsi按公式二计算：
其中，RTTi是第i条路径的往返延迟RTT(Round-Trip Time)，CWNDi是第i条路径的拥塞窗口CWND(CongestionWindow)，这两个值从路径信息获取。
3.3.2.3数据报主动丢弃模块A将不能用于发送数据段的路径排除，方法是判断公式三是否成立：
表示在第k条路径上发送的数据段到达接收方需要的时间，若公式三成立，说明第k条路径上发送的数据段到达接收方需要的时间大于Deadline，则将第k条路径排除。按公式三排除发送数据段会在Deadline之后到达的路径，剩余的m条路径可以用于发送数据段，m＝D-按公式三排除掉的路径数，令剩余的m条路径称为有效路径，令m条有效路径构成的集合为有效路径集合S。
3.3.2.4数据报主动丢弃模块A根据公式四是否成立判断剩下的m条路径能否在Deadline内将该数据报的num个数据段发送到服务端，
公式四左侧表示m条路径能够在Deadline时间内发送的数据段的数量。若公式四成立，即左侧小于右侧，说明不能在Deadline内将该数据报的num个数据段发送到服务端，数据报主动丢弃模块A将该数据报丢弃，转3.1继续等待应用发送下一个数据单元；若公式四不成立，说明能在Deadline内将该数据报的num个数据段发送到服务端，将该数据报交付客户端数据报分配模块A，转3.3.3。
3.3.3客户端的数据报分配模块A将待发送的数据报切割成num个数据段，按数据段顺序标记序号，并决定数据报包含的数据段在各条路径上分配的比例，方法是：
3.3.3.1数据报分配模块A使用公式五计算数据报最短交付时间MinDeliverTime：
xii代表在第ii条路径上分配的数据段比例，xii在0到1之间，且满足：
公式五和公式六构成m个约束公式，利用Water-filling算法(Water-Filling算法见文献M.～Schwartz,Broadband integrated networks[M],1996：宽带集成网络437页Water-Filling算法)求得在m条有效路径上分配的数据段的比例集合X，X＝[x1,x2,…,xii,…,xm]。
3.3.3.2数据报分配模块A将数据段在m条有效路径上分配的比例信息X输出到调度模块A，即告知第ii条路径需要发送cntii个数据报文，cntii为第ii条路径上分配的数据报文数量,cntii＝xii×num；同时数据报分配模块A将数据段按序编号，将按序编号后的num个数据段输出到数据加密模块A。
3.3.4客户端的数据加密模块A使用会话信息A中的密钥结合传输层安全协议1.3版(即TLS1.3，传输层安全协议1.3版见文献Rescorla E.The transport layer security(TLS)protocol version 1.3[R].2018.：传输层安全协议1.3版本)对接收的按序编号后的num个数据段加密。将加密后的num个数据段打包成数据报文，按序依次发送给调度模块A。
3.3.5客户端的调度模块A向接收方的接收模块B按照每条路径上分配的报文数量发出数据报文，其中第ii条路径上分配的数据报文数为cntii，待发送的数据报文数量初始化为n＝num，其方法是：
3.3.5.1客户端的调度模块A监控有效路径集合S，若存在一条或多条有效路径，从有效路径中随机选择一条有效路径(令为第k条有效路径)将报文发出，第k条有效路径发出报文后，该路径所分配的数据报文数cntk＝cntk-1，1≤k≤m-1，若cntk为零，将第k条路径从有效路径集合S中删除。
3.3.5.2令剩余未发送的报文数为n＝n–1，若n为0，则该数据报的所有数据段全部被发出，转3.1，继续等待发送下一个数据单元或文件。若n值不为0，转3.3.4继续发送下一个数据报文；
第四步：接收方接收数据报文，对数据报文进行处理并重组成完整的文件或数据单元，方法是：4.1服务端的接收模块B经路径信息中的所有路径接收数据报文，解封装取出数据段，使用密钥对数据段解密，将数据段交付给乱序重排模块B，若数据段属于数据流，转4.2；若数据段属于数据报，转4.3。
4.2乱序重排模块B接收数据段，根据数据段的序号重排发送方数据流模块A传输的N个数据段，方法是：
4.2.1令n＝1，一共需要接收N个数据报文；
4.2.2乱序重排模块B从接收模块B接收数据段，若未接收到数据段，转4.2.2等待，若接收到数据段，转4.2.3。
4.2.3令n＝n+1，若n≤N，转4.2.2等待接收后续的报文；若n>N，转4.2.4。
4.2.4乱序重排模块B根据数据段的序号对N个数据段进行重排序，将排序得到的文件交付应用，转4.1等待接收下一个文件的数据报文。
4.3乱序重排模块B根据数据段的序号重排接收到的num个数据段，num个数据段的交付截止时间均为Deadline，方法是：
4.3.1令j＝1，一共需要接收num个数据报文；
4.3.2乱序重排模块B从接收模块B接收第j个数据段，若未接收到数据段，转4.3.2等待，若接收到数据段，转4.3.3；
4.3.3令j＝j+1,若j≤num且当前时间未超过Deadline，转4.3.2等待接收后续的数据段；若j≤num且当前时间超过Deadline，转4.3.4；若j≥num，转4.3.5；
4.3.4丢弃已收到的j个数据段(超过Deadline，说明收到的都是无效的报文，直接丢弃)，转4.1，等待接收下一个数据报文；
4.3.5乱序重排模块B根据数据段的序号对num个数据段进行重排序，得到完整的接收的数据单元，交付给需要用该数据单元的应用软件，转4.1，等待接收下一个数据报文。
综上所述，采用本发明可以达到以下技术效果：
1.本发明第1步设计了一种基于多路径QUIC协议的部分可靠传输系统，能够在同一个网络会话中同时传输可靠的数据流和不可靠的数据报，拓宽了多路径QUIC的适用场景。
2.本发明第3.3.2步在传输数据单元的过程中，综合考虑了数据单元的交付截止时间、各条路径的延迟和带宽信息，对不能够在交付截止时间内完成的数据单元主动丢弃，减少网络资源浪费。
3.在调度报文时，根据不同的报文类型，合理调度报文到多条有效路径：
如果是报文来自数据流，使用第3.2.5步调用现存的、为可靠传输模式设计的调度策略(如前文所述的minRTT、BLEST等)；如果报文来自数据报，使用第3.3.3步针对一个数据报对应的数据单元，综合考虑各条路径的延迟、带宽、数据单元的数据量大小以决定在各条路径上的报文分配比例，减小了数据报的交付时间。
附图说明
图1是传统的多路径传输系统逻辑架构图。
图2是本发明的第一步所构建的基于多路径QUIC协议的部分可靠传输系统逻辑结构图。
图3是本发明的总体流程图。
图4是使用本发明，可靠数据和不可靠数据同时传输时的数据单元成功交付率、系统有效吞吐率指标与传统的多路径QUIC协议的对比图。图4(a)表示使用本发明和传统的基于QUIC协议的多路径传输方法传输1800个数据单元，在交付截止时间内到达接收方的比例。图4(b)是使用本发明和传统的基于QUIC协议的多路径传输方法传输1800个数据单元和120份可靠数据，不同系统的有效吞吐量。
具体实施方式
下面结合附图对本发明进行详细说明。
图3是本发明的总体流程图，如图3所示，本发明包括以下步骤：
第一步：构建基于多路径QUIC协议的部分可靠传输系统，方法是：
基于图1所示的传统的基于QUIC协议的多路径传输架构，构建如图2所示的基于多路径QUIC协议的部分可靠传输系统，除了图1的数据流模块、数据加密模块和调度模块之外，在数据发送模块中添加数据报模块、数据报主动丢弃模块、数据报分配模块。即在数据发送模块A中添加数据报模块A、数据报主动丢弃模块A、数据报分配模块A；在数据发送模块B中添加数据报模块B、数据报主动丢弃模块B、数据报分配模块B；
客户端的握手模块A与服务端的握手模块B、客户端的数据发送模块A相连。客户端的握手模块A向服务端的握手模块B发送探测报文，探测报文包含客户端的QUIC协议版本号、密钥信息、客户端的端口信息。客户端的握手模块A还从服务端的握手模块B接收成功响应报文或失败响应报文。如果接收的是成功响应报文，会话建立，生成会话信息A，客户端的握手模块A将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，握手模块A同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A；如果是失败响应报文，则建立会话失败，失败响应报文包含的信息为握手失败的错误代码。
服务端的握手模块B与客户端的握手模块A、服务端的数据发送模块B相连。服务端的握手模块B收到客户端握手模块A的探测报文，根据其中的客户端QUIC协议版本号决定响应报文的类型。如果客户端QUIC协议版本号与服务端的QUIC协议版本号一致，则握手模块B根据探测报文中的客户端的端口信息和本服务端的端口数生成路径信息，根据探测报文中密钥信息生成加解密数据的密钥，填入成功响应报文，发送到客户端的握手模块A。如果客户端的QUIC协议版本号与服务端的所使用的QUIC协议版本号不一致，则握手模块B将错误代码填入失败响应报文，发送到客户端的握手模块A。若握手模块B发送的是成功响应报文，则生成会话信息B，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，会话信息B包含的内容和成功响应报文相同，路径信息中包含了所有可以发送数据报文的路径以用各条路径的往返延迟RTT和各条路径的拥塞窗口CWND，调度模块B选择其中的路径进行数据报文调度，密钥用于数据加解密模块B对数据进行加解密、接收模块B进行解密。
客户端的数据报模块A与客户端应用、客户端的数据报主动丢弃模块A相连，接收来自客户端应用要发送的数据单元和交付截止时间，该数据单元是应用发送的一个具有交付截止时间消息体，数据量通常比较小，为了与可靠传输区别，称为数据单元。数据报模块A根据数据单元生成数据报，然后将数据报和其交付截止时间(等于数据单元的交付截止时间)传输给客户端的数据报主动丢弃模块A。
服务端的数据报模块B与服务端应用、服务端的数据报主动丢弃模块B相连，接收来自服务端应用要发送的数据单元和交付截止时间，数据报模块B根据数据单元生成数据报，然后将数据报和其交付截止时间传输给服务端的数据报主动丢弃模块B。
客户端的数据报主动丢弃模块A与客户端的数据报模块A、客户端的数据报分配模块A相连，接收来自客户端数据报模块A的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态(该网络状态由调度模块A根据以往在每一条路径上发送的数据报文统计得到，包括每条路径的往返的时间延迟、带宽等信息)计算是否能够在交付截止时间之前交付到服务端。若能够交付，将该数据报输出到客户端的数据报分配模块A；若不能，则主动丢弃该数据报。
服务端的数据报主动丢弃模块B与服务端的数据报模块B、服务端的数据报分配模块B相连，接收来自服务端数据报模块B的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态计算是否能够在交付截止时间之前交付到客户端。若能够交付，将该数据报输出到服务端的数据报分配模块B；若不能，则主动丢弃该数据报。
客户端的数据报分配模块A与客户端的数据报主动丢弃模块A、客户端的调度模块A、客户端的数据加密模块A相连，将从客户端的数据报主动丢弃模块A接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例。并将该数据报在各条路径上分配的比例信息输出到客户端的调度模块A，将切割后的数据段输出到客户端的数据加密模块A。
服务端的数据报分配模块B与服务端的数据报主动丢弃模块B、服务端的调度模块B、服务端的数据加密模块B相连，将从服务端的数据报主动丢弃模块B接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例。并将该数据报在各条路径上分配的比例信息输出到服务端的调度模块B，将切割后的数据段输出到服务端的数据加密模块B。
客户端的数据流模块A与数据加密模块A相连，用于发送客户端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块A。
服务端的数据流模块B与数据加密模块B相连，用于发送服务端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块B。
客户端的数据加密模块A与客户端的数据报分配模块A、客户端的数据流模块A、客户端的调度模块A相连，接收客户端的数据流模块A或者客户端的数据报分配模块A发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块A。
服务端的数据加密模块B与服务端的数据报分配模块B、服务端的数据流模块B、服务端的调度模块B相连，接收服务端的数据流模块B或者服务端端的数据报分配模块B发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块B。
客户端的调度模块A与客户端的数据加密模块A、客户端的数据报分配模块A、服务端的接收模块B相连，接收来自客户端的数据加密模块A的数据报文，从客户端的数据报分配模块A接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自客户端的数据报分配模块A，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到服务端的接收模块B，然后将该路径上分配的比例减1。若该数据报文的数据来自客户端的数据流模块A，则使用调度算法(可以是背景技术的4种调度算法RR、ECF、BLEST、minRTT的任意一种)将该数据报文发送到服务端的接收模块B。
服务端的调度模块B与服务端的数据加密模块B、服务端的数据报分配模块B、客户端的接收模块A相连，接收来自服务端的数据加密模块B的数据报文，从服务端的数据报分配模块B接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自服务端的数据报分配模块B，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到客户端的接收模块A，然后将该路径上分配的比例减1。若该数据报文的数据来自服务端的数据流模块B，则使用调度算法(与客户端的调度模块A的调度算法相同)将该数据报文发送到服务端的接收模块B。
客户端的接收模块A与服务端的调度模块B、客户端的乱序重排模块A相连，从服务端的调度模块B接收其发出的数据报文，将数据报文解封装，取出数据段，使用密钥解密后输出到客户端的乱序重排模块A。
服务端的接收模块B与客户端的调度模块A、服务端的乱序重排模块B相连，从客户端的调度模块A接收其发出的数据报文，将数据报文解封装，取出数据段，使用密钥解密后输出到服务端的乱序重排模块B。
客户端的乱序重排模块A与客户端的接收模块A、客户端的应用软件相连，从客户端的接收模块A接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给客户端的应用软件。
服务端的乱序重排模块B与服务端的接收模块B、服务端的应用软件相连，从服务端接收模块B接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给服务端的应用软件。
第二步，基于多路径QUIC的部分可靠传输系统的客户端的握手模块A与服务器的握手模块B进行通信，建立多路径QUIC会话，完成握手：
2.1客户端的握手模块A向服务器的握手模块B发送探测报文。
2.2服务端的握手模块B从客户端的握手模块A接收探测报文。
2.3服务端的握手模块B识别探测报文中的信息，若探测报文中QUIC协议版本号与服务端的QUIC协议版本号一致，生成成功响应报文(成功响应报文包含了握手成功后建立的路径信息，以及双方加解密数据使用的统一密钥)和会话信息B(内容和成功响应报文相同)，向客户端的握手模块A发送成功响应报文，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，转步骤2.4。否则，生成失败响应报文(包含握手失败的错误代码)并向客户端的握手模块A发送失败响应报文，转步骤2.6。
2.4客户端的握手模块A接收服务端握手模块B发出的成功响应报文，提取其中的密钥和路径信息作为会话信息A发送给数据发送模块A，将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A。
2.5一旦握手完成，则进入数据传输阶段，将发送数据报文的一端定义为发送方，将接收数据的一端定义为接收方。客户端既可以作为发送方，也可以是接收方；服务器既可以作为发送方，也可以是接收方；为了描述方便，令客户端为发送方，服务端为接收方，则客户端的数据发送模块A定义为发送方的数据发送模块、数据流模块A定义为发送方的数据流模块、数据加密模块A定义为发送方的数据加密模块、调度模块A定义为发送方的调度模块、数据报模块A定义为发送方的数据报模块、数据报主动丢弃模块A定义为发送方的数据报主动丢弃模块、数据报分配模块A定义为发送方的数据报分配模块。服务端的接收模块B定义为接收方的接收模块B、乱序重排模块B定义为接收方的乱序重排模块。发送方转第三步发送报文，同时接收方转第四步接收报文(即第三步和第四步并行执行)。
2.6客户端的握手模块A接收服务端失败响应报文，转步骤2.1。
第三步，发送方向接收方传输数据，方法是：
3.1文件或数据单元发送由发送方的应用主动发起，发送方的数据发送模块(即客户端的数据发送模块A)从应用接收需要发送的文件或者数据单元及其交付截止时间，如果是文件则将该文件传输到发送方的数据流模块(即客户端的数据数据流模块A)，转步骤3.2；若是数据单元及其交付截止时间，则将数据单元及其交付截止时间传输到发送方的数据报模块(即客户端的数据报模块A)，转步骤3.3。
3.2客户端的数据流模块A发送文件，方法是：
3.2.1客户端的数据流模块A为将要发送的文件生成对应的一个数据流，并将该文件切割成N个属于该数据流的数据段，将切割后的N个数据段按照顺序依次发送到客户端的数据加密模块A。
3.2.2客户端的数据加密模块A对从客户端数据流模块A接收的N个数据段使用密钥将数据加密，并封装成N个数据报文。
3.2.3令变量n＝1；
3.2.4客户端数据加密模块A从N个数据报文取出第n个输出到客户端的调度模块A。
3.2.5客户端的调度模块A使用调度算法(可以是背景技术的4种调度算法RR、ECF、BLEST、minRTT的任意一种)根据路径信息在多路径中选择一条可用路径(这四种调度算法均选出唯一一条路径)，若没有可用的路径，则转3.2.5等待；若存在可用的路径，转3.2.6；
3.2.6将第n个数据报文从3.2.5选出的路径发出，令n＝n+1，如果n≤N，转3.2.4。如果n>N，该数据流对应的所有数据报文发送完毕，转3.1等待发送方应用发送下一个文件。
3.3客户端向数据报模块A发送数据单元及其交付截止时间，方法是：
3.3.1客户端的数据报模块A对数据单元生成一个对应的数据报block，并将block及其交付截止时间Deadline发送到客户端的数据报主动丢弃模块A。
3.3.2客户端的数据报主动丢弃模块A首先判断数据报block能否在交付截止时间Deadline前发送到服务端，方法是：
3.3.2.1数据报主动丢弃模块A计算数据报包含的数据段的数量num，使用公式一计算：
其中，DataSize为block的数据量大小(单位为字节)，MSS为数据报的一个数据段的大小，为1220字节。
3.3.2.2假设一共存在D条路径，D为正整数，数据报主动丢弃模块A计算一条路径每秒能够传输数据段的数量，其中第i条路径每秒能够传输数据段的数量ppsi按公式二计算：
其中，RTTi是第i条路径的往返延迟RTT(Round-Trip Time)，CWNDi是第i条路径的拥塞窗口CWND(CongestionWindow)，这两个值从路径信息获取。
3.3.2.3数据报主动丢弃模块A将不能用于发送数据段的路径排除，方法是判断公式三是否成立：
表示在第k条路径上发送的数据段到达接收方需要的时间，若公式三成立，说明第k条路径上发送的数据段到达接收方需要的时间大于Deadline，则将第k条路径排除。按公式三排除发送数据段会在Deadline之后到达的路径，剩余的m条路径可以用于发送数据段，m＝D-按公式三排除掉的路径数，令剩余的m条路径称为有效路径，令m条有效路径构成的集合为有效路径集合S。/>
3.3.2.4数据报主动丢弃模块A根据公式四是否成立判断剩下的m条路径能否在Deadline内将该数据报的num个数据段发送到服务端，
公式四左侧表示m条路径能够在Deadline时间内发送的数据段的数量。若公式四成立，说明不能在Deadline内将该数据报的num个数据段发送到服务端，数据报主动丢弃模块A将该数据报丢弃，转3.1继续等待应用发送下一个数据单元；若公式四不成立，说明数据报主动丢弃模块A能将数据报的num个数据段交付到数据报分配模块A，转3.3.3。
3.3.3客户端的数据报分配模块A将待发送的数据报切割成num个数据段，按数据段顺序标记序号，并决定数据报包含的数据段在各条路径上分配的比例，方法是：
3.3.3.1数据报分配模块A使用公式五计算数据报最短交付时间MinDeliverTime：
xii代表在第ii条路径上分配的数据段比例，xii在0到1之间，且满足：
公式五和公式六构成m个约束公式，利用Water-filling算法求得在m条有效路径上分配的数据段的比例集合X，X＝[x1,x2,…,xii,…,xm]。
3.3.3.2数据报分配模块A将数据段在m条有效路径上分配的比例信息X输出到调度模块A，即告知第ii条路径需要发送cntii个数据报文，cntii为第ii条路径上分配的数据报文数量,cntii＝xii×num；同时数据报分配模块A将数据段按序编号，将按序编号后的num个数据段输出到数据加密模块A。
3.3.4客户端的数据加密模块A使用会话信息A中的密钥结合传输层安全协议1.3版对接收的按序编号后的num个数据段加密。将加密后的num个数据段打包成数据报文，按序依次发送给调度模块A。
3.3.5客户端的调度模块A向接收方的接收模块B按照每条路径上分配的报文数量发出数据报文，其中第ii条路径上分配的数据报文数为cntii，待发送的数据报文数量初始化为n＝num，其方法是：
3.3.5.1客户端的调度模块A监控有效路径集合S，若存在一条或多条有效路径，从有效路径中随机选择一条有效路径(令为第k条有效路径)将报文发出，第k条有效路径发出报文后，该路径所分配的数据报文数cntk＝cntk-1，1≤k≤m-1，若cntk为零，将第k条路径从有效路径集合S中删除。
3.3.5.2令剩余未发送的报文数为n＝n–1，若n为0，则该数据报的所有数据段全部被发出，转3.1，继续等待发送下一个数据单元或文件。若n值不为0，转3.3.4继续发送下一个数据报文；
第四步：接收方接收数据报文，对数据报文进行处理并重组成完整的文件或数据单元，方法是：4.1服务端的接收模块B经路径信息中的所有路径接收数据报文，解封装取出数据段，使用密钥对数据段解密，将数据段交付给乱序重排模块B，若数据段属于数据流，转4.2；若数据段属于数据报，转4.3。
4.2乱序重排模块B接收数据段，根据数据段的序号重排发送方数据流模块A传输的N个数据段，方法是：
4.2.1令n＝1，一共需要接收N个数据报文；
4.2.2乱序重排模块B从接收模块B接收数据段，若未接收到数据段，转4.2.2等待，若接收到数据段，转4.2.3。
4.2.3令n＝n+1，若n≤N，转4.2.2等待接收后续的报文；若n>N，转4.2.4。
4.2.4乱序重排模块B根据数据段的序号对N个数据段进行重排序，将排序得到的文件交付应用，转4.1等待接收下一个文件的数据报文。
4.3乱序重排模块B根据数据段的序号重排接收到的num个数据段，num个数据段的交付截止时间均为Deadline，方法是：
4.3.1令j＝1，一共需要接收num个数据报文；
4.3.2乱序重排模块B从接收模块B接收第j个数据段，若未接收到数据段，转4.3.2等待，若接收到数据段，转4.3.3；
4.3.3令j＝j+1,若j≤num且当前时间未超过Deadline，转4.3.2等待接收后续的数据段；若j≤num且当前时间超过Deadline，转4.3.4；若j≥num，转4.3.5；
4.3.4丢弃已收到的j个数据段(超过deadline，说明收到的都是无效的报文，直接丢弃)，转4.1，等待接收下一个数据报文；
4.3.5乱序重排模块B根据数据段的序号对num个数据段进行重排序，得到完整的接收的数据单元，交付给需要用该数据单元的应用软件，转4.1，等待接收下一个数据报文。
本发明通过利用网络虚拟化软件Mininet2.3.0版本在Ubuntu系统16.04版本内搭建包含两条传输路径的实验环境来验证效果，在Mininet内构建虚拟客户端和虚拟服务器，服务器和客户端之间具有两条传输路径，两条传输路径具有的传输条件分别为：
路径一：2.7Mbps的传输速率,0.6％的丢包率,20ms的传输延迟。
路径二：2.4Mbps的传输速率,0.4％的丢包率,25ms的传输延迟。
其中，将本发明部署在虚拟客户端和虚拟服务器上，类似于图2，二者以点对点的方式传输数据。构造视频直播场景，视频直播利用本发明所构建的多路径传输方法做直播测试，验证实验效果，其中服务器发送数据，客户端接收数据。
以视频直播作为测试本发明的方式，视频直播包含了两部分内容：视频内容、参与观看用户的弹幕信息。其中以包含60秒、1800个图像帧的视频作为视频内容，该视频的平均比特率为5Mbps。该视频的每一个视频帧被视为一个数据单元，为了保证视频直播的实时性，要求应用将一个视频帧交付给本发明第一步构建的基于多路径QUIC协议的部分可靠传输系统后，发送方将视频帧在500ms内传输到接收方。文字内容是观看用户的弹幕信息，该部分使用可靠传输方式传输，该部分内容在视频直播期间一共随机传输120次，每次的弹幕内容大小为1024字节。
采用上述实验环境，模拟视频流直播传输，本发明和其他使用了RR调度算法、minRTT调度算法、BLEST调度算法、ECF调度算法的传统的基于QUIC协议的多路径传输方法作比较，统计作为数据单元的视频帧在交付时间内传输到接收方的数目，如图4(a)所示，本发明的传输数据单元成功交付率是87％，而使用了RR调度算法、minRTT调度算法、BLEST调度算法、ECF调度算法的传统的基于QUIC协议的多路径传输方法的传输数据单元成功交付率分别为52％、75％、78％、77％；本发明相比使用了RR调度算法、minRTT调度算法、BLEST调度算法、ECF调度算法的传统的基于QUIC协议的多路径传输方法在传输数据单元成功交付率上分别提高了约35、12、9、10个百分点。
另外，为了验证本发明的有效吞吐率(有效吞吐率为按时到达的视频帧的数据量大小与传输弹幕信息的数据量大小相加，然后除以直播播放时长)。如图4(b)所示，本发明的有效吞吐率是3.5Mbps，而使用了RR调度算法、minRTT调度算法、BLEST调度算法、ECF调度算法的传统的基于QUIC协议的多路径传输方法的有效吞吐率2.2Mbps、2.6Mbps、2.7Mbps、2.8Mbps；本发明相比使用了RR调度算法、minRTT调度算法、BLEST调度算法、ECF调度算法的传统的基于QUIC协议的多路径传输方法在传输数据的有效吞吐率上分别提升了约1.3、0.9、0.8、0.7Mbps。
以上对本发明所提供的一种基于QUIC协议的部分可靠多路径传输方法进行了详细介绍。本文对本发明的原理及实施方式进行了阐述，以上说明用于帮助理解本发明的核心思想。应当指出，对于本技术领域的普通研究人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (8)

1.一种基于QUIC协议的部分可靠多路径传输方法，基于QUIC协议的部分可靠多路径传输方法基于QUIC协议的多路径传输架构实现，基于QUIC协议的多路径传输架构由服务端、客户端构成，客户端上安装有握手模块A、数据发送模块A、接收模块A、乱序重排模块A；数据发送模块A包括数据流模块A、数据加密模块A、调度模块A；服务端上安装有握手模块B、数据发送模块B、接收模块B、乱序重排模块B；数据发送模块B包括数据流模块B、数据加密模块B、调度模块B；
客户端的握手模块A与服务端的握手模块B、客户端的数据发送模块A相连；客户端的握手模块A向服务端的握手模块B发送探测报文，探测报文包含客户端的QUIC协议版本号、密钥信息、客户端的端口信息；客户端的握手模块A还从服务端的握手模块B接收成功响应报文或失败响应报文；如果接收的是成功响应报文，会话建立，生成会话信息A，客户端的握手模块A将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，握手模块A同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A；如果是失败响应报文，则建立会话失败，失败响应报文包含的信息为握手失败的错误代码；
服务端的握手模块B与客户端的握手模块A、服务端的数据发送模块B相连；服务端的握手模块B收到客户端握手模块A的探测报文，根据其中的客户端QUIC协议版本号决定响应报文的类型；如果客户端QUIC协议版本号与服务端的QUIC协议版本号一致，则握手模块B根据探测报文中的客户端的端口信息和本服务端的端口数生成路径信息，根据探测报文中密钥信息生成加解密数据的密钥，填入成功响应报文，发送到客户端的握手模块A；如果客户端的QUIC协议版本号与服务端的所使用的QUIC协议版本号不一致，则握手模块B将错误代码填入失败响应报文，发送到客户端的握手模块A；若握手模块B发送的是成功响应报文，则生成会话信息B，握手模块B将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，会话信息B包含的内容和成功响应报文相同，路径信息中包含了所有可以发送数据报文的路径以用各条路径的往返延迟RTT和各条路径的拥塞窗口CWND，调度模块B选择其中的路径进行数据报文调度，密钥用于数据加解密模块B对数据进行加解密、接收模块B进行解密；
客户端的数据流模块A与数据加密模块A相连，用于发送客户端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块A；
服务端的数据流模块B与数据加密模块B相连，用于发送服务端的文件，每发送一个文件，生成一个数据流，并将数据流的数据切割成若干个数据段输出到数据加密模块B；
客户端的接收模块A与服务端的调度模块B、客户端的乱序重排模块A相连，客户端的接收模块A从服务端的调度模块B接收数据报文，从握手模块A接收会话信息A中的密钥，将数据报文解封装，取出数据段，使用密钥解密后输出到乱序重排模块A；
服务端的接收模块B与客户端的调度模块A、服务端的乱序重排模块B相连，服务端的接收模块B从客户端调度模块A接收数据报文，从握手模块B接收会话信息B中的密钥，将数据报文解封装，取出数据段，使用密钥解密后输出到乱序重排模块B；
其特征在于包括以下步骤：
第一步：构建基于多路径QUIC协议的部分可靠传输系统，方法是：
在数据发送模块A中添加数据报模块A、数据报主动丢弃模块A、数据报分配模块A；在数据发送模块B中添加数据报模块B、数据报主动丢弃模块B、数据报分配模块B，构成基于多路径QUIC协议的部分可靠传输系统；
客户端的数据报模块A与客户端应用、客户端的数据报主动丢弃模块A相连，接收来自客户端应用要发送的数据单元和交付截止时间，该数据单元是应用发送的一个具有交付截止时间消息体；数据报模块A根据数据单元生成数据报，然后将数据报和数据报交付截止时间传输给客户端的数据报主动丢弃模块A；所述数据报交付截止时间等于数据单元的交付截止时间；
服务端的数据报模块B与服务端应用、服务端的数据报主动丢弃模块B相连，接收来自服务端应用要发送的数据单元和交付截止时间，数据报模块B根据数据单元生成数据报，然后将数据报和其交付截止时间传输给服务端的数据报主动丢弃模块B；
客户端的数据报主动丢弃模块A与客户端的数据报模块A、客户端的数据报分配模块A相连，接收来自客户端数据报模块A的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态计算是否能够在交付截止时间之前交付到服务端；若能够交付，将该数据报输出到客户端的数据报分配模块A；若不能，则主动丢弃该数据报；所述网络状态由调度模块A根据以往在每一条路径上发送的数据报文统计得到，包括每条路径的往返的时间延迟、带宽；
服务端的数据报主动丢弃模块B与服务端的数据报模块B、服务端的数据报分配模块B相连，接收来自服务端数据报模块B的数据报，根据该数据报包含的数据量大小、交付截止时间、所有路径的网络状态计算是否能够在交付截止时间之前交付到客户端；若能够交付，将该数据报输出到服务端的数据报分配模块B；若不能，则主动丢弃该数据报；
客户端的数据报分配模块A与客户端的数据报主动丢弃模块A、客户端的调度模块A、客户端的数据加密模块A相连，将从客户端的数据报主动丢弃模块A接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例；并将该数据报在各条路径上分配的比例信息输出到客户端的调度模块A，将切割后的数据段输出到客户端的数据加密模块A；
服务端的数据报分配模块B与服务端的数据报主动丢弃模块B、服务端的调度模块B、服务端的数据加密模块B相连，将从服务端的数据报主动丢弃模块B接收的数据报切分成若干个数据段，根据所有路径的网络状态，决定各个路径上分配的数据段的比例；并将该数据报在各条路径上分配的比例信息输出到服务端的调度模块B，将切割后的数据段输出到服务端的数据加密模块B；
客户端的数据加密模块A与客户端的数据报分配模块A、客户端的数据流模块A、客户端的调度模块A相连，接收客户端的数据流模块A或者客户端的数据报分配模块A发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块A；
服务端的数据加密模块B与服务端的数据报分配模块B、服务端的数据流模块B、服务端的调度模块B相连，接收服务端的数据流模块B或者服务端端的数据报分配模块B发出的切割后的数据段，使用密钥对切割后的数据段加密，将切割后的数据段封装成数据报文输出到调度模块B；
客户端的调度模块A与客户端的数据加密模块A、客户端的数据报分配模块A、服务端的接收模块B相连，接收来自客户端的数据加密模块A的数据报文，从客户端的数据报分配模块A接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自客户端的数据报分配模块A，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到服务端的接收模块B，然后将该路径上分配的比例减1；若该数据报文的数据来自客户端的数据流模块A，则使用调度算法将该数据报文发送到服务端的接收模块B；
服务端的调度模块B与服务端的数据加密模块B、服务端的数据报分配模块B、客户端的接收模块A相连，接收来自服务端的数据加密模块B的数据报文，从服务端的数据报分配模块B接收数据报在各条路径上分配的比例信息，若该数据报文的数据来自服务端的数据报分配模块B，则按照该数据报在各条路径上分配的比例信息选取一条未阻塞且比例不为零的路径发送该数据报文到客户端的接收模块A，然后将该路径上分配的比例减1；若该数据报文的数据来自服务端的数据流模块B，则使用与客户端的调度模块A相同的调度算法将该数据报文发送到服务端的接收模块B；
客户端的乱序重排模块A与客户端的接收模块A、客户端的应用软件相连，从客户端的接收模块A接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给客户端的应用软件；
服务端的乱序重排模块B与服务端的接收模块B、服务端的应用软件相连，从服务端接收模块B接收数据段，将数据段重排序成完整的文件或数据单元，然后输出给服务端的应用软件；
第二步，基于多路径QUIC的部分可靠传输系统的客户端的握手模块A与服务器的握手模块B进行通信，建立多路径QUIC会话，完成握手：
2.1客户端的握手模块A向服务器的握手模块B发送探测报文；
2.2服务端的握手模块B从客户端的握手模块A接收探测报文；
2.3服务端的握手模块B识别探测报文中的信息，若探测报文中QUIC协议版本号与服务端的QUIC协议版本号一致，生成成功响应报文和会话信息B，所述成功响应报文包含握手成功后建立的路径信息，以及双方加解密数据使用的统一密钥；所述会话信息B内容和成功响应报文相同；握手模块B向客户端的握手模块A发送成功响应报文，并将会话信息B的握手成功后建立的路径信息发送到数据发送模块B的调度模块B，握手模块B同时将会话信息B的密钥发送给接收模块B和数据发送模块B的数据加密模块B，转步骤2.4；否则，生成包含握手失败的错误代码的失败响应报文并向客户端的握手模块A发送失败响应报文，转步骤2.6；
2.4客户端的握手模块A接收服务端握手模块B发出的成功响应报文，提取其中的密钥和路径信息作为会话信息A发送给数据发送模块A，将会话信息A中握手成功后建立的路径信息发送给数据发送模块A的调度模块A，同时将会话信息A中的密钥发送给接收模块A和数据发送模块A的数据加密模块A；
2.5握手完成，进入数据传输阶段，将发送数据报文的一端定义为发送方，将接收数据的一端定义为接收方；令客户端为发送方，服务端为接收方，发送方转第三步发送报文，同时接收方转第四步接收报文；
2.6客户端的握手模块A接收服务端的失败响应报文，转步骤2.1；
第三步，发送方向接收方传输数据，方法是：
3.1客户端的数据发送模块A从应用接收需要发送的文件或者数据单元及其交付截止时间，如果是文件则将该文件传输到客户端的数据数据流模块A，转步骤3.2；若是数据单元及其交付截止时间，则将数据单元及其交付截止时间传输到客户端的数据报模块A，转步骤3.3；
3.2客户端的数据流模块A发送文件，方法是：
3.2.1客户端的数据流模块A为将要发送的文件生成对应的一个数据流，并将该文件切割成N个属于该数据流的数据段，将切割后的N个数据段按照顺序依次发送到客户端的数据加密模块A；
3.2.2客户端的数据加密模块A对从客户端数据流模块A接收的N个数据段使用密钥将数据加密，并封装成N个数据报文；
3.2.3令变量n＝1；
3.2.4客户端数据加密模块A从N个数据报文取出第n个输出到客户端的调度模块A；
3.2.5客户端的调度模块A使用调度算法根据路径信息在多路径中选择一条可用路径，若没有可用的路径，则转3.2.5等待；若存在可用的路径，转3.2.6；
3.2.6将第n个数据报文从3.2.5选出的路径发出，令n＝n+1，如果n≤N，转3.2.4；如果n>N，该数据流对应的所有数据报文发送完毕，转3.1等待发送方应用发送下一个文件；
3.3客户端向数据报模块A发送数据单元及其交付截止时间，方法是：
3.3.1客户端的数据报模块A对数据单元生成一个对应的数据报block，并将block及其交付截止时间deadline发送到客户端的数据报主动丢弃模块A；
3.3.2客户端的数据报主动丢弃模块A首先判断数据报block能否在交付截止时间Deadline前发送到服务端，方法是：
3.3.2.1数据报主动丢弃模块A计算数据报包含的数据段的数量num，使用公式一计算：
其中，DataSize为block的数据量大小，MSS为数据报的一个数据段的大小；
3.3.2.2假设一共存在D条路径，数据报主动丢弃模块A计算一条路径每秒能够传输数据段的数量，其中第i条路径每秒能够传输数据段的数量ppsi按公式二计算：
其中，RTTi是第i条路径的往返延迟，CWNDi是第i条路径的拥塞窗口，这两个值从路径信息获取；D为正整数；
3.3.2.3数据报主动丢弃模块A将不能用于发送数据段的路径排除，剩余的m条路径用于发送数据段，m＝D-排除掉的路径数，令剩余的m条路径称为有效路径，令m条有效路径构成的集合为有效路径集合S；
3.3.2.4数据报主动丢弃模块A判断剩下的m条路径能否在Deadline内将该数据报的num个数据段发送到服务端，若不能在Deadline内将该数据报的num个数据段发送到服务端，数据报主动丢弃模块A将该数据报丢弃，转3.1继续等待应用发送下一个数据单元；若能在Deadline内将该数据报的num个数据段发送到服务端，转3.3.3；
3.3.3客户端的数据报分配模块A将待发送的数据报切割成num个数据段，按数据段顺序标记序号，并决定数据报包含的数据段在各条路径上分配的比例，方法是：
3.3.3.1数据报分配模块A使用公式五计算数据报最短交付时间MinDeliverTime：
xii代表在第ii条路径上分配的数据段比例，xii在0到1之间，且满足：
公式五和公式六构成m个约束公式，利用Water-filling算法求得在m条有效路径上分配的数据段的比例集合X，X＝[x1,x2,…,xii,…,xm]；
3.3.3.2数据报分配模块A将数据段在m条有效路径上分配的比例信息X输出到调度模块A，即告知第ii条路径需要发送cntii个数据报文，cntii为第ii条路径上分配的数据报文数量,cntii＝xii×num；同时数据报分配模块A将数据段按序编号，将按序编号后的num个数据段输出到数据加密模块A；
3.3.4客户端的数据加密模块A对接收的按序编号后的num个数据段加密；将加密后的num个数据段打包成数据报文，按序依次发送给调度模块A；
3.3.5客户端的调度模块A向接收方的接收模块B按照每条路径上分配的报文数量发出数据报文，其中第ii条路径上分配的数据报文数为cntii，待发送的数据报文数量初始化为n＝num，方法是：
3.3.5.1客户端的调度模块A监控有效路径集合S，若存在一条或多条有效路径，从有效路径中随机选择第k条有效路径将报文发出，第k条有效路径发出报文后，该路径所分配的数据报文数cntk＝cntk-1，1≤k≤m-1，若cntk为零，将第k条路径从有效路径集合S中删除；
3.3.5.2令剩余未发送的报文数为n＝n–1，若n为0，转3.1继续等待发送下一个数据单元或文件；若n值不为0，转3.3.4继续发送下一个数据报文；
第四步：接收方接收数据报文，对数据报文进行处理并重组成完整的文件或数据单元，方法是：
4.1服务端的接收模块B经路径信息中的所有路径接收数据报文，解封装取出数据段，使用密钥对数据段解密，将数据段交付给乱序重排模块B，若数据段属于数据流，转4.2；若数据段属于数据报，转4.3；
4.2乱序重排模块B接收数据段，根据数据段的序号重排发送方数据流模块A传输的N个数据段，将排序得到的文件交付应用，转4.1等待接收下一个文件的数据报文；
4.3乱序重排模块B根据数据段的序号重排接收到的num个数据段，得到完整的接收的数据单元，交付给需要用该数据单元的应用软件，转4.1等待接收下一个数据报文，num个数据段的交付截止时间均为Deadline。
2.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于所述调度算法指RR、ECF、BLEST、minRTT中的任意一种。
3.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于3.3.2.1步所述DataSize的单位为字节，MSS为1220字节。
4.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于3.3.2.3步所述数据报主动丢弃模块A将不能用于发送数据段的路径排除的方法是判断公式三是否成立，
表示在第k条路径上发送的数据段到达接收方需要的时间，若公式三成立，说明第k条路径上发送的数据段到达接收方需要的时间大于Deadline，将第k条路径排除。
5.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于3.3.2.4步所述数据报主动丢弃模块A判断剩下的m条路径能否在Deadline内将该数据报的num个数据段发送到服务端的方法是判断公式四是否成立：
公式四左侧表示m条路径能够在Deadline时间内发送的数据段的数量；若公式四成立，说明不能在Deadline内将该数据报的num个数据段发送到服务端，数据报主动丢弃模块A将该数据报丢弃。
6.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于3.3.4步所述客户端的数据加密模块A对接收的按序编号后的num个数据段加密的方法是使用会话信息A中的密钥结合传输层安全协议1.3版。
7.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于4.2步所述乱序重排模块B接收数据段，根据数据段的序号重排发送方数据流模块A传输的N个数据段的方法是：
4.2.1令n＝1，一共需要接收N个数据报文；
4.2.2乱序重排模块B从接收模块B接收数据段，若未接收到数据段，转4.2.2等待，若接收到数据段，转4.2.3；
4.2.3令n＝n+1，若n≤N，转4.2.2等待接收后续的报文；若n>N，转4.2.4；
4.2.4乱序重排模块B根据数据段的序号对N个数据段进行重排序，将排序得到的文件交付应用。
8.如权利要求1所述的一种基于QUIC协议的部分可靠多路径传输方法，其特征在于4.3步所述乱序重排模块B根据数据段的序号重排接收到的num个数据段的方法是：
4.3.1令j＝1，一共需要接收num个数据报文；
4.3.2乱序重排模块B从接收模块B接收第j个数据段，若未接收到数据段，转4.3.2等待，若接收到数据段，转4.3.3；
4.3.3令j＝j+1,若j≤num且当前时间未超过Deadline，转4.3.2等待接收后续的数据段；若j≤num且当前时间超过Deadline，转4.3.4；若j≥num，转4.3.5；
4.3.4丢弃已收到的j个数据段，转4.1，等待接收下一个数据报文；
4.3.5乱序重排模块B根据数据段的序号对num个数据段进行重排序，得到完整的接收的数据单元，交付给需要用该数据单元的应用软件。
CN202310292771.1A 2023-03-22 2023-03-22 一种基于quic协议的部分可靠多路径传输方法 Active CN116436864B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310292771.1A CN116436864B (zh) 2023-03-22 2023-03-22 一种基于quic协议的部分可靠多路径传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310292771.1A CN116436864B (zh) 2023-03-22 2023-03-22 一种基于quic协议的部分可靠多路径传输方法

Publications (2)

Publication Number Publication Date
CN116436864A CN116436864A (zh) 2023-07-14
CN116436864B true CN116436864B (zh) 2024-05-24

Family

ID=87093573

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310292771.1A Active CN116436864B (zh) 2023-03-22 2023-03-22 一种基于quic协议的部分可靠多路径传输方法

Country Status (1)

Country Link
CN (1) CN116436864B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200092250A (ko) * 2019-01-24 2020-08-03 고려대학교 산학협력단 심층 강화학습 기반 다중경로 패킷 스케줄링 방법
CN112243268A (zh) * 2020-10-16 2021-01-19 南京邮电大学 一种基于quic协议的多流传输控制方法
WO2022218692A1 (en) * 2021-04-14 2022-10-20 Deutsche Telekom Ag System and method for multipath transmission with efficient adjustable reliability
CN115835299A (zh) * 2022-11-01 2023-03-21 中盈优创资讯科技有限公司 基于单向网络质量测量的mp-quic多路径分配调度方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200092250A (ko) * 2019-01-24 2020-08-03 고려대학교 산학협력단 심층 강화학습 기반 다중경로 패킷 스케줄링 방법
CN112243268A (zh) * 2020-10-16 2021-01-19 南京邮电大学 一种基于quic协议的多流传输控制方法
WO2022218692A1 (en) * 2021-04-14 2022-10-20 Deutsche Telekom Ag System and method for multipath transmission with efficient adjustable reliability
CN115835299A (zh) * 2022-11-01 2023-03-21 中盈优创资讯科技有限公司 基于单向网络质量测量的mp-quic多路径分配调度方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Y. Cui ; Z. Liu ; H. Shi ; J. Zhang ; Tsinghua University ; K. Zheng ; W. Wang ; Huawei ; .Deadline-aware Transport Protocol draft-shi-quic-dtp-02.IETF .2020,第1-8节. *

Also Published As

Publication number Publication date
CN116436864A (zh) 2023-07-14

Similar Documents

Publication Publication Date Title
Dreibholz et al. Stream control transmission protocol: Past, current, and future standardization activities
US8937920B2 (en) High capacity network communication link using multiple cellular devices
US7310694B2 (en) Reducing information reception delays
US8943206B2 (en) Network bandwidth detection and distribution
US8577985B2 (en) Load balancing and admission scheduling in pull-based parallel video servers
CA2368513C (en) Performance enhancing proxy and method for enhancing performance
Bhat et al. Improving QoE of ABR streaming sessions through QUIC retransmissions
Seggelmann et al. SSH over SCTP—Optimizing a multi-channel protocol by adapting it to SCTP
CN115002023B (zh) 一种链路聚合方法、链路聚合装置、电子设备及存储介质
US8339945B2 (en) Data link control architecture for integrated circuit devices
CN113783942B (zh) 基于优先分级队列的mpquic数据包快速传输方法和系统
Becke et al. Data channel considerations for RTCWeb
CN116436864B (zh) 一种基于quic协议的部分可靠多路径传输方法
US20100030911A1 (en) Data transfer acceleration system and associated methods
CN116015943B (zh) 一种基于多级隧道混淆的隐私保护方法
US20110022717A1 (en) Network card and information processor
JP4036199B2 (ja) 秘匿通信方式
Evensen et al. Using multiple links to increase the performance of bandwidth-intensive UDP-based applications
JP5150413B2 (ja) 複数コネクションを用いたデータ通信方法
Halepoto et al. Evaluation of multimedia streams in internet applications
Zou et al. Throughput models for SCTP with parallel subflows
Rajiullah et al. Optimizing PR-SCTP performance using NR-SACKs
WO2003069836A1 (en) Multicasting selective repeat protocol
Xiao et al. A Secure and Efficient Transport Protocol for Multi-Identifier Network
Ince et al. SCTP: Are you still there?

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant