CN117220838A - Data packet transmission method, device, equipment and storage medium - Google Patents

Abstract

The application discloses a data packet transmission method, a data packet transmission device, data packet transmission equipment and a data packet storage medium, and belongs to the technical field of computer network communication. The method comprises the following steps: under the condition that the transmitting end is in an application limited state, determining first data from a retransmission unacknowledged queue; the application limited state means that the transmitting end temporarily does not have the initial transmission data which is not transmitted and the data which is retransmitted for the first time, and the retransmission unacknowledged queue is used for storing the data which is retransmitted but not acknowledged by the receiving end; retransmitting a first data packet corresponding to the first data to a receiving end; the position of the first data in the retransmission unacknowledged queue is adjusted. The transmitting end retransmits the lost data when the transmitting end is in the application limited state, the retransmission times of the lost data are increased, the time consumption of the receiving end for waiting to receive the retransmitted data is shortened, meanwhile, the phenomenon of transmission blocking in the communication process is reduced, and the communication quality between the transmitting end and the receiving end is improved.

Description

Data packet transmission methods, devices, equipment and storage media

Technical field

The present application relates to the field of computer network communication technology, and in particular to a data packet transmission method, device, equipment and storage medium.

Background technique

Affected by the quality of network communication between the sender and the receiver, the data packets sent by the sender may be lost. The sender needs to retransmit the lost data packets.

In related technologies, the sending end immediately retransmits the data after detecting data loss. If the sending end detects data loss again, the sending end retransmits the data again. If the sending end receives the message confirmation message, the sending end confirms that the receiving end successfully obtained the retransmitted data. The sender stops retransmitting the data.

However, with this method, the data receiving end needs to wait for a long time to receive the lost data, causing the service at the receiving end to be prone to lags.

Contents of the invention

This application provides a data packet transmission method, device, equipment and storage medium. The technical solutions are as follows:

According to one aspect of the embodiment of the present application, a data packet transmission method is provided, and the method includes:

When the sending end is in an application-limited state, the first data is determined from the retransmission unconfirmed queue; wherein the application-limited state means that the sending end does not have untransmitted initial transmission data and initial retransmission. The retransmission unconfirmed queue is used to store data that has been retransmitted but has not been confirmed by the receiving end;

Retransmitting the first data packet corresponding to the first data to the receiving end;

Adjust the position of the first data in the retransmission unconfirmed queue.

According to one aspect of the embodiment of the present application, a data packet transmission device is provided, and the device includes:

A data packet determination module configured to determine the first data from the retransmission unconfirmed queue when the sending end is in an application-limited state; wherein the application-limited state means that the sending end has no untransmitted packets. The initial transmission data and the first retransmission data, the retransmission unconfirmed queue is used to store data that has been retransmitted but has not been confirmed by the receiving end.

A data packet retransmission module is configured to retransmit the first data packet corresponding to the first data to the receiving end.

A queue maintenance module, configured to adjust the position of the first data in the retransmission unconfirmed queue.

According to an aspect of an embodiment of the present application, a computer device is provided. The computer device includes: a processor and a memory. A computer program is stored in the memory. The computer program is loaded and executed by the processor to implement The method of transmitting data packets as described above.

According to one aspect of the embodiment of the present application, a computer-readable storage medium is provided, and a computer program is stored in the storage medium, and the computer program is loaded and executed by a processor to implement the data packet transmission method as described above. .

According to an aspect of an embodiment of the present application, a computer program product is provided. The computer program product includes a computer program. The computer program is stored in a computer-readable storage medium. A processor reads the computer program from the computer-readable storage medium. The computer instructions are fetched and executed to implement the data packet transmission method as described above.

The beneficial effects brought by the technical solutions provided by the embodiments of this application at least include:

On the one hand, when the sending end is in an application-limited state, it performs a retransmission operation for the lost data, which increases the number of retransmissions of the lost data within a period of time and helps to reduce the time the receiving end waits for reception. Time consumed by lost data.

On the other hand, the sender in the application-limited state does not have the initial transmission data. That is, in the application-limited state, retransmitting the lost data can reduce the occurrence of transmission congestion.

For fields such as live broadcasts that require high network communication quality, this method alleviates audio and video lagging caused by the exhaustion of data in the application layer player cache at the receiving end, and improves the efficiency of lost data. While improving the data retransmission success rate, it also helps improve the smoothness of audio and video playback on the end, and helps improve the user experience of existing audio and video live broadcast services.

Description of drawings

Figure 1 is a schematic diagram of the solution implementation environment provided by an exemplary embodiment of the present application;

Figure 2 is a schematic diagram of an existing packet loss retransmission strategy provided by an exemplary embodiment of the present application;

Figure 3 is a schematic diagram of the data packet blocking principle provided by an exemplary embodiment of the present application;

Figure 4 is a schematic diagram of multipath transmission provided by an exemplary embodiment of the present application;

Figure 5 is a schematic diagram of the data packet retransmission process provided by an exemplary embodiment of the present application;

Figure 6 is a flow chart of a data packet transmission method provided by an exemplary embodiment of the present application;

Figure 7 is a schematic diagram of the retransmission unconfirmed queue update process provided by an exemplary embodiment of the present application;

Figure 8 is a schematic diagram of the retransmission timing of data packets provided by an exemplary embodiment of the present application;

Figure 9 is a schematic diagram of the time interval of level retransmission provided by an exemplary embodiment of the present application;

Figure 10 is a sequence diagram of a data packet transmission method provided by an exemplary embodiment of the present application;

Figure 11 is a schematic diagram of a data packet transmission method provided by an exemplary embodiment of the present application;

Figure 12 is a block diagram of a data packet transmission device provided by an exemplary embodiment of the present application;

Figure 13 is a structural block diagram of a computer device provided by an exemplary embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize data calculation, storage, processing, and sharing. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool and use it on demand, which is flexible and convenient. Cloud computing technology will become an important support. The background services of technical network systems require a large amount of computing and storage resources, such as video websites, picture websites and more portal websites. With the rapid development and application of the Internet industry, in the future each item may have its own identification mark, which needs to be transmitted to the backend system for logical processing. Data at different levels will be processed separately, and all types of industry data need to be powerful. System backing support can only be achieved through cloud computing.

Figure 1 is a schematic diagram of a solution implementation environment provided by an exemplary embodiment of the present application. The implementation environment of this solution can be realized as a data packet transmission system. The implementation environment of this solution may include: a sending end 10 and a receiving end 20 .

The sending end 10 is used to send data during network communication, and the receiving end 20 is used to receive data during network communication. Optionally, the sending end 10 and the receiving end 20 can convert each other during network communication.

The sending end 10 may be a server or a terminal. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, and middleware. Cloud servers for basic cloud computing services such as software services, domain name services, security services, CDN (ContentDelivery Network, content distribution network), and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart watch, etc., but is not limited to this. The terminal and the server can be connected directly or indirectly through wired or wireless communication methods, which is not limited in this application.

The target application is running on the terminal device. The target application is used for multimedia services such as video playback and audio playback.

In one example, the sending end 10 is a cloud server, the receiving end 20 is a terminal, and the data is video data. The cloud server obtains the live content from the content publisher, encodes and decodes the live content, and generates traffic data. The cloud server sends the data packet including the traffic data to the terminal. The application layer player of the terminal processes the data packet and generates the video content displayed in the terminal.

In another example, the sending end 10 is a cloud server, and the receiving end 20 is a terminal. The cloud server obtains video communication content from other devices; among them, other devices and the terminal are making video calls. The video communication content at the sending end is encoded and decoded to obtain the data content. The cloud server sends the data packet including the data content to the terminal. After the application layer player of the terminal processes the data packet, it generates the video content displayed in the terminal.

As shown in Figure 1, the sending end has established a connection with at least one receiving end (user). Affected by the quality of network communication, the data transmitted by the sender may be lost. In this application, retransmission of lost data is achieved through the following steps.

Step 1. The terminal sends a message request message or a message confirmation message to the server.

Step 2: After the server detects the message request message or packet loss, it creates a retransmission unconfirmed queue for the connection. The retransmission unacknowledged queue is used to record lost data packets that have been retransmitted but not acknowledged by the receiving end.

Step 3. The server sends the requested traffic message to the user terminal. When packet loss occurs, the server immediately retransmits the lost data packet to the user terminal and adds the data packet to the end of the retransmission unacknowledged queue.

Step 4. The server monitors whether it is "application restricted" (that is, there is no traffic data to send).

Step 5. If the server is in "Application Restricted", the server obtains the first data packet from the head of the retransmission unconfirmed queue and performs the operation of retransmitting the first data packet again; if the server is not in "Application Restricted" ”, the server continues to perform the traffic transmission and packet loss recovery operations of the existing method.

Step 6. When the connection between the server and the terminal ends, the server releases the retransmission unconfirmed queue. For details on these steps, please refer to the examples below.

With the continuous development of network infrastructure and network protocols, Internet services have become an indispensable part of people's lives. Among the many Internet services, audio and video services have become the core business of current cloud service providers; in audio and video services, lagging on the terminal side (equivalent to the receiving end) has become a measure of cloud service providers (equivalent to the sending end) important standards.

If the cloud server provider has good network transmission performance, there will be fewer lags, mosaics, screen blur, etc. when the terminal plays audio and video. In this case, more and more content service providers (such as video playback platforms, live broadcast platforms, audio playback platforms, etc.) will choose to use cloud services to transmit playback data in order to reduce lags in the terminal, making the cloud Service providers' business scope continues to expand. On the contrary, if the cloud service provider has poor network transmission performance, causing the terminal to frequently experience freezes and blurred screens during video and audio playback, it will cause the content service provider to lose a large number of users, causing the content service provider to lose money. Replace other cloud services to support your own audio and video services. Therefore, reducing network freezes on terminals has become an urgent problem that cloud service providers need to solve.

