CN108243211A - 一种数据传输方法及装置 - Google Patents

一种数据传输方法及装置 Download PDF

Info

Publication number
CN108243211A
CN108243211A CN201611210824.7A CN201611210824A CN108243211A CN 108243211 A CN108243211 A CN 108243211A CN 201611210824 A CN201611210824 A CN 201611210824A CN 108243211 A CN108243211 A CN 108243211A
Authority
CN
China
Prior art keywords
stream
data packet
serial number
receiving terminal
transmitting terminal
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.)
Pending
Application number
CN201611210824.7A
Other languages
English (en)
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201611210824.7A priority Critical patent/CN108243211A/zh
Priority to EP17883793.6A priority patent/EP3544261A4/en
Priority to PCT/CN2017/104547 priority patent/WO2018113373A1/zh
Publication of CN108243211A publication Critical patent/CN108243211A/zh
Priority to US16/448,649 priority patent/US20190312938A1/en
Pending legal-status Critical Current

Links

Classifications

    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • 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]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请的实施例提供一种数据传输方法，包括接收端接收来自发送端的至少两个流，所述至少两个流中的每个流包含多个数据包，每个数据包携带所属流的流标识及流内顺序号，所述流内顺序号表示所述每个数据包在所属流内的顺序；对于至少两个流中的至少一个流，接收端确定接收到流内顺序号满足按序条件的数据包；接收端提交流内顺序号满足按序条件的数据包。实现了在流内按序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内按序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率。

Description

