CN109644190B - 两个终端之间的多路径udp通信方法 - Google Patents

两个终端之间的多路径udp通信方法 Download PDF

Info

Publication number
CN109644190B
CN109644190B CN201780051712.8A CN201780051712A CN109644190B CN 109644190 B CN109644190 B CN 109644190B CN 201780051712 A CN201780051712 A CN 201780051712A CN 109644190 B CN109644190 B CN 109644190B
Authority
CN
China
Prior art keywords
communication device
udp
communication
data
path
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
CN201780051712.8A
Other languages
English (en)
Other versions
CN109644190A (zh
Inventor
M.布卡戴尔
C.雅克奎内特
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of CN109644190A publication Critical patent/CN109644190A/zh
Application granted granted Critical
Publication of CN109644190B publication Critical patent/CN109644190B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • 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
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及一种用于在IP网络中通信的方法，所述方法包括以下步骤：a)第一通信设备通过向第二通信设备发信号通知所述第一通信设备与基于用户数据报协议(UDP)的多路径通信兼容来初始化与所述第二通信设备的通信；以及b)如果所述第二通信设备也与多路径UDP通信兼容，则：所述第一通信设备通过不管使用什么路径在包含数据的消息中包括单个标识符来使用UDP传输协议向所述第二设备传输所述数据，所述标识符称为上下文标识符(上下文_ID)，从而允许所述第二通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报；和/或所述第二通信设备通过不管使用什么路径在包含数据的消息中包括单个标识符来使用UDP传输协议向所述第一设备传输所述数据，所述标识符称为上下文标识符(上下文_ID)，从而允许所述第一通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报。

Description

