WO2019148563A1 - 一种数据发送方法、接收方法及装置 - Google Patents

一种数据发送方法、接收方法及装置 Download PDF

Info

Publication number
WO2019148563A1
WO2019148563A1 PCT/CN2018/077432 CN2018077432W WO2019148563A1 WO 2019148563 A1 WO2019148563 A1 WO 2019148563A1 CN 2018077432 W CN2018077432 W CN 2018077432W WO 2019148563 A1 WO2019148563 A1 WO 2019148563A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
data
batch
data packet
sending
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/CN2018/077432
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.)
Wangsu Science and Technology Co Ltd
Original Assignee
Wangsu Science and Technology 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 Wangsu Science and Technology Co Ltd filed Critical Wangsu Science and Technology Co Ltd
Priority to EP18769942.6A priority Critical patent/EP3547580B1/en
Priority to US16/071,725 priority patent/US11316609B2/en
Publication of WO2019148563A1 publication Critical patent/WO2019148563A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/20Arrangements for detecting or preventing errors in the information received using signal quality detector
    • H04L1/203Details of error rate determination, e.g. BER, FER or WER
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0019Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy in which mode-switching is based on a statistical approach
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • H04L1/1685Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • H04L1/1877Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/2187Live feed

Definitions

  • the present invention relates to the field of network communication technologies, and in particular, to a data transmission method, a receiving method, and a device.
  • the live broadcast implementation relies on the technical means of live streaming, that is, the client of the anchor pushes the video data stream to the server of the live broadcast platform, and the client of the viewer obtains the video data stream from the server of the live broadcast platform, thereby realizing the live broadcast.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • the invention provides a data sending method, a processing method and a device, which are used to reduce packet loss and improve utilization of network resources.
  • the embodiment of the invention provides a data sending method, including:
  • the first device generates a data packet according to the data stream to be sent
  • the first device records the number of the data packets that have been sent
  • the first device sends a verification packet to the second device;
  • the first device updates the packet sending rate according to a packet loss rate of multiple batch data packets.
  • the first device updates the packet sending rate according to a packet loss rate of the multiple batch data packets, including:
  • the first device updates the packet sending rate according to a packet loss rate of a plurality of batch data packets whose round-trip delay difference is less than a preset range.
  • the data packet includes a sending sequence number
  • the verification response includes a sending sequence number of the batch data packet received by the second device
  • the first device updates the packet sending rate according to a packet loss rate of the multiple batch data packets, including:
  • the first device updates the packet sending rate according to a packet loss rate of multiple batch data packets.
  • it also includes:
  • the first device continues to send the next batch of data packets; the next batch of data packets includes the sent data packets that are not received by the second device.
  • the first device includes a sending buffer.
  • the method further includes:
  • the first device deletes the data packet corresponding to the batch from the sending buffer.
  • An embodiment of the present invention provides a data receiving method, including:
  • the second device receives the data packet sent by the first device
  • the second device When receiving the verification packet sent by the first device, the second device returns a verification response to the first device.
  • the second device includes a receiving buffer; the data packet includes a sending sequence number;
  • the second device When the second device receives the verification packet sent by the first device, the second device returns a verification response to the first device, including:
  • the second device generates a verification response, where the verification response includes a transmission sequence number of the data packet in the receiving buffer.
  • the second device further includes a processing buffer
  • the second device generates a verification response, and further includes:
  • the preset batch data packet When the preset batch data packet is buffered in the receiving buffer, the preset batch data packet is transferred from the receiving buffer to the processing buffer; the preset batch data packet And sending a preset number of data packets consecutive to the serial number;
  • the second device processes the data packet in a multi-thread in the processing buffer.
  • the second device is a node server in the content distribution network CDN; the data packet further includes an IP address of the destination node server;
  • the sending domain name chain is a path formed by a plurality of node servers in the CDN network as a destination node server;
  • the second device sends the data packet to the destination node server by using the sending domain name chain; the destination node server is configured to send the data packet to the application server.
  • An embodiment of the present invention provides a data sending apparatus, including:
  • a processing unit configured to generate a data packet according to the data stream to be sent
  • a transceiver unit configured to send the data packet to the second device according to the sending rate
  • the processing unit is further configured to record the number of the data packets that have been sent;
  • the processing unit is further configured to: when the number of the data packets that have been sent reaches a preset number of batches, send the verification packet to the second device by using the transceiver unit;
  • the processing unit is further configured to receive, by the transceiver unit, a verification response returned by the second device, and determine a packet loss rate of the batch data packet;
  • the processing unit is further configured to update the packet sending rate according to a packet loss rate of the plurality of batch data packets.
  • the processing unit is configured to:
  • the processing unit determines, according to the verification packet corresponding to the batch data packet and the verification response, the batch data packet corresponding to each batch of the plurality of batch data packets Round trip delay;
  • the processing unit updates the packet sending rate according to a packet loss rate of a plurality of batch data packets whose round-trip delay difference is less than a preset range.
  • the data packet includes a sending sequence number
  • the verification response includes a sending sequence number of the batch data packet received by the second device
  • the processing unit is used to:
  • the packet sending rate is updated according to a packet loss rate of the plurality of batch data packets.
  • processing unit is further configured to:
  • the transceiver unit And transmitting, by the transceiver unit, the next batch of data packets; the next batch of data packets includes the sent data packets that are not received by the second device.
  • the processing unit includes a sending buffer.
  • the processing unit is further configured to:
  • the preset batch data packet The text is a preset number of data packets with consecutive serial numbers
  • the processing unit deletes the preset batch data message from the sending buffer.
  • An embodiment of the present invention provides a data receiving apparatus, including:
  • a transceiver unit configured to receive a data packet sent by the first device
  • the processing unit is configured to: when the transceiver unit receives the verification packet sent by the first device, return a verification response to the first device by using the transceiver unit.
  • the processing unit includes a receiving buffer; the data packet includes a sending sequence number;
  • the processing unit is used to:
  • a verification response is generated, where the verification response includes a transmission sequence number of the data packet in the receiving buffer.
  • the processing unit further includes a processing buffer
  • the processing unit is also used to:
  • the data message is processed in multiple threads in the processing buffer.
  • the receiving device is a node server in a content distribution network; the data packet further includes an IP address of the destination node server;
  • the processing unit is further configured to:
  • the sending domain name chain is a path formed by a plurality of node servers in the content distribution network as a path of the destination node server;
  • the destination node server is configured to send the data packet to the application server.
  • An embodiment of the present invention provides a computing device, including: at least one processor and a memory communicatively coupled to the at least one processor;
  • the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the data transmitting method of any of the above And/or the data receiving method according to any of the above.
  • An embodiment of the present invention provides a non-transitory computer readable storage medium storing computer executable instructions for causing the computer to execute as described above
  • the embodiment of the present invention provides a data sending method, a receiving method, and a device, where the method includes: the first device generates a data packet according to the data stream to be sent; and the first device sends the data packet to the second device according to the sending rate. a data packet; the first device records the number of sent data packets; when the number of sent data packets reaches a preset number of batches, the first device sends a verification packet to the second device; When receiving the verification packet sent by the first device, the second device returns a verification response to the first device; the first device receives the verification response returned by the second device, and determines a packet loss rate of the batch data packet; The first device updates the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the first device updates the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the packet rate can reflect the current network state to a large extent. Therefore, updating the packet sending rate according to the packet loss rate can make the packet sending rate of the first device more adaptable to the fluctuation of the network bandwidth, thereby reducing the occurrence of packet loss.
  • the first device performs verification to the second device by batch, which reduces the occupation of network resources by the verification process and improves the utilization rate of the network resources.
  • FIG. 1 is a schematic flowchart of a data sending and receiving method according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a live streaming CDN network system according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of a live broadcast push acceleration method according to an embodiment of the present disclosure
  • FIG. 4 is a schematic structural diagram of a data sending apparatus according to an embodiment of the present disclosure.
  • FIG. 5 is a schematic structural diagram of a data receiving apparatus according to an embodiment of the present disclosure.
  • FIG. 6 is a schematic structural diagram of a computing device according to an embodiment of the present disclosure.
  • FIG. 7 is a schematic structural diagram of a computing device according to an embodiment of the present invention.
  • FIG. 1 is a schematic flowchart of a data sending and receiving method according to an embodiment of the present invention. As shown in FIG. 1 , the method includes the following steps:
  • the first device generates a data packet according to the data stream to be sent.
  • S102 The first device sends a data packet to the second device according to the sending rate.
  • S103 The first device records the number of sent data messages.
  • S105 The second device returns a verification response to the first device when receiving the verification packet sent by the first device.
  • the first device receives the verification response returned by the second device, and determines a packet loss rate of the batch data packet.
  • S107 The first device updates the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the first device may be a data sending end
  • the second device may be a data receiving end
  • data can be sent and received through the Internet between the first device and the second device.
  • the data stream sent by the first device to the second device may be a data stream with a known data volume, such as a picture collection, a recorded video program, or the like, or may be a data stream of unknown data volume, such as live video data.
  • the method provided by the embodiment of the present invention may be implemented by embedding a first device and/or a second device by a software development kit (SDK), and the operating system of the first device and/or the second device may be Linux. , Windows, Mac OS, IOS, Android and other mainstream operating systems.
  • SDK software development kit
  • the data stream is sent from the first device to the second device in the form of a data message.
  • the first device packs a certain amount of data stream data into a data packet, and then encapsulates the data packet into a data packet and sends the data packet to the second device.
  • the first device fills the data packet with the data stream data, so that each data packet can carry as much data stream data as possible, thereby reducing the number of data packets.
  • the first device determines that the number of transmitted data messages reaches a preset number of one batch.
  • the first device sends a verification packet to the second device, and the first device also restarts counting.
  • the preset number of a batch is 128, when the number of data packets sent by the first device reaches 128, the verification packet is sent to the second device, and the first device starts from 1 again. count.
  • the verification packet can also carry data stream data, thereby reducing a Round-Trip Time (RTT).
  • RTT Round-Trip Time
  • the second device queries the data packet received by itself.
  • the second device only queries the data packet received during the previous time that the verification packet is received until the verification packet is received, and generates a check according to the data packet received during the period. The response is returned to the second device.
  • the first device determines, according to the verification response, the receiving condition of the batch data packet by the second device, and further determines the packet loss rate of the batch data packet. .
  • the first device updates the packet sending rate according to the packet loss rate of the plurality of batch data packets, and it should be understood that the packet sending rate in S102 is also obtained according to the method shown in S107, where multiple batches are obtained.
  • the secondary data message is a plurality of batch data messages continuously sent by the first device.
  • the first device may obtain an average packet loss rate according to the packet loss rate of the multiple batch data packets, and update the packet transmission rate according to the average packet loss rate to eliminate the misjudgment caused by the network contingency jitter.
  • the first device may also update the packet sending rate according to the central value of the packet loss rate of the plurality of batch data packets, and the specific implementation manner may be determined according to the actual application scenario, and the embodiment of the present invention is not limited.
  • the first device may update the sending rate according to the packet loss rate of the multiple batch data packets, including: the first device is configured for each batch of the plurality of batch data packets, the first device Determining a round-trip delay corresponding to the batch data packet according to the verification packet and the verification response corresponding to the batch data packet; the first device is configured according to a plurality of batch datagrams whose round-trip delay difference is smaller than a preset range
  • the packet loss rate of the text updates the packet sending rate.
  • the packet loss rate in some special cases can be excluded to eliminate the misjudgment caused by the contingency jitter of the network, so that the updated packet rate is more suitable for the network bandwidth.
  • the embodiment of the present invention uses the packet loss rate judgment to avoid the situation that the network state is erroneously determined due to too many data packets received by the second device at the same time, because RTT can only roughly judge the current network congestion, but cannot determine the current bandwidth utilization. Therefore, updating the packet sending rate with the packet loss rate can make the updated packet sending rate more adaptable to the network bandwidth.
  • the first device may also first determine a packet loss rate of the plurality of batch data packets, and if the packet loss ratio of the plurality of batch data packets does not exceed a preset threshold, the multiple batch data is The packet loss rate of the packet can reflect the current network status, and the average packet loss rate of the plurality of batch data packets is obtained.
  • the first device reduces the packet sending rate, and when the average packet loss rate is lower than the second threshold, the first device increases the packet sending rate. If there is a large difference between the packet loss rate of a small number of batch data packets and the packet loss rate of other batches of data packets in consecutive batches of data packets, only the majority is used.
  • the packet loss rate of the batch of data packets determines the average packet loss rate, and then the packet rate is updated according to the average packet loss rate to eliminate false positives caused by network contingency jitter.
  • the first threshold is 0.5
  • the packet loss ratios of the three batch data packets are 0.1, 0.9, and 0.1, respectively. If the average packet loss rate is directly calculated, the calculation result is 0.55, and the first device may reduce the packet sending rate.
  • the data packet of the intermediate batch with a packet loss rate of 0.9 is likely to be caused by network jitter, and does not reflect the deterioration of the network condition. In this case, reducing the packet transmission rate will result in waste of bandwidth resources. Therefore, the intermediate batch with a packet loss rate of 0.9 is excluded, and the average packet loss rate is 0.1, thereby determining that the first device does not need to reduce the packet sending rate, thereby avoiding waste of bandwidth resources.
  • the first device updates the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the packet rate can reflect the current network state to a large extent. Therefore, updating the packet sending rate according to the packet loss rate can make the packet sending rate of the first device more adaptable to the fluctuation of the network bandwidth, thereby reducing the occurrence of packet loss.
  • the first device performs verification to the second device by batch, which reduces the occupation of network resources by the verification process and improves the utilization of network resources.
  • the first device needs to update the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the data packet includes a sending sequence number, and the sending sequence number of the continuously sent data packet continuously changes according to the sending sequence of the data packet.
  • the second device After receiving the verification packet, the second device returns a verification response to the first device, and the verification response includes the transmission sequence number of the batch data packet received by the second device.
  • the first device updates the sending rate according to the packet loss rate of the plurality of batch data packets, and the method includes: determining, by the first device, the batch data report according to the sending sequence number of the batch data packet received by the second device in the verification response The number of data packets that are not received by the second device in the text; the first device determines the packet loss rate of the batch data packet according to the number of the data packets that are not received by the second device and the preset number; The packet rate is updated according to the packet loss rate of multiple batch data packets. After receiving the verification response, the first device determines, according to the verification response, the transmission sequence number of the batch data message that the second device has received.
  • the sending sequence number of each data packet that is continuously sent is continuous, so that the first device can confirm the sending of the batch data packet that is not received by the second device by querying the sending sequence number of the data packet that has been received by the second device.
  • the sequence number can be used to determine the number of data packets that are not received by the second device. Because the first device sends the verification packet according to the preset quantity, the second device is determined not to receive the second packet. After the number of data packets, the packet loss rate can be determined directly according to the preset number. Similarly, after receiving the verification message, the second device does not need to query the exact batch to be verified by the verification message, and the second device queries the received message received since the last time the verification message was received. The sequence number of the data message is sent back to the first device, thereby reducing the query pressure of the second device.
  • the first device continues to send the next batch of data packets; the next batch of data packets includes the sent data packets that are not received by the second device.
  • the first device may determine, according to the sending sequence number of the data packet that the second device has received in the verification response, the sending sequence number of the data packet that is not received by the second device, and therefore resend the second device in the next batch of data packets.
  • the serial number of the data packet that was not received It should be understood that after sending the verification response, the first device does not stop sending the data message, so after transmitting the verification message of a certain batch of data messages, it is determined that the batch is not received by the second device. Multiple batches of data packets may be sent between the transmission sequence numbers of the data packets.
  • the next batch here refers to the sequence number of the data packets that are not received by the second device.
  • the next batch of the batch sent For example, the first device sequentially sends A, a, B, b, C, c, ... to the second device, where A, B, and C respectively represent a batch of data packets, and a, b, and c respectively represent The verification message corresponding to each batch. It is assumed that after the first device sends the data message of the batch A to the second device, the first device sends the verification message a to the second device, and then continues to send the data message of the batch B. After receiving the verification response of the verification message a returned by the second device, the first device determines the data packet in the batch A that is not received by the second device. At this time, the first device is sending the batch B. , the first device will add the data packet that is not received by the second device in batch A in batch C.
  • the first device includes a sending buffer
  • the method further includes: the first device according to the batch data packet received by the second device in the verification response
  • the sending sequence number determines whether the second device completely receives the preset batch data message; if yes, the first device deletes the preset batch data message from the sending buffer.
  • the preset batch data packet is a preset number of data packets with consecutive serial numbers. For example, if the preset number is 128, the first device sends one 128 data packets, and the first device confirms, because the first The device resends some data packets, so the sending sequence number of the data packets in each batch sent by the first device may be discontinuous.
  • the first device sends a data packet of the first batch, and the data packet is sent from 1 to 128, and a verification packet is sent.
  • the sending sequence number included in the first check response received by the first device is 1 to 100, indicating that the second device does not receive the data packet with the sequence number of 101 to 128.
  • the sending buffer of the first device A data packet with a sequence number of 101 to 128 is buffered in the area, and the first device directly sends a data packet with a sequence number of 101 to 128 and resends the data in the next batch, assuming that the next batch is sent by the first device.
  • the serial number of the third batch of data messages will be 101 to 128, and 257 to 357.
  • the data packet of the first device is buffered by the data packet with the sequence number of 1 to 128. After receiving the verification response, it is determined that the data packet with the sequence number of 1 to 128 is all second. After receiving the device, the first device deletes the data packet with the sequence number 1 to 128 from the sending buffer.
  • the data packet of the preset batch refers to a data packet with a sequence number of 1 to 128, a data packet with a sequence number of 129 to 256, and a data packet with a sequence number of 257 to 384. and many more.
  • the second device includes a receiving buffer, and the data packet received by the second device is first buffered in the receiving buffer.
  • the second device determines the sending sequence number of the data packet in the receiving buffer, and generates a verification response, where the verification response includes sending the data packet in the receiving buffer.
  • Serial number the second device only determines the sending sequence number of the data packet received so far after receiving the verification packet last time, and generates a verification response, thereby reducing the running pressure of the second device.
  • the second device may further return the size of the remaining space in the receiving buffer to the first device, and the first device may dynamically adjust the size of each data packet according to the size of the remaining space in the receiving buffer, thereby improving the data.
  • the utilization efficiency of the message and the receive buffer space can also prevent the situation that the remaining space of the receive buffer is too small to receive all data packets.
  • the second device transfers the preset batch data packet from the receive buffer to the processing buffer; the preset batch data packet is Sending a preset number of data packets consecutively; the second device processing the data packet in a multi-thread in the processing buffer. Similar to the first device, the second device also removes the data message from the receive buffer according to the preset batch to ensure that the second device can receive all the data messages. At the same time, the data packet is processed by the multi-thread in the processing buffer to improve the processing capability of the second device for the data packet. Further, a dedicated processor for data reception and processing can also be provided in the second device to reduce the overhead of system scheduling and improve the hit rate of the processor cache.
  • the first device dynamically adjusts the size of the sending buffer according to the packet loss rate, and sends an adjustment command to the second device.
  • the second device adjusts the size of the receiving buffer, generally, sending a buffer.
  • the size of the zone and receive buffers must be the same.
  • the packet loss rate is low, the size of the sending buffer and the receiving buffer are increased, so that the first device can continuously send data packets, and the second device can continuously receive data packets.
  • the first device sends the data packet in the sending buffer according to the sending rate. If the sending buffer is too small, the first device may send no data packet. , resulting in wasted bandwidth resources. Based on the same principle, the receiving buffer of the second device is too small, which also causes waste of bandwidth resources.
  • the first device when the packet loss rate is high, gradually reduces the size of the sending buffer according to the binary method, and sends an adjustment command to the second device to indicate that the second device adjusts the size of the receiving buffer.
  • the first device gradually reduces the size of the sending buffer according to the binary method, and sends an adjustment command to the second device to indicate that the second device adjusts the size of the receiving buffer.
  • FIG. 2 is a schematic structural diagram of a live streaming CDN network system according to an embodiment of the present invention.
  • the live streaming CDN network includes a user terminal, a management server, a plurality of node servers, and an application server.
  • the user terminal is a terminal with an anchor client installed, and the application server is an application server of the live broadcast platform.
  • the user terminal can push live video data to the application server through the live streaming CDN network shown in FIG. 2, thereby enabling the audience to be installed.
  • the terminal of the terminal can obtain live video data from the application server.
  • the live broadcast push stream is performed based on the live streaming CDN network shown in FIG. 2 , and the embodiment of the present invention provides a live broadcast push acceleration method.
  • the data packet further includes an IP address of the destination node server.
  • the method further includes: determining, by the second device, the sending domain name chain according to the IP address of the destination node server; sending the domain name chain to multiple in the CDN network An end point formed by the node server is the path of the destination node server; the second device sends the data packet to the destination node server by sending the domain name chain; the destination node server is configured to send the data packet to the application server.
  • FIG. 3 is a schematic flowchart of a live broadcast traffic acceleration method according to an embodiment of the present invention. As shown in FIG. 3, the method includes the following steps:
  • S301 The user terminal sends an authentication request to the management server.
  • S302 The management server receives the authentication request, and authenticates the user terminal. When the authentication is passed, the configuration list is returned to the user terminal.
  • S303 The user terminal sends the live video data according to the configuration one-way acceleration domain name chain.
  • S304 Accelerate the domain name chain to accelerate the live broadcast of the live video data.
  • the user terminal may send an authentication request to the management server when the client starts, and periodically send an authentication request to the management server during the live broadcast of the video.
  • the user terminal carries the unique identification information corresponding to the client installed by the user terminal in the authentication request sent to the management server, and the unique identifier information may enable the management server to determine the application server to be accessed by the user terminal.
  • the authentication performed by the management server includes determining whether the application server determined according to the identification information in the authentication request has the right to perform live streaming acceleration. For example, if the application A does not purchase the live streaming acceleration service, the management server determines that the corresponding application server is the application server of the application A after determining the application server in the authentication request, and then refuses to provide the live streaming acceleration server. Return the configuration sheet to the user terminal.
  • the configuration list returned by the management server to the user terminal includes the IP address of the node server 1 and the IP address of the destination node server, and the node server 1 is the management server according to the location information of the user terminal, the network status, and the like. The preferred node server that the terminal matches.
  • the destination node server is a node server bound to the application server.
  • the node server 5 in FIG. 2 has a direct data communication relationship with the application server, and can directly send data to the application server.
  • the configuration list may further include acceleration authentication information, for example, a validity period of the live streaming acceleration service, a preset requirement of the live streaming acceleration server, etc.
  • the so-called preset requirement means that the application developer may only need to Some user terminals perform live streaming acceleration.
  • application B purchases the live streaming acceleration service, but application B's application server is located in the north, and application B can only accelerate the live streaming of the southern user terminal. Therefore, in S303, after receiving the configuration list, the user terminal may determine, according to the accelerated authentication information in the configuration list, whether the live video data of the user terminal needs to be accelerated.
  • the accelerated domain name chain refers to a data transmission path composed of a plurality of node servers, the initial node server is the node server 1, and the last node server is the destination node server (node server 5).
  • the user terminal may send the live video data and the IP address of the destination node server to the node server 1 according to the IP address of the node server 1 in the configuration list, and the node server 1 determines the accelerated domain name chain.
  • the user terminal is the first device in the embodiment of the present invention
  • the node server is the second device provided by the embodiment of the present invention
  • the data sending method and the receiving method provided by the embodiment of the present invention interact with each other.
  • accelerating the acceleration of the live stream by the domain name chain is performed by multiple node servers.
  • the path one is the node server 1 - the node server 2 - the node server 3 - the node server 5
  • the path 2 is the node server 1 - the node server 4 - the node
  • the server 5 stores the delay information, the operator information, and the like of the two paths in the node server 1, and the node server 1 selects the optimal path as the accelerated domain name chain.
  • the node server 1 determines that the path 2 is an accelerated domain name chain
  • the data packet sent by the user terminal is forwarded to the node server 4, and the path to the node server 5 is also saved in the node server 4, and finally the data packet is sent.
  • the node server 5 is directly connected to the application server and sends data packets to the application server.
  • FIG. 2 is only a simplified case. In actual use, there may be multiple paths between the node server 4 and the node server 5. In this case, the node server 4 also selects an optimal path from multiple paths. And determining the node server of the next hop, and continuing to forward the data packet to the node server of the next hop and finally to the node server 5.
  • the embodiment of the present invention provides a data sending method and a receiving method, including: a first device generates a data packet according to a data stream to be sent; and the first device sends a data packet to the second device according to the sending rate; The first device records the number of sent data packets; when the number of sent data packets reaches a preset number of batches, the first device sends a verification message to the second device; the second device receives Returning the verification response to the first device when the verification packet is sent by the first device; the first device receives the verification response returned by the second device, and determines the packet loss rate of the batch data packet; The packet loss rate of multiple batch data packets is updated.
  • the first device updates the packet sending rate according to the packet loss rate of the multiple batch data packets.
  • the packet rate can reflect the current network state to a large extent. Therefore, updating the packet sending rate according to the packet loss rate can make the packet sending rate of the first device more adaptable to the fluctuation of the network bandwidth, thereby reducing the occurrence of packet loss.
  • the first device performs verification to the second device by batch, which reduces the occupation of network resources by the verification process and improves the utilization of network resources.
  • FIG. 4 is a schematic structural diagram of a data sending apparatus according to an embodiment of the present invention.
  • the data sending apparatus 400 includes a processing unit 401 and a transceiver unit 402, where:
  • the processing unit 401 is configured to generate a data packet according to the data stream to be sent;
  • the transceiver unit 402 is configured to send the data packet to the second device according to the sending rate.
  • the processing unit 401 is further configured to record the number of the data packets that have been sent;
  • the processing unit 401 is further configured to: when the number of the data packets that have been sent reaches a preset number of batches, send, by the transceiver unit 402, a verification packet to the second device;
  • the processing unit 401 is further configured to receive, by the transceiver unit 402, a verification response returned by the second device, and determine a packet loss rate of the batch data packet;
  • the processing unit 401 is further configured to update the packet sending rate according to a packet loss rate of multiple batch data packets.
  • processing unit 401 is specifically configured to:
  • the processing unit 401 determines, according to the verification packet corresponding to the batch data packet and the verification response, the batch data packet corresponding to each batch of the plurality of batch data messages. Round trip delay;
  • the processing unit 401 updates the packet sending rate according to a packet loss rate of a plurality of batch data packets whose round-trip delay difference is smaller than a preset range.
  • the data packet includes a sending sequence number
  • the verification response includes a sending sequence number of the batch data packet received by the second device
  • the processing unit 401 is specifically configured to:
  • the packet sending rate is updated according to a packet loss rate of the plurality of batch data packets.
  • processing unit 401 is further configured to:
  • the transceiver unit 402 And transmitting, by the transceiver unit 402, the next batch of data packets; the next batch of data packets includes the sent data packets that are not received by the second device.
  • the processing unit 401 includes a sending buffer.
  • the processing unit 401 is further configured to:
  • the preset batch data packet is Sending a preset number of data packets with consecutive serial numbers
  • the processing unit 401 deletes the preset batch data message from the sending buffer.
  • FIG. 5 is a schematic structural diagram of a data receiving apparatus according to an embodiment of the present invention.
  • the data receiving apparatus 500 includes a processing unit 501 and a transceiver unit 502, where:
  • the transceiver unit 502 is configured to receive a data packet sent by the first device.
  • the processing unit 501 is configured to: when the transceiver unit 502 receives the verification packet sent by the first device, return, by the transceiver unit 502, a verification response to the first device.
  • the processing unit 501 includes a receiving buffer; the data packet includes a sending sequence number;
  • the processing unit 501 is specifically configured to:
  • a verification response is generated, where the verification response includes a transmission sequence number of the data packet in the receiving buffer.
  • the processing unit 501 further includes a processing buffer
  • the processing unit 501 is further configured to:
  • the preset batch data packet When the preset batch data packet is buffered in the receiving buffer, the preset batch data packet is transferred from the receiving buffer to the processing buffer; the preset batch data packet And sending a preset number of data packets consecutive to the serial number;
  • the data message is processed in multiple threads in the processing buffer.
  • the receiving device is a node server in a content distribution network; the data packet further includes an IP address of the destination node server;
  • the processing unit 501 is further configured to:
  • the sending domain name chain is a path formed by a plurality of node servers in the content distribution network as a destination node server;
  • the transceiver unit 502 is configured to send the data packet to the destination node server by using the sending domain name chain; the destination node server is configured to send the data packet to the application server.
  • the transceiver unit may be implemented by a transceiver, and the processing unit may be implemented by a processor.
  • FIG. 6 is a schematic structural diagram of a computing device according to an embodiment of the present invention. As shown in FIG. 6, the computing device corresponds to the first device in any of the above embodiments.
  • the computing device of FIG. 6 includes a processor 600 for reading a program in the memory 620 and performing the following processes:
  • the transceiver 610 sends a verification message to the second device;
  • the packet rate is updated according to the packet loss rate of multiple batch data packets.
  • processor 600 is specifically configured to:
  • the packet rate is updated according to the packet loss rate of several batch data packets whose round-trip delay difference is less than the preset range.
  • the data packet includes a sending sequence number
  • the verification response includes a sending sequence number of the batch data packet received by the second device
  • the processor 600 is specifically configured to:
  • the packet rate is updated according to the packet loss rate of multiple batch data packets.
  • processor 600 is further configured to:
  • the next batch of data packets is continuously sent through the transceiver 610; the next batch of data packets includes the transmitted data packets that are not received by the second device.
  • the processor 600 includes a sending buffer.
  • the processor 600 is also used to:
  • the preset batch data packet is a preset with consecutive serial numbers. a number of data messages
  • the bus interface can include any number of interconnected buses and bridges, specifically linked by one or more processors represented by processor 600 and various circuits of memory represented by memory 620.
  • the bus interface can also link various other circuits, such as peripherals, voltage regulators, and power management circuits, as is known in the art and, therefore, will not be further described herein.
  • the bus interface provides an interface.
  • Transceiver 610 can be a plurality of components, including a transmitter and a receiver, providing means for communicating with various other devices on a transmission medium.
  • the user interface 630 may also be an interface capable of externally connecting the required devices, including but not limited to a keypad, a display, a speaker, a microphone, a joystick, and the like.
  • the processor 600 is responsible for managing the bus interface and the usual processing, and the memory 620 can store data used by the processor 600 when performing operations.
  • the processor 600 may be a CPU (Central Embedded Device), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a CPLD (Complex Programmable Logic Device). , complex programmable logic devices).
  • CPU Central Embedded Device
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • CPLD Complex Programmable Logic Device
  • FIG. 7 is a schematic structural diagram of a computing device according to an embodiment of the present invention. As shown in FIG. 7, the computing device corresponds to the second device in any of the above embodiments.
  • the computing device of Figure 7 includes a processor 700 for reading a program in memory 720 and performing the following processes:
  • the transceiver 710 Upon receiving the verification message sent by the first device, the transceiver 710 returns a verification response to the first device.
  • the processor 700 includes a receiving buffer; the data packet includes a sending sequence number;
  • the processor 700 is specifically configured to:
  • a verification response is generated, and the verification response includes a transmission sequence number of the data packet in the receive buffer.
  • the processor 700 further includes a processing buffer.
  • the processor 700 is also used to:
  • the preset batch data packet When the preset batch data packet is buffered in the receiving buffer, the preset batch data packet is transferred from the receiving buffer to the processing buffer; the preset batch data packet is a preset number of consecutive serial numbers. Data message;
  • the data message is processed in multiple threads in the processing buffer.
  • the computing device is a node server in the content distribution network; the data packet further includes an IP address of the destination node server;
  • the processor 700 is also used to:
  • Determining a domain name chain according to an IP address of the destination node server Determining a domain name chain according to an IP address of the destination node server; sending a domain name chain to a destination end server formed by a plurality of node servers in the content distribution network;
  • the data message is sent to the destination node server by sending a domain name chain; the destination node server is configured to send the data message to the application server.
  • an embodiment of the present invention further provides a non-transitory computer readable storage medium storing computer-executable instructions for The computing device is caused to execute the data transmitting method or the data receiving method in any of the above embodiments.
  • the non-transitory computer readable storage medium can be any available media or data storage device accessible by a computer, including but not limited to magnetic storage (eg, floppy disk, hard disk, magnetic tape, magneto-optical disk (MO), etc.), optical storage (eg, CD, DVD, BD, HVD, etc.), and semiconductor memory (such as ROM, EPROM, EEPROM, NAND FLASH, SSD).
  • magnetic storage eg, floppy disk, hard disk, magnetic tape, magneto-optical disk (MO), etc.
  • optical storage eg, CD, DVD, BD, HVD, etc.
  • semiconductor memory such as ROM, EPROM, EEPROM, NAND FLASH, SSD.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Environmental & Geological Engineering (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种数据发送方法、接收方法及装置,其中方法包括:第一设备根据待发送的数据流生成数据报文;按照发包速率向第二设备发送数据报文;第一设备记录已发送的数据报文的数量;在已发送的数据报文的数量达到一个批次的预设数量时,向第二设备发送校验报文;第二设备向第一设备返回校验应答;第一设备接收第二设备返回的校验应答,确定该批次数据报文的丢包率;第一设备根据多个批次数据报文的丢包率更新发包速率。丢包率可以在很大程度上反应出当前的网络状态,因此根据丢包率更新发包速率可以使第一设备的发包速率更能适应网络带宽的波动,第一设备按批次校验,减少了校验过程对网络资源的占用。

Description

一种数据发送方法、接收方法及装置 技术领域
本发明涉及网络通信技术领域,尤其涉及一种数据发送方法、接收方法及装置。
背景技术
随着网络用户对直播这种新兴娱乐形式的追捧,给直播带来了巨大流量。直播的实现需借助于直播推流的技术手段,即主播的客户端将视频数据流推送给直播平台的服务器,由观众的客户端从直播平台的服务器获取视频数据流,从而实现了直播。
由于直播对数据的时效要求非常高,现有的直播推流技术多在具有较高传输速率的用户数据报协议(User Datagram Protocol,UDP)的基础上实现。然而,UDP是一种不可靠的传输协议,在网络带宽出现波动时,往往会出现视频丢帧等情况,影响了直播效果。与此对应的,现有技术中也存在一些基于传输控制协议(Transmission Control Protocol,TCP)的直播推流技术,然而,这种直播推流技术在网络带宽出现波动时,可能会出现视频卡顿等问题。
发明内容
本发明提供一种数据发送方法、处理方法及装置,用以减少丢包同时提高网络资源的利用率。
本发明实施例提供一种数据发送方法,包括:
第一设备根据待发送的数据流生成数据报文;
所述第一设备按照发包速率向第二设备发送所述数据报文;
所述第一设备记录已发送的所述数据报文的数量;
在已发送的所述数据报文的数量达到一个批次的预设数量时,所述第一设备向所述第二设备发送校验报文;
所述第一设备接收所述第二设备返回的校验应答,确定该批次数据报文的丢包率;
所述第一设备根据多个批次数据报文的丢包率更新所述发包速率。
可选的,所述第一设备根据多个批次数据报文的丢包率更新所述发包速率,包括:
针对所述多个批次数据报文中的每一批次数据报文,所述第一设备根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
所述第一设备根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新所述发包速率。
可选的,所述数据报文包括发送序号;所述校验应答中包括所述第二设备收到的该批次数据报文的发送序号;
所述第一设备根据多个批次数据报文的丢包率更新所述发包速率,包括:
所述第一设备根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定该批次数据报文中所述第二设备未收到的数据报文的数量;
所述第一设备根据所述第二设备未收到的数据报文的数量和所述预设数量确定该批次数据报文的丢包率;
所述第一设备根据多个批次数据报文的丢包率更新所述发包速率。
可选的,还包括:
所述第一设备继续发送下一批次数据报文;所述下一批次数据报文中包括所述第二设备未收到的已发送的数据报文。
可选的,所述第一设备包括发送缓冲区;
所述第一设备接收所述第二设备返回的校验应答之后,还包括:
所述第一设备根据所述校验应答中所述第二设备收到的该批次数据报文 的发送序号确定所述第二设备是否完全收到该批次数据报文;
若是,则所述第一设备从所述发送缓冲区中删除所述批次所对应的数据报文。
本发明实施例提供一种数据接收方法,包括:
第二设备接收第一设备发送的数据报文;
所述第二设备在接收到所述第一设备发送的校验报文时,向所述第一设备返回校验应答。
可选的,所述第二设备包括接收缓冲区;所述数据报文包括发送序号;
所述第二设备在接收到所述第一设备发送的校验报文时,向所述第一设备返回校验应答,包括:
所述第二设备确定所述接收缓冲区中的数据报文的发送序号;
所述第二设备生成校验应答,所述校验应答中包括所述接收缓冲区中的数据报文的发送序号。
可选的,所述第二设备还包括处理缓冲区;
所述第二设备生成校验应答,还包括:
在所述接收缓冲区中缓存有预设批次数据报文时,将该预设批次数据报文从所述接收缓冲区转移至所述处理缓冲区;所述预设批次数据报文为所述发送序号连续的预设数量个数据报文;
所述第二设备在所述处理缓冲区中多线程处理所述数据报文。
可选的,所述第二设备为内容分发网络CDN中的节点服务器;所述数据报文中还包括目的节点服务器的IP地址;
所述第二设备将所数据报文发送至应用服务器,包括:
所述第二设备根据所述目的节点服务器的IP地址确定发送域名链;所述发送域名链为所述CDN网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
所述第二设备通过所述发送域名链将所述数据报文发送至所述目的节点 服务器;所述目的节点服务器用于将所述数据报文发送至所述应用服务器。
本发明实施例提供一种数据发送装置,包括:
处理单元,用于根据待发送的数据流生成数据报文;
收发单元,用于按照发包速率向第二设备发送所述数据报文;
所述处理单元,还用于记录已发送的所述数据报文的数量;
所述处理单元,还用于在已发送的所述数据报文的数量达到一个批次的预设数量时,通过所述收发单元向所述第二设备发送校验报文;
所述处理单元,还用于通过所述收发单元接收所述第二设备返回的校验应答,并确定该批次数据报文的丢包率;
所述处理单元,还用于根据多个批次数据报文的丢包率更新所述发包速率。
可选的,所述处理单元用于:
针对所述多个批次数据报文中的每一批次数据报文,所述处理单元根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
所述处理单元根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新所述发包速率。
可选的,所述数据报文包括发送序号;所述校验应答中包括所述第二设备收到的该批次数据报文的发送序号;
所述处理单元用于:
根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定该批次数据报文中所述第二设备未收到的数据报文的数量;
根据所述第二设备未收到的数据报文的数量和所述预设数量确定该批次数据报文的丢包率;
根据多个批次数据报文的丢包率更新所述发包速率。
可选的,所述处理单元还用于:
通过所述收发单元继续发送下一批次数据报文;所述下一批次数据报文中包括所述第二设备未收到的已发送的数据报文。
可选的,所述处理单元包括发送缓冲区;
所述处理单元还用于:
根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定所述第二设备是否完全收到预设批次数据报文;所述预设批次数据报文为发送序号连续的预设数量个数据报文;
若是,则所述处理单元从所述发送缓冲区中删除所述预设批次数据报文。
本发明实施例提供一种数据接收装置,包括:
收发单元,用于接收第一设备发送的数据报文;
处理单元,用于在所述收发单元接收到所述第一设备发送的校验报文时,通过所述收发单元向所述第一设备返回校验应答。
可选的,所述处理单元包括接收缓冲区;所述数据报文包括发送序号;
所述处理单元用于:
确定所述接收缓冲区中的数据报文的发送序号;
生成校验应答,所述校验应答中包括所述接收缓冲区中的数据报文的发送序号。
可选的,所述处理单元还包括处理缓冲区;
处理单元还用于:
在所述接收缓冲区中发送序号连续的数据报文达到一个批次的预设数量时,将该批次数据报文从所述接收缓冲区转移至所述处理缓冲区;
在所述处理缓冲区中多线程处理所述数据报文。
可选的,所述接收装置为内容分发网络中的节点服务器;所述数据报文中还包括目的节点服务器的IP地址;
所述处理单元还用于:
根据所述目的节点服务器的IP地址确定发送域名链;所述发送域名链为 所述内容分发网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
控制所述收发单元通过所述发送域名链将所述数据报文发送至所述目的节点服务器;所述目的节点服务器用于将所述数据报文发送至所述应用服务器。
本发明实施例提供一种计算设备,包括:至少一个处理器和与所述至少一个处理器通信连接的存储器;
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如上述任一项所述的数据发送方法,和/或,如上述任一项所述的数据接收方法。
本发明实施例提供一种非易失性计算机可读存储介质,所述非易失性计算机可读存储介质存储有计算机可执行指令,所述计算机可执行指令用于使所述计算机执行如上述任一项所述的数据发送方法,和/或,如上述任一项所述的数据接收方法。
综上所述,本发明实施例提供一种数据发送方法、接收方法及装置,其中方法包括:第一设备根据待发送的数据流生成数据报文;第一设备按照发包速率向第二设备发送数据报文;第一设备记录已发送的数据报文的数量;在已发送的数据报文的数量达到一个批次的预设数量时,第一设备向第二设备发送校验报文;第二设备在接收到第一设备发送的校验报文时,向第一设备返回校验应答;第一设备接收第二设备返回的校验应答,确定该批次数据报文的丢包率;第一设备根据多个批次数据报文的丢包率更新发包速率。在本发明实施例中,第一设备根据多个批次数据报文的丢包率更新发包速率,丢包率越低说明网络状态越好,丢包率越高说明网络状态越差,由于丢包率可以在很大程度上反应出当前的网络状态,因此根据丢包率更新发包速率可以使第一设备的发包速率更能适应网络带宽的波动,从而减少丢包现象的发生。而且,第一设备按批次向第二设备进行校验,减少了校验过程对网络资源的占用,提高了网络资源利 用率。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种数据收发方法流程示意图;
图2为本发明实施例提供的一种直播推流CDN网络系统架构示意图;
图3为本发明实施例提供的一种直播推流加速方法流程示意图;
图4为本发明实施例提供的一种数据发送装置结构示意图;
图5为本发明实施例提供的一种数据接收装置结构示意图;
图6为本发明实施例提供的一种计算设备结构示意图;
图7为本发明实施例提供的一种计算设备结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
图1为本发明实施例提供的一种数据收发方法流程示意图,如图1所示,包括以下步骤:
S101:第一设备根据待发送的数据流生成数据报文。
S102:第一设备按照发包速率向第二设备发送数据报文。
S103:第一设备记录已发送的数据报文的数量。
S104:在已发送的数据报文的数量达到一个批次的预设数量时,第一设备 向第二设备发送校验报文。
S105:第二设备在接收到第一设备发送的校验报文时,向第一设备返回校验应答。
S106:第一设备接收第二设备返回的校验应答,确定该批次数据报文的丢包率。
S107:第一设备根据多个批次数据报文的丢包率更新发包速率。
具体实施过程中,第一设备可以为数据发送端,第二设备可以为数据接收端,第一设备和第二设备之间可以通过互联网实现数据收发。其中,第一设备向第二设备发送的数据流可以是已知数据量的数据流,如图片合集、录播的视频节目等,也可以是未知数据量的数据流,如直播视频数据。本发明实施例所提供的方法可通过软件开发工具包(Software Development Kit,SDK)嵌入第一设备和/或第二设备的方式实现,第一设备和/或第二设备的操作系统可以是Linux、Windows、Mac OS、IOS、Android等多种主流操作系统。
在S101中,数据流是以数据报文的形式从第一设备发送给第二设备的。具体来说,第一设备将一定量的数据流数据打包为数据包,进而封装为数据报文并发送给第二设备。可选的,第一设备将数据报文中填满数据流数据,使得每一个数据报文都能携带尽可能多的数据流数据,从而减少了数据报文的数量。
在S103和S104中,第一设备会判断已发送的数据报文的数量达到一个批次的预设数量。可选的,已发送的数据报文的数量每达到一个批次的预设数量时,第一设备便会向第二设备发送校验报文,同时,第一设备还会重新开始计数。例如,一个批次的预设数量为128,则当第一设备记录已发送的数据报文数量达到128时,便向第二设备发送校验报文,同时,第一设备会重新从1开始计数。可选的,校验报文也可以携带数据流数据,从而减少一个往返时延(Round-Trip Time,RTT)。此外,第一设备向第二设备发送的其它报文,如建立连接的请求报文等,控制指令在这些报文中所占空间较小,可以充分利用 报文的其它空间携带数据流数据。应理解,在校验报文中也携带视频流数据时,校验报文便对应着第一设备重新开始计数时的1。
在S105中,第二设备在接收到校验报文后,会查询自身接收到的数据报文的情况。可选的,第二设备只查询在前一次接收到校验报文至本次接收到校验报文期间所接收的数据报文情况,并根据这期间所接收的数据报文情况生成校验应答返回给第二设备。
在S106中,第一设备接收第二设备返回的校验应答后,会根据校验应答确定第二设备对该批次数据报文的接收情况,进而确定该批次数据报文的丢包率。
在S107中,第一设备根据多个批次数据报文的丢包率更新发包速率,应理解,在S102中的发包速率也是根据S107中所示的方法更新获得的,此处的多个批次数据报文为第一设备连续发送的多个批次数据报文。具体实施过程中,第一设备可以根据多个批次数据报文的丢包率获取平均丢包率,并根据平均丢包率更新发包速率,以排除网络偶然性的抖动所造成的误判。当然,第一设备也可以根据多个批次数据报文的丢包率的中心值更新发包速率等等,具体实现方式可以根据实际应用场景而定,本发明实施例并不多作限制。
可选的,第一设备可以根据多个批次数据报文的丢包率更新发包速率,包括:第一设备针对多个批次数据报文中的每一批次数据报文,第一设备根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;第一设备根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新发包速率。通过对往返时延的判断可以排除一些特殊情况下的丢包率,以排除网络偶然性的抖动所造成的误判,使得更新后的发包速率更加适应网络带宽情况。此外,与传统的通过RTT判断当前网络状态的方法相比,本发明实施例采用丢包率判断可以避免由于第二设备同时接收的数据报文过多而错误的判断网络状态的情况发生,因为RTT只能粗略地判断当前网络的拥塞情况,但无法判断当前带宽的利用率。因此,采用丢包率更新发包速率可以使更新后 的发包速率更能适应网络带宽情况。
可选的,第一设备还可以先判断连续多个批次数据报文丢包率,若连续多个批次数据报文的丢包率相差不超过预设阈值,说明该多个批次数据报文的丢包率能够反映当前网络状况,进而获取该多个批次数据报文的平均丢包率。在平均丢包率高于第一门限时,第一设备降低发包速率,在平均丢包率低于第二门限时,第一设备提高发包速率。若连续多个批次数据报文中明显存在少数个批次数据报文的丢包率与其它多数个批次的数据报文的丢包率之间存在较大差值,则仅根据该多数个批次的数据报文的丢包率确定平均丢包率,进而根据平均丢包率更新发包速率,以排除网络偶然性的抖动所造成的误判。例如,第一门限为0.5,三个批次数据报文的丢包率分别为0.1、0.9和0.1,若直接计算平均丢包率,则计算结果为0.55,可见第一设备会降低发包速率。然而,丢包率为0.9的中间批次的数据报文很可能是网络抖动造成的,并不能反映网路状况的恶化,在此情况下降低发包速率会造成带宽资源的浪费。因此,需将丢包率为0.9的中间批次排除,获得平均丢包率为0.1,从而确定第一设备无需降低发包速率,避免了对带宽资源的浪费。
在本发明实施例中,第一设备根据多个批次数据报文的丢包率更新发包速率,丢包率越低说明网络状态越好,丢包率越高说明网络状态越差,由于丢包率可以在很大程度上反应出当前的网络状态,因此根据丢包率更新发包速率可以使第一设备的发包速率更能适应网络带宽的波动,从而减少丢包现象的发生。而且,第一设备按批次向第二设备进行校验,减少了校验过程对网络资源的占用,提高了网络资源利用率。
在本发明实施例提供的数据发送方法中,第一设备需要根据多个批次数据报文的丢包率更新发包速率。可选的,数据报文包括发送序号,连续发送的数据报文的发送序号按数据报文的发送顺序连续变化。第二设备在收到校验报文后,会向第一设备返回校验应答,校验应答中会包括第二设备收到的该批次数据报文的发送序号。第一设备根据多个批次数据报文的丢包率更新发包速率, 包括:第一设备根据校验应答中第二设备收到的该批次数据报文的发送序号确定该批次数据报文中第二设备未收到的数据报文的数量;第一设备根据第二设备未收到的数据报文的数量和预设数量确定该批次数据报文的丢包率;第一设备根据多个批次数据报文的丢包率更新发包速率。第一设备在收到校验应答后,根据校验应答确定第二设备已接收的该批次数据报文的发送序号。由于连续发送的各个数据报文的发送序号是连续的,因此第一设备通过查询第二设备已接收的数据报文的发送序号便可确第二设备未接收的该批次数据报文的发送序号,进而便可以确定出第二设备未收到的数据报文的数量,由于第一设备是根据预设数量按批次发送校验报文的,因此,在确定出第二设备未收到的数据报文的数量后,便可以直接根据预设数量确定丢包率。同样的,第二设备在收到校验报文后,也无需查询该校验报文所要校验的确切批次,第二设备查询的是上一次接收校验报文之后至今所收到的数据报文的发送序号并返回给第一设备,从而减少第二设备的查询压力。
可选的,第一设备继续发送下一批次数据报文;下一批次数据报文中包括第二设备未收到的已发送的数据报文。第一设备可以根据校验应答中第二设备已接收的数据报文的发送序号确定第二设备未收到的数据报文的发送序号,因此在下一批次数据报文中重新发送第二设备未收到的数据报文的发送序号。应理解,第一设备在发送校验应答之后,并不会停止发送数据报文,因此在发送某一批次数据报文的校验报文之后到确定第二设备未收到的该批次的数据报文的发送序号之间可能会又发送的了多个批次的数据报文,此处的下一批次指的是确定了第二设备未收到的数据报文的发送序号时所发送批次的下一批次。举例说明,第一设备依次向第二设备发送A、a、B、b、C、c……,其中,A、B、C分别表示一个批次的数据报文,a、b、c分别表示每个批次对应的校验报文。假设,第一设备向第二设备发送了批次A的数据报文后,向第二设备发送校验报文a,之后,继续发送批次B的数据报文。第一设备在收到第二设备返回的校验报文a的校验应答后,确定第二设备未收到的批次A中的数据报文, 此时,第一设备正在发送批次B,则第一设备会在批次C中加入批次A中第二设备未收到的数据报文。
可选的,第一设备包括发送缓冲区;第一设备接收第二设备返回的校验应答之后,还包括:第一设备根据校验应答中第二设备收到的该批次数据报文的发送序号确定第二设备是否完全收到预设批次数据报文;若是,则第一设备从所述发送缓冲区中删除所述预设批次数据报文。其中,预设批次数据报文为发送序号连续的预设数量个数据报文,例如,预设数量为128,则第一设备每发送128个数据报文,便进行一次确认,由于第一设备会重新发送部分数据报文,因此第一设备所发送的每个批次中的数据报文的发送序号有可能是不连续的。假设第一设备发送了第一个批次的数据报文,数据报文的发送序号为1~128,并发送了校验报文。第一设备收到的第一个校验应答中所包括的发送序号为1~100,说明第二设备没有收到发送序号为101~128的数据报文,此时,第一设备的发送缓冲区中还缓冲有发送序号为101~128的数据报文,第一设备直接调取发送序号为101~128的数据报文并在下一批次重新发送,假设下一批次为第一设备发送的第三个批次的数据报文,则第三个批次的数据报文的发送序号将会是101~128,以及,257~357。此时,第一设备的发送缓冲区中依旧缓冲着发送序号为1~128的数据报文,直至某一次收到校验应答后,确定发送序号为1~128的数据报文全被第二设备接收后,第一设备才会将发送序号为1~128的数据报文从发送缓冲区删除。在以上具体实例中,预设批次的数据报文便指的是发送序号为1~128的数据报文,发送序号为129~256的数据报文,发送序号为257~384的数据报文等等。
可选的,第二设备包括接收缓冲区;第二设备所接收的数据报文会被先缓存在接收缓冲区中。第二设备在接收到第一设备发送的校验报文时,确定接收缓冲区中数据报文的发送序号,并生成校验应答,校验应答中包括接收缓冲区中的数据报文的发送序号。可选的,第二设备只确定上一次接收校验报文之后至今所收到的数据报文的发送序号,并生成校验应答,从而减少第二设备的运 行压力。可选的,第二设备还可以向第一设备返回接收缓冲区中剩余空间的大小,第一设备可以根据接收缓冲区中剩余空间的大小动态调整每条数据报文的大小,从而提高对数据报文和接收缓冲区空间的利用效率,也可以防止接收缓冲区剩余空间过小无法接收全部数据报文的情况。
可选的,在接收缓冲区中缓存有预设批次数据报文时,第二设备将该预设批次数据报文从接收缓冲区转移至处理缓冲区;预设批次数据报文为发送序号连续的预设数量个数据报文;第二设备在处理缓冲区中多线程处理数据报文。与第一设备类似,第二设备也按预设批次从接收缓冲区中移除数据报文,以确保第二设备能够接收全部的数据报文。同时,在处理缓冲区中多线程处理数据报文,提高第二设备对数据报文的处理能力。更进一步地,还可以在第二设备中为数据接收和处理配备专用的处理器,以减少系统调度的开销,提高处理器缓存的命中率。
可选的,第一设备根据丢包率动态调整发送缓冲区的大小,同时,向第二设备发送调节指令,第二设备收到调节指令后,相应调整接收缓冲区的大小,一般,发送缓冲区和接收缓冲区的大小需保持一致。可选的,在丢包率较低时,增大发送缓冲区和接收缓冲区的大小,使第一设备可以连续发送数据报文,第二设备可以连续接收数据报文。具体来说,第一设备会按照发包速率发送发送缓冲区中的数据报文,在发包速率较高时,若发送缓冲区过小,则可能会出现第一设备无数据报文可发的情况,造成带宽资源浪费。基于相同的道理,第二设备的接收缓冲区过小,也会造成带宽资源的浪费。可选的,在丢包率较高时,第一设备根据二分法逐步减小发送缓冲区的大小,同时,向第二设备发送调节指令以指示第二设备对应调整接收缓冲区的大小。逐步减小发送缓冲区和接收缓冲区的大小,可以减少过度缩小发送缓冲区和接收缓冲区对带宽资源造成的浪费。
为了更具体地说明本发明实施例所提供的数据发送及接收方法,本发明实施例提供了一种应用于直播推流内容分发网络(Content Delivery Network, CDN)的具体实现方式。图2为本发明实施例提供的一种直播推流CDN网络系统架构示意图,如图2所示,直播推流CDN网络中包括用户终端、管理服务器、若干个节点服务器、以及应用服务器。其中,用户终端为安装有主播客户端的终端,应用服务器为直播平台的应用服务器,用户终端可以通过图2所示的直播推流CDN网络向应用服务器推流直播视频数据,从而使安装有观众客户端的终端可以从应用服务器获取直播视频数据。
基于图2所示的直播推流CDN网络进行直播推流,本发明实施例提供了一种直播推流加速方法。可选的,数据报文中还包括目的节点服务器的IP地址。第二设备(节点服务器1)接收第一设备(用户终端)发送的数据报文之后,还包括:第二设备根据目的节点服务器的IP地址确定发送域名链;发送域名链为CDN网络中多个节点服务器构成的一条终点为目的节点服务器的路径;第二设备通过发送域名链将数据报文发送至目的节点服务器;目的节点服务器用于将数据报文发送至应用服务器。
图3为本发明实施例提供的一种直播推流加速方法流程示意图,如图3所示,主要包括以下几个步骤:
S301:用户终端向管理服务器发送鉴权请求。
S302:管理服务器接收鉴权请求,对用户终端进行鉴权。在鉴权通过时,向用户终端返回配置单。
S303:用户终端根据配置单向加速域名链发送直播视频数据。
S304:加速域名链对直播视频数据进行直播推流加速。
在S301的具体实施过程中,用户终端可以在客户端启动时便向管理服务器发送鉴权请求,在视频直播的过程中,周期性向管理服务器发送鉴权请求。用户终端在向管理服务器发送的鉴权请求中携带有与用户终端所安装的客户端相对应的唯一标识信息,该唯一标识信息可以使管理服务器确定用户终端所要访问的应用服务器。
在S302的具体实施过程中,管理服务器所进行的鉴权包括判断根据鉴权 请求中的标识信息所确定的应用服务器是否有权进行直播推流加速。例如,应用A未购买直播推流加速服务,则管理服务器在通过鉴权请求中的标识信息确定所对应的应用服务器为应用A的应用服务器后,便会拒绝提供直播推流加速服务器,不会向用户终端返回配置单。在鉴权通过时,管理服务器向用户终端返回的配置单中包括节点服务器1的IP地址以及目的节点服务器的IP地址,节点服务器1是管理服务器根据用户终端的位置信息、网络状况等因素为用户终端匹配的优选的节点服务器。目的节点服务器为与应用服务器绑定的节点服务器,如图2中节点服务器5,其与应用服务器之间存在直接的数据通信关系,可以直接将数据发送给应用服务器。可选的,配置单中还可以包括加速认证信息,例如,直播推流加速服务的有效期、直播推流加速服务器的预设要求等,所谓预设要求是指应用的开发商有可能只需要对部分用户终端进行直播推流加速,例如,应用B购买了直播推流加速服务,但应用B的应用服务器位于北方,应用B可以只对南方用户终端的直播推流加速服务。因此在S303中,用户终端在收到配置单后,可以根据配置单中的加速认证信息确定是否需要对用户终端的直播视频数据进行加速。
在S303中,所谓加速域名链指的是由多个节点服务器构成的数据传输路径,其初始的节点服务器为节点服务器1,末尾的节点服务器为目的节点服务器(节点服务器5)。用户终端可以根据配置单中的节点服务器1的IP地址将直播视频数据以及目的节点服务器的IP地址发送给节点服务器1,由节点服务器1确定加速域名链。此时,用户终端为本发明实施例中的第一设备,节点服务器为本发明实施例提供的第二设备,二者之间通过本发明实施例提供的数据发送方法及接收方法进行交互。
在S304的具体实施过程中,加速域名链对直播推流的加速是由多个节点服务器共同完成的。如图2所示,由节点服务器1到节点服务器5共有两条路径,路径一为节点服务器1—节点服务器2—节点服务器3—节点服务器5,路径二为节点服务器1—节点服务器4—节点服务器5,在节点服务器1中会保存 有该两条路径的时延信息、运营商信息等,节点服务器1从中选取最优路径作为加速域名链。例如,节点服务器1确定了路径二为加速域名链,则会将用户终端发送来的数据报文转发至节点服务器4,节点服务器4中同样保存到达节点服务器5的路径,最终将数据报文发送至节点服务器5。节点服务器5与应用服务器直接连接,将数据报文发送给应用服务器。应理解,图2仅为简化情况,实际使用过程中节点服务器4与节点服务器5之间也会有多条路径存在的情况,此时,节点服务器4也会从多条路径中挑选最优路径并确定下一跳的节点服务器,继续将数据报文转发给下一跳的节点服务器并最终传递至节点服务器5。
综上所述,本发明实施例提供一种数据发送方法、接收方法,包括:第一设备根据待发送的数据流生成数据报文;第一设备按照发包速率向第二设备发送数据报文;第一设备记录已发送的数据报文的数量;在已发送的数据报文的数量达到一个批次的预设数量时,第一设备向第二设备发送校验报文;第二设备在接收到第一设备发送的校验报文时,向第一设备返回校验应答;第一设备接收第二设备返回的校验应答,确定该批次数据报文的丢包率;第一设备根据多个批次数据报文的丢包率更新发包速率。在本发明实施例中,第一设备根据多个批次数据报文的丢包率更新发包速率,丢包率越低说明网络状态越好,丢包率越高说明网络状态越差,由于丢包率可以在很大程度上反应出当前的网络状态,因此根据丢包率更新发包速率可以使第一设备的发包速率更能适应网络带宽的波动,从而减少丢包现象的发生。而且,第一设备按批次向第二设备进行校验,减少了校验过程对网络资源的占用,提高了网络资源利用率。
基于相同的技术构思,本发明实施例还提供一种数据发送装置,该数据发送装置可以实现上述任一实施例所提供的数据发送方法。图4为本发明实施例提供的一种数据发送装置结构示意图,如图4所示,数据发送装置400包括处理单元401和收发单元402,其中:
处理单元401,用于根据待发送的数据流生成数据报文;
收发单元402,用于按照发包速率向第二设备发送所述数据报文;
所述处理单元401,还用于记录已发送的所述数据报文的数量;
所述处理单元401,还用于在已发送的所述数据报文的数量达到一个批次的预设数量时,通过所述收发单元402向所述第二设备发送校验报文;
所述处理单元401,还用于通过所述收发单元402接收所述第二设备返回的校验应答,并确定该批次数据报文的丢包率;
所述处理单元401,还用于根据多个批次数据报文的丢包率更新所述发包速率。
可选的,所述处理单元401具体用于:
针对所述多个批次数据报文中的每一批次数据报文,所述处理单元401根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
所述处理单元401根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新所述发包速率。
可选的,所述数据报文包括发送序号;所述校验应答中包括所述第二设备收到的该批次数据报文的发送序号;
所述处理单元401具体用于:
根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定该批次数据报文中所述第二设备未收到的数据报文的数量;
根据所述第二设备未收到的数据报文的数量和所述预设数量确定该批次数据报文的丢包率;
根据多个批次数据报文的丢包率更新所述发包速率。
可选的,所述处理单元401还用于:
通过所述收发单元402继续发送下一批次数据报文;所述下一批次数据报文中包括所述第二设备未收到的已发送的数据报文。
可选的,所述处理单元401包括发送缓冲区;
所述处理单元401还用于:
根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定所述第二设备是否完全收到预设批次数据报文;预设批次数据报文为发送序号连续的预设数量个数据报文;
若是,则所述处理单元401从所述发送缓冲区中删除所述预设批次数据报文。
基于相同的技术构思,本发明实施例还提供一种数据接收装置,该数据接收装置可以实现上述任一实施例所提供的数据接收方法。图5为本发明实施例提供的一种数据接收装置结构示意图,如图5所示,数据接收装置500包括处理单元501和收发单元502,其中:
收发单元502,用于接收第一设备发送的数据报文;
处理单元501,用于在所述收发单元502接收到所述第一设备发送的校验报文时,通过所述收发单元502向所述第一设备返回校验应答。
可选的,所述处理单元501包括接收缓冲区;所述数据报文包括发送序号;
所述处理单元501具体用于:
确定所述接收缓冲区中的数据报文的发送序号;
生成校验应答,所述校验应答中包括所述接收缓冲区中的数据报文的发送序号。
可选的,所述处理单元501还包括处理缓冲区;
处理单元501还用于:
在所述接收缓冲区中缓存有预设批次数据报文时,将该预设批次数据报文从所述接收缓冲区转移至所述处理缓冲区;所述预设批次数据报文为所述发送序号连续的预设数量个数据报文;
在所述处理缓冲区中多线程处理所述数据报文。
可选的,所述接收装置为内容分发网络中的节点服务器;所述数据报文中还包括目的节点服务器的IP地址;
所述处理单元501还用于:
根据所述目的节点服务器的IP地址确定发送域名链;所述发送域名链为所述内容分发网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
控制所述收发单元502通过所述发送域名链将所述数据报文发送至所述目的节点服务器;所述目的节点服务器用于将所述数据报文发送至所述应用服务器。
应理解,以上各个单元的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。本发明实施例中,收发单元可以由收发器实现,处理单元可以由处理器实现。
基于相同的技术构思,本发明实施例提供一种计算设备,图6为本发明实施例提供的一种计算设备结构示意图。如图6所示,该计算设备对应于上述任一实施例中的第一设备。图6中计算设备包括处理器600,用于读取存储器620中的程序,执行下列过程:
根据待发送的数据流生成数据报文;
按照发包速率通过收发器610向第二设备发送数据报文;
记录已发送的数据报文的数量;
在已发送的数据报文的数量达到一个批次的预设数量时,通过收发器610向第二设备发送校验报文;
通过收发器610接收第二设备返回的校验应答,并确定该批次数据报文的丢包率;
根据多个批次数据报文的丢包率更新发包速率。
可选的,处理器600具体用于:
针对多个批次数据报文中的每一批次数据报文,根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新发 包速率。
可选的,数据报文包括发送序号;校验应答中包括第二设备收到的该批次数据报文的发送序号;
处理器600具体用于:
根据校验应答中第二设备收到的该批次数据报文的发送序号确定该批次数据报文中第二设备未收到的数据报文的数量;
根据第二设备未收到的数据报文的数量和预设数量确定该批次数据报文的丢包率;
根据多个批次数据报文的丢包率更新发包速率。
可选的,处理器600还用于:
通过收发器610继续发送下一批次数据报文;下一批次数据报文中包括第二设备未收到的已发送的数据报文。
可选的,处理器600包括发送缓冲区;
处理器600还用于:
根据校验应答中第二设备收到的该批次数据报文的发送序号确定第二设备是否完全收到预设批次数据报文;预设批次数据报文为发送序号连续的预设数量个数据报文;
若是,则从发送缓冲区中删除该预设批次数据报文。
其中,在图6中,总线接口可以包括任意数量的互联的总线和桥,具体由处理器600代表的一个或多个处理器和存储器620代表的存储器的各种电路链接在一起。总线接口还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发器610可以是多个元件,即包括发送器和接收器,提供用于在传输介质上与各种其他装置通信的单元。针对不同的计算设备,用户接口630还可以是能够外接内接需要设备的接口,连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
处理器600负责管理总线接口和通常的处理,存储器620可以存储处理器600在执行操作时所使用的数据。
可选的,处理器600可以是CPU(中央处埋器)、ASIC(Application Specific Integrated Circuit,专用集成电路)、FPGA(Field-Programmable Gate Array,现场可编程门阵列)或CPLD(Complex Programmable Logic Device,复杂可编程逻辑器件)。
基于相同的技术构思,本发明实施例提供另一种计算设备,图7为本发明实施例提供的一种计算设备结构示意图。如图7所示,该计算设备对应于上述任一实施例中的第二设备。图7中计算设备包括处理器700,用于读取存储器720中的程序,执行下列过程:
通过收发器710接收第一设备发送的数据报文;
在接收到所述第一设备发送的校验报文时,通过收发器710向第一设备返回校验应答。
可选的,处理器700包括接收缓冲区;数据报文包括发送序号;
处理器700具体用于:
确定接收缓冲区中的数据报文的发送序号;
生成校验应答,校验应答中包括接收缓冲区中的数据报文的发送序号。
可选的,处理器700还包括处理缓冲区;
处理器700还用于:
在接收缓冲区中缓存有预设批次数据报文时,将该预设批次数据报文从接收缓冲区转移至处理缓冲区;预设批次数据报文为发送序号连续的预设数量个数据报文;
在处理缓冲区中多线程处理所述数据报文。
可选的,该计算设备为内容分发网络中的节点服务器;数据报文中还包括目的节点服务器的IP地址;
处理器700还用于:
根据目的节点服务器的IP地址确定发送域名链;发送域名链为内容分发网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
通过发送域名链将数据报文发送至目的节点服务器;目的节点服务器用于将数据报文发送至应用服务器。
基于相同的技术构思,本发明实施例还提供一种非易失性计算机可读存储介质,所述非易失性计算机可读存储介质存储有计算机可执行指令,所述计算机可执行指令用于使计算设备执行上述任一实施方式中的数据发送方法或数据接收方法。
所述非易失性计算机可读存储介质可以是计算机能够存取的任何可用介质或数据存储设备,包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (20)

  1. 一种数据发送方法,其特征在于,包括:
    第一设备根据待发送的数据流生成数据报文;
    所述第一设备按照发包速率向第二设备发送所述数据报文;
    所述第一设备记录已发送的所述数据报文的数量;
    在已发送的所述数据报文的数量达到一个批次的预设数量时,所述第一设备向所述第二设备发送校验报文;
    所述第一设备接收所述第二设备返回的校验应答,确定该批次数据报文的丢包率;
    所述第一设备根据多个批次数据报文的丢包率更新所述发包速率。
  2. 如权利要求1所述的方法,其特征在于,所述第一设备根据多个批次数据报文的丢包率更新所述发包速率,包括:
    针对所述多个批次数据报文中的每一批次数据报文,所述第一设备根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
    所述第一设备根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新所述发包速率。
  3. 如权利要求1所述的方法,其特征在于,所述数据报文包括发送序号;所述校验应答中包括所述第二设备收到的该批次数据报文的发送序号;
    所述第一设备根据多个批次数据报文的丢包率更新所述发包速率,包括:
    所述第一设备根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定该批次数据报文中所述第二设备未收到的数据报文的数量;
    所述第一设备根据所述第二设备未收到的数据报文的数量和所述预设数量确定该批次数据报文的丢包率;
    所述第一设备根据多个批次数据报文的丢包率更新所述发包速率。
  4. 如权利要求3所述的方法,其特征在于,还包括:
    所述第一设备继续发送下一批次数据报文;所述下一批次数据报文中包括所述第二设备未收到的已发送的数据报文。
  5. 如权利要求4所述的方法,其特征在于,所述第一设备包括发送缓冲区;
    所述第一设备接收所述第二设备返回的校验应答之后,还包括:
    所述第一设备根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定所述第二设备是否完全收到预设批次数据报文;所述预设批次数据报文为所述发送序号连续的预设数量个数据报文;
    若是,则所述第一设备从所述发送缓冲区中删除所述预设批次数据报文。
  6. 一种数据接收方法,其特征在于,包括:
    第二设备接收第一设备发送的数据报文;
    所述第二设备在接收到所述第一设备发送的校验报文时,向所述第一设备返回校验应答。
  7. 如权利要求6所述的方法,其特征在于,所述第二设备包括接收缓冲区;所述数据报文包括发送序号;
    所述第二设备在接收到所述第一设备发送的校验报文时,向所述第一设备返回校验应答,包括:
    所述第二设备确定所述接收缓冲区中的数据报文的发送序号;
    所述第二设备生成校验应答,所述校验应答中包括所述接收缓冲区中的数据报文的发送序号。
  8. 如权利要求7所述的方法,其特征在于,所述第二设备还包括处理缓冲区;
    所述第二设备生成校验应答,还包括:
    在所述接收缓冲区中缓存有预设批次数据报文时,所述第二设备将该预设批次数据报文从所述接收缓冲区转移至所述处理缓冲区;所述预设批次数据报文为所述发送序号连续的预设数量个数据报文;
    所述第二设备在所述处理缓冲区中多线程处理所述数据报文。
  9. 如权利要求6所述的方法,其特征在于,所述第二设备为内容分发网络中的节点服务器;所述数据报文中还包括目的节点服务器的IP地址;
    第二设备接收第一设备发送的数据报文之后,还包括:
    所述第二设备根据所述目的节点服务器的IP地址确定发送域名链;所述发送域名链为所述内容分发网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
    所述第二设备通过所述发送域名链将所述数据报文发送至所述目的节点服务器;所述目的节点服务器用于将所述数据报文发送至所述应用服务器。
  10. 一种数据发送装置,其特征在于,包括:
    处理单元,用于根据待发送的数据流生成数据报文;
    收发单元,用于按照发包速率向第二设备发送所述数据报文;
    所述处理单元,还用于记录已发送的所述数据报文的数量;
    所述处理单元,还用于在已发送的所述数据报文的数量达到一个批次的预设数量时,通过所述收发单元向所述第二设备发送校验报文;
    所述处理单元,还用于通过所述收发单元接收所述第二设备返回的校验应答,并确定该批次数据报文的丢包率;
    所述处理单元,还用于根据多个批次数据报文的丢包率更新所述发包速率。
  11. 如权利要求10所述的发送装置,其特征在于,所述处理单元用于:
    针对所述多个批次数据报文中的每一批次数据报文,所述处理单元根据该批次数据报文对应的校验报文和校验应答确定该批次数据报文对应的往返时延;
    所述处理单元根据往返时延差值小于预设范围的若干个批次数据报文的丢包率更新所述发包速率。
  12. 如权利要求10所述的发送装置,其特征在于,所述数据报文包括发 送序号;所述校验应答中包括所述第二设备收到的该批次数据报文的发送序号;
    所述处理单元用于:
    根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定该批次数据报文中所述第二设备未收到的数据报文的数量;
    根据所述第二设备未收到的数据报文的数量和所述预设数量确定该批次数据报文的丢包率;
    根据多个批次数据报文的丢包率更新所述发包速率。
  13. 如权利要求12所述的发送装置,其特征在于,所述处理单元还用于:
    通过所述收发单元继续发送下一批次数据报文;所述下一批次数据报文中包括所述第二设备未收到的已发送的数据报文。
  14. 如权利要求13所述的发送装置,其特征在于,所述处理单元包括发送缓冲区;
    所述处理单元还用于:
    根据所述校验应答中所述第二设备收到的该批次数据报文的发送序号确定所述第二设备是否完全收到预设批次数据报文;所述预设批次数据报文为发送序号连续的预设数量个数据报文;
    若是,则所述处理单元从所述发送缓冲区中删除所述预设批次数据报文。
  15. 一种数据接收装置,其特征在于,包括:
    收发单元,用于接收第一设备发送的数据报文;
    处理单元,用于在所述收发单元接收到所述第一设备发送的校验报文时,通过所述收发单元向所述第一设备返回校验应答。
  16. 如权利要求15所述的接收装置,其特征在于,所述处理单元包括接收缓冲区;所述数据报文包括发送序号;
    所述处理单元用于:
    确定所述接收缓冲区中的数据报文的发送序号;
    生成校验应答,所述校验应答中包括所述接收缓冲区中的数据报文的发送序号。
  17. 如权利要求16所述的接收装置,其特征在于,所述处理单元还包括处理缓冲区;
    处理单元还用于:
    在所述接收缓冲区中缓存有预设批次数据报文时,将该预设批次数据报文从所述接收缓冲区转移至所述处理缓冲区;所述预设批次数据报文为所述发送序号连续的预设数量个数据报文;
    在所述处理缓冲区中多线程处理所述数据报文。
  18. 如权利要求15所述的接收装置,其特征在于,所述接收装置为内容分发网络CDN中的节点服务器;所述数据报文中还包括目的节点服务器的IP地址;
    所述处理单元还用于:
    根据所述目的节点服务器的IP地址确定发送域名链;所述发送域名链为所述CDN网络中多个节点服务器构成的一条终点为所述目的节点服务器的路径;
    控制所述收发单元通过所述发送域名链将所述数据报文发送至所述目的节点服务器;所述目的节点服务器用于将所述数据报文发送至所述应用服务器。
  19. 一种计算设备,其特征在于,包括:至少一个处理器和与所述至少一个处理器通信连接的存储器;
    所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如权利要求1至5任一项所述的数据发送方法,和/或,如权利要求6至9任一项所述的数据接收方法。
  20. 一种非易失性计算机可读存储介质,其特征在于,所述非易失性计算 机可读存储介质存储有计算机可执行指令,所述计算机可执行指令用于使所述计算机执行如权利要求1至5任一项所述的数据发送方法,和/或,如权利要求6至9任一项所述的数据接收方法。
PCT/CN2018/077432 2018-01-30 2018-02-27 一种数据发送方法、接收方法及装置 Ceased WO2019148563A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18769942.6A EP3547580B1 (en) 2018-01-30 2018-02-27 Data sending method and apparatus, and data receiving method and apparatus
US16/071,725 US11316609B2 (en) 2018-01-30 2018-02-27 Data transmitting method, data receiving method, and device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810090042.7A CN108199925B (zh) 2018-01-30 2018-01-30 一种数据发送方法、接收方法及装置
CN201810090042.7 2018-01-30

Publications (1)

Publication Number Publication Date
WO2019148563A1 true WO2019148563A1 (zh) 2019-08-08

Family

ID=62591939

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/077432 Ceased WO2019148563A1 (zh) 2018-01-30 2018-02-27 一种数据发送方法、接收方法及装置

Country Status (4)

Country Link
US (1) US11316609B2 (zh)
EP (1) EP3547580B1 (zh)
CN (1) CN108199925B (zh)
WO (1) WO2019148563A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112698942A (zh) * 2020-12-29 2021-04-23 杭州海康威视数字技术股份有限公司 一种人工智能服务系统、主控装置和从控装置

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109361757B (zh) * 2018-11-09 2022-02-25 网宿科技股份有限公司 一种数据传输方法、装置及计算机可读存储介质
CN109347766B (zh) * 2018-12-07 2022-03-08 网宿科技股份有限公司 一种资源调度的方法及装置
CN111756641B (zh) * 2019-03-28 2024-07-09 华为技术有限公司 一种发送设备的调整方法和通信装置
CN112650618B (zh) * 2019-10-12 2024-08-23 伊姆西Ip控股有限责任公司 用于备份数据的方法、设备和计算机程序产品
CN112788265B (zh) * 2019-11-11 2024-02-02 浙江宇视科技有限公司 录像数据保存方法、装置、图像采集设备及可读存储介质
CN114221905B (zh) * 2020-09-03 2024-10-29 平头哥(上海)半导体技术有限公司 处理单元及流控制单元、以及相关方法
CN114301811B (zh) * 2020-09-23 2024-11-15 中国移动通信有限公司研究院 一种信息处理方法、装置及隧道端点网元
CN112565295A (zh) * 2020-12-24 2021-03-26 中国电子科技集团公司第二十研究所 一种基于顺序编码的指令应答优化方法
CN112583935B (zh) * 2020-12-28 2022-11-22 深信服科技股份有限公司 缓冲区窗口调整方法、网关设备及存储介质
CN113259255B (zh) * 2021-06-03 2021-10-08 鹏城实验室 一种网络拥塞控制方法、装置、终端及存储介质
CN113609049A (zh) * 2021-08-11 2021-11-05 联想长风科技(北京)有限公司 一种cpu与fpga之间的数据传输方法及系统
CN115037700B (zh) * 2022-04-29 2023-04-21 北京龙腾佳讯科技股份公司 一种复杂网络数据包传送方法、系统、终端及存储介质
CN116193432B (zh) * 2023-05-04 2023-07-04 国网浙江省电力有限公司信息通信分公司 一种基于5g网络的信息安全鉴权方法及系统
CN116390148B (zh) * 2023-06-02 2023-08-11 联友智连科技有限公司 用于c-v2x无线通信设备的通信距离测试方法和装置
CN116886611B (zh) * 2023-07-06 2025-07-11 广西通信规划设计咨询有限公司 一种基于cdn网络的拥塞控制方法、系统、设备及介质
CN119155000B (zh) * 2024-07-22 2025-10-14 北京邮电大学 基于自适应逐跳缓存的网络可靠性保障方法以及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1655547A (zh) * 2004-09-09 2005-08-17 上海川海信息科技有限公司 一种流媒体传输系统中的速率控制方法
CN101282173A (zh) * 2008-05-21 2008-10-08 华为技术有限公司 一种数据包发送速率的调整方法、系统和装置
US20080267077A1 (en) * 2007-04-26 2008-10-30 Juen-Tien Peng Real-Time Internet Error Correction
CN106452692A (zh) * 2016-11-30 2017-02-22 网宿科技股份有限公司 一种数据传输方法和系统
CN106487613A (zh) * 2016-11-16 2017-03-08 北京华为数字技术有限公司 一种带宽测试方法、装置和系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6112323A (en) * 1998-06-29 2000-08-29 Microsoft Corporation Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
US6381215B1 (en) * 1998-06-29 2002-04-30 Microsoft Corporation Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
JP3699910B2 (ja) * 2000-10-31 2005-09-28 株式会社東芝 データ伝送装置、データ伝送方法及びプログラム
EP2784996A1 (en) * 2013-03-27 2014-10-01 British Telecommunications public limited company Deadline driven content delivery
CN106936661B (zh) * 2015-12-31 2020-01-03 华为技术有限公司 一种网络监测方法、装置及系统
CN106330414B (zh) * 2016-08-16 2021-03-26 新华三技术有限公司 一种报文传输方法及装置
US20190215102A1 (en) * 2016-08-30 2019-07-11 Nec Corporation Transmission terminal, transmission method and transmission program
CN106533963B (zh) * 2017-01-11 2019-05-03 深圳云视融通科技有限公司 一种流媒体传输的网络拥塞控制方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1655547A (zh) * 2004-09-09 2005-08-17 上海川海信息科技有限公司 一种流媒体传输系统中的速率控制方法
US20080267077A1 (en) * 2007-04-26 2008-10-30 Juen-Tien Peng Real-Time Internet Error Correction
CN101282173A (zh) * 2008-05-21 2008-10-08 华为技术有限公司 一种数据包发送速率的调整方法、系统和装置
CN106487613A (zh) * 2016-11-16 2017-03-08 北京华为数字技术有限公司 一种带宽测试方法、装置和系统
CN106452692A (zh) * 2016-11-30 2017-02-22 网宿科技股份有限公司 一种数据传输方法和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112698942A (zh) * 2020-12-29 2021-04-23 杭州海康威视数字技术股份有限公司 一种人工智能服务系统、主控装置和从控装置
CN112698942B (zh) * 2020-12-29 2023-10-27 杭州海康威视数字技术股份有限公司 一种人工智能服务系统、主控装置和从控装置

Also Published As

Publication number Publication date
US20210203434A1 (en) 2021-07-01
EP3547580A1 (en) 2019-10-02
CN108199925B (zh) 2021-06-04
US11316609B2 (en) 2022-04-26
EP3547580B1 (en) 2020-06-03
CN108199925A (zh) 2018-06-22
EP3547580A4 (en) 2019-10-02

Similar Documents

Publication Publication Date Title
WO2019148563A1 (zh) 一种数据发送方法、接收方法及装置
US9300733B2 (en) System and/or method for client-driven server load distribution
KR102160494B1 (ko) 네트워크 노드, 엔드포인트 노드 및 관심 메시지 수신 방법
CN106664440B (zh) 用于在多媒体系统中接收和发送信息的方法和设备
US10893234B2 (en) System and method of dynamic playback variation for multimedia communication
KR102362244B1 (ko) 미션 크리티컬 데이터 통신 시스템에서의 데이터 송수신 방법 및 장치
WO2017097201A1 (zh) 一种数据传输方法、发送装置及接收装置
CN110505123A (zh) 丢包率的计算方法、服务器及计算机可读存储介质
WO2024207870A1 (zh) 一种数据传输方法和相关装置
CN111786901B (zh) 一种传输参数自适应调整方法及加速服务系统
CN117061071A (zh) 数据传输方法、装置、电子设备及存储介质
WO2026032342A1 (zh) Ack信息反馈策略确定方法、电子设备、存储介质及计算机程序产品
CN111404842A (zh) 数据传输方法、装置及计算机存储介质
WO2024260179A1 (zh) 数据的传输方法、设备及存储介质
US11915315B1 (en) Method, apparatus and system for time stamping and sequencing data items
CN118282967A (zh) 网络拥塞控制方法、系统、装置、产品及电子设备
CN116743660A (zh) 一种面向广域网的拥塞控制方法及装置
CN112449366B (zh) 报文转发方法、装置、无线ap设备及存储介质
US11070321B2 (en) Allowing packet drops for lossless protocols
CN116567104A (zh) 传输速率调整方法、装置及数据传输系统
CN107820274B (zh) 一种移动网络udp业务拥塞处理方法及基站
US20150350310A1 (en) Cloud Transport Platform (CTP) Based Data Transmission Method, System and Corresponding Cloud Transport Platform
CN119922751A (zh) 设备通信方法、装置、设备、存储介质及程序产品
CN121509527A (zh) 一种微信小程序WebSocket通讯连接方法、介质及设备
CN121283965A (zh) 一种文件分发方法、装置、设备及存储介质

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018769942

Country of ref document: EP

Effective date: 20180928

ENP Entry into the national phase

Ref document number: 2018769942

Country of ref document: EP

Effective date: 20180928

NENP Non-entry into the national phase

Ref country code: DE