Taking audio and video services as an example, packet loss is the main factor causing lagging on the terminal side. If a large number of packets are lost during the network transmission of audio and video business traffic, the terminal side needs to wait for the cloud server side to retransmit the lost packets. Until the retransmitted lost packets are received, the terminal can transmit the data packet and its subsequent data. The package is sent to the application layer player. In delay-sensitive audio and video services, network packet loss rate has become a key factor in the impression of service experience.

Figure 2 is a schematic diagram of an existing packet loss retransmission strategy provided by an exemplary embodiment of the present application.

The cloud server receives audio and video traffic requests from the terminal and sends audio and video data packets to the terminal according to the audio and video traffic requests. The end user periodically sends message confirmation packets to the cloud server, and the message confirmation packets carry packet loss information. The cloud server receives the message confirmation data packet and immediately retransmits the lost audio and video data packet according to the received message confirmation data packet until it receives the message confirmation data packet from the terminal. The message confirmation data packet is used to indicate that the terminal has received the lost audio and video data. Bag.

However, for network communication between the terminal and the cloud server, if a reliable transmission method (such as a network transmission protocol based on TCP (Transmission Control Protocol) or QUIC (Quick UDP Internet Connection), etc.) is used, if If a certain data packet (or data) is lost, the terminal cannot send subsequent data packets to the application layer player. In other words, packet loss will cause the terminal side to block subsequent data packets, which can easily cause the application layer player to freeze.

Figure 3 is a schematic diagram of the data packet blocking principle provided by an exemplary embodiment of the present application.

The cloud server sends audio and video data packets (Pkt.1, Pkt.2, Pkt.3) to the terminal. Pkt.1 is lost during network transmission, and the terminal successfully receives Pkt.2 and Pkt.3. Pkt.1 is missing. Even if the terminal receives Pkt.2 and Pkt.3, it cannot send Pkt.2 and Pkt.3 to the application layer player. In this case, the terminal notifies the cloud server to retransmit Pkt.1. After the user terminal receives Pkt.1, the terminal sends data packet 1, data packet 2, and data packet 3 to the application layer.

In this example, while the terminal is waiting to receive Pkt.1 retransmitted by the cloud server, if there is no data to be played in the cache of the application layer player, the audio and video playback process will be stuck; if the application layer player If there is data to be played in the cache, audio and video playback will not cause lag.

It can be seen from the above that how to retransmit lost data packets quickly and timely is an important idea to alleviate terminal freezes and improve the smoothness of audio and video playback.

In the above content, the cloud server is equivalent to the sending end in the claims, the terminal is equivalent to the receiving end in the claims, and the audio and video data packet is equivalent to the data packet in the claims.

In response to the packet loss retransmission problem mentioned above, solutions in related technologies are divided into the following two categories: One is to obtain real-time network conditions and status through heuristic or machine learning methods, so as to retransmit data packets. The cloud server uses an appropriate sending window and sending rate to retransmit the lost data packets, hoping that the retransmitted data packets will reach the terminal as soon as possible; another method uses a new network transmission method to return the lost audio and video traffic data packets, such as using Multipath transmission, redundant coding, and repeated retransmission methods are used to return lost data packets.

Figure 4 is a schematic diagram of multipath transmission provided by an exemplary embodiment of the present application.

After receiving the message confirmation data packet from the terminal, the cloud server repeatedly sends back the lost data packet to the terminal through multi-path network communication.

The above-mentioned optimization method for packet loss retransmission has the following problems: First, it is difficult for existing heuristic or machine learning methods to accurately obtain the current network status or conditions, making it difficult to guarantee that lost data packets will reach the terminal during the retransmission process. ,In particular, if the obtained network status or ,conditions are not accurate enough, the retransmitted data ,packet may be lost again during the retransmission process.

Figure 5 is a schematic diagram of a data packet retransmission process provided by an exemplary embodiment of the present application.

When the cloud server retransmits the lost data packet (retransmission data packet 1) for the first time, the data packet is lost at routing node R1; at this time, the message confirmation message sent by the terminal will carry the message that retransmission data packet 1 has not been received. information. After receiving the message confirmation message, the cloud server will retransmit the data packet (retransmit data packet 1) to the terminal again; in this case, the terminal is likely to be stuck waiting for retransmission of data packet 1. Increase.

It can be seen that although the methods based on multi-path transmission, redundant coding, and repeated retransmission in related technologies can avoid terminal freezes caused by retransmission data packets being lost again, indiscriminate repeated retransmission faces the following problems: (1) If the terminal does not support multi-path transmission and redundant coding, the server cannot improve the success rate of retransmission through this method; (2) Indiscriminate repeated retransmission of lost data packets will block subsequent audio and video traffic data to be sent. package, causing the actual download rate of the business to decrease, and also causing lag on the user side.

This application mainly aims at the problem of user terminal freezing caused by packet loss and retransmission, and proposes a packet loss retransmission optimization method for delay-sensitive audio and video services. It helps to reduce the waiting time of the receiving end for packet loss, and helps to alleviate the jamming of audio and video live broadcast services during the playback process.

Figure 6 is a flow chart of a data packet transmission method provided by an exemplary embodiment of the present application. For example, the execution subject of this method may be the sending end 10 in the implementation environment of the solution described in Figure 1. As shown in Figure 6, the method may include the following steps (610-630):

Step 610: When the sending end is in an application-limited state, determine the first data from the retransmission unconfirmed queue; where the application-limited state means that the sending end does not have untransmitted initial transmission data and initial retransmission data. Data, retransmission unconfirmed queue is used to store data that has been retransmitted but has not been acknowledged by the receiving end.

In some embodiments, a communication connection is established between the sending end and the receiving end. The sending end is used to send data to the receiving end, and the receiving end feeds back a message confirmation message to the sending end according to the reception status of the data. In the video playback business, the sender is a cloud server and the receiver is a terminal running a video playback application. In the cloud storage business, the sending end is the terminal that uploads data, and the receiving end is the cloud server.

It should be noted that the types of the sending end and the receiving end are determined according to actual needs, and are not limited here in this application.

In some embodiments, the application-limited state refers to a state in which the sending end does not need to send initial transmission data, nor does it need to perform initial retransmission of lost data. The sender in the application-limited state repeatedly retransmits the lost data.

Optionally, the sending end also has an application unrestricted state, and the sending end in the application unrestricted state has at least one initially transmitted data to be sent, or data that needs to be initially retransmitted.

Optionally, data refers to data requested by the receiving end. The data includes traffic data generated by the sender's codec. For example, data packets are not audio packets. For another example, the data packet is a video data packet. The sending end obtains the audio and video content from the video playback platform, encodes and decodes the audio and video content, and generates data.

In some embodiments, the initial data refers to data transmitted for the first time by the sending end. For example, the data generated by video encoding and decoding at the sending end is initial data. The data retransmitted for the first time refers to the data that was lost and retransmitted for the first time.

In some embodiments, the retransmission unacknowledged queue is used to store data that has been retransmitted but has not been acknowledged by the receiving end.

In some embodiments, the sending end has established connections with multiple receiving ends, and the sending end includes at least one retransmission confirmation queue corresponding to at least one receiving end.

Optionally, in a stream-based transmission protocol (such as QUIC), there are multiple data streams between the sender and a certain receiver. The sending end creates and maintains a corresponding retransmission unacknowledged queue for at least one data flow.

Optionally, if the sending end determines that a certain initially transmitted data has not been successfully received by the receiving end, the sending end immediately retransmits the data for the first time and adds the data to the retransmission unconfirmed queue (this process is performed by the application non-receiver). completed by the sender in a limited state).

For example, the sending end sends a data packet to the receiving end based on the message request information sent by the receiving end, where a is a positive integer. The receiving end receives a data packet and sends a message confirmation message to the sending end. According to the message confirmation message, the sender determines that packet 1 has been lost (that is, data 1 in packet 1 has been lost), then the sender immediately retransmits data 1 and adds data 1 to the retransmission unacknowledged list. queue.

In some embodiments, the size of the retransmission unacknowledged queue is dynamically changed. That is, the size of the retransmission unacknowledged queue is determined based on the amount of data that has been retransmitted but has not been acknowledged by the receiving end. Optionally, the retransmission unacknowledged queue is implemented through a linked list.

Optionally, in the case where the retransmission unconfirmed queue includes multiple data that have been retransmitted but have not been acknowledged by the receiving end, multiple data that have been retransmitted but have not been acknowledged by the receiving end are in the retransmission unacknowledged queue. The position in the queue is arranged according to the last retransmission time of each data.

For example, the last retransmission time of data 2 is 12:00:01, the last retransmission time of data 3 is 12:00:15, and the last retransmission time of data 4 is 11:59:01. In the unconfirmed transmission queue, the order of data 2, data 3 and data 4 is: data 4, data 2, data 3; among them, data 4 is closer to the head of the retransmission unconfirmed queue.

In some embodiments, when there is an unconfirmed retransmission queue corresponding to a certain receiving end in the sending end, the sending end maintains the unconfirmed retransmission queue. For details about this process, please refer to the embodiments below.

Optionally, after establishing a connection with the receiving end, the sending end monitors whether it is currently in an application restricted state. If it is detected that the sending end is currently in an application restricted state, the sending end determines the first data from the retransmission unconfirmed queue. If it is detected that the sending end is currently in an application unrestricted state, the sending end does not perform the step of retransmitting the first data in the unconfirmed queue.

Step 620: Retransmit the first data packet corresponding to the first data to the receiving end.