两个终端之间的多路径UDP通信方法
技术领域
本发明涉及电信领域，并且具体地涉及能够实现IP(互联网协议)协议的通信网络。更具体地，本发明涉及提供“增值”IP网络(也就是说，在能够根据在网络中路由的流量的性质而执行区分处理操作的网络中)服务。
背景技术
本发明具体地适用于任何类型的客户端设备(或“用户设备”)，如固定或移动终端、“连接TV”、或住宅网关(也就是说家庭网关或位于公司中的网关)、或网络运营商网关、或TV解码器(或“机顶盒”(STB))。为了简明起见，任何类型的客户端设备在下文中通常将被称为“终端”。
如今，诸如智能电话和个人计算机(或PC)之类的终端能够激活和利用链接到一个或多个物理接口的多个逻辑接口。这种终端被称为“多接口”(或MIF)。当终端具有多个能够将其连接到各种接入网络(例如：固定、移动或WLAN)的接口时，其就会受益于所谓的“混合”接入，因为所述混合接入组合了各种接入网络技术。
然后，可以向MIF终端指派多个IP地址。当该终端以同时或延迟的方式连接到各种类型的网络(如固定网络、移动网络、或WLAN网络(“无线局域网(wireless local areanetwork)”的缩写，其一个典型示例是Wi-Fi网络))时，使用这些地址。这些IP地址可以：
·属于同一地址族或者属于单独的地址族(IPv4、IPv6、或两者)，
·具有不同的使用期，
·具有不同的范围，例如私用IPv4地址、唯一本地范围IPv6地址(唯一本地地址(Unique Local Address)或ULA)、或者全局范围IPv6地址(全局单播地址(Global UnicastAddress)或GUA)，以及
·被指派给同一逻辑网络接口或者各种逻辑网络接口。
然而，将注意的是，由于使用多个接口的能力取决于连接到(多个)网络的条件、设备的位置或其他因素，因此“MIF”特征是易失性的。在建立简单通信(也就是说，沿着单个路径与给定通信方建立的通信)期间、或者甚至在建立简单通信之后，设备可能变成MIF。还将注意的是，设备并未先验地知道其是否可以使用多个单独的路径以便与给定通信方建立通信；更准确地说，该设备仅在其尝试与该通信方建立多路径通信的阶段结束时才获取此信息(如果适用)。
应当回顾的是，“多路径通信”是在两个设备之间同时采用这两个设备之间的一个或多个路径建立的通信。建立这样的通信并使其保持活动取决于专用协议的使用，如MPTCP(多路径TCP)，该专用协议可能可以被定义为先前定义的传输协议(如TCP(“传输控制协议(Transmission Control Protocol)”的缩写))的扩展。换句话说，多路径通信是采用同一个路径或不同的路径(部分或完全分开)的一个或多个简单通信的聚合。
还应当回顾的是，在网络领域，“链路聚合”是针对与多个(逻辑)接口相关联的多个链路的分组而给出的名称，就好像涉及与单个接口相关联的单个链路一样，具体是为了超出单个链路的限制增大比特率、同时将相同的操作程序应用于这样聚合的所有链路(“命运共享”的概念)的目的。具体地，关于具有混合接入的终端的服务提供是基于在网络中引入允许终端的所有网络通信(例如：WLAN和3G，或者ADSL、WLAN和4G)被聚合的功能。
如果网络链路出现故障，链路聚合还使得其他接口可以接管(冗余原则)。链路聚合适用于沿着这些链路路由的任何类型的流量，包括IP流量。
链路聚合也可以用于在多个链路上分配流量。在这种情况下，经受聚合的链路之间的流量分配取决于各种参数；因此，流量分配可以取决于流量工程策略(例如，优先考虑在稳健性或可用性方面的特性与特定流量的性质兼容的链路上路由所述流量)，或者取决于服务质量(QoS)策略，该策略例如可以优先考虑流量优先级上下文中的一些链路。
以示例的方式，图1a示出了通过实现多路径通信协议经由表示为R1、……、Rm和O的多个IP网络来与服务器S通信的终端T。各种接入网络R1、……、Rm可以是有线的、无线的或其他性质。此外，终端T可以具有同时或非同时连接到各种接入网络的能力。
同样，图1b示出了位于称为中继设备R的设备后面的终端T；此中继设备R通过实现多路径通信协议经由表示为R1、……、Rm和O的多个IP网络与服务器S通信。
一般来说，“中继设备”是将针对位于网络中并代表一个或多个客户端设备(如终端或网关)起作用的设备而给出的名称。此配置允许客户端设备受益于可用网络资源的优化使用，并且也在短时间内建立多路径通信。
将注意的是，链路聚合未关于远程机器的配置做出任何假设。因此，源机器可以使用这种功能来调用链路聚合功能而无需远程机器。
可以设想各种聚合模式，包括以下三种模式：
·“备用”模式：此模式在于当主路径不可用时使用辅助路径，并且这样做是为了提高网络可用性并因此提高在各种链路上建立的IP通信的稳健性和可靠性；
·关联(或“绑定”)模式：此模式在于使用与所有或一些可用路径相关联的资源，与同一应用相关联的IP流能够在多个路径之间被分配；利用所有路径或仅利用其中一些路径的选择可以例如取决于流量的性质或与每个路径相关联的可用性特性或可靠性特性，这些特性从一个路径到另一个路径可以发生极大的变化；针对此绑定模式所选择的所有路径被认为是主路径；以及
·所谓的“舒适”模式：此模式类似于绑定模式，除了给定应用的流不是在多个路径之间分配，而是在单个路径上被发送之外。
将注意的是，这些模式不是相互排斥的，并且不是特定于一种特定类型的流量。因此，可以独立于将沿着使用各种模式中的一种或另一种模式聚合的路径路由的流量的性质来使这些模式发挥其作用。
主要由软件应用使用以在互联网上通信的传输协议是TCP(上文提到的)和UDP(“用户数据报协议(User Datagram Protocol)”的缩写)。在这方面，允许客户端设备/中继设备根据要求和基于TCP或UDP的应用的约束来优化可用网络资源的使用的技术手段使得其提供与使用这种应用相关联的质量水平的明显提高。此外，一些互联网玩家目前正在对TCP的替代解决方案进行大规模实验，这些解决方案基于UDP(且更准确地说，基于封装布局)。从这个角度来看，服务提供商和IP网络运营商致力于在基于TCP的应用与基于UDP的应用程序之间提供同等水平的使用质量。
因此，希望TCP与UDP之间具有尽可能广泛的功能对等。具体地，能够以功能上与已知技术解决方案类似的方式建立多路径UDP通信将是有用的，如上文提到的MPTCP协议，该协议允许经由多个路径建立TCP连接。
在本发明的上下文中，“UDP数据报”是针对使用UDP协议传输的IP分组而给出的名称。
M.布卡达尔(M.Boucadair)等人在文献(“互联网草案(draft-Internet)”)中提出了对这个问题的一种解决方案，该文献提交给IETF(互联网工程任务组)并且标题为“网络辅助MPTCP部署的MPTCP选项：普通传输模式(An MPTCP Option for Network-AssistedMPTCP Deployments:Plain Transport Mode)”。此解决方案使用MPTCP协议具体在MPTCP连接的上下文中路由UDP流量。在UDP流量的情况下，该解决方案在于将UDP数据报转换成TCP分组。为此，作者定义了一个特定的TCP选项，该选项使得可以明确指示在MPTCP连接内传输的数据的性质，并且具体地明确指示路由数据是UDP数据报。因此，MPTCP代理功能通过进行如下操作来将UDP数据报转换成TCP分组：
-利用TCP报头替换UDP报头，并且
-插入其“协议”字段被设置为值“17”的TCP选项，这指示TCP分组的内容对应于UDP数据。
在接收到包含所述TCP选项的TCP分组之后，MPTCP代理功能进行如下操作：
-利用UDP报头替换TCP报头，并且
-将这样构造的UDP数据报传送到下一跳。
这种解决方案有利地使得可以使用相同的功能来为TCP流量和UDP流量两者建立多路径通信。
此解决方案的缺点是，由于TCP报头(20字节，不算选项，参见图2a)与UDP报头(8字节，参见图2b)之间的大小差异，其提供了更差的性能。具体地，这种大小差异可能导致UDP数据报的分段。这种分段要求网络运营商修改某些参数，如MTU(“最大传输单元(maximumtransfer unit)”的缩写)的值，其对应于能够在给定链路上传输的分组的最大大小：如果分组的大小超过MTU的值，则发送该分组的源被通知这种超过并被邀请对大小大于MTU值的所述分组进行分段。现在，在一些情况下，例如由于技术限制，修改这些参数并不总是可能的。此外，TCP协议特有的数据的可靠传输可能导致UDP应用的服务的恶化。
发明内容
因此，本发明涉及一种用于在IP网络中通信的方法，所述方法包括以下步骤：
a)第一通信设备通过向第二通信设备发信号通知所述第一通信设备与基于UDP(用户数据报协议)传输协议的多路径通信兼容来初始化与所述第二通信设备的通信，以及
b)如果所述第二通信设备本身也与多路径UDP通信兼容，则：
-所述第一通信设备通过不管使用什么路径在包含数据的消息中包括同一标识符来使用UDP传输协议向所述第二设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第二通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，和/或
-所述第二通信设备通过不管使用什么路径在包含数据的消息中包括同一标识符来使用UDP传输协议向所述第一设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第一通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报。
具体地，本发明的创建者已经认识到，如果希望允许接收通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，则必须充分标识由发送通信设备使用各种源IP地址或各种源端口号发送给接收通信设备的UDP数据报。这种标识具体地使得可以保持这两个设备之间的数据交换的完整性。根据本发明，发送通信设备在其发送的UDP数据报中插入上下文标识符(将被称为“上下文_ID(Context_ID)”)；这种多路径UDP通信将被称为“MPUDP”。
将注意的是，与基于利用封装报头的特定字段的现有解决方案(例如，IP-in-IP或GRE)或者TCP协议特定的解决方案(例如，MPTCP)或者在TCP分组中传输UDP数据的解决方案(如上文简要描述的布卡达尔等人的解决方案)相比，本发明基于UDP数据报的本机路由。
凭借这些规定，通过以与建立多路径TCP连接相当的方式建立多路径UDP会话，获得TCP与UDP之间的功能对等以便管理多个路径，从而以相同的效率处理在互联网上路由并且不加区别地基于TCP协议或UDP协议的所有流量。
此外，有利地，本发明：
·不对基于UDP的软件应用进行任何修改；
·使得可以为了从链路聚合的优势中受益而避免使用隧道(如在例如“GTP绑定”或“GRE绑定”技术中)，隧道的工程、建立和维护导致复杂性并且使得其损害与基于此类隧道的通信相关联的质量水平；
·使得可以优化可用网络资源的使用，而没有任何协议成本，并且没有违反协议，违反协议涉及例如将UDP数据报转换成通过其他传输协议(例如，TCP)传输的分组；并且
·与需要将聚合逻辑集成到应用程序本身中的解决方案相比，使得可以为通过UDP协议传输的所有软件应用部署单个解决方案。
因此，用户体验质量显著提高。
本发明的一个典型示例性应用是使用TFTP(简单文件传输协议)协议的资源传输文件或者基于SNMP(“简单网络管理协议(Trivial File Transfer Protocol)”的缩写)协议对统计数据收集流进行优化管理，所述SNMP协议使用UDP端口161和162。具有多个网络附件而充当TFTP客户端的终端可以动态地利用允许其访问TFTP服务器的所有可用路径。因此，数据传输时间将得到改善，好处是优化客户体验。在SNMP流量的情况下，本发明具体地使得可以通过在主路径不可用的情况下使得可以使用备用路径来使得流量路由更可靠。
将注意的是，根据本发明的通信中所涉及的通信设备可以是与IP协议兼容的任何设备。这种通信设备可以是任何类型，例如客户端设备、或者可在互联网上访问的内容服务器、或者流量集线器(应当回顾的是，“流量集线器”是物理或虚拟网络功能，其使得可以聚合利用给定设备可能使用的各种路径的通信以建立与远程设备的通信)。其可以具有指派给其物理或逻辑接口中的每个接口的一个或多个IP地址。其也可以仅具有单个接口，在这种情况下，将假设其位于连接到一个或多个网络并与链接聚合机制兼容的中继设备(如路由器或住宅网关)后面。
根据特定特征，第一通信设备和/或第二通信设备还在所述消息中插入安全令牌，从而允许这些消息的接收者认证其发送者。
凭借这些规定，当数据不合法地形成在终端T1与终端T2之间正在进行的交换的一部分时可以避免例如第三方终端将这些数据插入到去往终端T1或终端T2的消息中。
根据其他特定特征，第一通信设备和/或第二通信设备还在所述消息中插入信息项，从而允许这些消息的接收者按照其被发送的顺序对其进行处理。
凭借这些规定，UDP数据报被发送的顺序与其到达的顺序之间的可能偏移被校正，这种偏移具体可能是由与所使用的各种路径相关的质量水平的失真引起的。
根据又其他特定特征，所述方法包括以下步骤：
-与多路径UDP通信兼容的第一通信设备发送UDP消息，所述消息由嵌入在此第一通信设备中的中继器截取，
-所述中继器向第二通信设备发送用于使用TCP(传输控制协议)传输协议建立会话的消息，所述消息包含能够向所述第二通信设备发信号通知所述第一通信设备与多路径UDP通信兼容的专用选项，以及
-如果所述第二通信设备本身也与多路径UDP通信兼容，则其使用所述TCP传输协议发送响应消息，其在所述响应消息中插入所述专用选项，并且然后所述第一通信设备使用多路径UDP通信向所述第二通信设备发送数据和/或所述第二通信设备使用多路径UDP通信向所述第一通信设备发送数据。
凭借这些规定，允许建立多路径UDP通信的数据交换(包括例如IP地址、端口号或安全令牌的交换)的可靠性通过TCP或MPTCP协议得到了保证。
结合起来，本发明涉及一种通信设备，称为第一通信设备。所述通信设备值得注意的是，所述通信设备包括用于执行以下操作的装置：
-通过向IP网络内的称为第二通信设备的另一通信设备发信号通知所述第一通信设备与多路径UDP(用户数据报协议)通信兼容来初始化与所述第二通信设备的通信，
-通过不管使用什么路径在包含数据的消息中包括同一标识符来使用UDP协议向所述第二通信设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第二通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，以及
-通过不管使用什么路径在包含数据的消息中检测同一标识符来使用UDP协议从所述第二通信设备接收这些数据，所述标识符称为上下文标识符，从而允许所述第一通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报。
根据特定特征，所述通信设备还包括插入装置，所述插入装置用于在其发送的消息中插入安全令牌，从而允许这些消息的接收者认证其发送者。
根据其他特定特征，所述通信设备还包括插入装置，所述插入装置用于在其发送的消息中插入信息项，从而允许这些消息的接收者按照其被发送的顺序来对其进行处理。
根据又其他特定特征，所述通信设备嵌入有中继器，所述中继器包括用于向第二通信设备发送用于使用TCP(传输控制协议)传输协议建立会话的消息的装置，所述消息包含能够向所述第二通信设备发信号通知第一通信设备与多路径UDP通信兼容的专用选项。
相反，根据又其他特定特征，所述通信设备还包括用于执行以下操作的装置：
-在从称为第三通信设备的另一通信设备接收的用于使用TCP(传输控制协议)传输协议建立会话的消息中，考虑能够向所述第一通信设备发信号通知所述第三通信设备与多路径UDP通信兼容的专用选项，
-使用TCP传输协议发送包含所述专用选项的响应消息，以及
-使用多路径UDP通信，向所述第三通信设备发送数据和/或接收由所述第三通信设备发送的数据。
这些通信设备提供的优点基本上与上文简要概述的通信方法所提供的优点相同。
将注意的是，可以在软件指令的背景下和/或电子电路的背景下实现这些通信设备。
本发明还针对一种计算机程序，该计算机程序可从通信网络中下载和/或被存储在计算机可读介质上和/或能够由微处理器执行。此计算机程序值得注意的是，其包括用于当其在计算机上被执行时执行上文简要概述的通信方法中的一种通信方法的步骤的指令。
此计算机程序提供的优点基本上与上文简要概述的通信方法所提供的优点相同。
附图说明
在阅读以非限制性示例的方式给出的特定实施例的以下详细描述时，本发明的其他方面和优点将变得显而易见。该描述参照附图，在附图中：
-上文提到的图1a示出了通过实现多路径通信协议经由多个IP网络与服务器S进行通信的终端T，
-上文提到的图1b示出了位于通过实现多路径通信协议经由多个IP网络与服务器S进行通信的中继设备R后面的终端T，
-上文提到的图2a示出了UDP报头，
-上文提到的图2b示出了TCP报头，
-图3示出了与多路径通信兼容并连接到本身也与多路径通信兼容的服务器S的终端T，
-图4展示了根据本发明的使用上下文标识符的终端T与服务器S之间的MPUDP通信，
-图5展示了根据本发明的使用上下文标识符和安全令牌的终端T1与终端T2之间的MPUDP通信，
-图6示出了根据本发明的包含有效载荷数据以及上下文标识符和附加数据的UDP数据报，
-图7示出了形成单个MPTCP连接的TCP子流的聚合，
-图8示出了根据本发明的MPTCP选项“后备_UDP_能力(Fallback_UDP_Capable)”，
-图9示出了根据本发明的TCP选项“后备_UDP_能力”，
-图10展示了根据本发明的终端T与服务器S之间的通信，
-图11展示了根据本发明服务器S经由流量集线器C和住宅网关CPE向终端T发送UDP数据报，以及
-图12展示了根据本发明终端T经由住宅网关CPE和流量集线器C向服务器S发送UDP数据报。
具体实施方式
首先，应当回顾的是，简单UDP通信由以下一组参数来标识：源IP地址、源端口号、目的IP地址、和目的端口号。多路径UDP通信通常是与多组参数{源IP地址，源端口号，目的IP地址，目的端口号}相关联的通信；这四个参数中的至少一个参数的变化标识不同的路径(不同的简单通信)。因此，多路径UDP通信由多个简单UDP通信形成。
图3以示例的方式示出了与多路径通信兼容并且经由住宅网关CPE(“客户驻地设备(customer premises equipment)”的缩写)、三个(有线或者无线)接入网络N1、N2和N3以及互联网连接到本身也与多路径通信兼容的服务器S的终端T。终端T使用m个单独的IP地址(表示为IP@ti，其中i＝1，...，m)，而服务器S使用同一个IP地址(表示为IP@s1)但n个单独的端口号(表示为pj，其中j＝1，...n)。
如上文提及的，根据本发明，第一通信设备在使用UDP传输模式发送到第二通信设备的IP分组中插入称为“上下文_ID”的上下文标识符。对于在两个通信设备之间建立的每个MPUDP通信，上下文标识符必须是唯一的。然而，如果不存在与正在进行的通信的上下文标识符冲突的风险，则通信设备可以重用可能已经在现在已经结束的先前通信的上下文中使用的上下文标识符。此外，为了提高多路径UDP通信的安全水平，优选随机生成上下文标识符。
将注意的是，上下文标识符可以由接收通信设备选择，或者可以是由发送通信设备选择的标识符与由接收通信设备选择的另一标识符相关联的结果；只有在UDP数据报的多路径发送生效之前已经建立了在两个设备之间交换信息的步骤时，这些变体才是可能的。上下文标识符也可以由另一实体选择，如控制发送通信设备、或接收通信设备、或这两个设备的网络管理器。
还将注意的是，如果通信是双向的，则两个通信设备中的每个通信设备可以使用单独的上下文标识符。
图4展示了终端T与服务器S之间的MPUDP通信。在这个示例中，使用三个简单UDP通信发送UDP数据报。为了允许终端T将这些简单通信与同一个多路径UDP会话相关联，服务器S在其发送到T的分组中插入上下文标识符ID#1。
除了上下文标识符之外，可以有利地在两个通信设备之间交换的消息中插入诸如安全令牌之类的附加信息。图5展示了终端T1与终端T2之间的MPUDP通信，该通信使用上下文标识符ID#1并且终端T3试图在其中插入数据(例如，通过盗用T2的IP地址)。如果T3所包含的安全令牌的“认证_令牌(Authentication_Token)”与T2所使用的安全令牌不相同，则T1不考虑T3传输的数据。
上下文标识符连同附加数据可以被插入到IP分组中，并且根据第一变体，位置紧接在UDP数据之后。如图6所展示的，“IP长度”值表示IP分组的总大小，包括IP报头的大小(IPv4中为20字节，IPv6中为40字节)，而“UDP长度”值表示UDP报头和有效载荷数据的总大小。通过从IP长度减去IP报头的长度和UDP长度，IP分组的接收者能够确定上下文标识符和可能的附加数据的位置。
根据第二变体，在包含UDP有效载荷数据的字段中传输上下文标识符。
根据第三变体，定义了新的专用IPv4选项(在这种情况下，附加数据可以方便地记录在IPv4分组的报头的“选项”字段中)或者专用IPv6扩展报头。这些选项用于传输上下文标识符以及可能的附加数据(例如，安全令牌)。
显然重要的是，与常规UDP模式相比，多路径UDP通信的使用不会导致服务质量的恶化(例如，分组的丢失)。
具体地，与多个路径相关联的质量水平的失真使得其通过在UDP数据报被发送的顺序与其到达的顺序之间产生偏移来质疑通信的完整性。即使某些UDP应用被设计为最小化这种风险(这对于简单通信也是已知的)，发送UDP通信设备也可以有利地除了上下文标识符Context_ID之外在其发送的消息中插入附加信息项，从而允许接收UDP通信设备按照这些消息被发送的顺序来对其进行处理。这个附加信息项将被称为“顺序_排名(Order_Rank)”。这个信息元素可以例如被构造为其值递增的非零整数；因此，Order_Rank值等于“7”的UDP数据报指示这个UDP数据报是序列中的第七个数据报。
为了提高通信的安全性，初始Order_Rank值(也就是说，第一个分组的顺序_排名值)可以是非零的并且是随机生成的。
与多路径UDP通信兼容的终端应该优选地具有允许其确保远程终端本身也与多路径通信兼容的可靠机制。已经设想了多种方法来实现这一点，例如：
·使用DNS SRV(“域名系统服务记录(Domain Name System Service Record)”的缩写)资源：这种方法仅适用于涉及DNS交换的应用；其不适用于交换所谓的推荐连接信息(“推荐”)的应用(如P2P应用)(推荐信息项例如可以被构造为域名、IP地址、或端口号，参见https://tools.ietf.org/html/draft-carpenter-behave-referral-object-00# section-4)；
·使用新协议号来标识多路径UDP版本：这种方法可以在受控环境中设想，但是由于NAT(“网络地址转换器(Network Address Translator)”的缩写)和防火墙的激增而无法大规模部署；
·定义应用扩展(例如FTP)：这种方法仅适用于某些协议，并且不能推广；或者
·在UDP上定义新的应用；此应用将部分地专用于检查远程终端对MPUDP的支持。
现在将给出对本发明的一个实施例的描述，该实施例有利地组合了UDP和TCP传输协议。
应当回顾的是，TCP协议(具体地在文献RFC 793中定义)是连接到IP网络(例如，互联网)的终端所使用的主要协议之一，因此文献经常提到“TCP/IP”协议族。TCP协议使得可以以可靠、有序和无错误的方式在连接到局域网(例如，内部网)或互联网的终端上执行的应用之间路由数字数据流。TCP协议在OSI模型的传输层级别处进行操作。Web浏览器在连接到远程服务器时使用TCP协议；TCP协议也用于路由电子邮件或将文件从一个位置传输到另一个位置。如HTTP、HTTPS、SMTP、POP3、IMAP、SSH、FTP、Telnet等协议以及许多其他协议在TCP连接上进行传输。TCP连接由源终端的地址和端口号以及目的终端的地址和端口号来标识。
本实施例基于TCP选项或IPv4选项的使用来建立多路径UDP通信。为此，可以使用IPv4分组的报头的“选项”字段(在IETF的文献RFC 791中描述)。
传统上，两个终端能够在其之间交换的TCP消息中插入“TCP选项”，以便例如优化TCP连接的质量。此类选项占据在TCP报头的末尾处可用的空间，并且此类选项的长度以字节表示。选项的种类是描述TCP选项的种类的唯一标识符。例如，值“0”表示选项列表的末尾，并且值“2”表示TCP分段的最大大小(“最大分段大小(maximum segment size)”或MSS)。
术语“选项”还用于表示例如IPv6扩展报头、IPv4选项、封装分组的(多个)“源地址/源端口号”字段、封装分组的(多个)“目的地址/目的端口号”字段、封装分组的一个或多个字段、分组的封装另一分组的一个或多个字段、或封装布局的扩展、以及TCP协议或另一传输协议的选项、或者还有这些各种手段的组合。
MIF终端的出现引入了通过使用分配给MIF终端的各种接口的所有或一些IP地址而经由可用网络利用多个路径的资源来建立TCP连接的可能性。然而，这种可能性引入了TCP协议的操作模式的复杂性特性：假定TCP连接与IP地址和端口号相关联，对这些信息项中的至少一项的任何修改使得其损害正在进行的TCP连接的操作并因此损害使用所述TCP连接的服务。当终端被指派新的IP地址时，或者当终端连接到另一个网络时，或者甚至当IP地址与之相关联的接口不再可用时，这种改变尤其有害。例如，为了确保维持现有的TCP连接而不中断由此TCP连接提供的服务，则需要用于通知远程TCP通信方IP地址不再有效的装置。
IETF的“mptcp”工作组在2009年承担了指定TCP协议的扩展的任务，这些扩展能够适应将多个IP地址指派给终端的各种逻辑或物理接口的可能性所带来的约束。此工作组发布了MPTCP协议的第一批规范(参见A.Ford(A.福特)、C.Raiciu(C.莱修)、和M.Handley(M.汉德利)“用于利用多个地址进行多路径操作的TCP扩展(TCP Extensions for MultipathOperation with Multiple Addresses)”，RFC 6824，2013年1月)，一些智能手机和一些操作系统偶然已经能够实现该协议。如果终端是移动的，MPTCP协议尤其满足确保IP会话连续性的需要。IETF希望提升当前MPTCP规范的地位，从而使得这些规范成为IETF意义上的真正标准。
因此，提出了MPTCP协议以便将TCP连接的与例如这种地址修改相关联的不合时宜的丢失的风险最小化，并且更一般地，以便满足终端具有经由一个或多个接口连接到一个或多个网络的能力的背景所提出的要求。此外，文献RFC 6824中规定，如果试图建立MPTCP连接失败，通信将自动切换到简单TCP连接。
本实施例通常适用于TCP/IP族中管理多路径通信的任何协议。纯粹为了说明的目的，下面将在对MPTCP协议的某些特性进行一些提醒之后描述本发明在此协议上的应用。
根据MPTCP协议，“子流”是针对基于使用可用对(IP地址，端口号)之一的TCP连接而给出的名称。因此，MPTCP连接是TCP子流的聚合。以示例的方式，图7示出了终端A与终端B之间的MPTCP连接；在终端A的地址A1与终端B的地址B1之间建立了初始子流；后来，在终端A的地址A2与终端B的地址B1之间建立了附加子流。因此，MIF终端能够连接到新的网络，或者与某些网络断开连接，同时保持同一个多路径连接。
可以针对MPTCP协议设想各种使用情况，如：
·在多个无线接入网络之间交换数据，
·通过将流量中的一些流量切换到无线接入网络来降低移动网络的负载，
·通过同时利用多个接入链路的资源并且通过在这些各个链路上分配一个或多个MPTCP连接的流量负载来优化对网络资源的使用，从而使得可以显著地增大与MPTCP连接的建立相关联的带宽，或者
·通过在主路径丢失时将沿着该主路径路由的流量切换到备用路径，使得MPTCP连接更加可靠，并且这样做对用户透明(也就是说，没有服务中断)。
除了被称为MP_能力(MP_CAPABLE)(意味着发送终端与MPTCP扩展兼容)的TCP选项被包括在包含子流初始化标志(SYN)的消息中和随后的消息中的事实之外，和任何常规TCP连接一样对MPTCP连接进行初始化。MPTCP终端可以使用被称为添加_地址(ADD_ADDR)的TCP选项来发信号通知远程终端附加IP地址的可用性，而不一定创建相关联的子流。
因为如由远程终端所感知的外部IP地址可能与在本地可见的那些IP地址不同，所以发信号通知可用的且易于用于与通信方进行通信的多个IP地址可能导致一些TCP子流的建立失败。为此，MPTCP协议的ADD_ADDR选项包括用于明确标识可用IP地址的地址标识符，称为“地址ID”。此规定旨在避免由于已经建立MPTCP连接的两个终端之间的分组所采用的路径上的NAT的存在而产生的问题。如果MPTCP终端之一没有将相同的端口号用于所有可用IP地址，ADD_ADDR选项还用于传输端口号。
同样地，MPTCP协议做出了具体旨在使得可以穿过防火墙的规定。更确切地，MPTCP协议的规范规定了如在TCP报头中指示的序列号特定于每个子流，而在MPTCP协议的DSS(“数据序列信号”)选项中指示的序列号用于将这些子流与相同的MPTCP连接相关联。
因此，MPTCP协议旨在克服“中间盒子(middle box)”(通信链中的中间功能)(如部署在现代网络中的NAT和防火墙)的广泛激增所带来的约束。
MPTCP协议具体地使用以下TCP选项：
·MP_能力(MP_CAPABLE)：上文提到的此选项用于发信号通知远程终端发送终端与MPTCP选项兼容；
·添加_地址(ADD_ADDR)：上文提到的这个选项用于添加新地址；其包括可选的两字节字段，这也使得可以在适当时提供端口号；
·移除_地址(REMOVE_ADDR)：此选项用于删除地址；
·MP_优先级(MP_PRIO)：此选项用于修改TCP连接的优先级；
·MP_加入(MP_JOIN)：此选项用于标识与新子流的建立相关联的TCP连接；
·MP_失败(MP_FAIL)：此选项用于返回到没有MPTCP选项的TCP模式；以及
·MP_快速关闭(MP_FASTCLOSE)：此选项用于快速关闭MPTCP连接。
MPTCP协议可以根据多种模式被激活：
-本机模式：两个MPTCP终端建立与可用地址/端口的数量相对应的所有子流，并使用所有这些子流；
-主模式：两个MPTCP终端发信号通知子流，但是仅这些子流的一个子集实际上用于传送数据；
-辅助模式：如果子流的“主”子集不可用(或过载)，则调用子流的“辅助”子集以确保MPTCP连接的连续性；以及
-备用模式：两个MPTCP终端使用单个子流；如果出现故障，则流量被切换到为此目的创建的新子流。
为了与本实施例兼容，通信设备必须嵌入有中继设备，该中继设备将被称为“UDP/TCP中继器”，负责将由与通信设备相关联的软件应用发送的UDP消息中继到TCP或MPTCP连接。将注意的是，从应用性能的角度来看，使用MPTCP连接来中继UDP消息比简单TCP连接更有效；此外，MPTCP使得可以交换多个地址和/或端口号。
现在将给出对两个通信设备之间的通信方法的步骤的描述，其中至少一个通信设备(我们将称之为“第一通信设备”)与MPUDP兼容。此外，这里假设能够用于此通信的各种路径与MPTCP兼容。
在步骤E1中，与所述第一通信设备相关联的所述软件应用发送UDP消息，该消息由嵌入在此第一通信设备中的UDP/TCP中继器截取。
在步骤E2中，此UDP/TCP中继器发送打算用于第二通信设备的SYN消息，该消息包含将被称为“后备_UDP_能力(Fallback_UDP_Capable)”并且向第二通信设备发信号通知第一通信设备与MPUDP兼容的专用选项。
根据第一变体，这个Fallback_UDP_Capable选项是MPTCP选项，如图8中所展示的选项。根据第二变体，这个Fallback_UDP_Capable选项是TCP选项，如图9中所展示的选项，在这种情况下，不强制使用MPTCP信令。
在步骤E3中，第二通信设备通过SYN/ACK消息进行响应。然后可能有两种情况：
·如果第二通信设备本身也具有建立多路径UDP通信的能力，则其在所述SYN/ACK消息中插入Fallback_UDP_Capable选项；然后，在步骤E4中，两个通信设备通过MPUDP通信交换数据，而现在不调用嵌入在这些通信设备中的每个通信设备中的UDP/TCP中继器；可选地，中继器可以在其响应于SYN/ACK消息而发送给第二设备的ACK消息中包括Fallback_UDP_Capable选项；在ACK消息中包括该选项使得可以明确地向第二设备指示UDP/TCP中继器确实已经接收到Fallback_UDP_Capable选项；
·另一方面，如果第二通信设备不具有建立多路径UDP通信的能力，则在步骤E’4中，两个通信设备使用常规(简单)UDP传输模式或者使用简单TCP模式或者使用MPTCP模式来交换数据，这里所选择的模式是由通信设备的先前配置产生的。
下面是此实施例的两个示例性实现方式。
根据图10中所展示的第一示例，第一通信设备是与MPTCP兼容的终端T，预订特定网络，并且第二通信设备是内容服务器S(或第二终端)，其本身也与MPTCP兼容，能够经由此网络到达。对于这两个通信设备中的每个通信设备，UDP应用与UDP/TCP中继器之间的接口未在图10中展示，仅描绘了外部交换。
根据图11和图12中所展示的第二示例性实现方式，第一通信设备是与MPTCP兼容的住宅网关CPE，在该住宅网关后面设置有与内容服务器S(或与第二终端)通信的终端T。第二通信设备是与MPTCP兼容的流量集线器C，位于网关CPE与服务器S之间的通信路径上。与前面的示例一样，UDP应用与UDP/TCP中继器之间的这些通信设备中的每个通信设备的接口未在图11和图12中展示，仅描绘了外部交换。
在图11的情况下，在如上所述建立通信之后，从服务器S接收到的UDP数据报由流量集线器C在各种可用路径之间分配并被发送到住宅网关CPE。在这些UDP数据报由住宅网关CPE接收之后，后者将其发送到终端T。
在图12的情况下，在如上所述建立通信之后，从终端T接收到的UDP数据报由住宅网关CPE在两个可用路径之间分配并被发送到流量集线器C。在这些UDP数据报由流量集线器C接收之后，后者将其传输到服务器S。
在图12所展示的情况下，住宅网关CPE插入上文描述的Order_Rank信息项(除了上下文标识符Context_ID之外)。让我们假设例如数据报“1”、“2”和“5”由住宅网关CPE经由第一路径发送，而数据报“3”、“4”、“6”和“7”经由第二路径发送。在这些各种分组由流量集线器C接收之后，后者使用Order_Rank信息项来决定是否立即将数据报中继到服务器S或者是否应该在传输该数据报之前等待其他数据报的到达。为了避免重新排序功能导致长时间的延迟，可以规定集线器在时段REORDER_MAX过去后传输排队的分组。例如，如果分组经由两个路径到达的顺序是{“1”，“2”，“5”，“3”，“4”，“6”，“7”}，则流量集线器C首先必须处理分组“1”和“2”；Order_Rank信息项值等于“5”的分组被排队，直到接收到分组“3”和“4”；一旦接收到这些分组，流量集线器C就传输数据报“5”。假设在时段REORDER_MAX内没有接收到分组“3”和“4”，则分组“5”然后被中继到其目的地，而不等待丢失的分组。
将注意的是，在此第二示例性实现方式(如图11和图12中所展示的)中，终端T和服务器S的行为类似于常规UDP通信设备；因此，其不必与多路径UDP通信兼容。
本发明可以通过软件部件和/或硬件部件在通信网络节点(例如终端、服务器、住宅网关或流量集线器)内实现。可以将所述软件部件集成到常规计算机程序中以便管理网络节点。如以上所指示的，正是由于这个原因，本发明还涉及一种计算系统。如同常规一样，此计算系统包括使用信号来控制存储器以及输入单元和输出单元的中央处理单元。此外，此计算系统可以用于执行计算机程序，该计算机程序包括用于实现根据本发明的用于传递流量集线器的负载的方法中的任何方法的指令。
具体地，本发明还针对一种如上文简要描述的计算机程序。此计算机程序可以存储在计算机可读介质上并且可以能够由微处理器执行。此程序可以使用任何编程语言并且可以采取源代码、目标代码、或在源代码与目标代码之间的中间代码的形式，如部分编译的形式或任何其他令人期望的形式。
本发明还针对一种固定的或者部分或完全可移除的信息介质，该信息介质包括如上文简要描述的计算机程序的指令。
此信息介质可以是任何能够存储程序的实体或设备。例如，该信息介质可以包括存储装置，如ROM(例如CD-ROM或微电子电路ROM)、或者磁记录装置(如硬盘或USB密匙(“USB闪存驱动器”))。
此外，该信息介质可以是可传输介质，如电信号或光信号，其可以经由电缆或光缆、通过无线电或者通过其他方式被路由。根据本发明的计算机程序可以具体在互联网网络上下载。
作为变体，该信息介质可以是其中结合了程序的集成电路，该电路被设计成用于执行根据本发明的通信方法中的任何通信方法或者在执行根据本发明的通信方法中的任何通信方法时使用。

Claims (9)

1.一种用于在IP网络中通信的方法，所述方法包括以下步骤：
a)与多路径UDP通信兼容的第一通信设备通过向第二通信设备发信号通知所述第一通信设备与基于UDP传输协议的多路径通信兼容来初始化与所述第二通信设备的通信，以及
b)如果所述第二通信设备本身也与多路径UDP通信兼容，则：
-所述第一通信设备通过在包含数据的消息中包括同一标识符来使用UDP传输协议向所述第二通信设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第二通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，和/或
所述第二通信设备通过在包含数据的消息中包括同一标识符来使用UDP传输协议向所述第一通信设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第一通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，
其中所述方法进一步包括以下步骤：
所述第一通信设备发送UDP消息，所述消息由嵌入在此第一通信设备中的中继器截取，
所述中继器向第二通信设备发送用于使用TCP传输协议建立会话的消息，所述消息包含能够向所述第二通信设备发信号通知所述第一通信设备与多路径UDP通信兼容的专用选项，以及
如果所述第二通信设备本身也与多路径UDP通信兼容，则其使用TCP传输协议发送响应消息，其在所述响应消息中插入所述专用选项，并且然后所述第一通信设备使用多路径UDP通信向所述第二通信设备发送数据和/或所述第二通信设备使用多路径UDP通信向所述第一通信设备发送数据。
2.如权利要求1所述的方法，其特征在于，所述第一通信设备和/或所述第二通信设备还在所述包含数据的消息中插入安全令牌，从而允许这些消息的接收者认证其发送者。
3.如权利要求1所述的方法，其特征在于，所述第一通信设备和/或所述第二通信设备还在所述包含数据的消息中插入信息项，从而允许这些消息的接收者按照其被发送的顺序来对其进行处理。
4.一种通信设备，称为第一通信设备，其特征在于，所述通信设备包括用于执行以下操作的装置：
通过向IP网络内的称为第二通信设备的另一通信设备发信号通知所述第一通信设备与多路径UDP通信兼容来初始化与所述第二通信设备的通信，
通过在包含数据的消息中包括同一标识符来使用UDP协议向所述第二通信设备发送这些数据，所述标识符称为上下文标识符，从而允许所述第二通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，以及
通过在包含数据的消息中检测同一标识符来使用UDP协议从所述第二通信设备接收这些数据，所述标识符称为上下文标识符，从而允许所述第一通信设备关联与同一个多路径UDP通信相关联的所有UDP数据报，
所述第一通信设备嵌入有中继器，所述中继器包括用于向第二通信设备发送用于使用TCP传输协议建立会话的消息的装置，所述消息包含能够向所述第二通信设备发信号通知所述第一通信设备与多路径UDP通信兼容的专用选项。
5.如权利要求4所述的通信设备，其特征在于，所述通信设备还包括插入装置，所述插入装置用于在其发送的所述包含数据的消息中插入安全令牌，从而允许这些消息的接收者认证其发送者。
6.如权利要求4所述的通信设备，其特征在于，所述通信设备还包括插入装置，所述插入装置用于在其发送的所述包含数据的消息中插入信息项，从而允许这些消息的接收者按照其被发送的顺序来对其进行处理。
7.如权利要求4所述的通信设备，其特征在于，所述通信设备还包括用于执行以下操作的装置：
在从称为第三通信设备的另一通信设备接收的用于使用TCP传输协议建立会话的消息中考虑能够向所述第一通信设备发信号通知所述第三通信设备与多路径UDP通信兼容的专用选项，
使用TCP传输协议发送包含所述专用选项的响应消息，以及
使用多路径UDP通信，向所述第三通信设备发送数据和/或接收由所述第三通信设备发送的数据。
8.如权利要求4所述的通信设备，其特征在于，所述通信设备包括客户端设备、内容服务器、或流量集线器。
9.一种固定的或者部分或完全可移除的数据存储装置，包括用于执行如权利要求1所述的通信方法的步骤的计算机程序代码指令。
CN201780051712.8A 2016-06-24 2017-06-16 两个终端之间的多路径udp通信方法 Active CN109644190B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1655907 2016-06-24
FR1655907A FR3053196A1 (fr) 2016-06-24 2016-06-24 Procede de communication udp via des chemins multiples entre deux terminaux
PCT/FR2017/051570 WO2017220893A1 (fr) 2016-06-24 2017-06-16 Procédé de communication udp via des chemins multiples entre deux terminaux

