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

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

Info

Publication number
WO2018113373A1
WO2018113373A1 PCT/CN2017/104547 CN2017104547W WO2018113373A1 WO 2018113373 A1 WO2018113373 A1 WO 2018113373A1 CN 2017104547 W CN2017104547 W CN 2017104547W WO 2018113373 A1 WO2018113373 A1 WO 2018113373A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
data packet
sequence number
receiving end
flow
Prior art date
Application number
PCT/CN2017/104547
Other languages
English (en)
French (fr)
Inventor
邓振杰
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP17883793.6A priority Critical patent/EP3544261A4/en
Publication of WO2018113373A1 publication Critical patent/WO2018113373A1/zh
Priority to US16/448,649 priority patent/US20190312938A1/en

Links

Images

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

Definitions

  • the present application relates to the field of communications, and in particular, to a data transmission method and apparatus.
  • the Transmission Control Protocol has requirements for reliability and order.
  • out-of-order refers to a packet with a larger sequence number arriving at the receiving end than a packet with a smaller sequence number.
  • the data packets When transmitting data using the TCP protocol, it is required that the data packets must be submitted to the application layer in strict order, that is, in the order in which they are submitted, such as in the order in which the serial numbers arrive from small. If a resource, request, or session with a small sequence number has a packet loss or a long delay, even if other independent resources, requests, or sessions with large sequence numbers are successfully received, they cannot be submitted to the application layer. In the buffer of the end. This phenomenon is a line header blocking problem of the TCP protocol. As shown in Figure 1.
  • Packet 1, packets 4 and 6, packets 2, 3 and 5 belong to three different resources. These three resources are transmitted over the same TCP connection, and the data packets are transmitted from 1 to 6. When packet 1 is not successfully received for some reason, even if packets 2 to 6 are successfully received in order, it needs to be temporarily stored in the buffer and cannot be submitted to the application layer.
  • the embodiment of the present application provides a data transmission method and apparatus, which can reduce the line header blocking problem of the TCP protocol and improve the efficiency of data transmission.
  • a data transmission method including receiving, by a receiving end, at least two flows from a transmitting end, each of the at least two flows comprising a plurality of data packets, each data packet carrying a flow identifier of the associated flow and In-stream sequence number, the in-stream sequence number indicates the order of each packet within its own stream. For at least one of the at least two streams, the receiving end determines that the data packet whose sequence number in the stream meets the sequential condition is received. The receiving end submits a data packet whose sequence number in the stream satisfies the sequential condition.
  • the sequential data packets in the stream can be directly submitted to the application layer, and the out-of-order at the connection level does not affect the sequential data packets in the stream.
  • submission Effectively reduce the occurrence of wire head blocking and improve the efficiency of data transmission
  • the sequential condition includes the intra-sequence sequence number being the maximum in-stream sequence number of the submitted data packet plus one.
  • the receiving end before the receiving end determines that the data packet whose sequence number in the stream meets the sequence condition is received, for at least two For each stream in the stream, the receiving end records indication information, wherein the indication information indicates the maximum in-stream sequence number of the submitted data packet.
  • the indication information can be the maximum in-stream sequence number of the submitted data packet. It is also possible to add 1 to the maximum in-stream sequence number of the submitted packet, indicating the in-stream sequence number of the next packet to be submitted.
  • the receiving end determines that the data packet whose sequence number in the stream meets the sequence condition is received: the receiving end determines that the data packet having the first in-stream sequence number is received.
  • the in-stream sequence number of the submitted packet indicates that the packet has not been submitted yet, and the next packet to be submitted is the packet with the first in-stream sequence number.
  • each data packet further carries a flow priority identifier.
  • the receiving end receives a plurality of data packets whose sequence numbers satisfy the sequence condition, the receiving end preferentially submits the data packets in the stream with the higher priority indicated by the flow priority identifier.
  • the receiving end determines the data packets with high priority according to the flow priority identifier, and preferentially submits these priorities. High data packets.
  • each of the at least two flows corresponds to at least one resource.
  • a resource can be transmitted through a stream, so that after a packet in a stream is submitted, the corresponding resource of the stream can be transmitted without being affected by other resources that are not completed.
  • the data in the in-stream sequence number satisfying the sequential condition is submitted at the receiving end Before the packet, the receiving end receives a preset number of data packets consecutive to the data packet satisfying the sequential condition. Thereafter, the receiving end submits the data packet satisfying the sequential condition, and a preset number of data packets consecutive to the data packet satisfying the sequential condition.
  • the second aspect provides a method for establishing a TCP connection, where the receiving end receives a connection establishment request from a sending end, where the connection request carries a multi-flow capability indication parameter of the transmitting end.
  • the receiving end returns a connection establishment response to the transmitting end, where the connection response carries the multi-flow capability indication parameter of the receiving end.
  • the receiving end receives the connection establishment response from the transmitting end, establishing a connection with the transmitting end.
  • the multi-stream capability negotiation can better deal with the compatibility problem with the traditional TCP protocol, and establishes a connection supporting multi-stream transmission after the multi-stream capability negotiation, which can avoid the prior art to establish multiple TCP connections for data transmission.
  • the multi-stream capability indication parameter of the receiving end includes the maximum number of input streams allowed by the receiving end.
  • the number of streams received by the receiving end from the transmitting end is less than or equal to the maximum number of input streams allowed by the receiving end.
  • the multi-stream capability indication parameter of the transmitting end includes the maximum number of input streams allowed by the transmitting end, and the receiving end sends the transmitting end to the transmitting end.
  • the number of streams sent is less than or equal to the maximum number of input streams allowed at the sender.
  • the maximum number of input streams allowed by the sender and receiver is not necessarily the same.
  • the sender and the receiver determine the maximum number of input streams allowed by the other party through negotiation. In the subsequent data transmission process, the sender and the receiver send a stream to the other party that does not exceed the maximum number of input streams allowed by the other party.
  • a computing device comprising: a processor, a memory, a bus, and a communication interface; the memory is configured to store a computing device to execute an instruction, and the processor is connected to the memory through the bus When the computing device is in operation, the processor executes the computer-executed instructions stored by the memory to cause the computing device to perform the method of any of the first aspect and the first aspect.
  • a computing device comprising: a processor, a memory, a bus, and a communication interface; the memory is configured to store a computing device to execute an instruction, and the processor is connected to the memory through the bus When the computing device is in operation, the processor executes the computer-executed instructions stored by the memory to cause the computing device to perform the method of any of the second aspect and the second aspect.
  • a fifth aspect a computer readable storage medium storing executable program code for implementing the method of the first aspect and any one of the possible implementations of the first aspect.
  • a computer readable storage medium wherein executable program code is stored, the program code being used to implement the method of any one of the second aspect and the second aspect.
  • a data transmission apparatus comprising means for performing the method of the first aspect and any one of the possible implementations of the first aspect.
  • a device for establishing a TCP connection comprising means for performing the method in any one of the possible implementations of the second aspect and the second aspect.
  • the traditional TCP protocol is extended to support multi-stream capability negotiation and data multi-stream transmission, so that the sequenced data packets in the stream can be directly submitted to the application layer, throughout Out-of-order on the connection level does not affect the submission of sequential packets within the stream. It effectively reduces the occurrence of line head blocking and improves the efficiency of data transmission.
  • each of the independent TCP connections needs to be established by using a three-way handshake.
  • the technical solution provided by the embodiment of the present application can effectively reduce the number of TCP connections, thereby reducing the load pressure of the server, and can Effectively reduce the initial delay caused by establishing a connection.
  • FIG. 1 is a schematic view of a wire head blocking phenomenon in the prior art
  • FIG. 2 is a schematic diagram of a network architecture according to an embodiment of the present application.
  • FIG. 3 is a schematic diagram showing the hardware structure of a computer device 300 according to an embodiment of the present application.
  • FIG. 4 is an exemplary flowchart of a multi-stream TCP connection establishment method 400 in accordance with an embodiment of the present application
  • FIG. 5 is a schematic diagram of a package format of a TCP option according to an embodiment of the present application.
  • FIG. 6 is a schematic diagram of an optional encapsulation format of an extended multi-stream TCP capability negotiation according to an embodiment of the present application
  • FIG. 7 is an exemplary flowchart of multi-stream TCP capability negotiation according to an embodiment of the present application.
  • FIG. 8 is an exemplary flowchart of a data transmission method 800 in accordance with an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an encapsulated format of an optional multi-stream transmission according to an embodiment of the present application.
  • FIG. 10 is an exemplary flowchart of a data transmission method according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a data transmission method according to an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a data transmission method according to an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a data transmission device 1300 according to an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a data transmission device 1400 according to an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a network architecture in accordance with an embodiment of the present application.
  • data transmission is performed between the transmitting end 201 and the receiving end 202 through the multi-stream TCP connection 203 provided by the present application.
  • a multi-stream TCP connection in this application refers to a TCP connection capable of transmitting two or more streams simultaneously.
  • the TCP connection in the prior art does not support the simultaneous transmission of two or more streams, and the extension of the TCP protocol can make two or more streams can be simultaneously transmitted on the TCP connection.
  • the sending end 201 can be a terminal or a server, and the receiving end 202 can also be a terminal or a server.
  • different resources in the application layer can be transmitted through different streams in the transport layer, so that the data packets in a certain stream are not transmitted due to other streamed packets in the transport layer.
  • the delay is caused by ensuring that the packets in the data stream are in order and can be submitted to the application layer.
  • the sending end 201 is a webpage server and the receiving end 202 is a tablet computer
  • the webpage and the image can be transmitted through different streams, and the image resource can be transmitted through other streams without waiting for the webpage transmission to be completed, thereby improving transmission efficiency and improving users.
  • Stream 1 to stream n are shown in Figure 2, represented by Stream 1, Stream 2, Stream 3, and Stream n.
  • Resources can be pictures, audio, video, text, conversations, requests, and more.
  • a terminal may be referred to as a user equipment (User Equipment, UE), an access terminal, a terminal device, a subscriber unit, a subscriber station, a mobile station, a mobile station, a remote station, a remote terminal, and a mobile device.
  • user terminal wireless communication device, user agent or user device.
  • the terminal can be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), and a wireless communication function.
  • NR Radio
  • FIG. 3 is a schematic diagram showing the hardware structure of a computer device 300 according to an embodiment of the present application.
  • computer device 300 includes a processor 302, a memory 304, a communication interface 306, and a bus 308.
  • the processor 302, the memory 304, and the communication interface 306 implement a communication connection with each other through the bus 308.
  • the processor 302 can be a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits for executing related programs.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • the memory 304 may be a read only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM).
  • Memory 304 can store operating system 3041 and other applications 3042.
  • the program code for implementing the technical solution provided by the embodiment of the present application is saved. In memory 304, and executed by processor 302.
  • Communication interface 306 implements communication with other devices or communication networks using transceivers such as, but not limited to, transceivers.
  • Bus 308 can include a path for communicating information between various components (e.g., processor 302, memory 304, communication interface 306).
  • the processor 302 executes the program code stored in the memory 304 for implementing the technical solution provided by the embodiment of the present application to implement the method shown in the embodiments of FIG. 4 and FIG.
  • the processor 302 can also execute the program code stored in the memory 304 for implementing the technical solution provided by the embodiment of the present application to implement the method shown in the embodiment of FIG. 8.
  • the extended TCP protocol supports multi-stream transmission, which can effectively reduce the occurrence of line header blocking.
  • the following describes the establishment process of a multi-stream TCP connection and how to perform multi-stream transmission through a multi-stream TCP connection in combination with a specific implementation.
  • FIG. 4 is an exemplary flowchart of a multi-stream TCP connection establishment method 400 according to an embodiment of the present invention. The following describes how to perform multi-stream TCP capability negotiation at the transmitting end and the receiving end to establish a multi-stream TCP connection.
  • the multi-stream TCP connection establishment method 400 can be performed by the transmitting end 201 and the receiving end 202 shown in FIG.
  • the sending end sends a connection establishment request to the receiving end, where the connection establishment request carries the multi-flow capability indication parameter of the sending end.
  • the receiving end returns a connection establishment response to the sending end, where the connection establishment response carries the multi-flow capability indication parameter of the receiving end.
  • the transmitting end determines, according to the multi-flow capability indication parameter of the receiving end, that the receiving end supports multi-stream TCP capability, returns a connection establishment response to the receiving end, and establishes a multi-stream TCP connection with the receiving end.
  • the traditional TCP protocol needs to be extended to support the multi-stream TCP capability negotiation function.
  • this can be achieved by extending the options of TCP.
  • the encapsulation format of the options is as shown in FIG. 5, including the option type Kind, the option length Length, the subtype subtype, and the subtype specific data subtype-specific-data.
  • the option type Kind field indicates the function name that needs to be extended, which is 8 bits, and there are 256 possibilities.
  • SACK Selective Acknowledgement
  • MSTCP to indicate that the local end supports multi-streaming transport control protocol.
  • the value can be allocated by the Internet Assigned Numbers Authority (IANA) or other organizations.
  • the carried multi-flow capability indication parameter may be MSTCP.
  • the receiving end receives the connection establishment request carrying the MSTCP field from the transmitting end, the receiving end determines that the transmitting end supports the multi-stream TCP capability.
  • the transmitting end receives the connection establishment response carrying the MSTCP field from the receiving end, the transmitting end determines that the receiving end supports the multi-stream TCP capability. Then the transmitting end returns a connection establishment response to the receiving end, establishing and receiving Multi-stream TCP connection between the ends.
  • the value of MS_CAPABLE is allocated by IANA.
  • Multi-stream TCP capability negotiation is implemented by carrying information in subtype-specific-data of MS_CAPABLE.
  • the information may include flags, key information of the sender, key information of the receiver, maximum number of accepted inbound streams, and the like.
  • the key information is used for identity authentication and authentication of subsequent operations.
  • the key information is generated in a unique way, but it needs to be random enough to prevent it from being deciphered.
  • the key information can be generated by different encryption algorithms, such as Hash Message Authentication Code-Secure Hash Algorithm 1, HMAC-SHA1.
  • the encryption algorithm that generates the key information is identified by flags.
  • the sender and the receiver send only the key information of the local end.
  • the sender sends the key information of the two peers to the receiver.
  • the maximum number of input streams allowed by the local end indicates the processing capability of the local end. When multi-stream transmission is performed, the number of streams received by the local end cannot exceed the maximum number of input streams allowed by the local end.
  • the maximum number of input streams allowed at the transmitting end is 3, and the maximum number of input streams allowed at the receiving end is 5.
  • the number of streams sent by the sender to the receiver can be 1, 2, 3, 4, 5, but cannot exceed 5.
  • the number of streams sent by the receiving end to the sender can be 1, 2, 3, but cannot exceed 3.
  • the payload user data refers to the actual load user data, that is, the data of the upper layer application.
  • the parameters in the specific data of the above subtypes are optional implementations for the present application.
  • the maximum number of input streams allowed by the local end may also be determined by a pre-agreed or configured manner.
  • the process of establishing a multi-stream TCP connection may include a capability negotiation process, as shown in S701, S702, and S703.
  • SYN Synchronous
  • SEQ sequence number
  • a TCP connection request which carries the optional MS_CAPABLE of the extended multi-stream TCP capability negotiation, including the key information of the sender A, flags, and the maximum number of input streams allowed by the sender A.
  • ACK Acknowledgement
  • ack acknowledgement number
  • the sender A selects the MS_CAPABLE of the multi-stream TCP capability negotiation according to the receiving end B. It is determined that the receiving end B supports the multi-stream TCP capability, and the number of maximum input streams allowed by the receiving end B is obtained.
  • the sender A sets the ACK flag to 1, the ack is set to K+1 (ie, the SEQ of the receiver B is incremented by 1), and the key information of the sender A and the key information of the receiver B are recorded, and the multi-stream is returned to the receiver B.
  • the TCP connection response which carries the optional MS_CAPABLE of the extended multi-stream TCP capability negotiation, includes the key information of the sender A, the key information of the receiver B, and flags.
  • the multi-stream TCP capability negotiation is completed between the transmitting end A and the receiving end B, and a multi-stream TCP connection is established.
  • FIG. 8 is an exemplary flow diagram of a data transfer method 800 in accordance with an embodiment of the present application.
  • the data transmission method 800 can be performed by the transmitting end 201 and the receiving end 202 shown in FIG. 2.
  • the sender acquires at least two resources to be sent, and each resource is transmitted through one stream. Each resource is divided into packets and streamed.
  • the sender allocates a flow identifier for each flow, and the data packet in each flow carries the flow identifier of the current flow and the sequence number in the flow.
  • the in-stream sequence number indicates the order in which the packets are within the associated stream.
  • a stream can also transmit multiple resources.
  • a resource is transmitted by using one stream as an example.
  • the sending end sends, to the receiving end, at least two streams that transmit at least two resources.
  • the receiving end receives at least two streams from the transmitting end.
  • the transmitting end sends at least two streams that transmit at least two resources to the receiving end through the multi-stream TCP connection.
  • the traditional TCP protocol needs to be extended to support the multi-stream transmission function of data. This can be done by extending the options of TCP.
  • a stream identifier (Stream Identifier) is defined in the subtype specific data of the MS_DATA to uniquely identify a stream. Defines the Stream Data Sequence Number (SDSN), which is used to indicate the order of packets in the stream. You can also define a Stream Priority Identifier to indicate the priority of a stream.
  • SDSN Stream Data Sequence Number
  • the flow priority identifier is used to ensure the priority transmission of the higher-priority flow and improve the user experience for the upper-layer application.
  • a flag B can be defined to indicate the first packet of the split packet; a flag E is defined to represent the last packet of the split packet. The meanings of the values of the flags B and E are shown in Table 1.
  • Table 1 indicates the meaning of flag B and flag E
  • a flag U can be defined in the subtype specific data of MS_DATA to indicate whether the stream can be submitted out of order. If the flag bit U is valid, the stream's data packet is committed as soon as it is successfully received. in case If the flag bit U is invalid, the data packets of the stream need to be submitted in order, and submitted in the order of the SDSN.
  • the data packet sent by the sending end to the receiving end by the multi-stream TCP connection carries the extended multi-stream transmission option, where the stream identifier Stream Identifier is used to carry the stream identifier allocated by the sending end for each stream, and the SDSN is used to carry the The sequence number of the stream in the stream to which it belongs.
  • the sender sends three streams to the receiver through the multi-stream TCP connection.
  • the stream identifiers are Stream 1, Stream 2, and Stream 3.
  • the value of the Stream Identifier of the packets belonging to Stream 1 is Stream 1, and belongs to Stream 2.
  • the value of the Stream Identifier of the packet is Stream 2, and the value of the Stream Identifier of the packet belonging to Stream 3 is Stream 3.
  • the SDSN of the Stream 1 packet ranges from 0 to 199; the Stream 2 packet has an SDSN from 0 to 399; and the Stream 3 packet has an SDSN of 0 to 499.
  • the receiving end determines, according to the in-stream sequence number of the submitted data packet and the in-stream sequence number of the received data packet, whether the sequence number of the received data packet in the stream is Meet the order conditions.
  • the receiving end submits a data packet whose sequence number in the stream satisfies the in-order condition.
  • the sequential condition includes the sequence number in the stream whose sequence number is the maximum in-stream sequence number of the submitted data packet plus one.
  • 1 refers to the number of packets.
  • the maximum in-stream sequence number of the submitted data packet is 10.
  • the data packet whose sequence number in the stream meets the sequence condition is received, including receiving the data with sequence number 10 in the stream.
  • the next packet of the packet that is, the packet with sequence number 11 in the stream.
  • the in-stream sequence number is represented by the amount of data carried by the data packet, and the amount of data carried by one data packet is 576 bytes
  • the maximum in-stream sequence number of the submitted data packet is 5760
  • the data packet whose sequence number in the stream satisfies the sequence condition is received, and includes a packet whose sequence number in the stream is 576 bytes larger than the sequence number in the stream is 5760, that is, the sequence within the stream The number is 6336.
  • the receiving end Before the receiving end determines that the data packet whose sequence number in the stream meets the sequence condition is received, for each of the at least two streams, the receiving end records indication information, where the indication information indicates that the data is submitted. The maximum in-stream sequence number of the packet.
  • the indication information indicates that the in-stream sequence number of the submitted data packet is empty; then the receiving end determines to receive The data packet that meets the sequence condition in the sequence number of the stream is: the receiving end determines that the data packet having the first in-stream sequence number is received.
  • the receiving end After receiving the data packet, the receiving end determines the SDSN of the received data packet. If the SDSN of the received data packet is the first intra-stream sequence number in the associated stream, the receiving end submits the data packet. For example, the receiving end receives the data packet whose stream identifier is Stream 2 and the SDSN is 0. The receiving end determines that the SDSN is 0, which is the first in-stream sequence number in Stream 2, and the receiving end submits the data packet. After the data packet is submitted, the receiving end records indication information indicating that the data packet with the SDSN of 0 in Stream 2 has been submitted.
  • the receiving end determines whether the data packet whose SDSN is smaller than the SDSN of the received data packet is submitted, for example, determines whether the data packet with the SDSN of 9 in Stream 2 has been submitted. If the SDSN has been submitted with a packet smaller than the SDSN of the received packet, the receiving end submits the received packet. For example, if the data packet with the SDSN of 9 in Stream 2 has been submitted, the receiving end submits the received data packet of the SDSN of Stream 2 to 10.
  • the receiving end records the indication information indicating that the data packet with the SDSN of 10 in Stream 2 has been submitted.
  • the indication information indicates that the information is null, and the indication information may be null or the first in-stream sequence number.
  • the SDSN in 2 is the first data packet of the sequence number in the stream.
  • Each data packet may also carry a flow priority identifier.
  • the receiving end receives a plurality of data packets whose sequence numbers satisfy the sequence condition, the receiving end preferentially submits the priority indicated by the flow priority identifier. High in-stream packets.
  • the receiving end receives the data packet of the Stream 1 whose SDSN is 20, and the stream 2 whose SDSN is 10.
  • the data packet of Stream 1 with SDSN of 19 and Stream 2 with SDSN of 9 have been submitted.
  • the receiving end first submits the data packet of the Stream 2 whose SDSN is 9.
  • Each of the data packets may further carry a transmission sequence number, where the transmission sequence number indicates an order of each of the data packets in all data packets; after the receiving end receives the data packet from the transmitting end, The method further includes: the receiving end returns a receiving response to the sending end, where the receiving response carries an indication parameter, where the indication parameter indicates a transmission sequence number of the data packet whose sequence number in the stream satisfies the sequential condition.
  • the data packet transmitted through the multi-stream TCP connection may carry the transmission sequence number.
  • the transmission sequence number can be considered to be a sequence number (SEQ) in the prior art.
  • SEQ sequence number
  • the transmission sequence number does not distinguish between streams, which is the ordering of packets in all streams in the whole.
  • FIG. 10 is an exemplary flowchart of a data transmission method according to an embodiment of the present application.
  • both the sender Host A and the receiver Host B support multi-stream TCP.
  • a multi-stream TCP connection has been established between Host A and Host B.
  • Host A sends three flows to Host B through a multi-stream TCP connection.
  • the flow identifiers are Stream 1, Stream 2, and Stream 3.
  • the SEQ of the Stream 1 packet is 100-299, the SDSN is 0-199; the SEQ of the Stream 2 packet is 300-499 and 700-899, the SDSN is 0-399; the SEQ of the Stream 3 packet is 500- 699 and 900-1199, SDSN is 0-499.
  • Stream 1, Stream 2, and Stream 3 are transmitted over the established multi-stream TCP connection.
  • Host A sends a packet with SEQ 100-499 at a certain time, where SEQ is 100-299, packet with SDSN of 0-199 belongs to Stream 1, SEQ is 300-499, and packet with SDSN of 0-199 belongs to Stream 2.
  • the packet belonging to Stream 1 was not successfully received by Host B because of the long network delay or packet loss.
  • Host B only successfully received the SEQ 300-499 belonging to Stream 2.
  • the packet is shown at S1 in the figure.
  • Host B determines that the data packet in Stream 2 has not been submitted, and the next data packet to be submitted is the data packet whose SDSN is 0 in Stream 2. Based on this, Host B determines that it can submit the received packet with the SDSN of Stream 2 as 0-199.
  • Host B submits a packet with a SDSN of 0 to 99 belonging to Stream 2.
  • the data packet with the SEQ 300-499 is the SDSN in Stream 2.
  • the receiver buffer does not need to buffer the packets with the SEQ 300-499, and the packets with the SEQ 300-499 can be submitted without waiting for the packets with the SEQ 100-299 to be successfully received.
  • the cache space is freed, which improves data transfer efficiency.
  • the application layer can process Stream 2 without waiting for the data transmission of Stream 1 to complete, which improves the quality of the application experience.
  • Host B After receiving the packet belonging to Stream 2 with the SEQ 300-499, Host B sends a selective response (SACK) to Host A, as shown at A1 in the figure.
  • SACK selective response
  • the format of SACK is ACK: 100
  • the transmission sequence number SEQ of the next expected received data packet is 100
  • the random access arrives in the buffer.
  • the SEQ of the receiving end packet is 300-499.
  • Host A After receiving the SACK message from Host B, Host A then sends a packet with SEQ 500-899.
  • the SEQ is 500-699
  • the data packet with the SDSN of 0-199 belongs to Stream 3
  • the SEQ is 700-899
  • the data packet with the SDSN of 200-399 belongs to Stream 2.
  • the packets belonging to Stream 3 are not successfully received by Host B.
  • Host B only successfully receives the SEQ of Stream 2 as 700.
  • the -899 packet as shown at S2 in the figure.
  • Host B After receiving the data packet with the SDSN of Stream 2 of 200-399, Host B sends a SACK to Host A, as shown in Figure A2.
  • the format of the SACK is ACK: 100, SACK: 300-499, 700-899, indicating that the maximum transmission sequence number SEQ of the continuously received data packet is 99, and the transmission sequence number SEQ of the next expected received data packet is 100, chaos.
  • the SEQ of the data packet arriving at the receiving end of the buffer is 300-499, 700-899.
  • the packet with the SEQ of 700-899 is a Stream.
  • the SDSN in 2 is a 200-399 data packet.
  • the data packet with the SDSN of 200-399 is in order and can be submitted to the application layer. In this way, the buffer space of the receiving end is released.
  • Host A After receiving the SACK message from Host B, Host A sends a packet with the SEQ 900-1199. These packets belong to Stream 3.
  • the data packet with the SEQ 900-1099 is not successfully received by Host B due to the long network delay or packet loss, as shown in Figure F3.
  • Host B only successfully received the packet with the SEQ of 1100-1199, as shown at S3 in the figure.
  • Host B determines that the data packet in Stream 3 has not been submitted, and the next data packet to be submitted is the data packet with SDSN 0 in Stream 3.
  • Host B determines that the received packet with the SDSN of 400-499 in Stream 3 does not satisfy the sequence condition. Therefore, it is necessary to cache the data packet of the Stream 3 SDSN of 400-499 in the receiving end buffer, and the data packet of the SDSN with the SDSN of 0-399 is successfully received and submitted before being submitted.
  • Host B After receiving the data packet of the SDSN belonging to Stream 3 of 400-499, Host B sends a SACK to Host A, as shown in Figure A3.
  • the format of SACK is ACK: 100, SACK: 300-499, 700-899, 1100-1199. Indicates that the maximum transmission sequence number SEQ of the continuously received data packet is 99, and the transmission sequence number SEQ of the next expected received data packet is 100, and the SEQ of the data packet that is out of order to arrive at the receiving end is 300-499, 700-899. , 1100-1199.
  • Host A triggers a fast retransmission of the TCP protocol and retransmits the data packet with the SEQ 100-299, as shown by the Fast retransmission in the figure.
  • the buffer of the receiving end only needs to buffer the data packets with the SEQs of 1100-1199 and the SDSN of 400-499, and the data packets of the SEQs of 300-499 and SEQs of 700-899 are in the Stream 2
  • it can be submitted to the application layer, and it will not need to be cached in the buffer because of the out of order at the connection level of the entire TCP.
  • all the packets that are out of order at the connection level that is, the packets with the SEQs of 300-499, 700-899, 1100-1199, are cached in the receiving buffer, occupying A large number of receiver side cache space.
  • the size of the remaining buffer space on the receiving end affects the maximum amount of data that the transmitting end can transmit, it further affects the transmission efficiency and the experience of the upper layer application.
  • the traditional TCP protocol is extended to support multi-stream capability negotiation and data multi-stream transmission, so that the sequenced data packets in the stream can be directly submitted to the application layer, throughout Out-of-order on the connection level does not affect the submission of sequential packets within the stream. It effectively reduces the occurrence of line head blocking and improves the efficiency of data transmission.
  • each of the independent TCP connections needs to be established by using a three-way handshake.
  • the technical solution provided by the embodiment of the present application can effectively reduce the number of TCP connections, thereby reducing the load pressure of the server, and can Effectively reduce the initial delay caused by establishing a connection.
  • FIG. 11 is a schematic diagram of a data transmission method according to an embodiment of the present application.
  • the data transmission method provided by the present application is applied to a web service based on a Hyper Text Transport Protocol (HTTP).
  • HTTP Hyper Text Transport Protocol
  • Each web page will include different resources such as text, video, images, and more.
  • the client will establish an end-to-end multi-stream TCP connection with the web server at the transport layer.
  • the encapsulation format of the capability negotiation option in establishing a multi-stream TCP connection request is as shown in FIG. 6.
  • the client sends a request to establish a multi-stream TCP connection to the web server.
  • the encapsulation format of the capability negotiation option in the multi-flow TCP connection response returned by the web server is shown in FIG. 6. The web server returns to the client a setup multi-flow TCP connection response indicating support for multi-stream TCP capabilities.
  • the client After receiving the response from the web server indicating that the multi-stream TCP capability is supported, the client returns a response accordingly.
  • the end-to-end transport layer multi-stream TCP connection between the client and the web server has been established, and multi-stream transmission of data can be performed.
  • the client requests three independent resources (not necessarily three, and may be multiple) of video, picture, and text. Among them, it is assumed that the video has the highest priority, the text has the lower priority, and the image has the lowest priority.
  • the server simultaneously sends video, picture, and text resource data to the client.
  • the stream priority identifier of the video resource is X1, and a unique stream identifier is randomly generated as S1.
  • the stream priority of the text resource is X2, and the stream ID is S2.
  • the stream priority of the image resource is X3 and the stream ID is S3. Wherein, S1 ⁇ S2 ⁇ S3, X1 ⁇ X2 ⁇ X3 (in the present embodiment, the smaller the value is, the higher the priority is).
  • the web server For each data packet to be sent, the web server identifies the flow to which the data packet belongs by using the stream identifier field identifier field; the SDSN field identifies the order of the data packet in the belonging stream.
  • the client When receiving the data from the server, the client first determines the flow to which the data packet belongs according to the flow identifier, and then determines whether the received data packet belongs to the SDSN according to the submitted SDSN of the data packet and the SDSN of the received data packet. In-stream order. If it is sorted in the stream, it is submitted to the upper browser for processing, otherwise it is cached in the client's buffer. After that, the client informs the web server of the out-of-order packet received by the SACK and the next expected packet.
  • a possible data transmission process is shown in Figure 9.
  • FIG. 12 is a schematic diagram of a data transmission method according to an embodiment of the present application.
  • the data transmission method provided by the present application is applied to a signaling protocol-based signaling interaction under a signaling network.
  • the diameter client and the diameter server establish a multi-stream TCP connection. For details, refer to the embodiments S401, S402, and S403 in FIG. 4, and details are not described herein again.
  • the diameter client assigns a flow identifier to each diameter session.
  • a stream can contain only one diameter session or multiple diameter sessions.
  • the server submits the sequential sessions to the upper layer. Further, certain urgent sessions or subscribed users may be given higher priority to improve the transmission efficiency of these sessions and the quality of experience of the corresponding users.
  • the embodiments S801 to S804 of FIG. 8 and details are not described herein again.
  • FIG. 13 is a schematic structural diagram of a data transmission device 1300 according to an embodiment of the present application.
  • the data transmission device 1300 includes a receiving module 1301, a processing module 1302, and a transmitting module 1303.
  • the data transmission device 1300 may be the receiving end 202 of FIG. 2, the computer device of FIG. 3, the receiving end of FIGS. 4 and 8, the receiving end B of FIG. 7, or the Host B of FIG.
  • the receiving module 1301 can be used to execute the embodiment in FIG. S803
  • the processing module 1302 can be used to execute S804 in the embodiment of FIG. 8
  • the sending module 1303 can be used to execute S805 in the embodiment of FIG.
  • the receiving module 1301 is configured to receive at least two flows from the sending end, where each of the at least two flows includes multiple data packets, where each data packet carries a flow identifier of the associated flow and an in-stream sequence number,
  • the in-stream sequence number indicates the order in which each of the data packets is within the belonging stream.
  • the processing module 1302 is configured to determine, for the at least one of the at least two flows, a data packet that receives an in-stream sequence number that satisfies the sequential condition.
  • the sending module 1303 is configured to submit a data packet in which the sequence number in the stream satisfies the sequential condition.
  • the sequential condition includes the sequence number in the stream whose sequence number is the maximum in-stream sequence number of the submitted data packet plus one.
  • the processing module 1302 may be configured to record indication information indicating that the data has been submitted. The maximum in-stream sequence number of the packet.
  • the indication information indicates that the in-stream sequence number of the submitted data packet is empty; then the processing module 1302 determines that the flow is received.
  • the data packet whose inner sequence number satisfies the sequential condition is: the processing module 1302 determines that the data packet having the first in-stream sequence number is received.
  • Each of the data packets may further carry a flow priority identifier.
  • the receiving module 1301 receives the data packets whose sequence numbers in the flow meet the sequence condition
  • the sending module 1303 preferentially submits the priority indicated by the flow priority identifier. High in-stream packets.
  • Each of the at least two streams corresponds to at least one resource.
  • the traditional TCP protocol is extended to support multi-stream capability negotiation and data multi-stream transmission, so that the ordered data packets in the stream can be directly submitted to the application layer.
  • Out-of-order on the connection level does not affect the submission of ordered packets within the stream. It effectively reduces the occurrence of line head blocking and improves the efficiency of data transmission.
  • each of the independent TCP connections needs to be established by using a three-way handshake.
  • the technical solution provided by the embodiment of the present application can effectively reduce the number of TCP connections, thereby reducing the load pressure of the server, and can Effectively reduce the initial delay caused by establishing a connection.
  • FIG. 14 is a schematic structural diagram of a device for establishing a TCP connection according to an embodiment of the present application.
  • the data transmission device 1400 includes a receiving module 1401 and a transmitting module 1402.
  • the data transmission device 1400 may be the receiving end 202 of FIG. 2, the computer device of FIG. 3, the receiving end of FIGS. 4 and 8, the receiving end B of FIG. 7, or the Host B of FIG.
  • the receiving module 1401 is configured to receive a connection establishment request from the sending end, where the connection establishment request carries a multi-flow capability indication parameter of the sending end.
  • the sending module 1402 is configured to return a connection establishment response to the sending end, where the connection establishment response carries a multi-flow capability indication parameter of the receiving end.
  • the receiving module 1401 is configured to receive a connection establishment response from the sending end, and establish a connection with the sending end.
  • the multi-flow capability indication parameter of the receiving end includes the maximum number of input streams allowed by the receiving end, and the number of streams received by the receiving module from the transmitting end is less than or equal to the maximum number of input streams allowed by the receiving end.
  • the multi-flow capability indication parameter of the sending end includes the maximum number of input streams allowed by the sending end, and the number of streams sent by the sending module to the sending end is less than or equal to the maximum number of input streams allowed by the sending end.
  • the traditional TCP protocol is extended to support multi-stream capability negotiation and data multi-stream transmission, so that the ordered data packets in the stream can be directly submitted to the application layer.
  • Out-of-order on the connection level does not affect the submission of ordered packets within the stream. It effectively reduces the occurrence of line head blocking and improves the efficiency of data transmission.
  • each of the independent TCP connections needs to be established by using a three-way handshake.
  • the technical solution provided by the embodiment of the present application can effectively reduce the number of TCP connections, thereby reducing the load pressure of the server, and can Effectively reduce the initial delay caused by establishing a connection.
  • the "module" in the embodiment of FIG. 13 and FIG. 14 may be an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor and a memory that execute one or more software or firmware programs, a combination logic circuit, and Other components that provide the above features.
  • ASIC Application Specific Integrated Circuit
  • the foregoing data transmission device and the TCP connection establishment device are implemented by using a computer device.
  • the receiving module and the sending module may be implemented by using a processor, a memory, and a communication interface of the computer device, where the processing module may pass through the computer device.
  • the processor and memory are implemented.
  • the computer device 300 shown in FIG. 3 only shows the processor 302, the memory 304, the communication interface 306, and the bus 308, in the specific implementation process, those skilled in the art should understand that the above data transmission device and The TCP connection establishment also includes other devices necessary to achieve proper operation. Meanwhile, those skilled in the art should understand that the above data transmission device and TCP connection establishing device may further include hardware devices that implement other additional functions, according to specific needs. Moreover, those skilled in the art should understand that the above data transmission apparatus and TCP connection establishing apparatus may also only include the necessary components for implementing the embodiments of the present application, and do not necessarily include all the devices shown in FIG.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • a computer readable storage medium A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

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