一种数据传输方法及装置
技术领域
本申请涉及通信领域，尤其涉及一种数据传输方法及装置。
背景技术
传输控制协议(Transmission Control Protocol，TCP)具有可靠性和按序性的要求。在TCP协议中，乱序(out-of-order)指的是序列号较大的数据包相比序列号较小的数据包先到达接收端。使用TCP协议传输数据时，要求数据包必须严格按序地向应用层提交，即按照既定的顺序提交，如按照序列号从小到达的顺序提交。如果序列号较小的某个资源、请求或者会话发生丢包情况或者延迟过长，就算序列号较大的其他独立的资源、请求或者会话被成功接收也不能往应用层提交，必须暂存在接收端的缓冲区中。这种现象为TCP协议的线头阻塞问题。如图1所示。数据包1，数据包4和6，数据包2、3和5，分别属于三个不同的资源。这三个资源通过同一个TCP连接传输，数据包的传输顺序为从1到6。当数据包1因为某种原因没有被成功接收时，就算数据包2至6按顺序被成功接收，也需要暂存在缓冲区，不能向应用层提交。
发明内容
本申请的实施例提供一种数据传输方法和装置，能够减少TCP协议的线头阻塞问题，提升数据传输的效率。
第一方面，提供了一种数据传输方法，包括接收端接收来自发送端的至少两个流，至少两个流中的每个流包含多个数据包，每个数据包携带所属流的流标识及流内顺序号，流内顺序号表示每个数据包在所属流内的顺序。对于至少两个流中的至少一个流，接收端确定接收到流内顺序号满足按序条件的数据包。所述接收端提交流内顺序号满足按序条件的数据包。
通过对传统的TCP协议进行扩展，使其支持数据多流传输，使得在流内按序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内按序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率
结合第一方面的实现方式，在第一方面第一种可能的实现方式中，对于某个流，按序条件包括流内顺序号为已提交的数据包的最大流内顺序号加1。
结合第一方面或第一方面的第一种可能的实现方式，在第二种可能实现的方式中，在接收端确定接收到流内顺序号满足按序条件的数据包之前，对于至少两个流中的每个流，接收端记录指示信息，其中，指示信息指示已提交的数据包的最大流内顺序号。
指示信息可以为已提交的数据包的最大流内顺序号。也可以为已提交的数据包的最大流内顺序号加1，表示下一个需要提交的数据包的流内顺序号。
结合第一方面或第一方面的第一种至第二种可能的实现方式中的任意一种，在第三种可能实现的方式中，对于至少两个流中的每个流，当接收端未提交过数据包时，指示信息指示已提交的数据包的流内顺序号为空。则接收端确定接收到流内顺序号满足按序条件的数据包为：接收端确定接收到具有首个流内顺序号的数据包。
已提交的数据包的流内顺序号为空表示还未提交过数据包，下一个要提交的数据包是具有首个流内顺序号的数据包。
结合第一方面或第一方面的第一种至第三种可能的实现方式中的任意一种，在第四种可能实现的方式中，每个数据包还携带流优先级标识。当接收端接收到多个流内顺序号满足按序条件的数据包时，接收端优先提交流优先级标识指示的优先级高的流内的数据包。
在接收端处理能力有限时，可能无法同时提交多个流内顺序号满足按序条件的数据包，此时，接收端会根据流优先级标识确定优先级高的数据包，优先提交这些优先级高的数据包。
结合第一方面或第一方面的第一种至第四种可能的实现方式中的任意一种，在第五种可能实现的方式中，至少两个流中的每个流对应至少一个资源。
可以通过一个流传输一个资源，这样，一个流内的数据包提交后，该流对应的资源就可以完成传输，不会受到其他未完成传输的资源的影响。
结合第一方面或第一方面的第一种至第五种可能的实现方式中的任意一种，在第六种可能实现的方式中，在接收端提交流内顺序号满足按序条件的数据包之前，接收端接收到与该满足按序条件的数据包连续的预设数量个数据包。此后，接收端提交该满足按序条件的数据包，以及与该满足按序条件的数据包连续的预设数量个数据包。
第二方面，提供了一种TCP连接的建立方法，包括接收端接收来自发送端的建立连接请求，其中，建立连接请求中携带发送端的多流能力指示参数。接收端向发送端返回建立连接应答，其中，建立连接应答中携带接收端的多流能力指示参数。接下来，接收端接收来自发送端的建立连接应答，建立与发送端之间的连接。
进行多流能力协商可以更好的处理与传统TCP协议的兼容问题，而且在多流能力协商后建立了支持多流传输的连接，能够避免现有技术建立多条TCP连接进行数据传输带来的服务器负载压力大、初始时延长的问题。
结合第二方面的实现方式，在第二方面第一种可能的实现方式中，接收端的多流能力指示参数包括接收端允许的最大输入流的数量。接收端接收的来自发送端的流的数量小于等于接收端允许的最大输入流的数量。
结合第二方面或第二方面的第一种可能的实现方式，在第二种可能实现的方式中，发送端的多流能力指示参数包括发送端允许的最大输入流的数量，接收端向发送端发送的流的数量小于等于发送端允许的最大输入流的数量。
发送端和接收端允许的最大输入流的数量不一定相同。发送端和接收端通过协商确定对方允许的最大输入流的数量，在后续数据传输过程中，发送端和接收端向对方发送不超过对方允许的最大输入流数量的流。
第三方面，提供了一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述计算设备执行第一方面及第一方面任一可能的实现方式所述的方法。
第四方面，提供了一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述计算设备执行第二方面及第二方面任一可能的实现方式所述的方法。
第五方面，提供了一种计算机可读存储介质，其中存储有可执行的程序代码，该程序代码用以实现第一方面及第一方面的任意一种可能的实现方式所述的方法。
第六方面，提供了一种计算机可读存储介质，其中存储有可执行的程序代码，该程序代码用以实现第二方面及第二方面的任意一种可能的实现方式所述的方法。
第七方面，提供了一种数据传输装置，包含用于执行第一方面及第一方面的任意一种可能的实现方式中的方法的模块。
第八方面，提供了一种TCP连接的建立装置，包含用于执行第二方面及第二方面的任意一种可能的实现方式中的方法的模块。
根据本申请实施例提供的技术方案，通过对传统的TCP协议进行扩展，使其支持多流能力协商以及数据多流传输，使得在流内按序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内按序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率。同时，相比于建立多条TCP连接，每条独立的TCP连接都需要通过三次握手来建立，本申请实施例提供的技术方案可以有效减少TCP连接的数量，从而减少服务器的负载压力，并且能够有效减少建立连接产生的初始时延。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1是现有技术中线头阻塞现象的示意图；
图2是依据本申请一实施例的网络架构的示意图；
图3是依据本申请一实施例的计算机设备300的硬件结构示意图；
图4是依据本申请一实施例的多流TCP连接建立方法400的示范性流程图；
图5是依据本申请一实施例的TCP可选项的封装格式示意图；
图6是依据本申请一实施例的扩展的多流TCP能力协商的可选项的封装格式示意图；
图7是依据本申请一实施例的多流TCP能力协商的示范性流程图；
图8是依据本申请一实施例的数据传输方法800的示范性流程图；
图9是依据本申请一实施例的扩展的多流传输的可选项的封装格式示意图；
图10是依据本申请一实施例的数据传输方法的示范性流程图；
图11是依据本申请一实施例的数据传输方法的示意图；
图12是依据本申请一实施例的数据传输方法的示意图；
图13是依据本申请一实施例的数据传输装置1300的结构示意图；
图14是依据本申请一实施例的数据传输装置1400的结构示意图。
具体实施方式
图2是依据本申请一实施例的网络架构的示意图。在图2中，发送端201与接收端202之间通过本申请提供的多流TCP连接203进行数据传输。本申请中多流TCP连接指的是能够同时传输两个或两个以上流的TCP连接。现有技术中的TCP连接不支持同时传输两个或两个以上的流，而本申请通过对TCP协议的扩展，可以使得TCP连接上可以同时传输两个或两个以上的流。发送端201可以为终端或服务器，接收端202也可以为终端或服务器。支持多流的TCP连接203中，应用层中不同的资源在传输层中可以通过不同的流传输，这样某一个流中的数据包的传输并不会因为传输层面其他流乱序的数据包而造成延迟，只要保证数据流内的数据包是按序的，就可以向应用层提交。例如发送端201为网页服务器，接收端202为平板电脑时，网页和图片能够通过不同的流传输，不需等待网页传输完成，图片资源就能够通过其他的流传输，从而提高传输效率，改善用户体验，避免或减少线头阻塞的问题。图2中示出了流1至流n，用Stream 1，Stream 2，Stream 3及Stream n表示。资源可以为图片、音频、视频、文字、会话、请求等。
应理解，在本申请实施例中，终端可称为用户设备(User Equipment，UE)、接入终端、终端设备、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、无线通信设备、用户代理或用户装置。终端可以是蜂窝电话、无绳电话、会话启动协议(Session Initiation Protocol，SIP)电话、无线本地环路(Wireless Local Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备以及未来新无线(New Radio，NR)网络中的终端设备等。
发送端201和接收端202可以通过计算机设备的形式实现。图3是依据本申请一实施例的计算机设备300的硬件结构示意图。如图3所示，计算机设备300包括处理器302、存储器304、通信接口306和总线308。其中，处理器302、存储器304和通信接口306通过总线308实现彼此之间的通信连接。
处理器302可以采用通用的中央处理器(Central Processing Unit，CPU)，微处理器，应用专用集成电路(Application Specific Integrated Circuit，ASIC)，或者一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。
存储器304可以是只读存储器(Read Only Memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(Random Access Memory，RAM)。存储器304可以存储操作系统3041和其他应用程序3042。在通过软件或者固件来实现本申请实施例提供的技术方案时，用于实现本申请实施例提供的技术方案的程序代码保存在存储器304中，并由处理器302来执行。
通信接口306使用例如但不限于收发器一类的收发装置，来实现与其他设备或通信网络之间的通信。
总线308可包括一通路，在各个部件(例如处理器302、存储器304、通信接口306)之间传送信息。
当计算机设备300是接收端202时，处理器302执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图4和图7实施例所示的方法。
当计算机设备300是接收端202时，处理器302还可以执行存储器304中保存的用于实现本申请实施例提供的技术方案的程序代码，以实现图8实施例所示的方法。
本申请实施例中，通过对TCP协议进行扩展，使得扩展后的TCP协议支持多流传输，能够有效减少线头阻塞的发生。下面就结合具体实现，说明多流TCP连接的建立过程以及如何通过多流TCP连接进行多流传输。
图4是依据本发明一实施例的多流TCP连接建立方法400的示范性流程图，以下结合具体步骤说明如何在发送端和接收端进行多流TCP能力的协商，从而建立多流TCP连接。多流TCP连接建立方法400可以由图2所示的发送端201和接收端202来执行。
S401，发送端向接收端发送建立连接请求，所述建立连接请求中携带所述发送端的多流能力指示参数。
S402，接收端向发送端返回建立连接应答，所述建立连接应答中携带所述接收端的多流能力指示参数。
S403，发送端根据所述接收端的多流能力指示参数确定所述接收端支持多流TCP能力，向所述接收端返回建立连接应答，建立与所述接收端之间的多流TCP连接。
具体的，在上述方法中需要对传统的TCP协议进行扩展，以支持多流TCP能力协商功能。例如，可以通过扩展TCP的可选项来实现。一般来说，可选项的封装格式如图5所示，包括可选项类型Kind，可选项长度Length，子类型subtype，以及子类型具体数据subtype-specific-data。其中，可选项类型Kind字段表示需要扩展的功能名称，占8位，有256种可能，如Kind＝0X3表示选择性应答(Selective Acknowledgement，SACK)功能。我们可以定义可选项类型Kind＝MSTCP，来表示本端支持多流TCP(multi-streaming transport controlprotocol)，值大小可以由互联网数字分配局(Internet Assigned Numbers Authority，IANA)或者其他机构进行分配。
在S401和S402中，携带的多流能力指示参数可以为MSTCP。在接收端接收到来自发送端的携带MSTCP字段的建立连接请求时，接收端确定发送端支持多流TCP能力。在发送端接收到来自接收端的携带MSTCP字段的建立连接应答时，发送端确定接收端支持多流TCP能力。然后发送端向接收端返回建立连接应答，建立与接收端之间的多流TCP连接。
在MSTCP可选项中，可以进一步定义子类型subtype＝MS_CAPABLE，表示用于多流TCP能力协商的可选项，以进行多流TCP能力协商。MS_CAPABLE的值大小由IANA分配。通过在MS_CAPABLE的子类型具体数据(subtype-specific-data)中承载信息，实现多流TCP能力的协商。这些信息可以包括flags，发送端的key信息，接收端的key信息，本端允许的最大输入流的数量(maximum number of accepted inbound streams)等。其中，key信息用于身份鉴权以及后续操作的鉴权。key信息的产生方式不唯一，但需要足够的随机以防被破译。key信息可以由不同的加密算法产生，如键控哈希加密算法(Hash Message AuthenticationCode-Secure Hash Algorithm 1，HMAC-SHA1)等。由flags来标识产生key信息的加密算法。在TCP的三次握手过程中，前两次握手阶段发送端和接收端只发送本端的key信息，在第三次握手时发送端向接收端发送两对端的key信息。本端允许的最大输入流的数量表示本端的处理能力，在进行多流传输时，本端接收的流的数量不能超过本端允许的最大输入流的数量。
例如，发送端允许的最大输入流的数量为3，接收端允许的最大输入流的数量为5。在发送端和接收端之间建立了连接后，发送端向接收端发送的流的数量可以为1,2,3,4,5，但不能超过5。接收端向发送端发送的流的数量可以为1,2,3，但不能超过3。
扩展的多流TCP能力协商的可选项的封装格式如图6所示。其中，payload userdata是指实际的负载用户数据，即上层应用的数据。
需要说明的是，以上子类型具体数据中的参数对于本申请来说都是可选的实现，例如对于本端允许的最大输入流的数量，也可以通过预先约定或者配置的方式确定好。
下面结合一个具体的实现实例，说明多流TCP连接的建立过程。
如图7所示，在扩展了多流TCP能力协商的可选项之后，多流TCP连接的建立过程可以包括能力协商过程，如S701，S702，S703所示。
S701，请求建立多流TCP连接的发送端A将请求同步标识(Synchronous，SYN)标志位置1，并随机产生一个顺序号(Sequence Number，SEQ)，SEQ＝J，向接收端B发送建立多流TCP连接请求，其中携带了上述扩展的多流TCP能力协商的可选项MS_CAPABLE，包括发送端A的key信息，flags，以及发送端A允许的最大输入流的数量。
S702，在接收到来自发送端A的多流TCP连接请求后，接收端B根据发送端A发送的多流TCP能力协商的可选项MS_CAPABLE确定发送端A支持多流TCP能力，并且得到了发送端A允许的最大输入流的数量。接收端B将SYN标志位置1，将确认同步标识(Acknowledgement，ACK)置1，随机产生一个SEQ，SEQ＝K，并将确认号(acknowledgement number，ack)设置为J+1，向发送端A返回建立多流TCP连接应答，其中携带了上述扩展的多流TCP能力协商的可选项MS_CAPABLE，包括接收端B的key信息，flags，以及接收端B允许的最大输入流的数量。
S703，发送端A根据接收端B返回的多流TCP能力协商的可选项MS_CAPABLE确定接收端B支持多流TCP能力，并且得到了接收端B允许的最大输入流的数量。发送端A将ACK标志位置1，ack设置为K+1(即接收端B的SEQ加1)，并记录发送端A的key信息与接收端B的key信息，向接收端B返回建立多流TCP连接应答，其中携带了扩展的多流TCP能力协商的可选项MS_CAPABLE，包括发送端A的key信息，接收端B的key信息以及flags。
此后，发送端A和接收端B之间完成了多流TCP能力协商，建立了多流TCP连接。
图8是依据本申请一实施例的数据传输方法800的示范性流程图。在本实施例中，数据传输方法800可以由图2所示的发送端201和接收端202来执行。
S801，发送端获取待发送的至少两个资源，每个资源通过一个流传输。每个资源被分成数据包通过流传输。发送端为每个流分配流标识，每个流中的数据包携带所属流的流标识以及流内顺序号。流内顺序号表示数据包在所属流内的顺序。
一个流也可以传输多个资源，在本实施例中，以一个流传输一个资源为例进行说明。
S802，发送端向接收端发送传输至少两个资源的至少两个流。
S803，接收端接收来自发送端的至少两个流。
具体的，发送端通过多流TCP连接向接收端发送传输至少两个资源的至少两个流。
在通过多流TCP连接进行数据传输的方法中，需要对传统的TCP协议进行扩展，以支持数据的多流传输功能。可以通过扩展TCP的可选项来实现。
可以在上述MSTCP可选项中定义子类型subtype＝MS_DATA，表示用于数据多流传输的可选项。在MS_DATA的子类型具体数据中定义流标识(Stream Identifier)，用于唯一的标示某个流。定义流内顺序号(Stream Data Sequence Number，SDSN)，用于标示流内数据包的顺序。还可以定义流优先级标识(Stream Priority Identifier)，用于标示某个流的优先级。流优先级标识用来保证优先级较高的流的优先传输，提升用户对上层应用的体验。另外，由于数据包的大小可能会超过TCP允许的最大字节数，因此需要将一个数据包分割成多个数据包。可以定义标志位B，表示分割的数据包的第一个封包；定义标志位E，表示分割的数据包的最后一个封包。标志位B和E取值的含义如表1所示。
表1标志位B和标志位E的含义
此外，还可以在MS_DATA的子类型具体数据中定义标志位U，用来表示流是否可以无序提交。如果标志位U有效，则该流的数据包一旦被成功接收就提交。如果标志位U无效，则该流的数据包需要按序提交，按照SDSN的顺序提交。
上述对标志位B，E，U的描述中，“有效”可以用标志位置1来表示，“无效”可以用标志位置0来表示；或者，“有效”可以用标志位置0来表示，“无效”可以用标志位置1来表示。
扩展的多流传输的可选项的封装格式如图9所示。
发送端通过多流TCP连接向接收端发送的数据包中携带上述扩展的多流传输的可选项，其中流标识Stream Identifier用来携带发送端为每个流分配的流标识，SDSN用来携带该数据包在所属流中的流内顺序号。例如，发送端通过多流TCP连接向接收端发送了3个流，流标识分别为Stream 1，Stream 2，Stream 3，属于Stream 1的数据包的StreamIdentifier的值为Stream 1，属于Stream 2的数据包的Stream Identifier的值为Stream2，属于Stream 3的数据包的Stream Identifier的值为Stream 3，。Stream 1的数据包的SDSN从0到199；Stream 2的数据包的SDSN从0到399；Stream 3的数据包的SDSN从0到499。
S804，对于至少两个流中的每个流，接收端根据已提交的数据包的流内顺序号以及接收到的数据包的流内顺序号，确定接收到的数据包的流内顺序号是否满足按序条件。
S805，接收端提交流内顺序号满足按序条件的数据包。
对于某个流，所述按序条件包括流内顺序号为已提交的数据包的最大流内顺序号加1。其中，1指数据包的数量。例如，对于Stream 1，已提交的数据包的最大流内顺序号为10，则对于Stream 1，接收到流内顺序号满足按序条件的数据包，包括接收到流内顺序号为10的数据包的下一个数据包，即流内顺序号为11的数据包。又例如，当流内顺序号通过数据包携带的数据量表示，并且一个数据包携带的数据量为576个字节时，对于Stream 1，如果已提交的数据包的最大流内顺序号为5760，则对于Stream 1，接收到流内顺序号满足按序条件的数据包，包括接收到流内顺序号比流内顺序号为5760的数据包大576个字节的数据包，即流内顺序号为6336的数据包。
在所述接收端确定接收到流内顺序号满足按序条件的数据包之前，对于所述至少两个流中的每个流，所述接收端记录指示信息，所述指示信息指示已提交的数据包的最大流内顺序号。
对于所述至少两个流中的每个流，当所述接收端未提交过数据包时，所述指示信息指示已提交的数据包的流内顺序号为空；则所述接收端确定接收到流内顺序号满足按序条件的数据包为：所述接收端确定接收到具有首个流内顺序号的数据包。
接收端接收到数据包后，确定接收到的数据包的SDSN。如果接收到的数据包的SDSN为所属流中的首个流内顺序号，则接收端提交该数据包。例如，接收端接收到流标识为Stream 2且SDSN为0的数据包，接收端确定SDSN为0是Stream 2中的首个流内顺序号，接收端提交该数据包。在提交了该数据包后，接收端记录指示信息，该指示信息指示已提交Stream 2中SDSN为0的数据包。如果接收端接收到的数据包的SDSN不是所属流中的首个流内顺序号，例如接收到流标识为Stream 2且SDSN为10的数据包，则接收端确定是否已提交SDSN比接收到的数据包的SDSN小1的数据包，例如确定是否已提交Stream 2中SDSN为9的数据包。如果已提交SDSN比接收到的数据包的SDSN小1的数据包，则接收端提交该接收到的数据包。例如，如果已提交Stream 2中SDSN为9的数据包，则接收端提交接收到的Stream 2中的SDSN为10的数据包。接收端记录指示信息，指示已提交Stream 2中的SDSN为10的数据包。对于Stream 2，指示信息可以为SDSN＝10或者SDSN＝11，表示已提交SDSN为10的数据包，也能够表示下一个要提交的数据包是Stream 2中SDSN为11的数据包。
需要说明的是，如果接收端未提交过数据包，则指示信息指示空，指示信息可以为null或者为首个流内顺序号。例如，接收端未提交过Stream 2中的数据包，则指示信息可以为SDSN＝null或者SDSN＝0，表示未提交过属于Stream 2的数据包，也能够表示下一个要提交的数据包是Stream 2中SDSN为首个流内顺序号的数据包。
每个数据包还可以携带流优先级标识；当所述接收端接收到多个流内顺序号满足按序条件的数据包时，所述接收端优先提交所述流优先级标识指示的优先级高的流内的数据包。
例如，接收端接收到Stream 1的SDSN为20的数据包，以及Stream 2的SDSN为10的数据包。此前已经提交了Stream 1的SDSN为19的数据包，以及Stream 2的SDSN为9的数据包。当接收端当前的处理能力有限时，如果Stream 2的优先级比Stream 1的优先级高，则接收端先提交Stream 2的SDSN为9的数据包。
所述每个数据包还可以携带传输顺序号，所述传输顺序号表示所述每个数据包在所有数据包中的顺序；在所述接收端接收到来自所述发送端的数据包后，所述方法还包括：所述接收端向所述发送端返回接收应答，所述接收应答中携带指示参数，所述指示参数指示所述流内顺序号满足按序条件的数据包的传输顺序号。
本申请实施例提供的技术方案中，通过多流TCP连接传输的数据包可以携带传输顺序号。可以认为传输顺序号是现有技术中的序列号(sequence number，SEQ)。传输顺序号并不区分流，是所有流中的数据包在整体中的排序。
图10是依据本申请一实施例的数据传输方法的示范性流程图。在图10中，发送端Host A与接收端Host B都支持多流TCP能力，在Host A与Host B之间已经建立了多流TCP连接。Host A通过多流TCP连接向Host B发送了3个流，流标识分别为Stream 1，Stream 2，Stream 3。Stream 1的数据包的SEQ为100-299，SDSN为0-199；Stream 2的数据包的SEQ为300-499以及700-899，SDSN为0-399；Stream 3的数据包的SEQ为500-699以及900-1199，SDSN为0-499。Stream 1，Stream 2，Stream 3通过建立的多流TCP连接传输。
Host A在某时刻发送SEQ为100-499的数据包，其中，SEQ为100-299，SDSN为0-199的数据包属于Stream 1；SEQ为300-499，SDSN为0-199的数据包属于Stream 2。由于网络延时过长或者传输丢包等原因，属于Stream 1的数据包没有被Host B成功接收，如图中F1处所示，Host B只成功接收到属于Stream 2的SEQ为300-499的数据包，如图中S1处所示。在提交接收到的数据包之前，Host B确定未提交过Stream 2中的数据包，下一个要提交的数据包是Stream 2中SDSN为0的数据包。Host B据此确定可以提交接收到的属于Stream 2的SDSN为0-199的数据包。Host B提交属于Stream 2的SDSN为0-199的数据包。
虽然SEQ为300-499的数据包在所有数据包的排列顺序中是乱序的，即在整个TCP的连接层面上是乱序的，但是SEQ为300-499的数据包是Stream 2中的SDSN为0-199的数据包。对于Stream 2来说，这些数据包是按序的，可以向应用层提交。这样一来，接收端缓冲区就不需要缓存SEQ为300-499的数据包，无需等待SEQ为100-299的数据包成功接收才能提交SEQ为300-499的数据包。释放了缓存空间，提升了数据传输效率。应用层无需等到Stream 1的数据传输完成就能处理Stream 2，提升了应用的体验质量。
在接收到属于Stream 2的SEQ为300-499的数据包后，Host B会发送选择性应答(SACK)给Host A，如图中A1处所示。SACK的格式为ACK:100，SACK:300-499，表示连续接收到的数据包的最大传输顺序号SEQ为99，下一个期待接收的数据包的传输顺序号SEQ为100，乱序到达缓存在接收端的数据包的SEQ为300-499。Host B记录Stream 2中已提交的数据包的最大流内顺序号为SDSN＝199。
在接收到来自Host B的SACK消息后，Host A接着发送SEQ为500-899的数据包。其中，SEQ为500-699，SDSN为0-199的数据包属于Stream 3；SEQ为700-899，SDSN为200-399的数据包属于Stream 2。同样地，由于网络延时过长或者传输丢包等原因，属于Stream 3的数据包没有被Host B成功接收，如图中F2处所示，Host B只成功接收到属于Stream 2的SEQ为700-899的数据包，如图中S2处所示。Host B根据之前记录的Stream 2中已提交的数据包的最大流内顺序号SDSN＝199，确定可以提交接收到的属于Stream 2的SDSN为200-399的数据包。Host B提交属于Stream 2的SDSN为200-399的数据包。Host B记录Stream 2中已提交的数据包的最大流内顺序号为SDSN＝399。
在接收到属于Stream 2的SDSN为200-399的数据包后，Host B会发送SACK给HostA，如图中A2处所示。SACK的格式为ACK:100，SACK:300-499，700-899，表示连续接收到的数据包的最大传输顺序号SEQ为99，下一个期待接收的数据包的传输顺序号SEQ为100，乱序到达缓存在接收端的数据包的SEQ为300-499，700-899。对于SEQ为700-899的数据包来说，虽然在所有数据包的排列顺序中是乱序的，即在整个TCP的连接层面上是乱序的，但是SEQ为700-899的数据包是Stream 2中的SDSN为200-399的数据包。对于Stream 2来说，由于已经提交了SDSN为0-199的数据包，因此SDSN为200-399的数据包是按序的，可以向应用层提交。这样，释放了接收端的缓存空间。
Host A在接收到来自Host B的SACK消息后，发送SEQ为900-1199的数据包。这些数据包都属于Stream 3。其中，由于网络延时过长或者传输丢包等原因，SEQ为900-1099的数据包没有被Host B成功接收，如图中F3处所示。Host B只成功接收到SEQ为1100-1199的数据包，如图中S3处所示。在提交接收到的数据包之前，Host B确定未提交过Stream 3中的数据包，下一个要提交的数据包是Stream 3中SDSN为0的数据包。由于未成功接收到Stream 3中SDSN为0-399的数据包，Host B据此确定接收到的Stream 3中的SDSN为400-499的数据包不满足按序条件，因此需要将Stream 3的SDSN为400-499的数据包缓存在接收端缓冲区里，待Stream 3中SDSN为0-399的数据包被成功接收并提交后才能够提交。
在接收到属于Stream 3的SDSN为400-499的数据包后，Host B会发送SACK给HostA，如图中A3处所示。SACK的格式为ACK:100，SACK:300-499，700-899，1100-1199。表示连续接收到的数据包的最大传输顺序号SEQ为99，下一个期待接收的数据包的传输顺序号SEQ为100，乱序到达缓存在接收端的数据包的SEQ为300-499，700-899，1100-1199。进一步的，Host A在接收到连续三个具有相同ACK传输顺序号的SACK应答后，会触发TCP协议的快速重传，重新传输SEQ为100-299的数据包，如图中Fast retransmission所示。
从本实施例可以看出，接收端缓冲区只需要缓存SEQ为1100-1199，SDSN为400-499的数据包，而SEQ为300-499以及SEQ为700-899的数据包在Stream 2内是按序的，可以往应用层提交，不会因为在整个TCP的连接层面上的乱序而导致需要在缓冲区进行缓存。而对于传统的TCP协议来说，则需要把所有在连接层面乱序的数据包，即SEQ为300-499，700-899，1100-1199的数据包，都缓存在接收端缓冲区中，占据了大量的接收端缓存空间。而且，由于接收端剩余的缓存空间大小会影响发送端可以发送的最大数据量，因此还会进一步影响传输效率和上层应用的体验。
根据本申请实施例提供的技术方案，通过对传统的TCP协议进行扩展，使其支持多流能力协商以及数据多流传输，使得在流内按序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内按序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率。同时，相比于建立多条TCP连接，每条独立的TCP连接都需要通过三次握手来建立，本申请实施例提供的技术方案可以有效减少TCP连接的数量，从而减少服务器的负载压力，并且能够有效减少建立连接产生的初始时延。
图11是依据本申请一实施例的数据传输方法的示意图。在图11实施例中，本申请提供的数据传输方法应用于基于超文本传输协议(Hyper Text Transport Protocol，HTTP)的web业务。每个网页会包括不同的资源，如文字，视频，图片等。当客户端启动浏览器输入网址等待响应时：
首先，客户端会在传输层与web服务器建立端到端的多流TCP连接。客户端会根据图4实施例所示，构造请求建立多流TCP连接的数据包，即将TCP报头中的SYN标志位置1，随机产生一个SEQ，SEQ＝J，以及产生标识客户端身份的key信息。客户端扩展TCP能力协商的可选项，扩展kind＝MSTCP字段，subtype为MS_CAPABLE，并设置允许的最大输入流的数量maximum number of accepted inbound streams字段。建立多流TCP连接请求中能力协商可选项的封装格式如图6所示。客户端向web服务器发送建立多流TCP连接请求。
当web服务器支持多流TCP能力时，web服务器向客户端返回建立多流TCP连接应答。应答中将SYN和ACK标志位置1，随机产生一个SEQ，SEQ＝K，产生标识web服务器身份的key信息，并设置ack＝J+1。web服务器扩展TCP能力协商的可选项，扩展kind＝MSTCP字段，subtype为MS_CAPABLE。web服务器根据当前负载和处理能力设置允许的最大输入流的数量maximum number of accepted inbound streams。Web服务器返回的建立多流TCP连接应答中能力协商可选项的封装格式如图6所示。web服务器向客户端返回指示支持多流TCP能力的建立多流TCP连接应答。
客户端接收到web服务器返回的指示支持多流TCP能力的应答后，相应的返回应答。在客户端返回的应答中，ACK标志位置1，ack＝K+1，同时将客户端的key信息和web服务器的key信息包含在如图6所示的可选扩展项中。至此，客户端与web服务器之间的端到端的传输层多流TCP连接已经建立，可以进行数据的多流传输了。
本实施例中，假设客户端请求的有视频，图片，文字三种独立的资源(不一定是三个，可以是多个)。其中，假设视频的优先级最高，文字的优先级次之，图片的优先级最低。服务器同时向客户端发送视频、图片、文字资源数据。其中，视频资源的流优先级标识(streampriority identifier)为X1，随机产生一个唯一的流标识(stream identifier)为S1。文字资源的流优先级标识为X2，流标识为S2；图片资源的流优先级标识为X3，流标识为S3。其中，S1≠S2≠S3，X1<X2<X3(本实施例中认为值越小优先级越高)。
对于每个待发送的数据包，web服务器通过流标识stream identifier字段来标识该数据包所属的流；通过SDSN字段来标识该数据包在所属流内的顺序。客户端在接收到来自服务器的数据时，首先根据流标识确定数据包所属的流，然后，根据已提交的数据包的SDSN以及接收到的数据包的SDSN，判断接收到的数据包是否在所属流内按序。如果在流内按序，就提交给上层浏览器处理，否则缓存在客户端的缓冲区中。之后，客户端通过SACK告知web服务器收到的乱序的数据包以及下一个期望的数据包。一种可能的数据传输过程如图9所示。
这样，视频，图片，文字资源之间的传输不会相互影响，同时又保证了每个资源都能可靠地到达客户端，以及优先级高的资源优先传输。减少了线头阻塞，提升上层应用的体验质量。
图12是依据本申请一实施例的数据传输方法的示意图。在图12施例中，本申请提供的数据传输方法应用于信令网络下的基于diameter协议的信令交互。在一个diameter客户端(diameter client)和diameter服务器端(diameter server)之间会存在大量并发独立的会话session 1，session 2，session 3，这些会话可能属于不同的用户。首先，diameter客户端与diameter服务器的建立多流TCP连接，具体过程可以参考图4实施例S401，S402和S403，此处不再赘述。然后，diameter客户端会给每个diameter会话分配流标识，一个流中可以只包含一个diameter会话，也可以包含多个diameter会话。当服务器接收到的会话在所属流内按序时，服务器向上层提交按序的会话。进一步的，可以为某些紧急的会话或者签约的用户提供较高的优先级，以提升这些会话的传输效率和相应用户的体验质量。具体过程可以参考图8实施例S801至S804，此处不再赘述。
图13是依据本申请一实施例的数据传输装置1300的结构示意图。数据传输装置1300包括接收模块1301，处理模块1302，发送模块1303。数据传输装置1300可以为图2中的接收端202，图3中的计算机设备，图4和图8中的接收端，图7中的接收端B，或者图10中的Host B。接收模块1301可以用来执行图8实施例中的S803，处理模块1302可以用来执行图8实施例中的S804，发送模块1303可以用来执行图8实施例中的S805。
接收模块1301，用于接收来自发送端的至少两个流，所述至少两个流中的每个流包含多个数据包，每个数据包携带所属流的流标识及流内顺序号，所述流内顺序号表示所述每个数据包在所属流内的顺序。
处理模块1302，用于对于所述至少两个流中的至少一个流，确定接收到流内顺序号满足按序条件的数据包。
发送模块1303，用于提交所述流内顺序号满足按序条件的数据包。
对于某个流，所述按序条件包括流内顺序号为已提交的数据包的最大流内顺序号加1。
在处理模块1302确定接收到流内顺序号满足按序条件的数据包之前，对于所述至少两个流中的每个流，处理模块1302可以用于记录指示信息，所述指示信息指示已提交的数据包的最大流内顺序号。
对于所述至少两个流中的每个流，当发送模块1303未提交过数据包时，所述指示信息指示已提交的数据包的流内顺序号为空；则处理模块1302确定接收到流内顺序号满足按序条件的数据包为：处理模块1302确定接收到具有首个流内顺序号的数据包。
所述每个数据包还可以携带流优先级标识；当接收模块1301接收到多个流内顺序号满足按序条件的数据包时，发送模块1303优先提交所述流优先级标识指示的优先级高的流内的数据包。
所述至少两个流中的每个流对应至少一个资源。
根据本申请实施例提供的技术方案，通过对传统的TCP协议进行扩展，使其支持多流能力协商以及数据多流传输，使得在流内有序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内有序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率。同时，相比于建立多条TCP连接，每条独立的TCP连接都需要通过三次握手来建立，本申请实施例提供的技术方案可以有效减少TCP连接的数量，从而减少服务器的负载压力，并且能够有效减少建立连接产生的初始时延。
图14是依据本申请一实施例的TCP连接的建立装置1400的结构示意图。数据传输装置1400包括接收模块1401和发送模块1402。数据传输装置1400可以为图2中的接收端202，图3中的计算机设备，图4和图8中的接收端，图7中的接收端B，或者图10中的Host B。
接收模块1401，用于接收来自发送端的建立连接请求，所述建立连接请求中携带所述发送端的多流能力指示参数。
发送模块1402，用于向所述发送端返回建立连接应答，所述建立连接应答中携带接收端的多流能力指示参数。
接收模块1401，用于接收来自所述发送端的建立连接应答，建立与所述发送端之间的连接。
所述接收端的多流能力指示参数包括所述接收端允许的最大输入流的数量，所述接收模块接收的来自所述发送端的流的数量小于等于所述接收端允许的最大输入流的数量。
所述发送端的多流能力指示参数包括所述发送端允许的最大输入流的数量，所述发送模块向所述发送端发送的流的数量小于等于所述发送端允许的最大输入流的数量。
根据本申请实施例提供的技术方案，通过对传统的TCP协议进行扩展，使其支持多流能力协商以及数据多流传输，使得在流内有序的数据包可以直接向应用层提交，在整个连接层面上的乱序不影响流内有序的数据包的提交。有效减少了线头阻塞的发生，提升了数据传输的效率。同时，相比于建立多条TCP连接，每条独立的TCP连接都需要通过三次握手来建立，本申请实施例提供的技术方案可以有效减少TCP连接的数量，从而减少服务器的负载压力，并且能够有效减少建立连接产生的初始时延。
其中，图13和图14实施例中的“模块”可以为专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、电子线路、执行一个或多个软件或固件程序的处理器和存储器、组合逻辑电路和其他提供上述功能的组件。可选的，上述数据传输装置和TCP连接的建立装置通过计算机设备的形式来实现，上述接收模块、发送模块可以通过计算机设备的处理器、存储器和通信接口来实现，上述处理模块可以通过计算机设备的处理器和存储器来实现。
应注意，尽管图3所示的计算机设备300仅仅示出了处理器302、存储器304、通信接口306和总线308，但是在具体实现过程中，本领域的技术人员应当明白，上述数据传输装置和TCP连接建立装置还包含实现正常运行所必须的其他器件。同时，根据具体需要，本领域的技术人员应当明白，上述数据传输装置和TCP连接建立装置还可包含实现其他附加功能的硬件器件。此外，本领域的技术人员应当明白，上述数据传输装置和TCP连接建立装置也可仅仅包含实现本申请实施例所必须的器件，而不必包含图3中所示的全部器件。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (20)

1.一种数据传输方法，其特征在于，包括以下步骤：
接收端接收来自发送端的至少两个流，所述至少两个流中的每个流包含多个数据包，每个数据包携带所属流的流标识及流内顺序号，所述流内顺序号表示所述每个数据包在所属流内的顺序；
对于所述至少两个流中的至少一个流，所述接收端确定接收到流内顺序号满足按序条件的数据包；
所述接收端提交所述流内顺序号满足按序条件的数据包。
2.根据权利要求1所述的方法，其特征在于，对于某个流，所述按序条件包括流内顺序号为已提交的数据包的最大流内顺序号加1。
3.根据权利要求1或2所述的方法，其特征在于，在所述接收端确定接收到流内顺序号满足按序条件的数据包之前，对于所述至少两个流中的每个流，所述接收端记录指示信息，所述指示信息指示已提交的数据包的最大流内顺序号。
4.根据权利要求3所述的方法，其特征在于，对于所述至少两个流中的每个流，当所述接收端未提交过数据包时，所述指示信息指示已提交的数据包的流内顺序号为空；则所述接收端确定接收到流内顺序号满足按序条件的数据包为：所述接收端确定接收到具有首个流内顺序号的数据包。
5.根据权利要求1至4任意一项所述的方法，其特征在于，所述每个数据包还携带流优先级标识；当所述接收端接收到多个流内顺序号满足按序条件的数据包时，所述接收端优先提交所述流优先级标识指示的优先级高的流内的数据包。
6.根据权利要求1至5任意一项所述的方法，其特征在于，所述至少两个流中的每个流对应至少一个资源。
7.一种TCP连接的建立方法，其特征在于，包括以下步骤：
接收端接收来自发送端的建立连接请求，所述建立连接请求中携带所述发送端的多流能力指示参数；
所述接收端向所述发送端返回建立连接应答，所述建立连接应答中携带所述接收端的多流能力指示参数；
所述接收端接收来自所述发送端的建立连接应答，建立与所述发送端之间的连接。
8.根据权利要求7所述的方法，其特征在于，所述接收端的多流能力指示参数包括所述接收端允许的最大输入流的数量，所述接收端接收的来自所述发送端的流的数量小于等于所述接收端允许的最大输入流的数量。
9.根据权利要求7或8所述的方法，其特征在于，所述发送端的多流能力指示参数包括所述发送端允许的最大输入流的数量，所述接收端向所述发送端发送的流的数量小于等于所述发送端允许的最大输入流的数量。
10.一种数据传输装置，其特征在于，包括：接收模块，处理模块和发送模块：
所述接收模块，用于接收来自发送端的至少两个流，所述至少两个流中的每个流包含多个数据包，每个数据包携带所属流的流标识及流内顺序号，所述流内顺序号表示所述每个数据包在所属流内的顺序；
所述处理模块，用于对于所述至少两个流中的至少一个流，确定接收到流内顺序号满足按序条件的数据包；
所述发送模块，用于提交所述流内顺序号满足按序条件的数据包。
11.根据权利要求10所述的装置，其特征在于，对于某个流，所述按序条件包括流内顺序号为已提交的数据包的最大流内顺序号加1。
12.根据权利要求10或11所述的装置，其特征在于，在所述处理模块确定接收到流内顺序号满足按序条件的数据包之前，对于所述至少两个流中的每个流，所述处理模块用于记录指示信息，所述指示信息指示已提交的数据包的最大流内顺序号。
13.根据权利要求12所述的装置，其特征在于，对于所述至少两个流中的每个流，当所述发送模块未提交过数据包时，所述指示信息指示已提交的数据包的流内顺序号为空；则所述处理模块确定接收到流内顺序号满足按序条件的数据包为：所述处理模块确定接收到具有首个流内顺序号的数据包。
14.根据权利要求10至13任意一项所述的装置，其特征在于，所述每个数据包还携带流优先级标识；当所述接收模块接收到多个流内顺序号满足按序条件的数据包时，所述发送模块优先提交所述流优先级标识指示的优先级高的流内的数据包。
15.根据权利要求10至14任意一项所述的装置，其特征在于，所述至少两个流中的每个流对应至少一个资源。
16.一种TCP连接的建立装置，其特征在于，包括接收模块和发送模块：
所述接收模块，用于接收来自发送端的建立连接请求，所述建立连接请求中携带所述发送端的多流能力指示参数；
所述发送模块，用于向所述发送端返回建立连接应答，所述建立连接应答中携带接收端的多流能力指示参数；
所述接收模块，用于接收来自所述发送端的建立连接应答，建立与所述发送端之间的连接。
17.根据权利要求16所述的装置，其特征在于，所述接收端的多流能力指示参数包括所述接收端允许的最大输入流的数量，所述接收模块接收的来自所述发送端的流的数量小于等于所述接收端允许的最大输入流的数量。
18.根据权利要求16或17所述的装置，其特征在于，所述发送端的多流能力指示参数包括所述发送端允许的最大输入流的数量，所述发送模块向所述发送端发送的流的数量小于等于所述发送端允许的最大输入流的数量。
19.一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算设备执行指令，以使所述计算设备执行权利要求1至6任意一项所述的方法。
20.一种计算设备，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算设备执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算设备运行时，所述处理器执行所述存储器存储的所述计算设备执行指令，以使所述计算设备执行权利要求7至9任意一项所述的方法。
CN201611210824.7A 2016-12-24 2016-12-24 一种数据传输方法及装置 Pending CN108243211A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201611210824.7A CN108243211A (zh) 2016-12-24 2016-12-24 一种数据传输方法及装置
EP17883793.6A EP3544261A4 (en) 2016-12-24 2017-09-29 DATA TRANSMISSION METHOD AND DEVICE
PCT/CN2017/104547 WO2018113373A1 (zh) 2016-12-24 2017-09-29 一种数据传输方法及装置
US16/448,649 US20190312938A1 (en) 2016-12-24 2019-06-21 Data Transmission Method And Apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611210824.7A CN108243211A (zh) 2016-12-24 2016-12-24 一种数据传输方法及装置

Publications (1)

Publication Number Publication Date
CN108243211A true CN108243211A (zh) 2018-07-03

Family

ID=62624659

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611210824.7A Pending CN108243211A (zh) 2016-12-24 2016-12-24 一种数据传输方法及装置

Country Status (4)

Country Link
US (1) US20190312938A1 (zh)
EP (1) EP3544261A4 (zh)
CN (1) CN108243211A (zh)
WO (1) WO2018113373A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109714326A (zh) * 2018-12-21 2019-05-03 北京明朝万达科技股份有限公司 一种应用层数据顺序组包方法、装置、设备及存储介质
CN110858791A (zh) * 2018-08-22 2020-03-03 华为技术有限公司 分布式并行传输方法、装置、设备及存储介质
CN111147573A (zh) * 2019-12-24 2020-05-12 网宿科技股份有限公司 一种数据传输的方法和装置
CN111163019A (zh) * 2018-11-07 2020-05-15 中兴通讯股份有限公司 处理数据包的方法、装置和存储介质
CN111385069A (zh) * 2018-12-27 2020-07-07 广州市百果园信息技术有限公司 数据传输方法及计算机设备
CN111385212A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 数据传输技术及神经网络系统
CN112511449A (zh) * 2019-09-16 2021-03-16 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
WO2021052151A1 (zh) * 2019-09-16 2021-03-25 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
WO2021169279A1 (zh) * 2020-02-28 2021-09-02 华为技术有限公司 报文乱序检测方法、装置及系统
CN116488812A (zh) * 2023-06-25 2023-07-25 中电科网络安全科技股份有限公司 一种业务数据处理方法、装置、电子设备和存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11122019B2 (en) * 2019-09-13 2021-09-14 Oracle International Corporation Systems and methods for client collaborated migration of live TLS connection

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101719918A (zh) * 2009-11-27 2010-06-02 北京交通大学 一种改进的适用于多连接多路径的传输方法
US20120020375A1 (en) * 2009-01-19 2012-01-26 Tsuneomi Haruna Sctp communication method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100417156C (zh) * 2003-07-16 2008-09-03 中兴通讯股份有限公司 一种流控传输协议中数据传输实现方法及系统
CN101534297B (zh) * 2009-03-05 2011-11-09 北京交通大学 一种实现流控制传输协议的动态流创建方法
JP4973749B2 (ja) * 2010-03-02 2012-07-11 沖電気工業株式会社 通信装置及び通信制御方法
CN102315918B (zh) * 2010-07-06 2013-11-20 大唐移动通信设备有限公司 一种tcp连接与sctp连接互通的方法及装置
US8943380B2 (en) * 2010-11-29 2015-01-27 Empire Technology Development Llc Forward error correction for a data flow associated with a connectionless packet network service
CN103929369A (zh) * 2014-05-07 2014-07-16 北京邮电大学 一种基于tcp友好的多路传输控制机制

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120020375A1 (en) * 2009-01-19 2012-01-26 Tsuneomi Haruna Sctp communication method
CN101719918A (zh) * 2009-11-27 2010-06-02 北京交通大学 一种改进的适用于多连接多路径的传输方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GERARD J. HEINZ II: "PRIORITIES IN STREAM TRANSMISSION ONTROL PROTOCOL (SCTP) MULTISTREAMING", 《UNIVERSITY OF DELAWARE》 *
R. STEWART, ED.: "Stream Control Transmission Protocol", 《IETF》 *
WOJCIECH FRĄCZEK ET.AL: "Stream Control Transmission Protocol Steganography", 《2010 INTERNATIONAL CONFERENCE ON MULTIMEDIA INFORMATION NETWORKING AND SECURITY》 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110858791A (zh) * 2018-08-22 2020-03-03 华为技术有限公司 分布式并行传输方法、装置、设备及存储介质
CN111163019B (zh) * 2018-11-07 2022-10-28 中兴通讯股份有限公司 处理数据包的方法、装置和存储介质
US11985071B2 (en) 2018-11-07 2024-05-14 Zte Corporation Method and apparatus for processing data packets, device, and storage medium
CN111163019A (zh) * 2018-11-07 2020-05-15 中兴通讯股份有限公司 处理数据包的方法、装置和存储介质
CN109714326A (zh) * 2018-12-21 2019-05-03 北京明朝万达科技股份有限公司 一种应用层数据顺序组包方法、装置、设备及存储介质
CN111385069A (zh) * 2018-12-27 2020-07-07 广州市百果园信息技术有限公司 数据传输方法及计算机设备
CN111385212A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 数据传输技术及神经网络系统
CN112511449A (zh) * 2019-09-16 2021-03-16 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
WO2021052151A1 (zh) * 2019-09-16 2021-03-25 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
CN112511449B (zh) * 2019-09-16 2022-12-30 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
US11303737B2 (en) 2019-12-24 2022-04-12 Wangsu Science & Technology Co., Ltd. Method and device for data transmission
CN111147573A (zh) * 2019-12-24 2020-05-12 网宿科技股份有限公司 一种数据传输的方法和装置
WO2021169279A1 (zh) * 2020-02-28 2021-09-02 华为技术有限公司 报文乱序检测方法、装置及系统
CN116488812A (zh) * 2023-06-25 2023-07-25 中电科网络安全科技股份有限公司 一种业务数据处理方法、装置、电子设备和存储介质
CN116488812B (zh) * 2023-06-25 2023-10-20 中电科网络安全科技股份有限公司 一种业务数据处理方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
WO2018113373A1 (zh) 2018-06-28
EP3544261A4 (en) 2020-04-08
EP3544261A1 (en) 2019-09-25
US20190312938A1 (en) 2019-10-10

Similar Documents

Publication Publication Date Title
CN108243211A (zh) 一种数据传输方法及装置
US8438281B2 (en) Techniques for accounting for multiple transactions in a transport control protocol (TCP) payload
CN107104936B (zh) 建立全双工双向通信的方法和系统
EP2611111A2 (en) Method of implementing content-centric network (CCN) using internet protocol (IP)-based network in gateway, and gateway
CN110086578A (zh) 数据传输方法、装置和系统
CN108494817A (zh) 数据传输方法、相关装置及系统
WO2016077716A1 (en) Communication sessions at a coap protocol layer
JP5135421B2 (ja) ページモードメッセージング
CN107995233B (zh) 建立连接的方法及相应的设备
WO2018112327A1 (en) Methods of concurrency control for block transfer in coap publish-subscribe architecture
CN101567769A (zh) 数据重传方法、系统及对等节点
CN111885093B (zh) 事件请求的传输方法和装置、存储介质及电子设备
CN103384181A (zh) 数据包的传输方法和设备
CN101621532B (zh) 一种使用线程池实现超文本传输协议应用的方法
CN107113223A (zh) 用于消息会话中继协议会话的消息块大小的协商
US8443057B1 (en) System, method, and/or apparatus for establishing peer-to-peer communication
CN104205743A (zh) 无线接入网中用于内容分发的方法和装置
CN111385068B (zh) 数据传输方法、装置、电子设备及通信系统
WO2013152614A1 (zh) 一种基于应用层数据的网络接入系统和方法
CN109450991A (zh) 基于移动应用的数据传输加速方法、相关设备和加速系统
WO2009113947A1 (en) Using a hash value as a pointer to an application class in a communications device
WO2009011968A1 (en) Endpoint discriminator in network transport protocol startup packets
CN110324302B (zh) 一种iot设备通信方法
WO2022268137A1 (zh) Tcp连接方法、系统、网络设备及存储介质
CN109120578B (zh) 一种实现链路连接处理的方法及装置

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20180703