When the sending end is in the application-restricted state, there is no data packet that needs to be initially transmitted (the sending end's sending queue is empty). Therefore, the sending end can select any available transmission resource to retransmit the first data packet.

In some embodiments, the sending end determines the data packet header according to the communication protocol used to establish the connection with the receiving end, and generates the first data packet based on the data packet header and the first data. The sending end uses available transmission resources to transmit the first data packet to the receiving end.

Optionally, the action performed by the sending end in the application-limited state on the lost data is called repeated retransmission.

In some embodiments, the transmission parameters used to transmit the first data are different from those used to initially transmit the data or the first retransmission of the data. Optionally, the sending end retransmits the first data using a sending window different from that used to send the initially transmitted data or the first retransmitted data. Optionally, the transmission rate of the first data is less than or equal to the transmission rate of the initial transmission number. This method can avoid data transmission congestion caused by repeated retransmissions and improve the reliability of the communication process.

Step 630: Adjust the position of the first data in the retransmission unconfirmed queue.

After the sending end retransmits the first data, it adjusts the position of the first data in the retransmission confirmation queue. Optionally, the sending end moves the first data to the end of the retransmission unacknowledged queue.

To sum up, on the one hand, when the sender is in an application-limited state, it performs a retransmission operation for the lost data, which increases the number of retransmissions of the lost data within a period of time, which helps to reduce The time the receiver waits to receive lost packets.

On the other hand, the sender in the application-limited state does not have the initial transmission data. That is, in the application-limited state, retransmitting the lost data will not affect the initial data transmission process, which is helpful to Reduce the occurrence of packet transmission blocking.

For fields such as live broadcasts that require high network communication quality, this method can help shorten the time for the receiver to receive lost data, and help alleviate the problem of exhaustion of data in the application layer player cache at the receiver. It not only improves the success rate of packet loss data retransmission, but also helps maintain the smoothness of audio and video playback at the receiving end and improves the user experience of existing audio and video live broadcast services.

In some embodiments, the retransmission unconfirmed queue is arranged in sequence from the beginning to the end of the queue in order of the last retransmission time; the sending end determines the first data from the retransmission unconfirmed queue, including : The sending end determines the data at the head of the retransmission unconfirmed queue as the first data; the sending end adjusts the position of the first data in the retransmission unconfirmed queue, including: the sending end moves the first data to the retransmission unconfirmed queue End of queue unacknowledged.

For example, the retransmission unconfirmed queue includes: data 1, data 3, data 4 and data 5 in order from the beginning of the queue to the end of the queue. That is, the last retransmission time of data 1 is earlier than other data packets in the retransmission confirmation queue. When the sending end is in an application-limited state, the sending end determines data 1 as the first data from the retransmission unconfirmed queue, and retransmits data 1. Subsequently, the sending end moves data 1 to the end of the retransmission unacknowledged queue. The retransmission unconfirmed queue includes data 3, data 4, data 5 and data 1 in order from the beginning of the queue to the end of the queue.

Figure 7 is a schematic diagram of the retransmission unconfirmed queue update process provided by an exemplary embodiment of the present application.

The sending end creates and maintains a retransmission unconfirmed (Queue_unack_loss) queue. The retransmission unconfirmed queue records 4 data that have been retransmitted but have not been confirmed by the receiving end (i.e. Loss0, Loss1, Loss2, Loss3 ). They are respectively at positions 0, 1, 2 and 3 in the retransmission unacknowledged queue. When in the application-limited state, the sending end repeatedly retransmits the lost data. The sending end extracts Loss0 from the head of the retransmission unacknowledged queue and generates the first data packet based on Loss. The sending end sends the first data packet to the receiving end to retransmit the Loss. Subsequently, the sending end moves Loss0 from position 0 to position 4 of the Queue_unack_loss queue.

Through this method, any data packet in the retransmission unconfirmed queue that has been retransmitted but has not been confirmed by the receiving end has the opportunity to be retransmitted in an application-limited state. At the same time, by arranging the earliest data packet at the last retransmission time at the head of the retransmission unconfirmed queue, the data packet at the head of the queue is prioritized and repeatedly transmitted, which helps to shorten the retransmission time of each data packet and shortens the time for successful reception at the receiving end. This reduces the time it takes to retransmit data packets, helping to reduce lagging in audio and video played at the terminal application layer.

In some embodiments, the data packet transmission method further includes: when the sending end detects that the second data is lost and the second data does not exist in the retransmission unconfirmed queue, sending the second data corresponding to the second data. package, and adds the second data to the end of the retransmission unconfirmed queue; or, when the sending end detects that the second data is lost and there is second data in the retransmission unconfirmed queue, the sending end sends the second data packet corresponding to the second data packet, and moves the second data to the end of the retransmission unconfirmed queue; or, when the sender receives the second data in the retransmit unconfirmed queue and is confirmed by the receiving end, The second data is deleted from the retransmission unacknowledged queue.

The second data refers to any data sent by the sending end to the receiving end. For example, the second data is the first data. For another example, the second data is any data except the first data. In some embodiments, after sending the second data to the receiving end, the sending end determines whether packet loss occurs in the second data according to the message confirmation message sent by the receiving end. For example, the receiving end carries the data identifier corresponding to the lost data in the message confirmation message, and the sending end determines whether the second data packet is lost based on the data identifier.

Optionally, if the message confirmation message includes a data flag of the second data, and the received message corresponding to the data flag corresponding to the second data is a negative reception, the sending end detects that the second data is lost.

In some embodiments, after the sending end detects that the second data is lost, the sending end detects the retransmitted but unconfirmed data in the retransmission unconfirmed queue to find out whether the second data is stored in the retransmission queue. Unconfirmed list. If the retransmission unconfirmed queue includes the second data, the position of the second data in the retransmission queue needs to be adjusted; if the retransmission unconfirmed queue does not include the second data, the second data needs to be added to the retransmission queue. location in.

In some embodiments, when the sending end detects that the second data is lost, the sending end generates a data packet header according to the communication protocol used to connect with the receiving end; the sending end generates a data packet header according to the header of the data packet and the second data, Generate a second data packet. The sending end sends the second data packet to the receiving end.

It can be seen from the above that the second data packet is used to immediately retransmit the lost second data, and the first data packet is used to repeatedly retransmit the first data.

In some embodiments, the second data packet belongs to the initial transmission data packet. In other words, the second data packet is not included in the retransmission unacknowledged queue. In this case, if the sending end detects that the second data packet is lost, the sending end immediately retransmits the second data for the first time and adds the second data to the end of the retransmission unacknowledged queue.

In some embodiments, the second packet data retransmits the packet. That is to say, the retransmission unacknowledged queue includes the second data packet. In this case, if the sending end detects that the second data packet is lost, the sending end immediately retransmits the second data for the first time and moves the second data to the end of the retransmission unacknowledged queue.

Optionally, the sending end deletes the second data in the retransmission unconfirmed queue by performing a MOVE operation on the second data in the retransmission unconfirmed queue, and adds the second data to the end of the retransmit unconfirmed queue. , to move the second data to the end of the retransmission unconfirmed queue.

In some embodiments, when the sending end detects that the second data packet is lost, the sending end generates strong correlation data and transmits the strong correlation data. The sending end deletes the second data from the retransmission unconfirmed queue and sends the strongly correlated data. Relevant data is added to the end of the retransmission unacknowledged queue.

Optionally, the strongly correlated data is used to perform packet loss recovery on the second data. Although the content of the strong correlation data is different from the content of the second data packet, the receiving end can obtain the content of the second data packet based on the strong correlation data. That is, by transmitting strongly correlated data, packet loss recovery can be performed on the second data. For example, the data content of the strongly correlated data packet includes the data content in the second data packet and other data content.

Assume that the second data is data 1, data 3 is any undetermined data for retransmission, and the strongly related data of the second data is data 5. After the sending end detects that data 1 is lost, it generates data 5, where data 5 includes data 1 and data 3. The sending end sends data 5 to the receiving end, and deletes data 1 and data 3 from the retransmission unconfirmed queue.

In some embodiments, there is no strong correlation between any two data in the retransmission unacknowledged queue. It can be seen from the above embodiment that if data 5 is added to the retransmission unconfirmed queue and data 1 in the retransmission unconfirmed queue is not deleted, data 1 may easily be retransmitted multiple times within a period of time. For example, the sender retransmits data 1 within a short period of time after transmitting data 5. Since the receiving end may successfully receive data 5, there is no need to retransmit data 1 again.

By maintaining that there is no strong correlation between data in the retransmission unconfirmed queue, it helps to avoid unnecessary retransmission of lost data by the sender, saves transmission resources during the retransmission process, and also helps shorten the time The time taken to retransmit packets in the unacknowledged queue.

In some embodiments, when the sending end acknowledges receipt of the second data in the retransmission unconfirmed queue and the receiving end acknowledges receipt, the second data is deleted in the retransmit unconfirmed queue.

Optionally, the sending end determines that the second data is confirmed to be received by the receiving end based on the confirmation message sent by the receiving end. For example, if the confirmation message includes the identifier and ACK of the second data packet, it means that the receiving end confirms receipt of the second data packet. The sending end deletes the second data packet from the retransmission unacknowledged queue.

For example, the data included in the retransmission unconfirmed queue from the beginning to the end of the queue are [data 3, data 2, data 1, data 4]; the sending end in the application unrestricted state determines the data according to the message confirmation message 1 Data 1 and 5 are lost. The sending end in the application unrestricted state generates a second data packet A corresponding to data 1, sends the second data packet A, and retransmits data 1. The sending end determines that the retransmission unconfirmed queue includes data 1, and the sending end moves data 1 to the end of the retransmission unconfirmed queue. At this time, the data included in the retransmission unconfirmed queue from the beginning to the end of the queue are [data 3, data 2, data 4, data 1] respectively. The sending end in the application unrestricted state generates a second data packet B corresponding to data 5 and sends the second data packet B; the sending end determines that the retransmission unconfirmed queue does not include data 5, and the sending end adds data 5 to the retransmission The data included in the tail of the unconfirmed queue and the retransmission unconfirmed queue from the head to the end of the queue are [data 3, data 2, data 4, data 1, data 5] respectively. The sending end receives the message confirmation message 2 sent by the receiving end, and determines that the receiving end has received data 4, then the sending end deletes data 4 from the retransmission unconfirmed queue. The data included in the retransmission unconfirmed queue from the beginning to the end of the queue are [data 3, data 2, data 1, data 5] respectively.

The sender adds data, adjusts the position of the data, and deletes data in the retransmission unconfirmed queue according to the situation of data loss and the data reception situation of the receiving end, ensuring that only the retransmitted unconfirmed lost queues include those that have been retransmitted and have not yet been retransmitted. Data received is acknowledged. By moving the retransmitted data to the end of the retransmission unconfirmed queue, it ensures that the earliest data at the last sent time is arranged at the head of the retransmitted unconfirmed queue, which helps reduce the need for the earliest data at the last sent time. The time to retransmit.

In some embodiments, when the sending end is in an application-limited state, determining the first data from the retransmission unconfirmed queue includes: when the sending end is in an application-limited state and the first condition is met, sending The end determines the first data from the retransmission unconfirmed queue; wherein the first condition includes at least one of the following: the end-to-end transmission delay between the sending end and the receiving end is greater than or equal to the first threshold; The packet loss rate during the period is greater than or equal to the second threshold.

In some embodiments, the end-to-end transmission delay is used to characterize the transmission delay between the sending end and the receiving end. The packet loss rate is used to represent the proportion of lost data packets among the sent data packets.

In some embodiments, the first threshold and the second threshold may be preset by the protocol or set by the administrator.

In some embodiments, the first condition is used to characterize the network communication quality of the connection established by the sending end and the receiving end. If the end-to-end transmission delay is larger, the network communication quality between the sender and the receiver will be worse, and the data being transmitted is prone to loss; if the end-to-end transmission delay is smaller, the sender and receiver will be The better the quality of network communication between them, the higher the success rate of the receiving end in receiving data.

If the packet loss rate is larger, the data being transmitted is more likely to be lost; if the packet loss rate is smaller, the data being transmitted is less likely to be lost.

In some embodiments, when the sending end is in an application-limited state and the end-to-end transmission delay between the sending end and the receiving end is greater than or equal to the first threshold, the sending end determines the first time from the retransmission unconfirmed queue. data.

For example, the retransmission unconfirmed queue includes at least one piece of data that has been retransmitted but has not been confirmed to be received. When in the application-limited state, the sender detects the end-to-end transmission delay and compares the end-to-end transmission delay with The first threshold is compared. If the end-to-end transmission delay is greater than or equal to the first threshold, it indicates that the network transmission quality is poor. The sending end in the application-limited state determines the first data from the retransmission unconfirmed queue and generates the first data including the first data. A data packet; the sending end in the application-limited state implements repeated retransmission of the first data by sending the first data packet. If the end-to-end transmission delay is less than the first threshold, the sending end does not perform the step of selecting the first data from the retransmission unconfirmed queue.

In some embodiments, when the sending end is in an application-limited state and the packet loss rate between the sending end and the receiving end is greater than or equal to the second threshold, the sending end determines the first data packet from the retransmission unacknowledged queue.

For example, the retransmission unconfirmed queue includes at least one piece of data that has been retransmitted but has not been confirmed to be received. When in the application restricted state, the sending end detects the packet loss rate and compares the packet loss rate with the second threshold. If the packet loss rate is greater than or equal to the second threshold, it indicates that the network transmission quality is poor. The sending end in the application-limited state determines the first data from the retransmission unconfirmed queue and generates the first data packet including the first data. ; The sending end in the application-limited state implements repeated retransmission of the first data by sending the first data packet. If the packet loss rate is less than the second threshold, the sending end does not perform the step of selecting the first data from the retransmission unconfirmed queue.

In some embodiments, when the sending end is in an application-limited state, the end-to-end transmission delay between the sending end and the receiving end is greater than or equal to the first threshold, and the packet loss rate between the sending end and the receiving end is greater than or equal to In the case of the second threshold, the sending end determines the first data packet from the retransmission unacknowledged queue.

For example, the retransmission unconfirmed queue includes at least one piece of data that has been retransmitted but has not been confirmed to be received. When it is in an application-limited state, the sender detects the end-to-end transmission delay and packet loss rate, and transmits it end-to-end. The delay is compared with the first threshold, and the packet loss rate is compared with the second threshold. If the end-to-end transmission delay is greater than or equal to the first threshold and the packet loss rate is greater than or equal to the second threshold, it indicates that the network transmission quality is poor. The sender in the application-limited state determines the first transmission rate from the retransmission unconfirmed queue. data, and generates a first data packet including the first data; the sending end in the application-limited state implements repeated retransmission of the first data by sending the first data packet.

If the end-to-end transmission delay is less than the first threshold and the packet loss rate is greater than or equal to the second threshold, the sending end in the application-limited state does not perform the step of selecting the first data from the retransmission unconfirmed queue.

If the end-to-end transmission delay is greater than or equal to the first threshold and the packet loss rate is less than the second threshold, the sending end in the application-limited state does not perform the step of selecting the first data from the retransmission unconfirmed queue.

If the end-to-end transmission delay is greater than or equal to the first threshold and the packet loss rate is greater than or equal to the second threshold, the sending end does not perform the step of selecting the first data from the retransmission unconfirmed queue. Optionally, the sending end detects the end-to-end transmission delay and packet loss rate in real time, and determines whether the retransmission unconfirmed queue is in the application-restricted state based on the end-to-end transmission delay and packet loss rate detected in real time. Identify the first packet.

In some embodiments, the sending end is in an application-limited state and detects the end-to-end transmission delay and packet loss rate at least n times, where n is a positive integer.

For example, n equals 1, that is, when the sending end is in an application-limited state, the sending end only performs a real-time detection of the end-to-end transmission delay or packet loss rate. In this case, after detecting that the sending end is currently in an application-limited state, it immediately detects the end-to-end transmission delay or packet loss rate, and determines whether the end-to-end transmission delay or packet loss rate meets the first requirement. Condition to determine whether to select at least one data packet from the retransmission unconfirmed queue for retransmission in this application restricted state.

It should be noted that the value of n is set according to actual needs, and is not set here in this application.

Optionally, the sending end can send up to N pieces of data that have been retransmitted but have not been acknowledged in the application-restricted state. For example, if the sending end sends the first data packet corresponding to the first data to the receiving end and detects that the application is still in a restricted state (the sending end still does not have the initial transmission data), the sending end determines again whether the first condition is met. If the first condition is met, the sending device performs the step of selecting the first data from the retransmission unconfirmed queue again. If the condition is not met, the sending device temporarily does not perform the step of selecting the first data from the retransmission unconfirmed queue.

Optionally, the sending end in the application-limited state sends k pieces of data that have been retransmitted but have not been confirmed to be received, and detect whether the first condition is met, where k is a positive integer less than or equal to N; if the first condition is not currently met, If the condition is met, the sending end in the application restricted state will again perform the step of selecting the first data from the retransmission unconfirmed queue; if the first condition is not currently met, the sending end will suspend the execution of the retransmission unconfirmed queue in this application restricted state. Confirm the step of selecting the first data in the queue.

In some embodiments, the sending end periodically detects the end-to-end transmission delay or packet loss rate. For example, the sending end detects the end-to-end transmission delay or packet loss rate every t seconds. The value of t is set according to actual needs and is not limited in this application.

If the sender measures the end-to-end transmission delay or packet loss rate multiple times during application restriction, then the sender will retransmit if the end-to-end transmission delay or packet loss rate meets the first condition. The first data is selected and retransmitted in the unconfirmed queue. If the end-to-end transmission delay or the packet loss rate does not meet the first condition, the sending end suspends retransmission of the first data.

For example, if the sending end detects in the i-th detection that the end-to-end transmission delay is greater than or equal to the first threshold T, or the packet loss rate is greater than or equal to the second threshold R, that is, the second condition is met, then the sending The end selects the first data from the retransmission pending confirmation queue to generate a first data packet equal to the first data, and sends the first data packet.

If the sending end detects that the end-to-end transmission delay is less than or equal to the first threshold T in the i+1th detection, or the packet loss rate is small or equal to the second threshold R, that is, the first condition is not met, then The pause in the application-limited state selects the first data from the retransmission pending confirmation queue and repeatedly retransmits the first data.

Through this method, based on the communication quality between the sender and the receiver, it is determined whether the sender in the application-limited state repeatedly retransmits the lost data, which helps to avoid unnecessary unnecessary transmission of the sender in the application-limited state. Data retransmission helps save transmission resources and reduce the power consumption of the sending end.

Optionally, before the sending end in the application-limited state detects the end-to-end transmission delay or packet loss rate, the sending end detects whether there is at least one retransmitted but not confirmed by the receiving end in the retransmission unconfirmed queue. received data.

If there is no data in the retransmission unconfirmed queue that has been retransmitted but has not been confirmed by the receiving end, the sending end does not perform the step of checking whether the first condition is met. If there is at least one piece of data in the retransmission unconfirmed queue that has been retransmitted but has not been confirmed by the receiving end, the sending end performs the step of checking whether the first condition is met.

For example, the retransmission unacknowledged queue includes one piece of data that has been retransmitted but has not been acknowledged by the receiving end, and the first threshold is T. The sender in the application-limited state determines the end-to-end transmission delay detection result 1; if the end-to-end transmission delay detection result 1 is greater than T, the sender in the application-limited state retransmits the unconfirmed list from The head of the queue selects the first data, sends the first data packet corresponding to the first data to the receiving end, and moves the first data to the end of the retransmission unacknowledged queue.

At this time, the sending end is still in an application-limited state, and the retransmission unconfirmed queue contains data that has been retransmitted but has not been acknowledged by the receiving end. The sending end detects the end-to-end transmission delay and obtains the detection result 2 of the end-to-end transmission delay. If the detection result 2 of the end-to-end transmission delay is less than T, the sending end in the application-limited state does not perform retransmission. The process of identifying the first packet in the acknowledgment queue.

After a detection interval has elapsed, the sender is still in an application-restricted state. The sending end detects the end-to-end transmission delay on the sending end and obtains the end-to-end transmission delay detection result 3. If the end-to-end transmission delay detection result 3 is greater than T, the sending end is in an application-limited state. Select the first data from the head of the retransmission unconfirmed queue, send the first data packet corresponding to the first data to the receiving end, and move the first data to the tail of the retransmission unconfirmed queue. The sender in the application-limited state obtains the message confirmation message from the receiver. The message confirmation message is used to indicate that the receiver has received the first data. The sender in the application-limited state deletes the first data from the retransmission unconfirmed queue. .

Before the next detection of the end-to-end transmission delay, the sender in the application-limited state determines that there is no data in the retransmission unconfirmed queue that has been retransmitted but has not been confirmed by the receiving end. The sender in the application-limited state Pause to detect the end-to-end transmission delay. Optionally, in this case, the sender in the application-limited state checks whether the retransmission unconfirmed queue has added a new retransmission but has not been received. Confirm received data. If data that has been retransmitted but has not been confirmed by the receiving end is added, the sending end in the application-limited state will again detect the end-to-end transmission delay in real time.

There is no data in the retransmission unconfirmed queue that has been retransmitted but has not been confirmed by the receiving end, indicating that the sending end in the application-limited state does not need to retransmit any data. In this case, pausing to check whether the first condition is met helps reduce the computational overhead of the sender.

In some embodiments, when the sending end is in an application-limited state, determining the first data from the retransmission unconfirmed queue includes: when the sending end is in an application-limited state and the second condition is met, sending The end determines the first data from the retransmission unconfirmed queue; where the second condition includes: the number of repeated retransmissions of packet loss is greater than or equal to the third threshold; where the number of repeated retransmissions of packet loss refers to the number of repeated retransmissions of packet loss between the sending end and the receiving end. The maximum number of times a data packet is retransmitted while maintaining a connection.

In some embodiments, the number of repeated retransmissions of lost packets refers to the maximum number of retransmissions of a data packet while the sender and receiver maintain a connection. For example, if the number of repeated retransmissions of lost packets is equal to 6, it means that the data packet corresponding to a certain data can be transmitted up to 6 times while the sender and receiver maintain the connection.

In some embodiments, the third threshold is equal to 1. That is to say, when the number of repeated retransmissions of lost packets is equal to 1, after a data packet is lost, the sending end will immediately retransmit the data, and the sending end will not retransmit the data again in the application-limited state. The data is retransmitted.

If the number of repeated retransmissions for lost packets is greater than 1, after the sender immediately retransmits a lost data packet, it can also retransmit the data packet repeatedly in the application-restricted state.

In some embodiments, a retransmission counter is provided in the sending end to record the number of retransmissions of each data that has been retransmitted but has not been confirmed to be received. Optionally, the number of retransmissions of the first data packet is less than or equal to the number of repeated retransmissions of lost packets.

In some embodiments, the number of repeated retransmissions of lost packets may be determined based on historical service quality. For details about this process, please refer to the embodiment below.

During the period after the sender and receiver have just established a connection, the sender and receiver have not yet established a strong connection, and the sender cannot measure the end-to-end transmission delay or packet loss rate in a timely manner. In this case, the sending end in the application-limited state determines whether it is necessary to select and repeatedly retransmit the lost data based on the second condition, which provides more reference information for the repeated retransmission process of data.

In some embodiments, the data packet transmission method also includes: the sending end obtains historical service quality; wherein the historical service quality is used to characterize the data packet transmission status of the historical session established with the receiving end; the sending end calculates based on the historical service quality The number of repeated retransmissions for lost packets.

In some embodiments, the sending end obtains historical service quality through the receiving end. Optionally, the sending end and receiving end establish a historical connection. Before the connection ends, the sender sends the quality of service (QoS) measured during the session to the receiver. This quality of service is the historical quality of service (QoS_his) that can be referenced after the next time the sender and the receiver establish a connection. The receiving end stores the quality of service.

When the sending end and the receiving end establish a connection again, the receiving end sends the stored historical service quality to the sending end, and the receiving end determines the number of repeated retransmissions of lost packets based on the historical service quality.

This method helps reduce the data storage pressure on the sending end. Since the sender device establishes connections with multiple receivers within a period of time, the historical service quality is stored in each receiver, reducing the amount of data that the sender needs to store and maintain.

In some embodiments, the sending end stores historical service quality corresponding to historical connections with the receiving end. The sending end obtains historical service quality from the storage space.

In some embodiments, after obtaining the historical service quality, the sending end needs to determine whether the historical service quality information is available. Optionally, the historical service quality includes the start time of the historical session and the end time of the historical session. The sender determines the time interval between the historical session and the current moment based on the end time.

If the time interval between the historical session and the current moment is less than or equal to the time interval threshold, it means that the historical service quality is available, and the sender uses the historical service quality to calculate the number of repeated retransmissions of lost packets.

If the time interval between the historical session and the current moment is greater than or equal to the time interval threshold, it means that the historical service quality is not available, and the sender does not use the historical service quality to calculate the number of repeated retransmissions of lost packets; optionally, here In this case, the sending end in the application-limited state directly determines the first data packet from the retransmission to confirmation queue, and retransmits the first data packet.

In an example, the process by which the sending end determines whether historical service quality information is available is as follows:

1) The server obtains the current time Time_cur and calculates the time interval Time_gap between the current time and the session end time. The calculation process of time interval is as follows:

