WO2024022334A1 - 数据传输方法、装置和系统 - Google Patents

数据传输方法、装置和系统 Download PDF

Info

Publication number
WO2024022334A1
WO2024022334A1 PCT/CN2023/109109 CN2023109109W WO2024022334A1 WO 2024022334 A1 WO2024022334 A1 WO 2024022334A1 CN 2023109109 W CN2023109109 W CN 2023109109W WO 2024022334 A1 WO2024022334 A1 WO 2024022334A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
frame
transmitted
offset
receiving end
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.)
Ceased
Application number
PCT/CN2023/109109
Other languages
English (en)
French (fr)
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.)
Douyin Vision Co Ltd
Original Assignee
Douyin Vision 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 Douyin Vision Co Ltd filed Critical Douyin Vision Co Ltd
Priority to CN202380054941.0A priority Critical patent/CN119563299A/zh
Publication of WO2024022334A1 publication Critical patent/WO2024022334A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems

Definitions

  • the present disclosure relates to the field of communication technology, and in particular to a data transmission method, a data transmission device, a data transmission system, a non-volatile computer-readable storage medium, a computer program and a computer program product.
  • the QUIC (Quick UDP Internet Connection, Quick User Datagram Protocol Internet Connection) transmission protocol is a secure universal transmission protocol that provides reliable multi-channel connections for application data transmission.
  • the QUIC transmission protocol can use multiple streams to transmit data, which is called the multi-stream function.
  • the QUIC transmission protocol is usually used in full-duplex mode. In full-duplex mode, a device may be either a sender or a receiver. Both the server and the client can create streams independently of each other, and can also set the priority of transmission.
  • a data transmission method including: the sending end sending to the receiving end an expired offset frame for indicating data that does not need to be repeatedly transmitted, a boundary frame for indicating independent data blocks, or a At least one of the related frames of multiple data streams of the same request is associated, so that the receiving end transmits data according to at least one of the expired offset frame, the boundary frame, or the related frame.
  • a data transmission method on the sending end side including: establishing a connection with the receiving end of the data to be transmitted; sending to the receiving end a message indicating that the data in the data to be transmitted is not to be retransmitted.
  • the end transmits data to be transmitted based on at least one of an expired offset frame, a boundary frame, or a related frame. If the receiving end does not confirm receipt of the data block within the preset time, an expired offset frame is sent to the receiving end.
  • a data transmission method including: a receiving end receives a sending end At least one of the expired offset frame sent to indicate data that does not need to be retransmitted, the boundary frame used to indicate independent data blocks, or the related frame used to associate multiple data streams of the same request; the receiving end uses the expired offset Data is transmitted in at least one of frames, boundary frames or related frames.
  • another data transmission method on the receiving end side including: establishing a connection with the sending end of the data to be transmitted; receiving a message sent by the sending end to indicate that the data to be transmitted is not to be re-transmitted. At least one of the expired offset frame of the data to be transmitted, the boundary frame used to indicate the boundary position of the data block in the data stream of the data to be transmitted, or the related frame used to associate multiple data streams created based on the same request in the data to be transmitted. One; transmitting data to be transmitted according to at least one of an expired offset frame, a boundary frame or a related frame.
  • a data transmission device is provided.
  • the transmission device is provided at the sending end, including: a sending unit configured to send an expired offset frame for indicating data that does not need to be repeatedly transmitted to the receiving end; At least one of a boundary frame used to indicate an independent data block or a related frame used to associate multiple data streams of the same request, so that the receiving end transmits data according to at least one of the expired offset frame, the boundary frame, or the related frame.
  • a data transmission device is provided.
  • the transmission device is provided at the sending end and includes: a connection unit for establishing a connection with the receiving end of data to be transmitted; and a sending unit for sending data to the receiving end.
  • Expired offset frames used to indicate data that will not be retransmitted in the data to be transmitted, boundary frames used to indicate the boundary positions of data blocks in the data stream of the data to be transmitted, or used to associate multiple data created based on the same request in the data to be transmitted.
  • the expired offset frame is sent by the transmitting end so that the receiving end can adjust the expired offset frame according to the expiration offset frame.
  • the data to be transmitted is transmitted in at least one of the , boundary frame or related frame.
  • the sending unit sends an expired offset frame to the receiving end when the receiving end does not confirm receipt of the data block within a preset time.
  • a data transmission device is provided.
  • the transmission device is provided at the receiving end and includes: a receiving unit configured to receive an expiration offset sent by the transmitting end to indicate data that does not need to be transmitted repeatedly. At least one of a frame, a boundary frame for indicating an independent data block, or a related frame for associating multiple data streams of the same request; a transmission unit for at least one of an offset frame, a boundary frame, or a related frame based on expiration Carry out data transmission.
  • a data transmission device the transmission device is arranged at the receiving end, including: a connection unit, used to establish a connection with the sending end of data to be transmitted; a receiving unit, used to receive a message sent by the sending end to indicate that the data to be transmitted is not to be re-transmitted.
  • Expiration offset frame of the data to be transmitted boundary frame used to indicate the boundary position of the data block in the data stream of the data to be transmitted, or related frame used to correlate multiple data streams created based on the same request in the data to be transmitted.
  • the expired offset frame is sent by the sending end; the transmission unit is used to calculate the expired offset frame, boundary frame, or At least one of the relevant frames carries out the transmission of data to be transmitted.
  • a data transmission system including: a sending end, used to perform the transmission method on the sending end side in any of the above embodiments; a receiving end, used to perform any of the above embodiments The transmission method of the receiving end.
  • a data transmission device including: a memory; and a processor coupled to the memory, the processor being configured to, based on instructions stored in the memory device, Execute the data transmission method in any of the above embodiments.
  • a non-volatile computer-readable storage medium on which a computer program is stored.
  • the program is executed by a processor, the data transmission method described in any of the above embodiments is implemented.
  • a computer program including: instructions, which when executed by a processor cause the processor to perform the data transmission method according to any of the above embodiments.
  • a computer program product including instructions that, when executed by a processor, cause the processor to perform the data transmission method according to any of the above embodiments.
  • FIG. 1a to 1b illustrate flowcharts of some embodiments of data transmission methods according to the present disclosure
  • FIGS. 2a to 2c show schematic diagrams of some embodiments of frame structures according to the present disclosure
  • Figure 3 shows a schematic diagram of some embodiments of a data transmission method according to the present disclosure
  • FIGS. 4a-4b show block diagrams of some embodiments of the data transmission device of the present disclosure
  • Figure 5 shows a block diagram of other embodiments of the data transmission device of the present disclosure.
  • Figure 6 shows a block diagram of further embodiments of the data transmission device of the present disclosure.
  • FIG. 7 illustrates a block diagram of some embodiments of the data transmission system of the present disclosure
  • the QUIC transmission protocol has ORTT (Round-Trip Time, round trip time) connection establishment (ORTT means that when both communicating parties initiate a communication connection, the first data packet can carry valid business data), congestion control, link migration, Safe and reliable transmission and other functions.
  • ORTT Red-Trip Time, round trip time
  • Most UDP (User Datagram Protocol) applications can be migrated to QUIC, but the current QUIC transmission protocol still has some technical problems in real-time communication scenarios.
  • QUIC is a reliable transmission protocol, and data transmitted in a stream will still suffer from the technical problem of head-of-line blocking. This technical problem is more serious in real-time streaming.
  • the main frame formats in this solution are as follows: DATAGRAM type frames are used to transmit application data in an unreliable manner; the format of the 'Type' field in the DATAGRAM frame is 0b0011000X, and the value can be 0x30, 0x31 .
  • the last bit of the 'Type' field is significant, it is the length identification (LEN) bit (0x01), which indicates whether there is a length field next. If the last bit of the 'Type' field is 0, it means there is no length field, and the length of the entire message data will continue to the end of the packet; if the last bit of the 'Type' field is 1, it means there is a length field.
  • LSN length identification
  • DATAGRAM frame format is as follows:
  • the DATAGRAM frame contains fields with the following semantics.
  • Length is a variable-length integer that represents the data content length of DATAGRAM in bytes. This field only exists when the LEN bit is 1. When LEN is 0, the data in DATAGRAM will be continued into the entire QUIC data packet. Note that the length of the data content can be 0.
  • Datagram Data is the data content that needs to be transmitted.
  • the specifications and usage of the technical solutions in the above embodiments in the QUIC transmission protocol are as follows.
  • QUIC when an application needs to send data via QUIC, QUIC generates a new DATAGRAM frame; it is then sent out in the first available QUIC data packet.
  • This DATAGRAM frame will be sent out as quickly as possible (actually depends on some actual conditions, such as congestion control that will be introduced later).
  • the DATAGRAM frame will also be combined with other frames into a QUIC data packet.
  • the data needs to be returned to the application layer immediately as long as the application layer can process the DATAGRAM frame and has memory to store it. Similar to the Stream frame, the application layer data carried by the DATAGRAM frame needs to be protected with an 0RTT key or a 1RTT key.
  • the max_datagram_frame_size transmission parameter represents the maximum value limit of DATAGRAM, However, in fact, this limit will be reduced due to the max_udp_payload_size transmission parameter and the maximum transmission unit (Maximum Transmission Unit, MTU) between end-to-end. DATAGRAM frames cannot be split. Therefore, the application layer protocol needs to deal with the problem that the maximum value is affected by the actual situation.
  • MTU Maximum Transmission Unit
  • DATAGRAM frames belong to the entire QUIC connection, rather than being associated with streams at the QUIC layer.
  • the application wishes to distinguish different DATAGRAM frames through different identifiers.
  • QUIC logical shunting of data packets or distinguishing different types of data packets.
  • Defining the identification of multiplexing or logical splitting is an application layer obligation using the QUIC protocol, and the application defines the syntax and parsing method of the data content. If an application needs to support multiple simultaneous packet streams, one approach is to use a "variable length" field at the beginning of the data content. This is a simple method that allows a large number of streams to be encoded using minimal space.
  • QUIC implementations SHOULD provide an API to applications to assign relative priorities to datagram frames relative to each other and to QUIC streams.
  • DATAGRAM frames are not retransmitted during loss detection, they can trigger acknowledgment (ACK), that is, 'ACK trigger frame'.
  • ACK acknowledgment
  • the sender suspects that the DATAGRAM may have been lost, and sends a probe packet to trigger an ACK response faster. If the sending end detects that the data packet containing the DATAGRAM frame is lost, it needs to send a notification to the application layer to inform the application layer that the data packet is lost.
  • a data packet containing a DATAGRAM frame is responded to, the application layer also needs to be notified that the message was successfully transmitted and received. Due to out-of-order reasons, a data packet may be confirmed as lost, but then received and acknowledged.
  • the response to the DATAGRAM frame only represents that the transport layer has received and processed it, but does not guarantee that the receiving application layer successfully processed the data. Therefore, this does not replace the successful processing of the application layer message with ACK.
  • DATAGRAM frames do not explicitly provide flow control signaling, nor do they effect any QUIC stream-level or QUIC connection-level flow control.
  • the risk of DATAGRAM frames not providing flow control is that the receiving end may not obtain enough resources to process the data. For example, the application does not have enough memory to store data. However, because the DATAGRAM frame itself is unreliable, the receiving end can Discard data.
  • DATAGRAM frames use QUIC's congestion control, so the connection may not be able to send DATAGRAM frames created by the application layer until data congestion control allows sending.
  • the sender must wait until congestion control allows, or drop the data. If racing is used in the implementation, sending may be delayed due to racing. In actual implementation, it can be supported to allow applications to set a sending timeout, which is the maximum time for delaying packet sending until data is discarded due to congestion control.
  • QUIC's reliable transmission algorithm will continue to retransmit the lost data until the data is successfully received. While this ensures data reliability, it also increases data transmission delays due to head-of-line congestion.
  • the present disclosure finds that the following problems exist in the above-mentioned related technologies: data transmission delay increases. In view of this, the present disclosure proposes a data transmission technical solution.
  • FIG. 1a-1b illustrate flowcharts of some embodiments of data transmission methods according to the present disclosure.
  • a connection with the receiving end of the data to be transmitted is established. For example, at least one of an expiration offset frame for indicating data that does not need to be transmitted repeatedly, a boundary frame for indicating independent data blocks, or a correlation frame for correlating multiple data streams of the same request is generated.
  • the expired offset frame includes a first offset
  • the first offset is used to indicate that data before the first offset relative to the expired offset frame in the data stream to be transmitted is not to be reset. transmission.
  • the boundary position includes an end position
  • the boundary frame includes a second offset
  • the second offset is used to indicate an end position of the data block.
  • the boundary frame is used to save information related to the transmission of the data segment, information related to the retransmission, or information related to the retransmission request in the case where the data segment included in the data block has been lost and will not be retransmitted. interest.
  • boundary frames are used to assign the same transmission priority to multiple data segments included in a data block. For example, the same transmission priority is used to indicate that if some data segments in a data block are lost and are not retransmitted, another part of the data segments in the data block will not be retransmitted either.
  • an expired offset frame used to indicate data that is not to be retransmitted in the data to be transmitted, a boundary frame used to indicate the boundary position of the data block in the data stream of the data to be transmitted, or a boundary frame used for association is sent to the receiving end.
  • the related frame includes a related stream ID that is the same for each of multiple data streams created based on the same request. For example, multiple data streams associated with related frames are presented together.
  • the receiving end when establishing a connection, it is confirmed whether the receiving end supports QUICU based on the receiving end's identifier. At least one of an expired offset frame, a boundary frame, or a correlation frame is sent if the receiving end supports QUICU.
  • step 110b a connection with the sending end of the data to be transmitted is established.
  • step 120b receive an expired offset frame sent by the sending end for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of the data block in the data stream of the data to be transmitted, or a boundary frame for Correlate at least one of the related frames of multiple data streams created based on the same request in the data to be transmitted.
  • step 130b the data to be transmitted is transmitted according to at least one of an expired offset frame, a boundary frame, or a related frame.
  • an identifier is sent to the sending end to identify whether the receiving end of the data to be transmitted supports QUICU. At least one of an expired offset frame, a boundary frame, or a correlation frame is sent if the receiving end supports QUICU.
  • the present disclosure provides a QUIC unreliable transmission protocol (QUICU), which is an extension of the QUIC protocol and is used to transmit unreliable data, with the purpose of reducing data transmission delay.
  • QUICU QUIC unreliable transmission protocol
  • QUIC's excellent transmission features (such as retransmission, congestion control, multiplexing, etc.) are reused and packet loss features are added.
  • QUICU controls the time and range of packet loss, reduces useless transmission to improve transmission efficiency, and reduces line congestion to improve transmission timeliness, which is beneficial to delay-sensitive applications, especially audio and video applications.
  • the present disclosure proposes a mechanism involving defining three new frame types, namely, Expire Offset Frame (Expire Offset Frame), Boundary Frame (Boundary Frame), and Correlation Frame (Correlation Frame).
  • Expire Offset Frame Expire Offset Frame
  • Boundary Frame Boundary Frame
  • Correlation Frame Correlation Frame
  • Each of these frames carries a type field that indicates the frame type (Type) and stream ID (Stream ID) of the current stream (the stream containing the frame).
  • each of the above frames contains a special field as follows.
  • the expired offset frame carries the offset of the data stream and is used to notify the receiving end that data before the offset in the data stream will not be retransmitted. After receiving this notification, the receiving end will not wait for any data before the offset in the data stream.
  • boundary frames also carry offsets into the data stream and are used to indicate the end of individual data blocks in the data stream. All data segments of an independent data block should be coupled in transmission. Because, a data segment is only meaningful if all data segments of the same independent data block are successfully received. This information can be used to save transmissions or retransmissions or retransmission requests for certain data segments in situations where it is known that certain data segments of the same independent block have been lost and will not be retransmitted.
  • This information can also be used, for example, to assign the same priority to all data segments of independent data blocks. For example, if a portion of an encoded picture is lost and will not be retransmitted, all subsequent pictures in the same independent group of pictures are usually useless even if they are received. Since they usually rely on the lost (or partially lost) previous picture for inter-frame prediction reference, in this case, the transmission, retransmission, and retransmission request of the data of these pictures can be skipped.
  • the related frame carries the related flow ID, which is the flow ID of the flow containing the request based on which the current flow is created, and is used to associate multiple flows created based on the same request.
  • the streaming system can store multiplexed media content (for example, in FLV format, i.e. Flash video format) in the origin server and edge server, while using QUIC to transmit the media in separate streams components to take advantage of the different priorities and other properties of different media components.
  • multiple streams can be created based on one request (download request or upload request).
  • an entity receiving these multiple streams will not be able to determine which of the received streams are from the same request.
  • Related frames in these received streams should therefore be presented together to provide such additional information; those received streams with the same related stream ID value, from the same request, should be presented together.
  • This unreliable transmission method of the present disclosure will achieve a balance between delay and transmission quality.
  • the following will describe the solution through several aspects such as transmission negotiation, data sending, data receiving, and data expiration, and provide some examples of the protocol.
  • the QUICU identifier needs to be used to confirm whether the receiving end supports QUICU.
  • a value of 0 for the QUICU identifier indicates that QUICU is not supported, a value of 1 indicates that QUICU is supported. HOLD QUICU.
  • the QUICU identifier needs to be registered with IANA (Internet Assigned Numbers Authority Services, Internet Numbers Assignment Authority), and needs to be carried through ALPN (Application-Layer Protocol Negotiation, application layer protocol negotiation) to indicate whether the QUICU protocol is supported.
  • IANA Internet Assigned Numbers Authority Services, Internet Numbers Assignment Authority
  • ALPN Application-Layer Protocol Negotiation, application layer protocol negotiation
  • a bidirectional stream can be created like normal QUIC.
  • the receiver Before the boundary frame is received, the receiver can respond to data like a normal QUIC stream, and after the boundary frame is received, it starts entering QUICU mode.
  • boundary frames, correlation frames, and expired offset frames must not be sent to a peer when the peer's QUICU identifier is not received during handshake negotiation. If a party receives a QUICU-specific frame from a peer that does not itself carry the QUICU identifier, it should disconnect and indicate to the other party that it does not support the QUICU protocol.
  • QUICU mode will be used for the entire life cycle of the flow.
  • QUICU mode may be one-way. Receiving a boundary frame indicates that the entity's incoming stream is in QUICU mode. However, the entity's outgoing streams can still be in normal QUIC mode.
  • the data is usually encapsulated in stream frames, and boundary frames can be used to indicate the boundaries between independent blocks of data in the data stream.
  • the beginning and end of an independent data block may be determined by two boundary frames. Except for the first independent data block and the last independent data block, the starting position of the first independent data block is the beginning of the data flow, and the end position of the last independent data block is the end of the data flow.
  • the way of dividing the data blocks includes dividing according to the length of the data each time the user calls the write interface.
  • the packaging measures include placing the Boundary Frame and the first byte of the corresponding data block in the same QUIC packet, which facilitates retransmission of the Boundary Frame.
  • priorities can be set at the interface. For example, QUIC The protocol stack creates different Streams for different priorities, which are not application-aware.
  • a Correlation Frame needs to be sent, in which the Stream ID is the ID that initiated the request, and the Correlation ID is the ID corresponding to the Stream built by the protocol stack. For example, in the same request, there is only one stream ID, but there can be multiple correlation IDs.
  • the data in each Boundary frame is delivered to the application layer in order, and the minimum delivery unit is a Boundary frame, that is, the data of the entire Boundary frame has been received in order. , can be delivered to the application. However, when the data of a Boundary frame expires, the data of subsequent Boundary frames can continue to be delivered to the application layer.
  • the callback is performed in units of boundary frames, that is, a data callback can be performed each time a continuous stream offset is greater than or equal to the first boundary offset is received.
  • the stream needs to be set to block state and wait for relevant frames. After the relevant frame arrives, associate the quic stream created by the server with the quic stream created by the client. After association, data callback is performed in units of boundary frames.
  • an Expire Frame is received, it means that the sender will no longer retransmit the content before the Offset corresponding to the StreamID specified in the Expire Frame. The receiving end needs to discard the block content. If there is a complete block later, it can continue to return data to the user.
  • the sending data segment of the flow may be considered to have been lost.
  • an expired offset frame can be sent to notify the other party that some data of the stream has been lost and will not be retransmitted, and the expired offset frame needs to be sent as soon as possible.
  • the unreliable implementation of the technical solution of the present disclosure is to notify the other party that the data has been lost by sending an Expire Frame.
  • the frame needs to be sent out as quickly as possible and is not guaranteed to be reliable.
  • the expiration time may be a fixed value or set by the user through the application. For example, use a fixed expiration time, or use a callback to let the user decide how to expire. Regardless of application layer implementation or protocol stack implementation, each Boundary frame will be indexed.
  • three new regular frames are added.
  • the frame type requires IANA registration. These frames can be used in the above-mentioned transmission negotiation, data sending, data receiving, and data expiration processes.
  • the timeout period can be configured by the sender itself, or the timeout period can be determined through negotiation.
  • FIGS 2a-2c show schematic diagrams of some embodiments of frame structures according to the present disclosure.
  • the boundary frame (Boundary Frame) includes the following content.
  • Stream ID is the ID of a common QUIC stream (A common quic stream ID).
  • Offset is the offset of the stream ID data (Stream ID's data offset), indicating the position offset of the stream corresponding to the "Stream ID”. "Offset" is the end position of an independent data block. Multiple boundary frames constitute multiple independent discardable content blocks. The starting offset of the first boundary data received is 0.
  • the Stream ID in the Boundary Frame is the stream ID that transmits the data block.
  • the offset in the Boundary Frame corresponds to the end position of the data block in the Stream.
  • the start and end of a block can be determined by two blocks. The start position of the first block is 0 by default.
  • the correlation frame includes the following content.
  • Stream ID is the ID of a common QUIC stream (A common quic stream ID).
  • Correlation Stream ID is the ID of a common QUIC stream (A common quic stream ID), which is the stream ID where the client initiates a request.
  • the client delivers data from multiple streams to the buffer called by the same application layer through related frames.
  • the Expire Offset Frame includes the following contents.
  • Stream ID is the ID of a common QUIC stream (A common quic stream ID).
  • Offset is the offset of the stream ID's data (Stream ID's data offset), which represents the position offset of the stream corresponding to the "Stream ID”. The data before "offset” has been lost and the data will not be retransmitted. The offset is also the value of a boundary frame.
  • the Stream ID of the Expire Offset Frame is used to indicate which Stream is to be expired. Offset is the offset of the Stream Data Frame, which means that the server will no longer retransmit the data before the offset.
  • the goal of QUICU is to provide applications with controllable unreliable data transmission capabilities. This capability has two modes, single-stream mode and multi-stream mode.
  • multi-stream mode different types of data can be put into different streams. These streams can be mapped to the same request stream through related frames, thus solving the problem of single-stream mode.
  • Each stream's data block must be completely A block of data is delivered to the application buffer before another stream can be delivered. If a stream's data chunks are blocked on delivery due to buffer size, all streams corresponding to the request should be blocked until the data can be delivered.
  • the technical solution of the present disclosure may also include an error handling process. If the receiving end does not support QUICU mode but receives a boundary, expire offset or correlation frame, it should close the link and return to "QUICU not supported" mode.
  • Figure 3 shows a schematic diagram of some embodiments of a data transmission method according to the present disclosure.
  • a streaming media application is transmitting HTTP (HyperText Transfer Protocol, Hypertext Transfer Protocol)-FLV (FLASH VIDEO) video data. Due to real-time reasons, audio and video need to be transmitted separately.
  • HTTP HyperText Transfer Protocol
  • Hypertext Transfer Protocol Hypertext Transfer Protocol
  • FLASH VIDEO FLASH VIDEO
  • two streams are created on the server side, respectively used to transmit audio and video, that is, "data of different priorities" in Figure 3.
  • the stream of the received request is used to reply to the http response and send the header information of flv, that is, the "file header" in Figure 3.
  • the server first responds to the relevant header through the client's stream, then creates a stream and sends a CORRELATION frame, and finally transmits audio and video data.
  • this process does not guarantee the order in which the data actually arrives at the client. Therefore, a state is needed to maintain their relationship. Audio and video streams, that is, data of different priorities and file headers, are all controlled by the state, and are in a blocking state under state control.
  • the status control after receiving the CORRELATION frame, it will act on the status control; the status control will set the non-priority data and file header indicated by the CORRELATION frame to the non-blocking state, that is, start transmitting data to the application. .
  • FIGS 4a-4b show block diagrams of some embodiments of the data transmission device of the present disclosure.
  • the data transmission device 4a is provided at the sending end and includes: a connection unit 41a, used to establish a connection with the receiving end of the data to be transmitted; a sending unit 42a, used to send an indication to the receiving end of the data to be transmitted.
  • An expired offset frame for data that is not to be retransmitted a boundary frame used to indicate the boundary position of a data block in a data stream of data to be transmitted, or a correlation used to correlate multiple data streams created based on the same request in the data to be transmitted.
  • At least one of the frames so that the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.
  • the transmission device 4a includes: a generating unit 43a, configured to generate at least one of an expired offset frame, a boundary frame or a related frame.
  • the expired offset frame includes a first offset indicating that it is to be transmitted Data in the data stream before the first offset relative to the expired offset frame is not retransmitted.
  • the boundary position includes an end position
  • the boundary frame includes a second offset
  • the second offset is used to indicate an end position of the data block.
  • the boundary frame is used to save information related to transmission of a data segment, information related to retransmission, or information related to a retransmission request in the case where the data segment included in the data block has been lost and is not retransmitted.
  • boundary frames are used to assign the same transmission priority to multiple data segments included in a data block.
  • the same transmission priority is used to indicate that in the event that a part of the data segments in the data block is lost and is not retransmitted, another part of the data segments in the data block is not retransmitted either.
  • the related frame includes a related stream ID that is the same for each of multiple data streams created based on the same request.
  • multiple data streams associated with related frames are presented together.
  • the sending unit 42a when establishing a connection, the sending unit 42a confirms whether the receiving end supports QUICU according to the identifier of the receiving end. At least one of an expired offset frame, a boundary frame, or a correlation frame is sent if the receiving end supports QUICU.
  • the data transmission device 4b is provided at the receiving end and includes: a connection unit 43b, used to establish a connection with the sending end of the data to be transmitted; a receiving unit 41b, used to receive instructions sent by the sending end to be transmitted.
  • the transmission unit 42b is configured to transmit the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the relevant frame.
  • FIG. 5 shows a block diagram of other embodiments of the data transmission device of the present disclosure.
  • the data transmission device 5 of this embodiment includes: a memory 51 and a processor 52 coupled to the memory 51 .
  • the processor 52 is configured to execute the instructions of the present disclosure based on instructions stored in the memory 51 .
  • Data transmission method in any embodiment.
  • the memory 51 may include, for example, system memory, fixed non-volatile storage media, etc.
  • System memory stores, for example, operating systems, applications, boot loaders, databases, and other programs.
  • Figure 6 shows a block diagram of further embodiments of the data transmission device of the present disclosure.
  • the data transmission device 6 of this embodiment includes: a memory 610 and a memory 610 coupled to the memory 610.
  • the processor 620 of the memory 610 is configured to execute the data transmission method in any of the foregoing embodiments based on instructions stored in the memory 610.
  • Memory 610 may include, for example, system memory, fixed non-volatile storage media, and the like.
  • System memory stores, for example, operating systems, applications, boot loaders, and other programs.
  • the data transmission device 6 may also include an input/output interface 630, a network interface 640, a storage interface 650, etc. These interfaces 630, 640, 650, the memory 610 and the processor 620 may be connected through a bus 660, for example. Among them, the input and output interface 630 provides connection interfaces for input and output devices such as monitors, mice, keyboards, touch screens, microphones, and speakers. Network interface 640 provides a connection interface for various networked devices. The storage interface 650 provides a connection interface for external storage devices such as SD cards and USB disks.
  • Figure 7 illustrates a block diagram of some embodiments of the data transmission system of the present disclosure.
  • the data transmission system 7 includes: a sending end 71, used to perform the data transmission method on the sending side in any of the above embodiments; a receiving end 72, used to perform the receiving end in any of the above embodiments. Data transfer method.
  • a streaming media application is transmitting video data. It writes 5 FLV Video Tags to the QUIC unreliable stream (the stream data before A, B, C, D, and E have all been delivered to the application layer. For simplicity, this example only represents a non-reliable stream).
  • QUIC generates the corresponding BOUNDARY frame (boundary frame) every time the application writes.
  • the BOUNDARY frame is used to indicate the starting position of a data block (such as Tag A ⁇ E) in the data stream.
  • Tag A was truncated into part 1 and part 2 due to its excessive size, but QUIC ensures that the BOUNDARY frame of A and the beginning part of A (such as part 1 of Tag A) are sent in the same QUIC packet.
  • the receiving end receives the BOUNDARY frame of A and the beginning of A. However, it cannot deliver A to the application at this time because it has not received the next BOUNDARY frame.
  • the receiving end successively receives the remaining part of A (such as part 2 of Tag A), the starting stream data of B (such as part 1 of Tag B) and the corresponding BOUNDARY frame. Since the receiving end has received two BOUNDARY frames, and the continuous content in the middle has been received, and the previous data has been delivered, it delivers A to the application layer.
  • the data segments between the boundary frame and the previous boundary frame are delivered to the application by the receiving end.
  • the sending end decides to actively expire B.
  • the sending end sends an EXPIRE_OFFSET frame (not shown in the figure) out, that is, expired offset frame).
  • the receiving end After receiving the EXPIRE_OFFSET frame, the receiving end increases the minimum offset value (buffer offset) of the buffered data of the received data to the position specified by the EXPIRE_OFFSET frame, which is the position where B ends. Notify the receiving end through EXPIRE_OFFSET that the data segment before the offset of EXPIRE_OFFSET will not be retransmitted.
  • the receiving end does not confirm receipt of the data block within a preset time, send an expired offset frame to the receiving end.
  • the remaining data of B is not retransmitted by the sending end, and the receiving end receives the stream data of C and D and their BOUNDARY frames. Since the BOUNDARY frames of C and D have been received, and the continuous data in the middle has been received, the previous data has been expired, so the receiving end can deliver the stream data of C to the application (indicated in bold in the figure).
  • both ends send/receive the remaining data.
  • the sender sends an empty BOUNDARY frame before the end to indicate that the data block is sent and received. complete.
  • unreliable transmission can also be achieved.
  • the receiving end's data reading strategy needs to be modified. Under this semantics, the receiving end only needs one BOUNDARY frame to know the end position of a piece of data, and the starting position can be calculated from the position of the BOUNDARY frame.
  • embodiments of the present disclosure may be provided as methods, systems, or computer program products. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product embodied on one or more computer-usable non-transitory storage media (including, but not limited to, disk memory, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. .
  • the methods and systems of the present disclosure may be implemented in many ways.
  • the methods and systems of the present disclosure may be implemented through software, hardware, firmware, or any combination of software, hardware, and firmware.
  • the above order for the steps of the methods is for illustration only, and the steps of the methods of the present disclosure are not limited to the order specifically described above unless otherwise specifically stated.
  • the present disclosure may also be implemented as programs recorded in recording media, and these programs include machine-readable instructions for implementing methods according to the present disclosure. Therefore, this disclosure A recording medium storing a program for executing the method according to the present disclosure is also covered.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

本公开涉及一种数据传输方法、装置和系统，涉及通信技术领域。该数据传输方法，包括：建立与待传输数据的接收端的连接；向接收端发送用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。在接收端在预设时间内没有确认接收到数据块的情况下，向接收端发送过期偏移帧。

Description

数据传输方法、装置和系统
相关申请的交叉引用
本申请是以PCT申请号为PCT/CN2022/107952，申请日为2022年7月26日的申请为基础，并主张其优先权，该PCT申请的公开内容在此作为整体引入本申请中。
技术领域
本公开涉及通信技术领域，特别涉及一种数据传输方法、数据传输装置、数据传输系统、非易失性计算机可读存储介质、计算机程序和计算机程序产品。
背景技术
在相关技术中，QUIC(Quick UDP Internet Connection，快速用户数据报协议互联网连接)传输协议是一种安全的通用传输协议，它为应用程序数据传输提供可靠的多路连接。QUIC传输协议可以使用多个流(stream)进行数据的传输，称为多路传输(multi stream)功能。QUIC传输协议通常应用于全双工模式，在全双工模式下一个设备既可能是发送端也可能是接收端。服务端和客户端均可以创建流，彼此之间相互独立，也可以设定传输的优先级。
发明内容
根据本公开的一些实施例，提供了一种数据传输方法，包括：发送端向接收端发送用于指示无需重复传输的数据的过期偏移帧、用于指示独立数据块的边界帧或者用于关联同一请求的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行数据的传输。
根据本公开的一些实施例，提供了一种发送端侧的数据传输方法，包括：建立与待传输数据的接收端的连接；向接收端发送用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。在接收端在预设时间内没有确认接收到数据块的情况下，向接收端发送过期偏移帧。
根据本公开的另一些实施例，提供一种数据传输方法，包括：接收端接收发送端 发送的用于指示无需重复传输的数据的过期偏移帧、用于指示独立数据块的边界帧或者用于关联同一请求的多个数据流的相关帧中的至少一个；接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行数据的传输。
根据本公开的一些实施例，提供了另一种接收端侧的数据传输方法，包括：建立与待传输数据的发送端的连接；接收所述发送端发送的用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个；根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
根据本公开的又一些实施例，提供一种数据传输装置，所述传输装置设置在发送端，包括：发送单元，用于向接收端发送用于指示无需重复传输的数据的过期偏移帧、用于指示独立数据块的边界帧或者用于关联同一请求的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行数据的传输。
根据本公开的又一些实施例，提供一种数据传输装置，传输装置设置在发送端，包括：连接单元，用于建立与待传输数据的接收端的连接；发送单元，用于向接收端发送用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，在待传输数据的接收端在预设时间内没有确认接收到数据块的情况下，过期偏移帧被发送端发送，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。发送单元在接收端在预设时间内没有确认接收到数据块的情况下，向接收端发送过期偏移帧。
根据本公开的再一些实施例，提供一种数据的传输装置，所述传输装置设置在接收端，包括：接收单元，用于接收发送端发送的用于指示无需重复传输的数据的过期偏移帧、用于指示独立数据块的边界帧或者用于关联同一请求的多个数据流的相关帧中的至少一个；传输单元，用于根据过期偏移帧、边界帧或者相关帧中的至少一个进行数据的传输。
一种数据传输装置，传输装置设置在接收端，包括：连接单元，用于建立与待传输数据的发送端的连接；接收单元，用于接收发送端发送的用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的 至少一个，在待传输数据的接收端在预设时间内没有确认接收到数据块的情况下，过期偏移帧被所述发送端发送；传输单元，用于根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
根据本公开的再一些实施例，提供一种数据的传输系统，包括：发送端，用于执行上述任一个实施例中的发送端侧的传输方法；接收端，用于执行上述任一个实施例中的接收端的传输方法。
根据本公开的再一些实施例，提供一种数据的传输装置，包括：存储器；和耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器装置中的指令，执行上述任一个实施例中的数据的传输方法。
根据本公开的再一些实施例，提供一种非易失性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一些实施例所述的数据的传输方法。
根据本公开的一些实施例，还提供了一种计算机程序，包括：指令，所述指令当由处理器执行时使所述处理器执行根据上述任一个实施例所述的数据的传输方法。
根据本公开的一些实施例，还提供了一种计算机程序产品，包括指令，所述指令当由处理器执行时使所述处理器执行根据上述任一个实施例所述的数据的传输方法。
通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。
附图说明
此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：
图1a～1b示出根据本公开的数据传输方法的一些实施例的流程图；
图2a～2c示出根据本公开的帧结构的一些实施例的示意图；
图3示出根据本公开的数据传输方法的一些实施例的示意图；
图4a～4b示出本公开的数据传输装置的一些实施例的框图；
图5示出本公开的数据传输装置的另一些实施例的框图；
图6示出本公开的数据传输装置的又一些实施例的框图；
图7示出本公开的数据传输系统的一些实施例的框图；
图8a～8e示出根据本公开的数据传输方法的另一些实施例的示意图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
如前所述，一些对实时性要求高的应用程序，需要传输层协议提供数据内容相关的传输优先级，避免优先级间的队头阻塞，做到应用层无感知。
例如，在实时性要求高的流媒体直播应用中，如果优先级低的某段数据一直因丢包而被重传，则为了保证实时性，应用更希望放弃等待这段数据，转而继续使用已经产生的新数据。因为，继续等待这段数据会增大观众端到主播端的延迟，可能影响到用户的观看体验。
为此，可以将一些超时未送达的数据进行丢弃，不再重传。虽然不再重传，可以有效保证延迟，但传输到应用层的数据质量是不可控的。
虽然，QUIC传输协议具有0RTT(Round-Trip Time，往返时间)连接建立(0RTT是指通信双方发起通信连接时，第一个数据包便可以携带有效的业务数据)、拥塞控制、链路迁移、安全可靠传输等多种功能。大多数UDP(User Datagram Protocol，用户数据报协议)应用程序可以迁移到QUIC，但当前的QUIC传输协议在实时通信场景下还存在一些技术问题。
例如，QUIC是可靠传输协议，在一个流(stream)中进行传输的数据依旧会出现队头阻塞的技术问题。该技术问题在实时流里面是比较严重的。
针对上述技术问题，可以增加对通过QUIC连接发送和接收的不可靠数据报的支持，以提出扩展的QUIC(QUICU)。
在一些实施例中，该方案中主要的帧格式如下：DATAGRAM类型的帧，用来传输非可靠方式传输应用数据；DATAGRAM帧中的'Type'字段的格式是0b0011000X，取值可以是0x30、0x31。
例如，'Type'字段的最后一位是有重要意义的，它是长度标识(LEN)位(0x01)，它指出接下来是否存在长度字段。如果'Type'字段的最后一位是0，表示没有长度字段，整个报文数据的长度将延续到数据包的结束；如果'Type'字段的最后一位是1，则表示有长度字段。
例如，DATAGRAM帧格式如下：
例如，DATAGRAM帧包含的字段的语义如下。Length是一个长度可变的整数，以字节为单位表示DATAGRAM的数据内容长度。该字段只有当LEN位是1时才存在。当LEN是0时，DATAGRAM的数据将延续到整个QUIC数据包里。注意数据内容的长度可以是0。
例如，Datagram Data是需要被传输的数据内容。
在一些实施例中，上述实施例中的技术方案在QUIC传输协议中的规范及用法如下。
例如，当应用需要通过QUIC发送数据时，QUIC会生成一个新的DATAGRAM帧；然后在第一个可用的QUIC数据包里将它发出去。这个DATAGRAM帧将会尽可能快地发送出去(实际上取决于一些实际情况，例如后面将介绍的拥塞控制)。该DATAGRAM帧也会和其他帧一起组合到一个QUIC数据包中。
例如，当一个QUIC终端接收到DATAGRAM帧时，只要应用层能处理该DATAGRAM帧且有内存存储它，则需要立即将数据返回给应用层。类似Stream帧，DATAGRAM帧携带的应用层数据需要用0RTT秘钥或1RTT秘钥保护起来。
虽然，max_datagram_frame_size传输参数代表了DATAGRAM的最大值限定， 但是，实际上该限制会因为max_udp_payload_size传输参数、端到端之间的最大传输单元(Maximum Transmission Unit，MTU)而减小。DATAGRAM帧是不能被拆分的。因此，应用层协议需要处理最大值受实际情况影响的问题。
例如，DATAGRAM帧是属于整个QUIC连接的，而并非是在QUIC层与stream关联的。然而，应用希望通过不同的标识符区别出不同的DATAGRAM帧。
例如，数据包的逻辑分流或者是区分不同类型的数据包。定义多路复用或者逻辑分流的标识是使用QUIC协议的应用层义务，由应用定义数据内容的语法以及解析方式。如果应用需要支持同时存在的多路数据包流，一种方式是在数据内容的开头使用一个“变长”的字段，这是一种允许使用最小空间对大量流进行编码的简单方法。QUIC实现应该向应用程序提供一个API，以便为数据报帧彼此之间以及QUIC流分配相对优先级。
虽然，DATAGRAM帧在丢失检测时不会重新传输，但它们能触发确认(Acknowledgement，ACK)，即'ACK激发帧'。接收方应支持延迟ACK帧，以响应仅包含DATAGRAM帧的数据包的接收。因为，如果这些DATAGRAM暂时未确认，则发送方不会采取任何行动。因为，数据包的有效载荷对接收机来说是未知的，所以，当条件指示数据或者由max_ack_delay(最大ACK延迟)指示或者其他组件指示DATAGRAM包可能丢失时，接收机将继续发送ACK帧。
如果DATAGRAM没有跟其他“ACK激发帧”一起传输，发送端怀疑DATAGRAM可能已经丢失，则发送一个探测包以更快的触发一个ACK应答。如果发送端检测到包含DATAGRAM帧的数据包丢失，则需要向应用层发送一个通知，告知应用层数据包丢失了。
如果一个包含DATAGRAM帧的数据包被应答了，也需要通知应用层该报文以传输成功并被接收了。因为乱序的原因，可能引起一个数据包被确认为已丢失，但之后又被接收且被应答的情况。对DATAGRAM帧的应答只代表了传输层已接收并处理了，但并不保证接收端应用层成功的处理了该数据。因此，这并不能用ACK代替应用层的成功处理消息。
DATAGRAM帧并不显示的提供流量控制信令，也不作用在任何QUIC stream级或QUIC connection级的流量控制。DATAGRAM帧不提供流量控制的风险在于接收端可能获取不到足够的资源去处理数据。例如，应用没有足够的内存来存储数据。尽管如此，因为DATAGRAM帧本身就是非可靠的，所以接收端在不能处理数据时可以 丢弃数据。
DATAGRAM帧使用QUIC的拥塞控制，因此连接可能不能发送应用层创建的DATAGRAM帧，直到数据拥塞控制允许发送。发送端必须等待直到拥塞控制允许，或者丢弃数据。若在实现中使用了竞速，那么也可能因为竞速使得发送延迟。实际实现时，可以支持允许应用设置发送超时时间，该超时时间是因为拥塞控制而延迟发包直至丢弃数据的最大时间。
即使在QUIC传输协议引入上述技术方案，仍然存在一定的技术问题。在具有高比特率的实时传输场景中，例如，音频和视频传输，包括虚拟现实类型的应用程序，数据包丢失有时是不可避免的。
一方面，在检测到数据包丢失后，QUIC的可靠传输算法将继续重新传输丢失的数据，直到成功接收到数据。虽然这确保了数据的可靠性，但也会增加由于线路头阻塞而导致的数据传输延迟。
另一方面，存在分组丢失后不进行任何重传的技术问题，例如，通过使用上述技术方案中指定的数据包QUIC帧类型。虽然，没有重传可以有效保证延迟，但是，传输到应用层的数据质量是不可控的。例如，音频可能是间歇性的，具有频繁和尖锐的突发，并且视频图像可能经常模糊或无法播放。
因此，希望具有允许控制重传数据量和时间范围的机制，从而允许在延迟和媒体质量之间进行最佳权衡。
本公开发现上述相关技术中存在如下问题：数据传输延迟增加。鉴于此，本公开提出了一种数据的传输技术方案。
图1a～1b示出根据本公开的数据传输方法的一些实施例的流程图。
如图1a所示，在步骤110a中，建立与待传输数据的接收端的连接。例如，生成用于指示无需重复传输的数据的过期偏移帧、用于指示独立数据块的边界帧或者用于关联同一请求的多个数据流的相关帧中的至少一个。
在一些实施例中，过期偏移帧包括第一偏移量，第一偏移量用于指示待传输数据的数据流中相对于过期偏移帧的第一偏移量之前的数据不被重新传输。
在一些实施例中，边界位置包括结束位置，边界帧包括第二偏移量，第二偏移量用于指示数据块的结束位置。
在一些实施例中，边界帧用于在数据块包括的数据段已丢失且不被重新传输的情况下，保存数据段的传输的相关信息、重新传输的相关信息或重新传输请求的相关信 息。
在一些实施例中，边界帧用于为数据块包括的多个数据段分配相同的传输优先级。例如，相同的传输优先级用于指示在数据块中的一部分数据段丢失且不被重新传输的情况下，数据块中的另一部分数据段也不被重新传输。
在步骤120a中，向接收端发送用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
在一些实施例中，相关帧包括相关流ID，基于同一请求创建的多个数据流中的每一个的相关流ID相同。例如，相关帧关联的多个数据流被一起呈现。
在一些实施例中，在建立连接时，根据接收端的标识符，确认接收端是否支持QUICU。过期偏移帧、边界帧或者相关帧中的至少一个在接收端支持QUICU的情况下被发送。
如图1b所示，在步骤110b中，建立与待传输数据的发送端的连接。
在步骤120b中，接收发送端发送的用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个。
在步骤130b中，根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
在一些实施例中，在建立连接时，向发送端发送标识符，用于标识待传输数据的接收端是否支持QUICU。过期偏移帧、边界帧或者相关帧中的至少一个在接收端支持QUICU的情况下被发送。
在一些实施例中，本公开提供了一种QUIC非可靠传输协议(QUICU)，是QUIC协议的扩展，用于传输非可靠的数据，其目的是减少数据传输延迟。
例如，复用了QUIC优秀的传输特性(如重传、拥塞控制、多路复用等)，并增加了数据包丢失的特性。QUICU通过控制丢包的时间和范围，减少无用传输以提高传输效率，减少线路阻塞以提高传输及时性，利于延迟敏感应用，尤其是音频和视频应用。
在一些实施例中，本公开提出了了一种机制，涉及定义三种新的帧类型，即过期偏移帧(Expire Offset Frame)、边界帧(Boundary Frame)和相关帧(Correlation Frame)。 这些帧中的每一个都携带一个类型字段，该字段指示当前流(包含帧的流)的帧类型(Type)和流ID(Stream ID)。
在一些实施例中，上述每个帧都包含一个如下的特殊字段。
例如，过期偏移帧携带数据流的偏移量，用于通知接收端数据流中偏移量之前的数据将不会被重新传输。在接收到该通知后，接收端将不等待数据流中偏移量之前的任何数据。
例如，边界帧也携带数据流的偏移量，用于指示数据流中独立数据块的结束。一个独立数据块的所有数据段都应该在传输中耦合。因为，只有在成功接收到同一个独立数据块的所有数据段时，数据段才有意义。在已知同一独立块的某些数据段已丢失且不会重新传输的情况下，该信息可用于保存某些数据段的传输或重新传输或重新传输请求。
例如，该信息还可以用于为独立数据块的所有数据段分配相同的优先级。例如，如果其中一部分的编码图片丢失并且不会被重新传输，则同一独立图片组中的所有后续图片即使被接收也通常是无用的。由于，它们通常依赖于丢失(或部分丢失)的前一图片进行帧间预测参考，因此，在这种情况下，可以跳过这些图片的数据的传输、重发、重发请求。
例如，相关帧携带相关流ID，该ID是包含创建当前流所基于的请求的流的流ID，用于关联基于同一请求创建的多个流。出于向后兼容性的原因，流系统可以在源服务器和边缘服务器中存储多路复用的媒体内容(例如，以FLV格式，即Flash视频格式)，同时使用QUIC在单独的流中传输媒体组件，以利用不同媒体组件的不同优先级和其他属性。
例如，在这种流系统中，基于一个请求(下载请求或上传请求)，可以创建多个流。然而，如果没有额外的信息，接收这些多个流的实体将无法确定哪些接收到的流来自同一请求。因此应该一起呈现这些接收流中的相关帧来提供此类附加信息；具有相同相关流ID值的那些接收的流，来自相同的请求，应该一起呈现。
本公开的这种非可靠传输方式会达到延迟与传输质量的平衡。下面将通过传输协商、数据发送、数据接收、数据过期等几个方面进行方案阐述，并提供一些关于协议的实施例。
在一些实施例中，在传输协商过程中，建立连接时，需要使用QUICU标识符确认接收端是否支持QUICU。QUICU标识符的值0表示不支持QUICU，值1表示支 持QUICU。
例如，QUICU标识符需要在IANA(Internet Assigned Numbers Authority Services，互联网数字分配机构)中注册，并需要通过ALPN(Application-Layer Protocol Negotiation，应用层协议协商)携带，以指示是否支持QUICU协议。当QUICU标识符不存在时，该值被推断为等于0。
在一些实施例中，在传输协商过程中，当建立连接时，可以像普通QUIC一样创建双向流。在接收到边界帧之前，接收器可以像正常QUIC流一样响应数据，而在接收到边界帧之后，它开始进入QUICU模式。
在一些实施例中，当在握手协商期间未接收到对等方的QUICU标识符时，不能将边界帧、相关帧和过期偏移帧发送给对等方。如果一方从对等方接收到QUICU特定帧，而其本身不携带QUICU标识符，则应断开连接，并向另一方指示其不支持QUICU协议。
在一些实施例中，当流建立QUICU模式后，QUICU模式将用于流的整个生命周期。
在一些实施例中，QUICU模式可以是单向的。接收边界帧表示实体的传入流处于QUICU模式。然而，该实体的传出流仍然可以处于正常的QUIC模式。
在一些实施例中，在发送数据的过程中，当数据的不同组件在传输中不需要进行不同的处理(例如，具有相同的优先级)时，它们可以在同一流中传输。在这种情况下，数据通常封装在流帧中，边界帧可用于指示数据流中独立数据块之间的边界。
在一些实施例中，独立数据块的开始和结束可以由两个边界帧确定。但第一个独立数据块和最后一个独立数据块除外，第一个独立数据块的开始位置是数据流的开始，最后一个独立数据块的结束位置是数据流的结束。
在一些实施例中，当数据的不同组件在传输中确实需要进行不同的处理时，例如，具有不同的优先级，它们应该在不同的流中传输。在这种情况下，需要将相关帧发送到基于相同请求创建的关联流。
在一些实施例中，划分数据块的方式包括根据用户每次调用写入接口时数据的长度划分。
在一些实施例中，组包措施包括让Boundary Frame(边界帧)与对应数据块的第一字节在同一个QUIC包里，这便于Boundary Frame的重传。
在一些实施例中，如果需要区分优先级，可以在接口处设定优先级。例如，QUIC 协议栈对不同优先级创建不同的Stream，该stream对应用不感知。需要发送Correlation Frame(相关帧)，其中的Stream ID即是发起请求的ID，Correlation ID是协议栈自建的Stream对应的ID。例如，同一个请求中，stream ID只有一个，但Correlation ID可以有多个。
在一些实施例中，在接收数据的过程中，在一个数据流中，如果没有收到过Boundary帧，那么它依旧使用普通的QUIC模式，否则进入QUICU模式。
在一些实施例中，在QUICU模式中，在每个Boundary帧内的数据都是按序交付给应用层的，且最小交付单元是一个Boundary帧，即整个Boundary帧的数据都已经按序接收到了，才能交付给应用。但是当一个Boundary帧的数据过期后，其后的Boundary帧的数据是可以继续交付给应用层的。
换而言之，在QUICU模式中，以boundary帧为单位进行回调，即每次收到连续的且stream offset大于等于第一个boundary offset时才能进行一次数据回调。在收到对方创建quic stream时，需要将stream设置成block状态，等待相关帧。在相关帧到达后，将服务端创建的quic stream与客户端创建的quic stream进行关联，关联后按boundary帧为单元进行数据回调。当收到Expire Frame时，意味着发送端将不再重传该Expire Frame中指定的StreamID对应的Offset(偏移量)之前的内容。接收端需要将该block内容丢弃，若后面有完整区块则可继续给用户返回数据。
在一些实施例中，在数据过期的情况下，如果在一段时间内数据报文仍未被确认接收，则可以认为流的发送数据段已丢失。此时，可以发送过期偏移帧来通知另一方流的某些数据已经丢失并且将不会重新传输，需要尽快发送过期偏移帧。
换而言之，发送数据到一定时间未被确认就可以被认为丢失，本公开的技术方案的非可靠实现是通过发送Expire Frame来通知对方数据已经丢失。该帧需要尽可能快的发出，不保证可靠的。
在一些实施例中，到期时间可以是固定值或由用户通过应用程序设置。例如，使用一个固定的过期时间，也可以使用一个回调让用户决定如何过期。无论应用层实现还是协议栈实现，都会对每个Boundary帧进行索引。
在一些实施例中，在QUIC传输协议的基础之上，新增了三个常规帧。帧类型需要IANA注册。这些帧可以应用在上述传输协商、数据发送、数据接收、数据过期的过程中。超时时间(timeout period)可以是发送端自己配置，也可以通过协商确定超时时间。
图2a～2c示出根据本公开的帧结构的一些实施例的示意图。
如图2a所示，边界帧(Boundary Frame)包括下面的内容。
Stream(流)ID，为通常QUIC流的ID(A common quic stream ID)。
Offset，为流ID数据的偏移(Stream ID's data offset)，表示“Stream ID”对应的stream的位置偏移。“offset”是一个独立数据块的结束位置，多个boundary帧构成多个独立的可丢弃的内容块。收到的第一个boundary数据的开始offset是0。
在一些实施例中，Boundary Frame中的Stream ID即传输该数据区块的stream ID。Boundary Frame中的offset对应的是该数据块在该Stream中的结束位置。可以通过两个区块确定区块的开始和结束，第一个区块的开始位置默认是0。
如图2b所示，相关帧(Correlation Frame)包括下面的内容。
Stream ID为通常QUIC流的ID(A common quic stream ID)。
相关流(Correlation Stream)ID，为通常QUIC流的ID(A common quic stream ID)，是客户端发起请求的stream ID。客户端通过相关帧将多个stream的数据投递到同一个应用层调用的buffer缓冲区中。
如图2c所示，期偏移帧(Expire Offset Frame)包括以下内容。
Stream ID为通常QUIC流的ID(A common quic stream ID)。
Offset(偏移量)为流ID数据的偏移(Stream ID's data offset)，表示“Stream ID”对应的stream的位置偏移。“offset”之前的数据已经丢失且数据不会重传，该offset也是一个boundary帧的值。
例如，Expire Offset Frame的Stream ID用于指示对哪个Stream进行过期操作。Offset是Stream Data Frame的offset，意味着该offset之前的数据，服务端都不再重传了。
在一些实施例中，QUICU的目标是为应用程序提供可控的非可靠数据传输能力，该能力有两种模式，单流模式和多流模式。
例如，在单流模式下，所有类型的数据按边界划分，并在单流中传输。当所有类型的数据具有相同的过期时间时，它们可以很好地工作。但是，如果不同类型的数据具有不同的超时时间(即过期时间)，那么一个过期的帧可能会使其他不应过期的数据类型过期，从而受到线路阻塞的影响。
例如，在多流模式中，可以将不同类型的数据放入不同的流中。这些流可以通过相关帧映射到相同的请求流，从而解决了单流模式的问题。每个流的数据块必须完全 交付到应用程序缓冲区，然后才能交付另一个流的数据块。如果流的数据块在交付时由于缓冲区大小而被阻止，则应阻止与请求对应的所有流，直到可以交付数据为止。
在一些实施例中，本公开的技术方案还可以包括错误处理流程。如果接收端不支持QUICU模式，但又收到了boundary、expire offset或correlation帧，应该关闭该链接并返回“不支持QUICU”模式。
图3示出根据本公开的数据传输方法的一些实施例的示意图。
如图3所示，一个流媒体应用正在传输HTTP(HyperText Transfer Protocol，超文本传输协议)-FLV(FLASH VIDEO)视频数据。因为实时性的原因，需要将音视频分开传输。
在一些实施例中，在服务端创建两个流，分别用于传输音频和视频，即图3中“不同优先级的数据”。
在一些实施例中，使用收到请求的流，进行http response的回复，并发送flv的头信息，即图3中的“file header”。
在一些实施例中，服务端先通过客户端的流进行相关头的回复，之后再创建流并发送CORRELATION帧，最后进行音视频数据传输。但是，该流程并不能保证数据实际到达客户端的顺序。所以，需要用一个状态维持它们的关系，音视频流即不同优先级数据和file header都受状态控制，在状态控制下都处于阻塞状态。
在一些实施例中，收到CORRELATION帧后，将会作用在状态控制上；状态控制将CORRELATION帧指示的不用优先级的数据还有file header，都设置成非阻塞状态，即开始向应用传送数据。
图4a～4b示出本公开的数据传输装置的一些实施例的框图。
如图4a所示，数据的传输装置4a设置在发送端，包括：连接单元41a，用于建立与待传输数据的接收端的连接；发送单元42a，用于向接收端发送用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便接收端根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
在一些实施例中，传输装置4a包括：生成单元43a，用于生成过期偏移帧、边界帧或者相关帧中的至少一个。
在一些实施例中，过期偏移帧包括第一偏移量，所述第一偏移量用于指示待传输 数据的数据流中相对于过期偏移帧的第一偏移量之前的数据不被重新传输。
在一些实施例中，边界位置包括结束位置，边界帧包括第二偏移量，第二偏移量用于指示数据块的结束位置。
在一些实施例中，边界帧用于在数据块包括的数据段已丢失且不被重新传输的情况下，保存数据段的传输的相关信息、重新传输的相关信息或重新传输请求的相关信息。
在一些实施例中，边界帧用于为数据块包括的多个数据段分配相同的传输优先级。
在一些实施例中，相同的传输优先级用于指示在数据块中的一部分数据段丢失且不被重新传输的情况下，数据块中的另一部分数据段也不被重新传输。
在一些实施例中，相关帧包括相关流ID，基于同一请求创建的多个数据流中的每一个的相关流ID相同。
在一些实施例中，相关帧关联的多个数据流被一起呈现。
在一些实施例中，发送单元42a在建立连接时，根据接收端的标识符，确认接收端是否支持QUICU。过期偏移帧、边界帧或者相关帧中的至少一个在接收端支持QUICU的情况下被发送。
如图4b所示，数据的传输装置4b设置在接收端，包括：连接单元43b，用于建立与待传输数据的发送端的连接；接收单元41b，用于接收发送端发送的用于指示待传输数据中不被重新传输的数据的过期偏移帧、用于指示待传输数据的数据流中数据块的边界位置的边界帧或者用于关联待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个；传输单元42b，用于根据过期偏移帧、边界帧或者相关帧中的至少一个进行待传输数据的传输。
图5示出本公开的数据传输装置的另一些实施例的框图。
如图5所示，该实施例的数据的传输装置5包括：存储器51以及耦接至该存储器51的处理器52，处理器52被配置为基于存储在存储器51中的指令，执行本公开中任意一个实施例中的数据传输方法。
其中，存储器51例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)、数据库以及其他程序等。
图6示出本公开的数据传输装置的又一些实施例的框图。
如图6所示，该实施例的数据的传输装置6包括：存储器610以及耦接至该存储 器610的处理器620，处理器620被配置为基于存储在存储器610中的指令，执行前述任意一个实施例中的数据传输方法。
存储器610例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)以及其他程序等。
数据传输装置6还可以包括输入输出接口630、网络接口640、存储接口650等。这些接口630、640、650以及存储器610和处理器620之间例如可以通过总线660连接。其中，输入输出接口630为显示器、鼠标、键盘、触摸屏、麦克、音箱等输入输出设备提供连接接口。网络接口640为各种联网设备提供连接接口。存储接口650为SD卡、U盘等外置存储设备提供连接接口。
图7示出本公开的数据传输系统的一些实施例的框图。
如图7所示，数据传输系统7包括：发送端71，用于执行上述任一个实施例中的发送端侧的数据传输方法；接收端72，用于执行上述任一个实施例中的接收端的数据传输方法。
图8a～8e示出根据本公开的数据传输方法的另一些实施例的示意图。
如图8a所示，一个流媒体应用正在传输视频数据，它向QUIC非可靠流写了5个FLV Video Tag(A、B、C、D、E之前的流数据都已被交付给应用层，为了简化，这个实施例只表示了一个非可靠流)。QUIC在应用每次写入的时候，都生成了对应的BOUNDARY帧(边界帧)。例如，BOUNDARY帧用于指示数据块(如Tag A～E)在数据流中的起始位置。Tag A由于体积过大被截断为part 1和part 2，但QUIC保证了A的BOUNDARY帧和A的起始部分(如Tag A的part 1)在同一个QUIC包中被发送。此时，接收端收到了A的BOUNDARY帧和A的起始部分。但是，此时它还不能把A交付给应用，因为它还没有收到紧邻的下一个BOUNDARY帧。
接下来，如图8b所示，接收端陆续收到了A的剩余部分(如Tag A的part 2)，B的起始流数据(如Tag B的part 1)和对应的BOUNDARY帧。由于接收端收到了两个BOUNDARY帧，且中间的连续内容都收到了，此前的数据也已经交付了，所以它将A交付给了应用层。
例如，在接收到边界帧且边界帧与上一边界帧之间的数据段均已被接收端接收到的情况下，边界帧与上一边界帧之间的数据段被接收端交付给应用。
接下来，如图8c所示，由于丢包，B的剩余部分迟迟没有被接收端确认，所以发送端决定主动把B过期掉，发送端此时发送了一个EXPIRE_OFFSET帧(图中没有示 出，即过期偏移帧)。接收端收到了EXPIRE_OFFSET帧后，将接收数据的缓存数据最小偏移值(buffer offset)增大到EXPIRE_OFFSET帧指定的位置，也即B结束的位置。通过EXPIRE_OFFSET通知接收端，EXPIRE_OFFSET的偏移量之前的数据段不被重新传输。
例如，在接收端在预设时间内没有确认接收到数据块的情况下，向接收端发送过期偏移帧
此后，如图8d所示，B的剩余数据没有再被发送端重传，接收端收到了C、D的流数据以及它们的BOUNDARY帧。由于收到了C和D的BOUNDARY帧，且中间的连续数据都收到了，此前的数据已被过期掉，所以接收端可以将C的流数据交付给应用(图中加粗表示)。
此后，如图8e所示，双端发送/接收完剩余的数据，为了保证最后一段数据E能够被交付，发送方在结束前发送了一个空的BOUNDARY帧，用于表示数据块被发送和接收完毕。
在一些实施例中，如果更改BOUNDARY帧的语义，使得它的offset字段表示的是下一段数据的结束位置，也能实现非可靠传输。例如，对应的，需要修改接收端读数据的策略，在这种语义下，接收端只需要一个BOUNDARY帧就能知道一段数据的结束位置，起始位置可由BOUNDARY帧的位置计算出来。
本领域内的技术人员应当明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
至此，已经详细描述了根据本公开的。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。
可能以许多方式来实现本公开的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和系统。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开 还覆盖存储用于执行根据本公开的方法的程序的记录介质。
虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。

Claims (19)

  1. 一种数据传输方法，包括：
    建立与待传输数据的接收端的连接；
    向所述接收端发送用于指示所述待传输数据中不被重新传输的数据的过期偏移帧、用于指示所述待传输数据的数据流中数据块的边界位置的边界帧或者用于关联所述待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便所述接收端根据所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个进行所述待传输数据的传输，
    其中，在所述接收端在预设时间内没有确认接收到所述数据块的情况下，向所述接收端发送所述过期偏移帧。
  2. 根据权利要求1所述的数据传输方法，其中，在接收到所述边界帧且所述边界帧与上一边界帧之间的数据段均已被接收端接收到的情况下，所述边界帧与上一边界帧之间的数据段被所述接收端交付给应用。
  3. 根据权利要求1或2所述的数据传输方法，其中，所述过期偏移帧包括第一偏移量，所述第一偏移量用于指示所述待传输数据的数据流中相对于所述过期偏移帧的所述第一偏移量之前的数据不被重新传输。
  4. 根据权利要求1～3任一项所述的数据传输方法，其中，所述边界位置包括结束位置，所述边界帧包括第二偏移量，所述第二偏移量用于指示所述数据块的结束位置。
  5. 根据权利要求1～4任一项所述的数据传输方法，其中，所述边界帧用于在所述数据块包括的数据段已丢失且不被重新传输的情况下，保存所述数据段的传输的相关信息、重新传输的相关信息或重新传输请求的相关信息。
  6. 根据权利要求1～5任一项所述的数据传输方法，其中，所述边界帧用于为所述数据块包括的多个数据段分配相同的传输优先级。
  7. 根据权利要求6所述的数据传输方法，其中，所述相同的传输优先级用于指示在所述数据块中的一部分数据段丢失且不被重新传输的情况下，所述数据块中的另一部分数据段也不被重新传输。
  8. 根据权利要求1～7任一项所述的数据传输方法，其中，所述相关帧包括相关流ID，所述基于同一请求创建的多个数据流中的每一个的相关流ID相同。
  9. 根据权利要求1～8任一项所述的数据传输方法，其中，所述相关帧关联的所述多个数据流被一起呈现。
  10. 根据权利要求1-9任一项所述的数据传输方法，还包括：
    在建立所述连接时，根据所述接收端的标识符，确认所述接收端是否支持扩展的快速用户数据报协议互联网连接QUICU，
    其中，所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个在所述接收端支持QUICU的情况下被发送。
  11. 一种数据传输方法，包括：
    建立与待传输数据的发送端的连接；
    接收所述发送端发送的用于指示所述待传输数据中不被重新传输的数据的过期偏移帧、用于指示所述待传输数据的数据流中数据块的边界位置的边界帧或者用于关联所述待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，在所述待传输数据的接收端在预设时间内没有确认接收到所述数据块的情况下，所述过期偏移帧被所述发送端发送；
    根据所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个进行所述待传输数据的传输。
  12. 根据权利要求11所述的数据传输方法，还包括：
    在建立所述连接时，向所述发送端发送标识符，用于标识所述待传输数据的接收端是否支持扩展的快速用户数据报协议互联网连接QUICU，
    其中，所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个在所述接收端 支持QUICU的情况下被发送。
  13. 一种数据传输装置，所述传输装置设置在发送端，包括：
    连接单元，用于建立与待传输数据的接收端的连接；
    发送单元，用于向所述接收端发送用于指示所述待传输数据中不被重新传输的数据的过期偏移帧、用于指示所述待传输数据的数据流中数据块的边界位置的边界帧或者用于关联所述待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，以便所述接收端根据所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个进行所述待传输数据的传输；
    其中，所述发送单元在所述接收端在预设时间内没有确认接收到所述数据块的情况下，向所述接收端发送所述过期偏移帧。
  14. 一种数据传输装置，所述传输装置设置在接收端，包括：
    连接单元，用于建立与待传输数据的发送端的连接；
    接收单元，用于接收所述发送端发送的用于指示所述待传输数据中不被重新传输的数据的过期偏移帧、用于指示所述待传输数据的数据流中数据块的边界位置的边界帧或者用于关联所述待传输数据中基于同一请求创建的多个数据流的相关帧中的至少一个，在所述待传输数据的接收端在预设时间内没有确认接收到所述数据块的情况下，所述过期偏移帧被所述发送端发送；
    传输单元，用于根据所述过期偏移帧、所述边界帧或者所述相关帧中的至少一个进行所述待传输数据的传输。
  15. 一种数据传输系统，包括：
    发送端，用于执行权利要求1～10任一项所述的数据传输方法；
    接收端，用于执行权利要求11或12所述的数据传输方法。
  16. 一种数据传输装置，包括：
    存储器；和
    耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器装置中的指令，执行权利要求1～12任一项所述的数据传输方法。
  17. 一种非易失性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1～12任一项所述的数据传输方法。
  18. 一种计算机程序，包括：
    指令，所述指令当由处理器执行时使所述处理器执行根据权利要求1～12任一项所述的数据传输方法。
  19. 一种计算机程序产品，包括指令，所述指令当由处理器执行时使所述处理器执行根据权利要求1～12任一项所述的数据传输方法。
PCT/CN2023/109109 2022-07-26 2023-07-25 数据传输方法、装置和系统 Ceased WO2024022334A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202380054941.0A CN119563299A (zh) 2022-07-26 2023-07-25 数据传输方法、装置和系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2022/107952 2022-07-26
CN2022107952 2022-07-26

Publications (1)

Publication Number Publication Date
WO2024022334A1 true WO2024022334A1 (zh) 2024-02-01

Family

ID=89705531

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/109109 Ceased WO2024022334A1 (zh) 2022-07-26 2023-07-25 数据传输方法、装置和系统

Country Status (2)

Country Link
CN (1) CN119563299A (zh)
WO (1) WO2024022334A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119547414A (zh) * 2022-07-26 2025-02-28 抖音视界有限公司 数据传输方法、装置和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107040343A (zh) * 2016-02-03 2017-08-11 中国移动通信集团公司 一种重传调度方法及装置
CN111740808A (zh) * 2019-03-25 2020-10-02 华为技术有限公司 一种数据传输方法及装置
US20220166832A1 (en) * 2020-04-16 2022-05-26 Huawei Technologies Co., Ltd. Device and Method for Romote Direct Memory Access
US20220191139A1 (en) * 2020-12-16 2022-06-16 Nokia Solutions And Networks Oy Reliable generic routing encapsulation tunnels
CN114697240A (zh) * 2020-12-31 2022-07-01 华为技术有限公司 数据传输方法、装置、系统及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107040343A (zh) * 2016-02-03 2017-08-11 中国移动通信集团公司 一种重传调度方法及装置
CN111740808A (zh) * 2019-03-25 2020-10-02 华为技术有限公司 一种数据传输方法及装置
US20220166832A1 (en) * 2020-04-16 2022-05-26 Huawei Technologies Co., Ltd. Device and Method for Romote Direct Memory Access
US20220191139A1 (en) * 2020-12-16 2022-06-16 Nokia Solutions And Networks Oy Reliable generic routing encapsulation tunnels
CN114697240A (zh) * 2020-12-31 2022-07-01 华为技术有限公司 数据传输方法、装置、系统及存储介质

Also Published As

Publication number Publication date
CN119563299A (zh) 2025-03-04

Similar Documents

Publication Publication Date Title
TWI559717B (zh) 互動式即時媒體之傳輸協議
CN102006283B (zh) 数据传输的方法和装置
JP5816718B2 (ja) 通信装置、通信システム、およびデータ通信の中継方法
EP3108639B1 (en) Transport accelerator implementing extended transmission control functionality
US20200358886A1 (en) Data Transmission Method, Apparatus, And System
CN115883680B (zh) 一种基于arq的udp协议数据传输方法、系统及设备
CN114051173B (zh) 一种基于rtp扩展头部的视频帧可靠传输方法、装置及设备
CN102143137A (zh) 媒体流发送及接收方法、装置和系统
CN106612284B (zh) 一种流数据的传输方法和装置
CN101854286A (zh) 基于用户数据报协议的数据流发送、接收方法及装置
EP3742746A1 (en) Method and device for realizing video service, and communication system and computer-readable storage medium
CN112769526B (zh) 数据包重传方法、系统和存储介质
CN117978787A (zh) 数据传输方法、装置、系统、电子设备及存储介质
US12192003B2 (en) Network equipment and method for delivering data packets
US20190387029A1 (en) Method and system for upload optimization
WO2024022334A1 (zh) 数据传输方法、装置和系统
CN115801199A (zh) 一种确认报文的处理方法和通信装置以及存储介质
WO2024022335A1 (zh) 数据传输方法、装置和系统
CN115348336B (zh) 异构数据流的通用传输架构
US11811877B2 (en) Universal transport framework for heterogeneous data streams
Hurtig et al. SCTP: designed for timely message delivery?
WO2025251782A1 (zh) 图像帧处理方法、网络设备、存储介质和程序产品
WO2023280405A1 (en) Multiple data flows management
WO2009138365A1 (en) Method of communication between a source unit and a destination unit and communication node
JP2004186737A (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: 23845543

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202380054941.0

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 202380054941.0

Country of ref document: CN

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 03.06.2025)

122 Ep: pct application non-entry in european phase

Ref document number: 23845543

Country of ref document: EP

Kind code of ref document: A1