Publications (2)

Publication Number Publication Date
CN109644190A CN109644190A (zh) 2019-04-16
CN109644190B true CN109644190B (zh) 2022-01-11

Family

ID=56787606

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780051712.8A Active CN109644190B (zh) 2016-06-24 2017-06-16 两个终端之间的多路径udp通信方法

Country Status (6)

Country Link
US (1) US10841406B2 (zh)
EP (2) EP3476096B1 (zh)
CN (1) CN109644190B (zh)
ES (2) ES2929278T3 (zh)
FR (1) FR3053196A1 (zh)
WO (1) WO2017220893A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9665854B1 (en) * 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
FR3053197A1 (fr) 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
FR3072529B1 (fr) * 2017-10-17 2019-10-18 Sagemcom Broadband Sas Routage de donnees dans une passerelle residentielle mettant en œuvre l'agregation de liens
FR3079987A1 (fr) * 2018-04-06 2019-10-11 Orange Procede de traitement d'une transaction entre un terminal source et un terminal destinataire, systeme de services bancaires, terminal et programme d'ordinateur correspondants.
US11064384B2 (en) * 2019-02-19 2021-07-13 Mediatek Inc. Apparatuses and methods for multipath communications using a plurality of wireless technologies
US11323552B2 (en) * 2019-04-19 2022-05-03 EMC IP Holding Company LLC Automatic security configurations in disaster recovery
CN113014483B (zh) * 2019-12-19 2023-04-18 华为技术有限公司 一种多路径传输的方法及设备
CN112398943B (zh) * 2020-11-13 2022-10-21 Oppo广东移动通信有限公司 信息互通方法、装置、存储介质及电子设备
WO2022157846A1 (ja) * 2021-01-20 2022-07-28 日本電信電話株式会社 通信システム、通信方法、通信装置及びプログラム
CN112954063A (zh) * 2021-02-25 2021-06-11 福州创实讯联信息技术有限公司 一种tftp内网穿透方法及tftp服务端
CN115915108A (zh) * 2021-08-05 2023-04-04 维沃移动通信有限公司 多路径通信方法、装置及终端
CN117135754A (zh) * 2022-05-27 2023-11-28 华为技术有限公司 一种信息传输方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101895466A (zh) * 2010-07-02 2010-11-24 北京交通大学 一种降低sctp多路径传输数据包乱序影响的方法
CN102725983A (zh) * 2010-01-15 2012-10-10 京瓷株式会社 通信装置和通信方法
CN104023006A (zh) * 2014-05-09 2014-09-03 东北大学 一种基于应用层中继的多径传输系统及方法
CN104618236A (zh) * 2015-01-21 2015-05-13 网宿科技股份有限公司 一种加速网络的并行数据传输系统及方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5737328A (en) 1995-10-04 1998-04-07 Aironet Wireless Communications, Inc. Network communication system with information rerouting capabilities
FI108692B (fi) 1999-12-30 2002-02-28 Nokia Corp Menetelmä ja laite datapakettien prosessoinnin ajoittamiseksi
US20050264581A1 (en) 2004-05-21 2005-12-01 Bea Systems, Inc. Dynamic program modification
US20060274899A1 (en) * 2005-06-03 2006-12-07 Innomedia Pte Ltd. System and method for secure messaging with network address translation firewall traversal
US7978725B2 (en) 2006-03-06 2011-07-12 Cisco Technology, Inc. Dynamic modification of contention-based transmission control parameters achieving load balancing scheme in wireless mesh networks
US8630291B2 (en) 2011-08-22 2014-01-14 Cisco Technology, Inc. Dynamic multi-path forwarding for shared-media communication networks
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
US9264353B2 (en) * 2011-09-22 2016-02-16 Qualcomm Incorporated Dynamic subflow control for a multipath transport connection in a wireless communication network
KR101820583B1 (ko) * 2012-12-14 2018-01-19 텔레폰악티에볼라겟엘엠에릭슨(펍) 통신 네트워크에서 다중경로 통신 제어 프로토콜 시그널링 처리
EP2972864B1 (en) * 2013-03-15 2019-12-11 Michelle Effros Method and apparatus for improving communication performance through network coding
US9843522B2 (en) * 2014-04-09 2017-12-12 Hcl Technologies Ltd. Efficient mechanism to improve data speed between systems by MPTCP and MIMO combination
EP3198464B1 (en) * 2014-09-25 2019-02-06 Hughes Network Systems, LLC Application-aware multihoming for data traffic acceleration in data communications networks
US10038741B1 (en) 2014-11-24 2018-07-31 Amazon Technologies, Inc. Selective enabling of sequencing for encapsulated network traffic
US10069719B2 (en) 2015-06-16 2018-09-04 Samsung Electronics Co., Ltd. Method and apparatus for multipath media delivery
EP3459217B1 (en) * 2016-05-16 2020-07-08 Telefonaktiebolaget LM Ericsson (PUBL) Transporting udp packets over an mptcp connection
FR3053197A1 (fr) 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102725983A (zh) * 2010-01-15 2012-10-10 京瓷株式会社 通信装置和通信方法
CN101895466A (zh) * 2010-07-02 2010-11-24 北京交通大学 一种降低sctp多路径传输数据包乱序影响的方法
CN104023006A (zh) * 2014-05-09 2014-09-03 东北大学 一种基于应用层中继的多径传输系统及方法
CN104618236A (zh) * 2015-01-21 2015-05-13 网宿科技股份有限公司 一种加速网络的并行数据传输系统及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Multipath RTP (MPRTP) draft-ietf-avtcore-mprtp-02";V.Singh;《IETF》;20160321;正文第11.5节、7.2节、9.1节以及图2、3、8 *