Time_gap=Time_cur-Time_last_end

Among them, Time_last_end represents the end time of the historical session. The sending end can determine the end time of the historical session from the historical service quality.

2) If Time_gap is greater than the time threshold Time_threshold, that is, Time_gap>Time_threshold, it means that the historical quality of service QoS_his is not available and the sending end does not use QoS_his information. Optionally, the sending end sets the packet loss retransmission policy to: if packet loss is detected, the lost message will be retransmitted immediately.

3) If Time_gap is less than or equal to the time interval threshold Time_threshold, that is, Time_gap ≤ Time_threshold, it means that the historical quality of service is available, and the server uses QoS_his information to determine the number of repeated transmissions of lost packets in this connection.

The time interval thresholds corresponding to different receiving ends can be the same or different. Staff can set personalized time interval thresholds for the receiving end according to the service types in different receiving ends. It should be noted that the specific value of the time interval threshold is set according to actual needs and is not limited here in this application.

Since communication quality changes dynamically, there is a certain similarity between network conditions within a period of time. By determining whether the time interval between the historical session corresponding to the historical service quality and the current moment exceeds the time threshold, we can filter out the information with reference significance. Historical service quality helps to improve the rationality of the number of repeated retransmissions of lost packets determined based on historical service quality.

In some embodiments, the historical service quality includes at least one of the following: the packet loss retransmission success rate of the historical session. The packet loss retransmission success rate is used to represent the probability that the receiving end successfully receives the retransmitted data packet; the maximum loss of the historical session. The number of packet retransmissions. The maximum number of packet loss retransmissions is used to represent the maximum number of transmissions of data packets in an application-restricted state; the number of occurrences of the maximum number of packet loss retransmissions in historical sessions; the repetition of packet loss in historical sessions. Number of transfers.