一种数据传输方法及装置
本申请要求于2016年12月24日提交中国专利局、申请号为201611210824.7，发明名称为“一种数据传输方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种数据传输方法及装置。
背景技术
传输控制协议(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 control protocol)，值大小可以由互联网数字分配局(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 Authentication Code-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 user data是指实际的负载用户数据，即上层应用的数据。
需要说明的是，以上子类型具体数据中的参数对于本申请来说都是可选的实现，例如对于本端允许的最大输入流的数量，也可以通过预先约定或者配置的方式确定好。
下面结合一个具体的实现实例，说明多流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的含义
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的数据包的Stream Identifier的值为Stream 1，属于Stream 2的数据包的Stream Identifier的值为Stream 2，属于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给Host A，如图中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给Host A，如图中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连接已经建立，可以进行数据的多流传输了。
本实施例中，假设客户端请求的有视频，图片，文字三种独立的资源(不一定是三个，可以是多个)。其中，假设视频的优先级最高，文字的优先级次之，图片的优先级最低。服务器同时向客户端发送视频、图片、文字资源数据。其中，视频资源的流优先级标识(stream priority 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实施例中的“模块”可以为专用集成电路(Application Specific 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任意一项所述的方法。
PCT/CN2017/104547 2016-12-24 2017-09-29 一种数据传输方法及装置 WO2018113373A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17883793.6A EP3544261A4 (en) 2016-12-24 2017-09-29 DATA TRANSMISSION METHOD AND DEVICE
US16/448,649 US20190312938A1 (en) 2016-12-24 2019-06-21 Data Transmission Method And Apparatus

Applications Claiming Priority (2)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/448,649 Continuation US20190312938A1 (en) 2016-12-24 2019-06-21 Data Transmission Method And Apparatus

Publications (1)

Publication Number Publication Date
WO2018113373A1 true WO2018113373A1 (zh) 2018-06-28

Family

ID=62624659

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/104547 WO2018113373A1 (zh) 2016-12-24 2017-09-29 一种数据传输方法及装置

Country Status (4)

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

Families Citing this family (11)

* 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 中兴通讯股份有限公司 处理数据包的方法、装置和存储介质
CN109714326A (zh) * 2018-12-21 2019-05-03 北京明朝万达科技股份有限公司 一种应用层数据顺序组包方法、装置、设备及存储介质
CN111385069A (zh) * 2018-12-27 2020-07-07 广州市百果园信息技术有限公司 数据传输方法及计算机设备
CN111385212B (zh) * 2018-12-29 2021-08-31 华为技术有限公司 数据传输技术及神经网络系统
US11122019B2 (en) * 2019-09-13 2021-09-14 Oracle International Corporation Systems and methods for client collaborated migration of live TLS connection
EP4024789A4 (en) * 2019-09-16 2022-12-14 Huawei Technologies Co., Ltd. METHOD FOR DETECTING AN UNORDERED MESSAGE FLOW, METHOD FOR PROCESSING MESSAGES AND ASSOCIATED DEVICE
CN112511449B (zh) * 2019-09-16 2022-12-30 华为技术有限公司 一种报文流乱序检测方法、报文处理方法及装置
CN111147573A (zh) * 2019-12-24 2020-05-12 网宿科技股份有限公司 一种数据传输的方法和装置
CN113328901B (zh) * 2020-02-28 2023-04-28 华为技术有限公司 报文乱序检测方法、装置及系统
CN116488812B (zh) * 2023-06-25 2023-10-20 中电科网络安全科技股份有限公司 一种业务数据处理方法、装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1571418A (zh) * 2003-07-16 2005-01-26 深圳市中兴通讯股份有限公司南京分公司 一种流控传输协议中数据传输实现方法及系统
CN101719918A (zh) * 2009-11-27 2010-06-02 北京交通大学 一种改进的适用于多连接多路径的传输方法
JP2011182234A (ja) * 2010-03-02 2011-09-15 Oki Electric Industry Co Ltd 通信装置及び通信制御方法
CN102315918A (zh) * 2010-07-06 2012-01-11 大唐移动通信设备有限公司 一种tcp连接与sctp连接互通的方法及装置
WO2012074507A1 (en) * 2010-11-29 2012-06-07 Empire Technoloogy 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友好的多路传输控制机制

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8908519B2 (en) * 2009-01-19 2014-12-09 Nec Corporation SCTP communication method
CN101534297B (zh) * 2009-03-05 2011-11-09 北京交通大学 一种实现流控制传输协议的动态流创建方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1571418A (zh) * 2003-07-16 2005-01-26 深圳市中兴通讯股份有限公司南京分公司 一种流控传输协议中数据传输实现方法及系统
CN101719918A (zh) * 2009-11-27 2010-06-02 北京交通大学 一种改进的适用于多连接多路径的传输方法
JP2011182234A (ja) * 2010-03-02 2011-09-15 Oki Electric Industry Co Ltd 通信装置及び通信制御方法
CN102315918A (zh) * 2010-07-06 2012-01-11 大唐移动通信设备有限公司 一种tcp连接与sctp连接互通的方法及装置
WO2012074507A1 (en) * 2010-11-29 2012-06-07 Empire Technoloogy 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友好的多路传输控制机制

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3544261A4

Also Published As

Publication number Publication date
EP3544261A4 (en) 2020-04-08
EP3544261A1 (en) 2019-09-25
CN108243211A (zh) 2018-07-03
US20190312938A1 (en) 2019-10-10

Similar Documents

Publication Publication Date Title
WO2018113373A1 (zh) 一种数据传输方法及装置
US20200358886A1 (en) Data Transmission Method, Apparatus, And System
WO2018086076A1 (zh) 数据传输方法及装置
CN108432194B (zh) 一种拥塞处理的方法、主机及系统
CN106612284B (zh) 一种流数据的传输方法和装置
WO2018151926A1 (en) Multipath transport communications
US8984158B2 (en) Data communication system and method
WO2018121535A1 (zh) 一种负载均衡处理方法及装置
WO2017097201A1 (zh) 一种数据传输方法、发送装置及接收装置
WO2012129922A1 (zh) 一种报文处理方法、转发设备及系统
US20170064679A1 (en) Processing method of data packet, terminal, base station and system
JP5923376B2 (ja) Ｔｃｐ中継装置
WO2015180418A1 (zh) 组播传输方法、装置及系统
WO2016161594A1 (zh) 一种数据传输的方法及装置
CN111510390A (zh) 应用程序或无线电信息在网络数据包头中的插入和使用
WO2017148419A1 (zh) 数据传输方法及服务器
WO2016165524A1 (zh) 内容访问方法、无线接入网内容分发网络基站和核心内容分发网络装置
WO2017091941A1 (zh) 一种处理业务数据包的方法及装置
WO2012065475A1 (zh) 分组交换域业务处理方法及装置
JP5476852B2 (ja) 通信装置、通信システムおよび通信方法
WO2012094901A1 (zh) 超长短信发送/接收方法、装置及系统
WO2022063187A1 (zh) 一种通信方法和装置
US11502778B2 (en) Method and apparatus for efficient delivery of source and forward error correction streams in systems supporting mixed unicast multicast transmission
WO2014100973A1 (zh) 视频处理方法、设备及系统
JP2017157963A (ja) 通信装置、通信方法及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17883793

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017883793

Country of ref document: EP

Effective date: 20190621