Also Published As

Publication number Publication date
EP3476096A1 (fr) 2019-05-01
ES2832813T3 (es) 2021-06-11
ES2929278T3 (es) 2022-11-28
EP3739843A1 (fr) 2020-11-18
US20190273809A1 (en) 2019-09-05
EP3739843B1 (fr) 2022-07-27
CN109644190A (zh) 2019-04-16
EP3476096B1 (fr) 2020-08-26
FR3053196A1 (fr) 2017-12-29
WO2017220893A1 (fr) 2017-12-28
US10841406B2 (en) 2020-11-17

Similar Documents

Publication Publication Date Title
CN109644190B (zh) 两个终端之间的多路径udp通信方法
US11088942B2 (en) Method of QUIC communication via multiple paths
CN109644186B (zh) 用于在两个终端之间经由多路径进行udp通信的方法
CN107534605B (zh) 用于选择网络连接集中器的方法
US10356013B2 (en) Method of emulating a multipath connection
US8817815B2 (en) Traffic optimization over network link
CN110266578B (zh) 用于传输和接收包的方法和系统
US10333831B2 (en) Method of optimizing the load of a network connection concentrator
US11159423B2 (en) Techniques for efficient multipath transmission
EP4000231A1 (en) Method and system for in-band signaling in a quic session
US20170142233A1 (en) Multi-path tcp communication method between two terminals
WO2021009554A1 (en) Method and system for secured information exchange between intermediate and endpoint nodes in a communications network
US10868796B2 (en) Method of communication by multiple paths between two terminals
US11489948B2 (en) Method and system for reliable application layer data transmission through unreliable transport layer connections in a network
US20170142231A1 (en) Multi-path tcp communication method between two terminals
EP3355522B1 (en) Access aggregation system and bonding client
CN115514828A (zh) 数据传输方法及电子设备
WO2020048622A1 (en) A method, apparatus & computer program
EP4373051A1 (en) Apparatuses, methods and non-transitory computer-readable storage mediums for network access to residential gateways
Brennan Exploring Alternative Routes Using Multipath TCP

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
GR01 Patent grant