In some embodiments, the packet loss retransmission success rate and the maximum number of packet loss retransmissions are calculated based on the number of equal-cost retransmissions in historical sessions; where the equal-cost retransmission is used to indicate that the sending end is within the duration threshold. Retransmission of data packets.

The action of the sender retransmitting certain data within the duration threshold is called equal-cost retransmission. For example, if data 1 is lost during transmission and the sender retransmits three data 1s within the duration threshold, then the retransmission of these three data 1s is called an equal-cost retransmission.

Optionally, the packet loss retransmission success rate of a certain data packet is equal to the reciprocal of the level retransmission for the data packet. For example, if the sender performs four level retransmissions on a certain data packet, the packet loss retransmission success rate of the data packet is 25%.

In some embodiments, the packet loss retransmission success rate during the connection establishment process between the sending end and the receiving end is equal to the average of the packet loss retransmission success rate of each data packet.

Optionally, the packet loss retransmission success rate is inversely proportional to the network communication quality. The greater the packet loss retransmission success rate, the worse the network communication quality; the smaller the packet loss retransmission success rate, the better the network communication quality.

In some embodiments, the maximum number of packet loss retransmissions refers to the maximum number of retransmissions of a certain data packet by the sending end in an application-limited state.

The number of occurrences of the maximum number of packet loss retransmissions in the historical session is used to represent the number of occurrences of the maximum number of packet loss retransmissions in the historical session.

The number of repeated transmissions of lost packets in historical sessions is used to represent the maximum number of retransmissions of a certain data packet in historical sessions.

In some embodiments, calculating the number of repeated retransmissions of lost packets based on historical service quality includes: if the historical service quality meets the third condition, determining the sum of the number of repeated retransmissions of lost packets in the historical session and the first value. is the number of repeated transmissions of lost packets; where the third condition includes at least one of the following: the success rate of packet loss retransmissions in historical sessions is less than or equal to the fourth threshold; the maximum number of packet loss retransmissions in historical sessions is greater than or equal to the fifth threshold ;The number of occurrences of the maximum number of packet loss retransmissions in the historical session is greater than or equal to the sixth threshold.

The third condition is used to evaluate the quality of network communication during historical sessions. If the historical service quality meets the third condition, it means that the network communication quality during the historical session was poor, and the data packet needs to be retransmitted more times to ensure that the receiving end successfully receives the data packet.

In some embodiments, the first numerical value is a positive integer. For example, the first data is equal to 1, which means that when the third condition is met, the sending end adds 1 to the number of repeated transmissions of lost packets in the historical session to determine the number of repeated transmissions of lost packets.

The calculation formula for the number of repeated transmissions of lost packets is as follows:

Retran_set_num_this=Retran_set_num+1

Among them, Retran_set_num_this represents the number of repeated transmissions of lost packets, and Retran_set_num represents the number of repeated transmissions of lost packets in historical sessions.

It should be noted that the specific value of the first value is determined according to actual needs and is not set here in this application.

In some embodiments, after determining that the historical service quality is available, the sending end determines whether the historical service quality satisfies the third condition.

In some embodiments, the third condition includes the following situations:

1) The third condition is that the packet loss retransmission success rate of historical sessions is less than or equal to the fourth threshold;

2) The third condition is that the maximum number of packet loss retransmissions in historical sessions is greater than or equal to the fifth threshold;

3) The third condition is that the number of occurrences of the maximum number of packet loss retransmissions in the historical session is greater than or equal to the sixth threshold;

4) The third condition is that the maximum number of packet loss retransmissions in the historical session is greater than or equal to the fifth threshold, and the number of occurrences of the maximum number of packet loss retransmissions in the historical session is greater than or equal to the sixth threshold.

5) The third condition is that the packet loss retransmission success rate of the historical session is less than or equal to the fourth threshold, the maximum number of packet loss retransmissions in the historical session is greater than or equal to the fifth threshold, and the maximum number of packet loss retransmissions in the historical session occurs The number of times is greater than or equal to the sixth threshold.

Optionally, if the third condition is case 5), the first numerical value is greater than the first numerical value corresponding to the third condition being 1), 2), 3), and 4).

In some embodiments, if the packet loss retransmission success rate Retran_success_ratio in QoS_his is too small, it means that after the data packet is lost in the historical session, the sending end can return the lost message to the receiver. The fourth threshold is denoted as Retran_success_ratio_t.

Optionally, the fourth threshold may be called the target success rate of packet loss equivalent retransmission. The value of the fourth threshold can be set by the administrator; if Retran_success_ratio<Retran_success_ratio_t, the sending end calculates Retran_set_num+p as if Retran_set_num_this, p is the first value. For example, p equals 1, 2, 3….

In some embodiments, if the maximum number of packet loss equal-cost retransmissions Retran_max_num and the maximum number of packet loss equivalent retransmissions Retran_max_amount in QoS_his are both too large, it means that after the message was lost in the last session, the sending end The lost message can be sent back to the receiving end only after multiple equal-cost retransmissions; the fifth threshold and the sixth threshold are recorded as Retran_max_num_t and Retran_max_amount_t respectively. The specific values of these two thresholds can be set by the administrator;

If Retran_max_num>Retran_max_num_t, and Retran_max_amount>Retran_max_amount_t; then the sending end calculates Retran_set_num+p as if Retran_set_num_this, p is the first value. For example, p equals 1, 2, 3….

Through the above method, determining the number of repeated transmissions of lost packets based on historical service quality will help improve the success rate of providing the receiving end with retransmitted data packets.

In some embodiments, the data packet transmission method further includes: if the historical service quality does not meet the third condition, comparing the number of repeated transmissions of lost packets in the historical session or the number of repeated transmissions of lost packets in the historical session with the second The difference between the values is determined as the number of repeated transmissions for packet loss.

In some embodiments, if the third condition is not met, it means that the network communication quality during the historical session between the sending end and the receiving end is good. In this case, the sending end follows the polling rules and according to the number of transmission failures of the data packet, selects the number of repeated transmissions of the lost packets in the historical session and the number of repeated transmissions of the lost packets in the historical session and the second value. Difference, as the number of repeated transmissions for packet loss.

For example, if the sending end detects the loss of a certain data packet for the first time, it will resend (Retran_set_num–1) identical data packets during retransmission; if the sending end detects the loss of the data packet for the second time, it will resend it again. Repeatedly send Retran_set_num identical data packets during transmission.

Figure 8 is a schematic diagram of retransmission timing of data packets provided by an exemplary embodiment of the present application.

The number of repeated retransmissions of lost packets Retran_set_num_this is set to 3, that is, if a data packet is lost during transmission, the sender needs to retransmit it three times, so the lost data packets 1 and 2 need to be retransmitted again. 2 times. The sender retransmits the remaining number of packet loss retransmission operations in the application restricted phase. As shown in Figure 8, the sender retransmits lost data packets 1 and 2 once in application restricted phase 1; in application restricted phase 2 Retransmit lost packets 1 and 2 once respectively.

In some embodiments, if the time interval between multiple data packets in equal-cost retransmission exceeds the round-trip time, the sending end gives up retransmitting the data packets in the equal-cost retransmission.

Figure 9 is a schematic diagram of the time interval of level retransmission provided by an exemplary embodiment of the present application.

The sender detects packet loss in data packets 1 and 2 at time t0 and immediately retransmits them. The next time the restricted phase is applied, the sender tries to retransmit the lost packet 1 again; but at this time, the equal-cost retransmission interval T_retran exceeds the round-trip time RTT between the server and the user terminal, that is, T_retran>RTT, then Lost data packets 1 and 2 will no longer be retransmitted during the application-limited phase of the equal-cost retransmission cycle.

In some embodiments, the data packet transmission method further includes: within the duration of the application restricted state, if the number of data determined and retransmitted from the retransmission unacknowledged queue does not reach the threshold, the sending end retransmits it again. The step of determining the first data in the unconfirmed queue begins; if the number of data determined and retransmitted from the retransmission unconfirmed queue reaches the threshold, the determination and retransmission of data from the retransmitted unconfirmed queue stops.

In some embodiments. The threshold value is used to characterize the number of equivalent retransmissions allowed in an application's restricted state. Optionally, the threshold value is a positive integer greater than or equal to 1. For example, the threshold value is equal to 6. It should be noted that the threshold value is set according to actual needs, and is not set here in this application.

In one example, within the duration of the application restricted state, the sending end determines the first data from the head of the retransmission unconfirmed queue and retransmits the first data packet corresponding to the first data; the sending end transmits the first data Move to the end of the retransmission undetermined queue. If the duration of the application restricted state has not ended, the sending end will retransmit the data at the head of the unconfirmed queue as the new first data, and retransmit the new first data; the sending end will retransmit the new first data. The data is moved to the end of the retransmission unacknowledged queue. The sender performs the above operations in a loop until the application restricted state ends or the number of data determined and retransmitted from the retransmission unconfirmed queue reaches the threshold.

In some embodiments, the number of retransmissions of the first data is limited by a threshold value and the number of retransmissions of lost packets. During the duration of an application-restricted state at the sender, the number of data retransmissions does not exceed the threshold value. If in a certain application restriction state, the retransmissions performed by the sender are equal to the threshold value, then during this application restriction process, the sender will no longer retransmit other data in the retransmission unconfirmed queue. However, when the sender transitions from the current application restricted state to the application unrestricted state, and then enters the application restricted state again, it will re-count whether the number of times the sender retransmits data in the new application restricted state exceeds the threshold. value. By sending at least one retransmission of data for the duration of an application-restricted state, it helps to shorten the time it takes for the receiver to obtain retransmitted data packets.

In some embodiments, the data packet retransmission method further includes: when the sending end switches from the application restricted state to the application unrestricted state, stopping to determine and retransmit data from the retransmission unacknowledged queue.

In some embodiments, the application unrestricted state means that the sender has untransmitted initial transmission data or initial retransmission data. Optionally, the sending end monitors whether it is in an application restricted state in real time. If it is determined to be in the application restricted state, the sender determines and retransmits the data from the retransmission unconfirmed queue; if it is determined to be in the application unrestricted state, it stops determining and retransmitting the data from the retransmit unconfirmed queue and starts transmitting the initial transmission data. Bag.

Optionally, the sending end has a sending queue, and by monitoring the number of data in the sending queue, it is determined whether the sending end is in an application-limited state. If there is no data in the sending queue, the sending end is in the application restricted state; if there is data in the sending queue, the sending end is in the application unrestricted state. If the sending queue changes from no data to at least one data, it means that the sending end switches from the application restricted state to the application unrestricted state. In this case, the sender stops identifying and retransmitting data from the retransmission unacknowledged queue. Optionally, the sending end in the application unrestricted state transmits the data in the sending queue in sequence.

Figure 10 is a sequence diagram of a data packet transmission method provided by an exemplary embodiment of the present application.

As shown in Figure 10, the sender executes a data packet transmission method based on the QUIC protocol or TCP protocol at time t0-t1. The sending end detects that it is in an application-limited state at time t1. The sending end extracts data (such as Loss0) from the head of the retransmission unconfirmed queue and retransmits the data to the receiving end.

When the sender switches from the application restricted state to the application unrestricted state, timely stop retransmitting the data in the retransmission unconfirmed queue, which helps to reduce the impact of retransmission operations on data packets in the application restricted state. The impact of the initial transmission helps avoid packet transmission blocking caused by retransmission of data in the retransmission unacknowledged queue.

In some embodiments, the data contained in the retransmission unconfirmed queue are different from each other, and there is no strong correlation between the data. If there is a strong correlation between the third data and the fourth data, the fourth data is retransmitted. The data realizes packet loss recovery of the third data.

In some embodiments, if the third data transmission is lost and the sending end sends the fourth data to the receiving end, and the receiving end recovers the third data based on the fourth data after obtaining the fourth data, it means that the third data and the fourth data are The data is relevant.

In some embodiments, the data contained in the retransmission unconfirmed queue are different from each other means that the data content contained in the data is different.

Since there is no strong correlation between the data in the retransmission unconfirmed queue, if the fourth data is added to the end of the retransmission unconfirmed queue, the third data needs to be removed from the retransmission unconfirmed queue. Prevent the data content of the third data from appearing repeatedly in the retransmission unconfirmed queue.

This method helps improve the efficiency of repeated retransmission of data.

In some embodiments, within the duration of the application restricted state, the retransmission parameter of the first data satisfies at least one of the following: the sending rate of the first number is less than or equal to the sending rate of the data in the application unrestricted state; The sending window of a data packet is different from the sending window of data in the application unrestricted state; where the application unrestricted state means that the sending end has untransmitted initial transmission data or initial retransmission data.

The sending rate is used to characterize the data transmission rate of the sending end. For related embodiments of the sending rate, please refer to the above embodiments.

The send window is used to send data packets to the terminal. In some embodiments, the sending window used in the application's restricted state is different from the sending window used in the application's unrestricted state.

For example, the sender has 60 sending windows at its disposal, and during the duration of the application unrestricted state, the first 40 sending windows are used to send initial transmission data or first retransmission data; during the duration of the application restricted state, the sending end never Select at least one sending window from the remaining 20 windows to retransmit the first data packet corresponding to the first data.

This method helps reduce the impact of repeated retransmission actions by the sender on data transmission in the application unrestricted state when the application is in the restricted state.

In some embodiments, the data packet transmission method also includes: when the sending end and the receiving end create a connection, the sending end creates a retransmission unconfirmed queue corresponding to the connection; when the sending end and the receiving end close the connection, release the connection corresponding Retransmit unacknowledged queue.

In some embodiments, the sender creates a retransmission unacknowledged queue when the sender establishes a connection with the receiver. While the sender and receiver maintain a connection, the sender continues to maintain the retransmission unacknowledged queue. Optionally, the retransmission unacknowledged queue includes at least one data packet that has been retransmitted but has not been acknowledged, or the retransmission unacknowledged queue is empty.

Through this method, during the connection process between the sending end and the receiving end, only one retransmission unconfirmed queue needs to be established and one retransmission unconfirmed queue needs to be released, which helps to simplify the sending end's management of the retransmission unconfirmed queue. step.

In some embodiments, when it is detected that the data corresponding to the connection is lost, the sending end creates a retransmission unconfirmed queue corresponding to the connection; when it is detected that the retransmission unconfirmed queue is empty, the sender releases the retransmission unconfirmed queue corresponding to the connection. .

In this case, the retransmission unacknowledged queue includes at least one packet that has been retransmitted but whose receipt has not been acknowledged.

Through this method, the sender only needs to maintain the retransmission unconfirmed queue when there is data that has been retransmitted and has not been confirmed to be received, which helps to reduce the sender's maintenance time of the retransmit unconfirmed queue and reduce the sender's workload. Computational overhead also helps reduce the space resources occupied by maintaining the retransmission unacknowledged queue.

In some embodiments, when it is detected that the data corresponding to the connection is lost, a retransmission unconfirmed queue corresponding to the connection is created; when the sending end and the receiving end close the connection, the retransmission unconfirmed queue corresponding to the connection is released.

For example, the sending end obtains the message confirmation information sent by the receiving end, determines that at least one data packet has been lost based on the message confirmation information, and creates a retransmission unconfirmed queue corresponding to the connection. The sender continues to maintain the retransmission unacknowledged queue before disconnecting from the receiver.

Optionally, the retransmission unacknowledged queue includes at least one data packet that has been retransmitted but has not been acknowledged, or the retransmission unacknowledged queue is empty.

Through this method, while the sender and receiver maintain the connection, only one action is required to create and release the retransmission unacknowledged queue. At the same time, the retransmission unconfirmed queue is created only when the first data packet is lost, which helps shorten the time the sender maintains the retransmit unconfirmed queue while the sender and receiver maintain the connection.

Figure 11 is a schematic diagram of a data packet transmission method provided by an exemplary embodiment of the present application.

After the sender and receiver establish a connection, a retransmission unconfirmed queue is created. The sender maintains the retransmit unconfirmed queue based on packet loss retransmission and confirmation information; the sender detects in real time whether it is currently in an application restricted state. If it is currently in an application In the restricted state, the sending end extracts at least one first data from the head of the retransmission unconfirmed queue; the sending end performs a repeated retransmission operation on the first data extracted from the retransmission unconfirmed queue. When the retransmission unconfirmed queue is not empty, the sending end releases the retransmission unconfirmed queue.

The following are device embodiments of the present application, which can be used to execute method embodiments of the present application. For details not disclosed in the device embodiments of this application, please refer to the method embodiments of this application.

Figure 12 shows a block diagram of a data packet transmission device provided by an exemplary embodiment of the present application. The device can be implemented as all or part of the terminal device through software, hardware, or a combination of both. The device 1200 may include: a data packet determination module 1210, a data packet retransmission module 1220, and a queue maintenance module 1230.

The data packet determination module 1210 is used to determine the first data from the retransmission unconfirmed queue when the sending end is in an application restricted state; wherein the application restricted state means that the sending end has no untransmitted data yet. The initial transmission data and the first retransmission data, the retransmission unconfirmed queue is used to store data that has been retransmitted but has not been confirmed by the receiving end.

The data packet retransmission module 1220 is configured to retransmit the first data packet corresponding to the first data to the receiving end.

The queue maintenance module 1230 is used to adjust the position of the first data in the retransmission unconfirmed queue.

In some embodiments, the data in the retransmission unconfirmed queue is arranged in the retransmission unconfirmed queue from the beginning to the end of the queue in order of the last retransmission time;

The data packet determination module 1210 is used to determine the data packet located at the head of the retransmission unconfirmed queue as the first data; the queue maintenance module 1230 is used to move the first data to the end of the retransmission unacknowledged queue.

In some embodiments, the queue maintenance module 1230 is also configured to: when it is detected that the second data is lost, and the second data is lost in the retransmission unconfirmed queue, retransmit all the lost data. second data corresponding to the second data, and add the second data packet to the end of the retransmission unconfirmed queue; or, after detecting that the second data packet is lost and the retransmission is not confirmed If the second data exists in the queue, retransmit the second data and move the second data to the end of the retransmission unconfirmed queue; or, in the retransmit unconfirmed queue When the second data packet in is confirmed to be received by the receiving end, the second data is deleted from the retransmission unconfirmed queue.

In some embodiments, the data packet determination module 1210 is configured to: determine the retransmission unconfirmed queue from the retransmission unconfirmed queue when the sending end is in the application restricted state and the first condition is met. The first data; wherein, the first condition includes at least one of the following: the end-to-end transmission delay between the sending end and the receiving end is greater than or equal to a first threshold; the sending end and the receiving end The packet loss rate between receiving ends is greater than or equal to the second threshold.

In some embodiments, the data packet determination module 1210 is configured to: determine the retransmission unconfirmed queue from the retransmission unconfirmed queue when the sending end is in the application restricted state and the second condition is met. The first data; wherein, the second condition includes: the number of repeated retransmissions of packet loss is greater than or equal to a third threshold; wherein the number of repeated retransmissions of packet loss refers to the number of repeated retransmissions between the sending end and the receiving end. The maximum number of times a data packet is retransmitted while the client remains connected.

In some embodiments, the device 1200 further includes: an information acquisition module, used to obtain historical service quality; wherein the historical service quality is used to characterize the data packet transmission status of the historical session established with the receiving end; the number of times A determining module, configured to calculate the number of repeated retransmissions of the lost packet based on the historical service quality.

In some embodiments, the historical service quality includes at least one of the following: the packet loss retransmission success rate of the historical session. The packet loss retransmission success rate is used to represent that the receiving end successfully receives the retransmission data packet. probability; the maximum number of packet loss retransmissions in the historical session, which is used to represent the maximum number of packet loss retransmissions in an application-restricted state; the maximum number of packet loss retransmissions in the historical session; The number of occurrences of transmission times; the number of repeated transmissions of lost packets in the historical session.

In some embodiments, the packet loss retransmission success rate and the maximum number of packet loss retransmissions are calculated based on the number of equal-cost retransmissions in the historical session; wherein the equal-cost retransmission refers to the time duration Within the threshold, the sending end retransmits the data packet.

In some embodiments, the number of times determination module is configured to determine the sum of the number of repeated transmissions of lost packets in the historical session and the first value as if the historical service quality satisfies the third condition. The number of repeated transmissions of the packet loss; wherein the third condition includes at least one of the following: the packet loss retransmission success rate of the historical session is less than or equal to the fourth threshold; the maximum packet loss retransmission of the historical session The number of times is greater than or equal to the fifth threshold; the number of occurrences of the maximum number of packet loss retransmissions in the historical session is greater than or equal to the sixth threshold.

In some embodiments, the number of times determination module is also configured to determine the number of repeated transmissions of lost packets in the historical session or the number of repeated transmissions of the historical session when the historical service quality does not meet the third condition. The difference between the number of repeated transmissions of lost packets in and the second value is determined as the number of repeated transmissions of lost packets.

In some embodiments, the device 1200 further includes: a quantity control module configured to, within the duration of the application restricted state, if the number of data determined and retransmitted from the retransmission unconfirmed queue does not reach threshold value, then start again from the step of determining the first data packet from the retransmission unconfirmed queue; if the number of data determined and retransmitted from the retransmission unconfirmed queue reaches the threshold value, stop from The data in the retransmission unacknowledged queue is determined and retransmitted.

In some embodiments, the apparatus 1200 further includes: a retransmission stopping module, configured to stop the retransmission from the unrestricted state when the sending end switches from the application restricted state to the application unrestricted state. Acknowledge the queue and retransmit the packet.

In some embodiments, the data contained in the retransmission unconfirmed queue are different from each other, and there is no strong correlation between the data. If there is a strong correlation between the third data and the fourth data, then the retransmission The fourth data packet implements packet loss recovery of the third data packet.

In some embodiments, within the duration of the application restricted state, the retransmission parameter of the first data packet satisfies at least one of the following: the sending rate of the first data is less than or equal to the application unrestricted state The transmission rate of data under the application is not restricted; the transmission window of the first data is different from the transmission window of data in the application unrestricted state; wherein the application unrestricted state means that the sending end has an initial untransmitted Transmitted data or data retransmitted for the first time.

In some embodiments, the apparatus 1200 further includes: a queue management module, configured to create the retransmission unconfirmed queue corresponding to the connection when the sending end and the receiving end create a connection; When the sending end and the receiving end close the connection, release the retransmission unconfirmed queue corresponding to the connection; or, when it is detected that the data corresponding to the connection is lost, create the retransmission corresponding to the connection. Unconfirmed queue; when it is detected that the retransmission unconfirmed queue is empty, release the retransmission unconfirmed queue corresponding to the connection; or, when it is detected that the data corresponding to the connection is lost, create the connection corresponding The retransmission unconfirmed queue; when the sending end and the receiving end close the connection, release the retransmission unconfirmed queue corresponding to the connection.

It should be noted that when implementing the functions of the device provided by the above embodiments, only the division of the above functional modules is used as an example. In practical applications, the above functions can be allocated to different functional modules according to needs, that is, The content structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be described again here. For the beneficial effects of the devices provided by the above embodiments, please refer to the description of the method side embodiments, which will not be described again here.

Figure 13 shows a structural block diagram of a computer device provided by an exemplary embodiment of the present application. The computer device 1300 may be the sending end introduced above, or the receiving end introduced above.

Generally, the computer device 1300 includes: a processor 1301 and a memory 1302.

The processor 1301 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1301 can be implemented in at least one hardware form among DSP (Digital Signal Processing, digital signal processing), FPGA (Field Programmable Gate Array, field programmable gate array), and PLA (Programmable Logic Array, programmable logic array). The processor 1301 may also include a main processor and a co-processor. The main processor is a processor used to process data in the wake-up state, also called CPU (Central Processing Unit, central processing unit); the co-processor is A low-power processor used to process data in standby mode. In some embodiments, the processor 1301 may be integrated with a GPU (Graphics Processing Unit, image processor), and the GPU is responsible for rendering and drawing content that needs to be displayed on the display screen. In some embodiments, the processor 1301 may also include an AI (Artificial Intelligence, artificial intelligence) processor, which is used to process computing operations related to machine learning.

Memory 1302 may include one or more computer-readable storage media, which may be tangible and non-transitory. Memory 1302 may also include high-speed random access memory, and non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in memory 1302 stores at least one instruction, at least one program, a set of codes, or a set of instructions, the at least one instruction, at least one segment of a program, a set of codes, or a set of instructions consisting of The processor 1301 is loaded and executed to implement the data packet transmission method provided by each of the above method embodiments.

Embodiments of the present application also provide a computer-readable storage medium, which stores a computer program. The computer program is loaded and executed by a processor to implement the data packet transmission method provided by the above method embodiments.

The computer-readable media may include computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read-Only Memory, Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or Other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc, high-density digital video disc) or other optical storage, tape cassettes, magnetic tapes, disk storage or other magnetic storage devices. Of course, those skilled in the art will know that the computer storage medium is not limited to the above types.

Embodiments of the present application also provide a computer program product. The computer program product includes computer instructions. The computer instructions are stored in a computer-readable storage medium. The processor reads and executes the instructions from the computer-readable storage medium. Computer instructions are used to implement the data packet transmission method provided by each of the above method embodiments.

It should be understood that "plurality" mentioned in this article means two or more. "And/or" describes the relationship between associated objects, indicating that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the related objects are in an "or" relationship.

It should be noted that the user data and signals involved in this application are authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions. . For example, the user data involved in this application was obtained with full authorization.

The above are only optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent switches, improvements, etc. made within the spirit and principles of this application shall be included in the protection of this application. within the range.

Claims (19)

1. A method for transmitting a data packet, the method comprising:

under the condition that the transmitting end is in an application limited state, determining first data from a retransmission unacknowledged queue; the application limited state means that the sending end does not have initial transmission data which is not transmitted and data which is retransmitted for the first time, and the retransmission unacknowledged queue is used for storing data which is retransmitted but not acknowledged to be received by the receiving end;

transmitting a first data packet corresponding to the first data to the receiving end;

and adjusting the position of the first data in the retransmission unacknowledged queue.

2. The method of claim 1, wherein the data in the retransmission unacknowledged queue is arranged in the retransmission unacknowledged queue in order from the beginning of the queue to the end of the queue in the order from the early to the late time of the last retransmission;

the determining the first data from the retransmission unacknowledged queue includes:

determining the data at the head of the retransmission unacknowledged queue as the first data;

the adjusting the position of the first data in the retransmission unacknowledged queue includes:

and moving the first data to the tail of the retransmission unacknowledged queue.

3. The method according to claim 2, wherein the method further comprises:

when the second data is detected to be lost and the second data does not exist in the retransmission unacknowledged queue, sending a second data packet corresponding to the second data, and adding the second data to the tail of the retransmission unacknowledged queue;

or,

when the second data is detected to be lost and the second data packet exists in the retransmission unacknowledged queue, sending second data corresponding to the second data, and moving the second data to the tail of the retransmission unacknowledged queue;

or,

and deleting the second data in the retransmission unacknowledged queue under the condition that the second data in the retransmission unacknowledged queue is acknowledged by the receiving end.

4. The method according to claim 1, wherein the determining the first data from the retransmission unacknowledged queue in the case that the transmitting end is in the application limited state includes:

determining the first data from the retransmission unacknowledged queue under the condition that the transmitting end is in the application limited state and a first condition is met;

Wherein the first condition includes at least one of:

the end-to-end transmission delay between the transmitting end and the receiving end is greater than or equal to a first threshold;

and the packet loss rate between the sending end and the receiving end is larger than or equal to a second threshold value.

5. The method according to claim 1, wherein the determining the first data from the retransmission unacknowledged queue in the case that the transmitting end is in the application limited state includes:

determining the first data from the retransmission unacknowledged queue under the condition that the transmitting end is in the application limited state and a second condition is met;

wherein the second condition includes: the repeated retransmission times of the lost packet is larger than or equal to a third threshold value; the number of repeated retransmission times of packet loss refers to the maximum number of retransmission times of the data packet in the process that the sending end and the receiving end keep connected.

6. The method of claim 5, wherein the method further comprises:

acquiring historical service quality; the historical service quality is used for representing the data transmission condition of the historical session established with the receiving end;

and calculating the repeated retransmission times of the lost packet according to the historical service quality.

7. The method of claim 6, wherein the historical quality of service comprises at least one of:

the packet loss retransmission success rate of the historical session is used for representing the probability of successful reception of the retransmission data packet by the receiving end;

the maximum packet loss retransmission times of the historical session are used for representing the maximum transmission times of data packets in a one-time application limited state;

the occurrence times of the maximum packet loss retransmission times in the historical session;

and repeating the transmission times of the lost packet in the history session.

8. The method of claim 7, wherein the packet loss retransmission success rate, the maximum number of packet loss retransmissions are calculated based on a number of equivalent retransmissions in the history session; the equivalent retransmission refers to retransmission of the data packet by the transmitting end within a duration threshold.

9. The method of claim 7, wherein the calculating the number of repeated retransmissions of the lost packet based on the historical quality of service comprises:

if the historical service quality meets a third condition, determining the sum of the repeated transmission times of the lost packet in the historical session and a first numerical value as the repeated transmission times of the lost packet;

Wherein the third condition includes at least one of:

the packet loss retransmission success rate of the historical session is smaller than or equal to a fourth threshold value;

the maximum packet loss retransmission times of the historical session is larger than or equal to a fifth threshold value;

and the occurrence frequency of the maximum packet loss retransmission frequency in the historical session is larger than or equal to a sixth threshold value.

10. The method according to claim 9, wherein the method further comprises:

and if the historical service quality does not meet the third condition, determining the repeated transmission times of the lost packets in the historical session or the difference between the repeated transmission times of the lost packets in the historical session and a second numerical value as the repeated transmission times of the lost packets.

11. The method according to claim 1, wherein the method further comprises:

if the quantity of the retransmitted data determined from the retransmission unacknowledged queue does not reach the threshold value within the duration of the application limited state, the step of determining the first data from the retransmission unacknowledged queue is started to be executed again;

and if the number of the retransmitted data packets determined from the retransmission unacknowledged queue reaches a threshold value, stopping determining and retransmitting the data from the retransmission unacknowledged queue.

12. The method according to claim 1, wherein the method further comprises:

and stopping determining and retransmitting data from the retransmission unacknowledged queue under the condition that the transmitting end is switched from the application limited state to the application non-limited state.

13. The method of claim 1, wherein the data included in the retransmission unacknowledged queue are different from each other, and there is no strong correlation between the data, and if there is a strong correlation between the third data and the fourth data, packet loss recovery of the third data is achieved by retransmitting the fourth data.

14. The method of claim 1, wherein the retransmission parameters of the first data satisfy at least one of the following for the duration of the application-limited state:

the sending rate of the first data is smaller than or equal to the sending rate of the data in an application unrestricted state;

the transmission window of the first data is different from the transmission window of the data in the application unrestricted state;

the application unrestricted status refers to that the sending end has initial transmission data which is not transmitted or data which is retransmitted for the first time.

15. The method according to claim 1, wherein the method further comprises:

When the transmitting end and the receiving end establish connection, the retransmission unacknowledged queue corresponding to the connection is established; when the sending end and the receiving end close the connection, releasing the retransmission unacknowledged queue corresponding to the connection;

or,

when the loss of the data corresponding to the connection is detected, creating the retransmission unacknowledged queue corresponding to the connection; releasing the retransmission unacknowledged queue corresponding to the connection when the retransmission unacknowledged queue is detected to be empty;

or,

when the loss of the data corresponding to the connection is detected, creating the retransmission unacknowledged queue corresponding to the connection; and when the sending end and the receiving end close the connection, releasing the retransmission unacknowledged queue corresponding to the connection.

16. A data packet transmission apparatus, the apparatus comprising:

the data packet determining module is used for determining first data from a retransmission unacknowledged queue under the condition that the transmitting end is in an application limited state; the application limited state means that the sending end does not have initial transmission data which is not transmitted and data which is retransmitted for the first time, and the retransmission unacknowledged queue is used for storing data which is retransmitted but not acknowledged to be received by the receiving end;

A data packet retransmission module, configured to retransmit a first data packet corresponding to the first data to the receiving end;

and the queue maintenance module is used for adjusting the position of the first data in the retransmission unacknowledged queue.

17. A computer device comprising a processor and a memory, wherein the memory has stored therein a computer program that is loaded and executed by the processor to implement the method of transmitting data packets according to any of claims 1 to 15.

18. A computer readable storage medium, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the method of transmitting data packets according to any of claims 1 to 15.

19. A computer program product, characterized in that it comprises a computer program stored in a computer readable storage medium, from which a processor reads and executes the computer program to implement the method of transmission of data packets according to any of claims 1 to 15.