WO2024001763A1 - 一种数据传输处理方法、装置、存储介质及电子装置 - Google Patents
一种数据传输处理方法、装置、存储介质及电子装置 Download PDFInfo
- Publication number
- WO2024001763A1 WO2024001763A1 PCT/CN2023/100013 CN2023100013W WO2024001763A1 WO 2024001763 A1 WO2024001763 A1 WO 2024001763A1 CN 2023100013 W CN2023100013 W CN 2023100013W WO 2024001763 A1 WO2024001763 A1 WO 2024001763A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- rate
- data
- adjusted
- packet sending
- current
- Prior art date
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 71
- 238000003672 processing method Methods 0.000 title claims abstract description 13
- 238000000034 method Methods 0.000 claims abstract description 29
- 230000015654 memory Effects 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 16
- 238000012545 processing Methods 0.000 claims description 9
- 230000009466 transformation Effects 0.000 claims description 6
- 238000005070 sampling Methods 0.000 claims description 4
- 238000004422 calculation algorithm Methods 0.000 abstract description 19
- 230000006870 function Effects 0.000 description 11
- 238000004364 calculation method Methods 0.000 description 10
- 238000005259 measurement Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000006399 behavior Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000009499 grossing Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000011010 flushing procedure Methods 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012946 outsourcing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000033764 rhythmic process Effects 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Definitions
- Embodiments of the present disclosure relate to the field of communications, specifically, to a data transmission processing method, device, storage medium and electronic device.
- TCP protocol Transmission Control Protocol
- Linux system the Transmission Control Protocol
- TCP congestion control algorithms have the ultimate goal of using up network bandwidth as much as possible.
- TCP congestion control algorithms have the ultimate goal of using up network bandwidth as much as possible.
- the measurement is inaccurate.
- the degree is even higher. During peak business periods, this will cause a large number of data packets that exceed the network capacity to enter the network, leading to more packet losses. After packet losses occur, the retransmission rate will increase and the transmission utilization will further decrease. It is difficult to Adapt to the transmission of current video service data.
- Embodiments of the present disclosure provide a data transmission processing method, device, storage medium and electronic device to at least solve the problem of a large number of packet losses and high retransmission rates caused by the general TCP congestion control algorithm in related technologies in a large traffic environment. Video service lag problem.
- a data transmission processing method includes:
- the data type is a video file, obtain the code rate information of the data to be transmitted;
- the data to be transmitted is transmitted according to the adjusted packet sending rate.
- a data transmission processing device is also provided, and the device includes:
- the determination module is configured to determine the data type of the data to be transmitted
- the first acquisition module is configured to acquire the code rate information of the data to be transmitted if the data type is a video file;
- the second acquisition module is set to acquire the current network status
- the first adjustment module is configured to adjust the current packet sending rate according to the current network conditions and the code rate information to obtain the adjusted packet sending rate;
- a transmission module configured to transmit the data to be transmitted according to the adjusted packet sending rate.
- a computer-readable storage medium is also provided, and a computer program is stored in the storage medium, wherein the computer program is configured to execute any one of the above method embodiments when running. steps in.
- an electronic device including a memory and a processor.
- a computer program is stored in the memory, and the processor is configured to run the computer program to perform any of the above. Steps in method embodiments.
- Figure 1 is a hardware structure block diagram of a computer device of a data transmission processing method according to an embodiment of the present disclosure
- Figure 2 is a flow chart of a data transmission processing method according to an embodiment of the present disclosure
- Figure 3 is a flow chart for adjusting the packet sending rate according to an embodiment of the present disclosure
- FIG. 4 is a block diagram three of the Linux operating system according to this embodiment.
- FIG. 5 is a block diagram of a data transmission processing device according to an embodiment of the present disclosure.
- FIG. 1 is a hardware structural block diagram of a CDN server device of the data transmission processing method according to an embodiment of the present disclosure.
- the CDN server device can include one or more (in Figure 1 Only one processor 102 is shown (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned CDN server device may also include Transmission device 106 and input and output device 108 for communication functions.
- a processing device such as a microprocessor MCU or a programmable logic device FPGA
- the structure shown in Figure 1 is only illustrative, and it does not limit the structure of the above CDN server device.
- the CDN server device may also include more or fewer components than shown in Figure 1, or have a different configuration than shown in Figure 1.
- the memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer programs corresponding to the data transmission processing methods in the embodiments of the present disclosure.
- the processor 102 executes the computer programs stored in the memory 104 by running them.
- Various functional applications and business chain address pool slicing processing implement the above method.
- Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
- the memory 104 may further include memory located remotely relative to the processor 102, and these remote memories may be connected to a CDN server device through a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.
- Transmission device 106 is used to receive or send data via a network.
- the above-mentioned specific example of the network may include a wireless network provided by a communication provider of the CDN server device.
- the transmission device 106 includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station to communicate with the Internet.
- the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet wirelessly.
- RF Radio Frequency
- TCP congestion control algorithms are generally divided into three categories:
- RTT path delay round trip time
- packet loss is used as a signal of congestion.
- the logic is that the cache of routers and switches is limited. Congestion will cause the cache to be exhausted, and some packets in the queue will be discarded. Congestion will Causes packet loss, but packet loss is not necessarily caused by congestion. Therefore, this congestion algorithm is easily interfered by noise. In an environment with high packet loss rate and high delay, the bandwidth utilization rate is very low. Most of the current network environments are WiFi. , 4G/5G signals have a high rate of noise packet loss in wireless environments.
- bandwidth delay detection such as BBR
- BBR bottleneck bandwidth and round-trip
- TCP congestion algorithms data transmission is controlled by the sending window and the receiving window.
- the amount of data sent at one time cannot exceed the minimum value of the two windows.
- the remaining data must wait until the receiving response comes back before it can continue to be sent. This limitation causes TCP data transmission to start slowly, which in turn makes the video playback time longer and affects the user's viewing experience.
- FIG. 2 is a flow chart of the data transmission processing method according to an embodiment of the present disclosure. As shown in Figure 2, the process includes the following steps:
- Step S202 determine the data type of the data to be transmitted
- Step S204 if the data type is a video file, obtain the code rate information of the data to be transmitted;
- Step S206 obtain the current network status
- Step S208 Adjust the current packet sending rate according to the current network conditions and code rate information to obtain the adjusted packet sending rate
- the current packet sending rate is obtained periodically.
- the speed measurement is performed periodically (this speed measurement period can be dynamically set through parameters) to obtain data packets that have been confirmed by the peer.
- the collected peer ACK serial number is obtained by difference calculation), calculate the transmission rate of the current cycle, and smooth the speed measurement results of the previous cycles (the number of times can be set, and the smoothing coefficient used in the calculation can be set) to calculate As the current packet sending rate.
- Step S210 Transmit the data to be transmitted according to the adjusted packet sending rate.
- the preset transmission rate is used as the code rate information, and then the current network status is obtained, and the current packet sending rate is adjusted according to the current network status and code rate information, and we get The adjusted packet sending rate, and the data to be transmitted is transmitted according to the adjusted packet sending rate.
- the current network status includes at least one of the following: RTT transformation, packet loss rate, retransmission rate and the actual transmission rate of the current network.
- the current network status is obtained periodically during the transmission process. Specifically, it may include: obtaining the transformation of the round trip time (RTT) in the TCP protocol stack and/or the actual transmission rate of the current network at a preset period; and/or obtaining the total transmission rate in the TCP protocol stack.
- RTT round trip time
- the number of packets sent, the total number of packets lost, and the total number of retransmissions are used to determine the packet loss rate and retransmission rate in the current sampling period based on the total number of packets sent, the total number of packets lost, and the total number of retransmissions.
- the system in this embodiment has RTT, packet loss rate and retransmission rate monitoring functions in order to obtain the current network status. Specifically Including changes in delay and blocking, this data is also sampled periodically to obtain the RTT value in the TCP protocol stack, the total number of packets sent, the total number of packet losses and the total number of retransmissions, and the packet loss rate in the current sampling period is calculated. and retransmission rate.
- FIG. 3 is a flow chart for adjusting the packet sending rate according to an embodiment of the present disclosure. As shown in Figure 3, adjusting the current packet sending rate according to the current network conditions and code rate information includes the following steps:
- Step S302 determine the minimum packet sending rate and the maximum packet sending rate according to the code rate information
- Step S304 adjust the current growth coefficient according to at least one of the changes in RTT, packet loss rate, retransmission rate and the actual transmission rate of the current network to obtain the adjusted growth coefficient;
- the above-mentioned step S304 may specifically include: performing a weighted calculation on the current speed increase coefficient based on at least one of RTT changes, packet loss rate, and retransmission rate to obtain an adjusted speed increase coefficient, where the initial speed increase coefficient is a preset
- the base weighting coefficient value is used to control how quickly the contract issuance rate increases.
- Step S306 Adjust the current contract issuance rate according to the adjusted growth coefficient to obtain the adjusted contract issuance rate.
- the above-mentioned step S306 may specifically include: determining the product of the adjusted growth coefficient and the current contract issuance rate, and determining the product as the adjusted contract issuance rate.
- Packet sending rate calculation is a comprehensive code rate information, using the current transmission rate (i.e. current packet sending rate) obtained by periodic speed measurement, RTT, packet loss rate and retransmission rate to calculate the optimal transmission rate in each cycle, reaching Intelligent adjustment is to further optimize the network, specifically including: when the video playback service is started, the initial packet sending rate is executed according to the initial packet sending rate v0 set by the service, and the sending window of the TCP link is appropriately adjusted as needed according to the packet sending rate. and receive windows to speed up the broadcast rate. At the same time, start the periodic test; obtain the baseline weighting coefficient value ⁇ (usually set to greater than or equal to 1). This value is used to control how quickly the packet sending rate increases.
- the current packet sending rate * ⁇ is used to obtain the packet sending rate of the next cycle.
- the current packet sending rate in the initial stage is the initial packet sending rate v0. Adjust the control v to be within the maximum packet sending rate and minimum packet sending rate set by the business. In this way, the next packet sending rate
- the cycle sends packets according to v packet sending rate; at the beginning of each time period, the actual transmission rate of the previous period and the network conditions are obtained to calculate the packet sending rate of the current period. At the beginning of the first period, the actual transmission rate is used Default starting transfer rate.
- the calculation weighting coefficient corresponding to RTT, packet loss rate and flushing rate can be dynamically adjusted, such as business settings and manual adjustment, or Automatically adjust through machine learning and computing power network.
- Transmitting video files based on the packet sending rate obtained in the above steps S302 to S306 can greatly reduce network congestion during peak business periods, reduce network packet loss, improve network transmission efficiency, and reduce the lag rate for users watching videos.
- the initial packet sending rate is determined to be a preset packet sending rate.
- the sender window and receiver window of the TCP protocol stack can also be adjusted according to the initial packet sending rate. Specifically, the size of the receiving window required for data sent within an RTT is calculated based on the initial packet sending rate; if the receiving end window is smaller than the receiving window size, the receiving end window is adjusted to the size of the receiving window; the sending end The window is adjusted to be no less than the size of the receiving end window, thereby increasing the TCP transmission startup rate, reducing the start time of the video stream, and improving the user's experience of watching the video.
- the opposite end When receiving the ack from the receiving end of the TCP protocol, the opposite end will bring the size of its receiving window. Especially during the startup period of the TCP link, the receiving window of the opposite end is usually relatively small, which affects the packet sending rate at startup. During the delay Higher links have a greater impact, because the next data transmission needs to wait until the receiving end's ack confirms that there is a receiving window, and this does It is recognized that you need to wait tens of ms or even hundreds of ms, so when the TCP link starts, it usually sends tens of K of data, then waits for tens or even hundreds of ms, and then sends slightly more data (received when receiving ack The end window may be enlarged, but it often still cannot accommodate all the sent data) and waits for tens of milliseconds; resulting in a slower increase in the packet sending rate of the TCP link.
- the receiving window size required for data sent within an RTT is calculated based on the initial packet sending rate set by the service. If the window brought by the receiving end is smaller than the calculated value, the TCP protocol will be adjusted. The receiving window size is the calculated value. Similarly, the sending window of the sending end will be adjusted to be no less than the receiving window of the opposite end. This ensures that during the TCP startup period, data can be sent at a constant rate at the initial packet sending rate set by the business, achieving the purpose of rapid transmission at startup, thus reducing the start time of the video.
- FIG. 4 is a block diagram of the Linux operating system according to this embodiment. As shown in Figure 4, it includes a user-mode packet sending module 42, a bbr_cdn module 44 and a sending module 46.
- the user-mode packet sending module 42 is also responsible for determining the type of data to be transmitted (the method of determination is not limited in the present invention). Currently, it is mainly divided into two categories (ordinary data type and video data type, and the possibility of adding categories is not ruled out. In this way, the bbr_cdn module 44 can be used to make more refined congestion control algorithms for different business types of data). For the video data type, the code rate information of the video (such as the minimum code rate, maximum code rate, average code rate, etc.) is obtained, and Pass these business information to bbr_cdn module 44 through the newly added socket interface.
- the code rate information of the video such as the minimum code rate, maximum code rate, average code rate, etc.
- bbr_cdn module 44 which uses the business information brought by the user mode packet sending module 42, combined with the RTT, packet loss and retransmission rate data generated by the TCP protocol packet sending that is continuously monitored (these data are obtained through processing from ordinary TCP protocol implementation), To calculate the rate at which this TCP link needs to be sent, and tell the sending module 46 the calculated rate information, so that the sending module 46 can send TCP data packets evenly at this rate; secondly, the bbr_cdn module 44 adjusts The sender window and receiver window of the TCP protocol are used to increase the startup rate of TCP protocol packet sending.
- Sending module 46 is a fair queue message scheduler in the Linux system.
- the sending module 46 sends the data stream through pacing.
- Pacing means that the fair queue (fair queuing scheduler, referred to as Fq) can use a certain sending rhythm.
- Send a data stream so that the data can enter the network evenly at a set rate.
- Fq is a packet queuing rule in the Linux network protocol stack.
- the bbr_cdn module 44 can be subdivided into the following functions: The bbr_cdn module 44 makes full use of the function of the original TCP_bbr congestion algorithm in the Linux system TCP protocol stack, and does not adopt the wheel. It can be realized by changing the control process of the original congestion algorithm.
- the interface connected with the user-mode packet sending module 42 is used to receive the business classification information of the user-mode sent data flow, so as to control the packet sending behavior of the TCP link in a more refined manner.
- the bbr_cdn module 44 can also use other methods to control the packet sending behavior of the TCP link. Infer the type of data stream (obtain some characteristic values of the video file by analyzing the data passed by the packet sending interface. For example, TS files are 188-byte data blocks, H.264 has obvious data headers, and has no obvious characteristics. Classified into data categories, after obtaining the characteristics, you can continue to analyze and obtain some of the code rate information) to achieve the same purpose, but it is not as accurate as directly informed by the business module.
- the speed measurement function obtains the actual number of bytes of data packets sent by the TCP link every 100ms (this time can be set through parameters), and through smoothing processing (the smoothing calculation window can be set, and the smoothing coefficient can be set), the current state of the TCP link can be obtained The actual packet delivery rate.
- RTT and packet loss rate, retransmission rate monitoring function in the TCP protocol, RTT will be calculated every time a TCP confirmation message is received, and the total packet sending count, packet loss count and retransmission count will be counted.
- the present invention It is necessary to monitor the RTT changes at the current time, the packet loss rate per unit time and the retransmission rate per unit time, so that the actual congestion status of the current network can be obtained more accurately. Therefore, the present invention will sample the current RTT and various Count to calculate the RTT, packet loss rate and retransmission rate of this 100ms.
- the window adjustment function all current TCP protocol congestion control implementations use the slow start process, which is achieved by controlling the sender window and the receiver window. Slow start can effectively prevent network congestion, but it also slows down The startup rate of TCP transmission increases the start time of video playback. Combined with the business data rate limiting function of the present invention, the window can be enlarged to speed up the TCP initial packet sending rate, but it will not affect network congestion.
- Packet sending rate calculation This functional module comprehensively considers business information, current speed measurement information, RTT changes, packet loss rate, and retransmission rate to calculate a rate suitable for the current network transmission.
- the bbr_cdn module 44 is a kernel module of the Linux system. It is based on the TCP_bbr module and the pacing function of the fair queue Fq. By replacing or modifying the main control process of TCP_bbr, it can reduce network congestion, reduce the video freeze rate, and speed up the process. The video start rate is used to improve the user’s viewing experience.
- TCP protocol congestion control algorithms use the maximum bandwidth of the network to transmit data. This implementation is more friendly to the transmission of general data files and can reduce the transmission time of data files. However, during peak business periods, It is also more likely to cause network congestion and packet loss and retransmission. For users to watch videos, it is not necessary to use the maximum bandwidth when transmitting video files. Video files all have bit rate information. The greater the bit rate, the faster the transmission needs to be, but as long as the transmission rate is equal to the bit rate Or slightly higher, which can meet the viewing needs of users. When currently transmitting video files, the content will be sent at a very fast rate, the player will store the file, and then the user will watch it slowly. After watching one file, it will request the next file and repeat the process.
- this method is like pulses one after another.
- the higher the pulse the greater the network traffic, which will lead to congestion, packet loss and retransmission.
- the network is completely idle, which is very wasteful. If the height of the pulse is lowered and widened, so that the network has no idle time, the network traffic will be evenly distributed, and the network traffic will not reach or exceed the maximum bandwidth of the network in each time period, thus greatly reducing the network traffic.
- the bit rate information of the video also allows the TCP congestion control algorithm to more accurately control the packet sending rate of video files, making full use of network time and reducing network congestion.
- the TCP transmission startup rate can be accelerated without introducing the risk of network congestion.
- Figure 5 is a block diagram of a data transmission processing device according to an embodiment of the present disclosure. As shown in Figure 5, the device includes:
- the determination module 52 is configured to determine the data type of the data to be transmitted
- the first acquisition module 54 is configured to acquire the code rate information of the data to be transmitted if the data type is a video file; the second acquisition module 56 is configured to acquire the current network status;
- the first adjustment module 58 is configured to adjust the current packet sending rate according to the current network conditions and the code rate information to obtain the adjusted packet sending rate;
- the transmission module 510 is configured to transmit the data to be transmitted according to the adjusted packet sending rate.
- the first acquisition module 54 is also configured to acquire the RTT in the TCP protocol stack at a preset period. transformation situation and/or the actual transmission rate of the current network; and/or, and obtain the total number of packets sent, the total number of packets lost, and the total number of retransmissions in the TCP protocol stack, and according to the total number of packets sent, the total number of packets lost And the total number of retransmissions determines the packet loss rate and retransmission rate within the current sampling period, wherein the current network conditions include at least one of the following: the transformation of the round trip time RTT, the packet loss rate, the Describe the retransmission rate and the actual transmission rate of the current network.
- the first adjustment module 58 includes:
- Determination sub-module configured to determine the minimum packet sending rate and the maximum packet sending rate based on the code rate information
- the first adjustment sub-module is configured to adjust the current growth coefficient according to at least one of the changes in the RTT, the packet loss rate, the retransmission rate and the actual transmission rate of the current network, to obtain the adjusted growth rate. speed coefficient;
- the second adjustment sub-module is configured to adjust the current packet issuance rate according to the adjusted speed increase coefficient to obtain the adjusted packet issuance rate.
- the first adjustment sub-module is further configured to perform a weighted calculation of the current speed increase coefficient based on at least one of the change in the RTT, the packet loss rate, and the retransmission rate, The adjusted growth rate coefficient is obtained, wherein the initial growth rate coefficient is a preset reference weighting coefficient value, wherein the base weighting coefficient value is used to control how quickly the outsourcing rate increases.
- the second adjustment sub-module is further configured to determine the product of the adjusted speed increase coefficient and the current packet issuance rate; and determine the product as the adjusted packet issuance rate.
- the device further includes:
- the determination module is configured to use the preset transmission rate as the code rate information if the data type is non-video data.
- the device further includes:
- the second adjustment module is configured to adjust the sender window and the receiver window of the TCP protocol stack according to the initial packet sending rate.
- the second adjustment module is further configured to calculate the size of the receiving window required for data sent within an RTT based on the initial packet sending rate; if the receiving window is smaller than the receiving window size, the The receiving end window is adjusted to the size of the receiving end window; the sending end window is adjusted to be no less than the size of the receiving end window.
- Embodiments of the present disclosure also provide a computer-readable storage medium that stores a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.
- the computer-readable storage medium may include but is not limited to: U disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM) , mobile hard disk, magnetic disk or optical disk and other media that can store computer programs.
- ROM read-only memory
- RAM random access memory
- mobile hard disk magnetic disk or optical disk and other media that can store computer programs.
- Embodiments of the present disclosure also provide an electronic device, including a memory and a processor.
- a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
- the above-mentioned electronic device may further include a transmission device and an input-output device, wherein the transmission device is connected to the above-mentioned processor, and the input-output device is connected to the above-mentioned processor.
- modules or steps of the present disclosure can be implemented using general-purpose computing devices, and they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices.
- they can be implemented using program codes executable by a computing device, and thus they can be stored in a storage device and used by the computing device.
- apparatus, and in some cases, the steps shown or described may be performed in an order different from that herein, or be made separately into individual integrated circuit modules, or be made into multiple modules or steps within them implemented as a single integrated circuit module.
- the present disclosure is not limited to any specific combination of hardware and software.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本公开实施例提供了一种数据传输处理方法、装置、存储介质及电子装置,该方法包括:确定待传输数据的数据类型;若该数据类型为视频文件,获取待传输数据的码率信息;获取当前网络状况;根据该当前网络状况与该码率信息调整当前发包速率,得到调整后的发包速率;根据该调整后的发包速率传输该待传输数据,可以解决相关技术中通用TCP拥塞控制算法在大流量环境下导致的大量丢包和重传率居高,引起视频业务卡顿的问题,对于视频文件,基于码率新与当前网络状况调整发包速率,提升了TCP传输效率,提高了用户观看视频的体验度。
Description
相关申请的交叉引用
本公开基于2022年06月29日提交的发明名称为“一种数据传输处理方法、装置、存储介质及电子装置”的中国专利申请CN202210765155.9,并且要求该专利申请的优先权,通过引用将其所公开的内容全部并入本公开。
本公开实施例涉及通信领域,具体而言,涉及一种数据传输处理方法、装置、存储介质及电子装置。
随着互联网的快速发展,短视频的兴起,视频流量在互联网中的占比越来越大,而这些视频流量绝大部分还是通过Linux系统的传输控制协议(Transmission Control Protocol,简称为TCP协议)在传输。相关技术中,TCP拥塞控制算法都是以尽量用完网络带宽为终极目标,而不管是测试时延或是测试带宽,都存在测不准的问题,特别是对于共享的网络,其测不准的程度更高,在业务高峰期,这就会导致大量超过网络能力的数据包进入网络,导致更多的丢包发生,丢包产生后导致重传率上升,传输利用率进一步下降,很难适应当前视频类业务数据的传输。
针对相关技术中相关技术中通用TCP拥塞控制算法在大流量环境下导致的大量丢包和重传率居高,引起视频业务卡顿的问题,尚未提出解决方案。
发明内容
本公开实施例提供了一种数据传输处理方法、装置、存储介质及电子装置,以至少解决相关技术中通用TCP拥塞控制算法在大流量环境下导致的大量丢包和重传率居高,引起视频业务卡顿的问题。
根据本公开的一个实施例,提供了一种数据传输处理方法,所述方法包括:
确定待传输数据的数据类型;
若所述数据类型为视频文件,获取所述待传输数据的码率信息;
获取当前网络状况;
根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率;
根据所述调整后的发包速率传输所述待传输数据。
根据本公开的另一个实施例,还提供了一种数据传输处理装置,所述装置包括:
确定模块,设置为确定待传输数据的数据类型;
第一获取模块,设置为若所述数据类型为视频文件,获取所述待传输数据的码率信息;
第二获取模块,设置为获取当前网络状况;
第一调整模块,设置为根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率;
传输模块,设置为根据所述调整后的发包速率传输所述待传输数据。
根据本公开的又一个实施例,还提供了一种计算机可读的存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例,还提供了一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
图1是本公开实施例的数据传输处理方法的计算机设备的硬件结构框图;
图2是根据本公开实施例的数据传输处理方法的流程图;
图3是根据本公开实施例的调整发包速率的流程图;
图4是根据本实施例的Linux操作系统的框图三;
图5是根据本公开实施例的数据传输处理装置的框图。
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
本公开实施例中所提供的方法实施例可以在计算机设备或者类似的运算装置中执行。以运行在CDN服务器设备上为例,图1是本公开实施例的数据传输处理方法的CDN服务器设备的硬件结构框图,如图1所示,CDN服务器设备可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104,其中,上述CDN服务器设备还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述CDN服务器设备的结构造成限定。例如,CDN服务器设备还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
存储器104可用于存储计算机程序,例如,应用软件的软件程序以及模块,如本公开实施例中的数据传输处理方法对应的计算机程序,处理器102通过运行存储在存储器104内的计算机程序,从而执行各种功能应用以及业务链地址池切片处理,即实现上述的方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至CDN服务器设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括CDN服务器设备的通信供应商提供的无线网络。在一个实例中,传输设备106包括一个网络适配器(Network Interface Controller,简称为NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输设备106可以为射频(Radio Frequency,简称为RF)模块,其用于通过无线方式与互联网进行通讯。
TCP拥塞控制算法大体上分为三类:
基于路径时延来回时间(round Trip Time,简称为RTT),将RTT升高作为发生拥塞的信号,在复杂网络环境下,RTT变化频繁,带宽容易被抢占,利用率低。
基于丢包(比如Cubic),将丢包作为发生拥塞的信号,其逻辑是路由器、交换机的缓存都是有限的,拥塞会导致缓存用尽,进而队列中的一些报文会被丢弃,拥塞会导致丢包,但是丢包不一定是拥塞导致的,因此这种拥塞算法容易被噪声干扰,在高丢包率高延迟的环境下带宽利用率很低,而现在的网络环境绝大部分是WiFi,4G/5G信号,在无线环境中噪声丢包的比率很大。
基于带宽时延探测(比如BBR),既然无法区分拥塞丢包和噪声丢包,瓶颈带宽和往返(bottleneck bandwidth and round-trip,简称为BBR)就不以丢包作为拥塞信号,而是通过探测最大带宽和最小路径时延来确定路径的带宽容量。这样抗丢包能力和带宽利用率比前两种拥塞控制算法高。
在所有的TCP拥塞算法中,其数据传输都受到发送窗口和接收窗口的控制,一次性发送的数据量不能超过两个窗口的最小值,其余的数据必须等到接收应答回来后才能继续发送,而这个限制导致TCP数据传输起步较慢,进而让视频起播时间较长,影响用户的观看体验。
在本实施例中提供了一种运行于上述网络架构的数据传输处理方法,图2是根据本公开实施例的数据传输处理方法的流程图,如图2所示,该流程包括如下步骤:
步骤S202,确定待传输数据的数据类型;
步骤S204,若数据类型为视频文件,获取待传输数据的码率信息;
步骤S206,获取当前网络状况;
步骤S208,根据当前网络状况与码率信息调整当前发包速率,得到调整后的发包速率;
本实施例的中当前发包速率是周期性获取的,为了更好的评估当前的网络带宽,测速采用周期性(此测速周期可通过参数的方式进行动态设置)获取已被对端确认的数据包(比如采集的对端ack序号做差值运算获得),计算出当前周期的传输速率,并对前几个周期(次数可设置,运算采用的平滑系数可设置)测速的结果作平滑计算,来作为当前发包速率。
步骤S210,根据调整后的发包速率传输待传输数据。
通过上述步骤S202至S210,可以解决相关技术中通用TCP拥塞控制算法在大流量环境下导致的大量丢包和重传率居高,引起视频业务卡顿的问题,对于视频文件,基于码率新与当前网络状况调整发包速率,提升了TCP传输效率,提高了用户观看视频的体验度。
本实施例中,对于非视频数据,即上述数据类型为非视频数据,将预设的传输速率作为码率信息,之后获取当前网络状况,根据当前网络状况与码率信息调整当前发包速率,得到调整后的发包速率,根据调整后的发包速率传输待传输数据。
本实施例中当前网络状况包括以下至少之一:RTT的变换情况、丢包率、重传率以及当前网络的实际传输速率,上述步骤S204中,获取当前网络状况在传输过程中周期性获取,具体可以包括:以预设周期获取TCP协议栈中的往返时间(Round Trip Time,简称为RTT)的变换情况和/或当前网络的实际传输速率;和/或,并获取TCP协议栈中的总发包数、总丢包数、总重传数,根据总发包数、总丢包数以及总重传数确定当前采样周期内的丢包率和重传率。
本实施例的系统具备RTT、丢包率和重传率监测功能,是为了获得当前网络状况,具体
包括延迟的变化,阻塞的变化情况,这个数据也是周期性采样,获取TCP协议栈中的RTT数值,总发包数,总丢包数和总重传数,计算出当前采样周期内的丢包率和重传率。
图3是根据本公开实施例的调整发包速率的流程图,如图3所示,根据当前网络状况与码率信息调整当前发包速率包括如下步骤:
步骤S302,根据码率信息确定最小发包速率与最大发包速率;
步骤S304,根据RTT的变化情况、丢包率、重传率以及当前网络的实际传输速率至少之一调整当前增速系数,得到调整后的增速系数;
上述步骤S304具体可以包括:根据RTT的变化情况、丢包率、重传率至少之一对当前增速系数进行加权计算,得到调整后的增速系数,其中,初始的增速系数为预设的基准加权系数值,该基准加权系数值用于控制发包速率增长的快慢程度。
步骤S306,根据调整后的增速系数调整当前发包速率,得到调整后的发包速率。
上述步骤S306具体可以包括:确定调整后的增速系数与当前发包速率的乘积,将乘积确定为调整后的发包速率。
发包速率计算,是综合码率信息,采用周期性测速得到的当前传输速率(即当前发包速率),RTT,丢包率和重传率的情况,来计算出每个周期最佳传送速率,达到智能调节,更加优化网络的目的,具体包括:视频播放业务启动的时候,起始发包速率根据业务设置的起始发包速率v0执行,并且根据发包速率适当按需调整TCP链路的发送窗口和接收窗口,以便加快起播速率。同时启动周期测试;获取基准加权系数值α(通常设置为大于等于1),这个值用来控制发包速率增长的快慢程度。查看当前发包周期的RTT变化情况、丢包率、重传率,分别按照相关的权重系数,对基准加权系数值α做相应的加权计算,获得加权计算后的增速系数β。将当前发包速率*β得到下一个周期的发包速率,起始阶段当前发包速率即为起始发包速率v0,调整控制v在业务设置的最大发包速率和最小发包速率内,这样,下一个发包周期就按照v发包速率来发包;在每一个时间周期的开始,获取前一个周期的实际传输速率,和网络状况,来计算出当前周期的发包速率,在第一个周期开始,实际传输速率使用预设的起始传输速率。
需要注意的是,本实施例采用了的以上基准加权系数值α,对应RTT、丢包率和冲出率相关的计算权重系数都是可以动态调整的,比如可以业务设置和人工调整,或是通过机器学习、算力网络的方式来自动调整。
基于上述步骤S302至S306得到的发包速率传输视频文件,可以在业务高峰期大大降低网络的拥塞程度,减少网络丢包,提升网络的传输效率,减少用户观看视频的卡顿率。
在一实施例中,在初始状态下,确定起始发包速率为预先设置的发包速率。为了确保视频起播时的传输速率,提升视频秒开率,还可以根据起始发包速率调整TCP协议栈的发送端窗口和接收端窗口。具体的,根据起始发包速率计算一个RTT内所发数据需要的接收窗口的大小;如果接收端窗口小于所述接收窗口大小,将接收端窗口调整为接收窗口的大小;将所述发送端窗口调整为不小于所述接收端窗口的大小,提高TCP传输启动速率,减少视频流的起播时间,提高用户观看视频的体验度。
在收到TCP协议接收端的ack时,对端会带来它的接收窗口的大小,特别是在TCP链路启动时期,对端的接收窗口通常比较小,影响了启动时的发包速率,在延时比较高的链路,影响更大,因为下一次的数据发送需要等到接收端的ack确认有了接收窗口才行,而这个确
认需要等待几十ms甚至上百ms,所以TCP链路启动时通常是发了几十K的数据,然后等上几十甚至上百ms,再发送稍微多一点的数据(收到ack时接收端的窗口可能扩大了,但经常还是不能容纳全部的发送数据),再等待几十ms;导致TCP链路的发包速率提升较慢。在本发明中,会根据业务设置的起始发包速率,计算出一个RTT内所发数据需要的接收窗口大小,如果接收端带来的窗口小于计算出来的值,就会调整TCP协议中的接收窗口大小为计算出来的值,同理发送端的发送窗口会调整为不小于对端的接收窗口。这样可以保证在TCP启动时期,就可以用业务设置的起始发包速率恒定发送数据,达到启动时快速传输的目的,从而减少视频的起播时间。
本实施例是基于Linux操作系统,不需要自己全部实现拥塞控制的功能,只是在必要的地方改变原bbr算法的控制逻辑,改变原拥塞控制算法的发包行为,以达到减少网络拥塞,降低发包重传,提升TCP传输启动时间的目标。运行在Linux内核空间,负责对TCP拥塞算法的控制,提高TCP传输利用率和启动时间。运行TCP_bbr拥塞算法之上,通过修改TCP_bbr的实现函数,来改变拥塞算法的行为,实现传输性能的提升。图4是根据本实施例的Linux操作系统的框图,如图4所示,包括用户态发包模块42、bbr_cdn模块44以及发送模块46。
用户态发包模块42除了发包,还负责判断传输的数据类型(其中判断的方法本发明不做限定),目前主要分为两类(普通数据类和视频数据类,不排除增加类别的可能性,这样利用bbr_cdn模块44可以针对不同的业务类数据做出更精细的拥塞控制算法),对于视频数据类,获得视频的码率信息(如最小码率,最大码率,平均码率等),并将这些业务信息通过新增加的套接字接口传递给bbr_cdn模块44。
bbr_cdn模块44,它利用用户态发包模块42带来的业务信息,结合持续监测得到的TCP协议发包产生的RTT、丢包和重传率数据(这些数据从普通TCP协议实现中通过加工获得),来计算出本条TCP链路需要用多大的速率去进行发送,并将这个计算出来的速率信息告诉发送模块46,让发送模块46按这个速率均匀的发送TCP数据包;其次,bbr_cdn模块44通过调整TCP协议的发送端窗口和接收端窗口,来提升TCP协议发包的启动速率。
发送模块46:Fq是linux系统的一种公平队列报文调度器,发送模块46是通过pacing的方式发送数据流,pacing是指公平队列(fair queuing scheduler,简称为Fq)能用一定的发送节奏发送一个数据流,这样数据就能够按设定的速率均匀的进入网络,Fq是Linux网络协议栈中一种发包排队规则。
bbr_cdn模块44可细分为以下功能:bbr_cdn模块44充分利用Linux系统TCP协议栈中原有TCP_bbr拥塞算法的功能,不重复造轮子,通过改变原有拥塞算法的控制流程,来实现即可。
与用户态发包模块42的接口连接,用来接收用户态发送数据流的业务分类信息,以便于更精细化的控制TCP链路的发包行为,没有此接口,bbr_cdn模块44也能够通过其它方式来推断出数据流的类型(通过分析发包接口传下来的数据,获取视频文件的一些特征值,比如TS文件是一个个188字节的数据块,H.264有明显的数据头,没有明显特征的归为数据类,获得特征后,就能继续分析得到其中的一些码率信息),来达到同样的目的,但是没有业务模块直接告知来的精确。
测速功能,通过获取每100ms(此时间可以通过参数设置)TCP链路实际发送了多少字节的数据包,并通过平滑处理(平滑计算窗口可设置,平滑系数可设置),得到TCP链路当前
的实际发包速率。
RTT和丢包率,重传率监测功能,TCP协议中每收到一次TCP的确认报文就会计算一次RTT,并会统计总共的发包计数,丢包计数和重传计数,但是在本发明中需要监控当前时间的RTT变化,单位时间的丢包率和单位时间的重传率,这样可以更精确的得到当前网络的实际拥塞状况,因此本发明会每隔100ms采样当前的RTT和各种计数,来计算出本100ms的RTT和丢包率和重传率。
窗口调节功能,当前所有的TCP协议拥塞控制的实现,都是使用的慢启动过程,这是通过控制发送端窗口和接收端窗口实现的,慢启动可以有效的防止网络拥塞,但也减慢了TCP传输的启动速率,增加了视频播放的起播时间,结合本发明的业务数据限速功能,可以放大窗口,使TCP起始发包速率加快,但是并不会影响网络的拥塞。
发包速率计算,这个功能模块综合考虑业务信息,当前的测速信息,RTT变化和丢包率,重传率的情况,计算出一个适合当前网络传输的速率。
bbr_cdn模块44是Linux系统的一个内核模块,它建立在TCP_bbr模块和公平队列Fq的pacing功能基础之上,通过替换或修改TCP_bbr的主要控制流程,来达到减少网络拥塞,降低视频卡顿率,加快视频起播速率,提升用户观看体验的目的。
当前所有的TCP协议拥塞控制算法,其本质都是想尽力用网络的最大带宽去传送数据,这种实现对于传输一般的数据文件比较友好,可以减少数据文件的传输时间,但是在业务高峰期,也更容易引起网络拥塞,丢包重传的现象。对于用户观看视频,在传输视频文件时并不需要以最大的带宽去发送,视频文件都是有码率信息的,码率越大,需要传输的越快,但是只要传输的速率跟码率持平或略高,就可以满足用户的观看需求。当前在传输视频文件时,会以很快的速率的发送完内容,播放器端存储文件,然后用户慢慢观看,看完了一个文件,再请求下一个文件,重复这个过程。这种方式,从网络的角度来看,像是一个个的脉冲,脉冲越高,网络流量就越大,会导致拥塞,丢包和重传的现象,没脉冲时网络完全空闲,非常浪费,如果将脉冲的高度压低,将之变宽,甚至让网络没有空闲的时间,这样网络的流量就会平均分摊下来,在每一个时间段网络流量都不会达到或超过网络的最大带宽,从而极大的降低网络的拥塞状况,减少丢包,降低重传。而视频的码率信息也让TCP拥塞控制算法可以更精确的控制视频文件的发包速率,达到充分利用网络时间,减少网络拥塞。
在这个基础上,通过提高TCP协议栈的发送端窗口和接收端窗口,可以加快TCP传输启动速率,而不会引入网络拥塞的风险。
根据本公开的另一个实施例,还提供了一种数据传输处理装置,图5是根据本公开实施例的数据传输处理装置的框图,如图5所示,所述装置包括:
确定模块52,设置为确定待传输数据的数据类型;
第一获取模块54,设置为若所述数据类型为视频文件,获取所述待传输数据的码率信息;第二获取模块56,设置为获取当前网络状况;
第一调整模块58,设置为根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率;
传输模块510,设置为根据所述调整后的发包速率传输所述待传输数据。
在一实施例中,所述第一获取模块54,还设置为以预设周期获取TCP协议栈中的RTT的
变换情况和/或当前网络的实际传输速率;和/或,并获取TCP协议栈中的总发包数、总丢包数、总重传数,根据所述总发包数、所述总丢包数以及所述总重传数确定当前采样周期内的丢包率和重传率,其中,所述当前网络状况包括以下至少之一:所述往返时间RTT的变换情况、所述丢包率、所述重传率以及当前网络的实际传输速率。
在一实施例中,所述第一调整模块58包括:
确定子模块,设置为根据所述码率信息确定最小发包速率与最大发包速率;
第一调整子模块,设置为根据所述RTT的变化情况、所述丢包率、所述重传率以及所述当前网络的实际传输速率至少之一调整当前增速系数,得到调整后的增速系数;
第二调整子模块,设置为根据所述调整后的增速系数调整所述当前发包速率,得到所述调整后的发包速率。
在一实施例中,所述第一调整子模块,还设置为根据所述RTT的变化情况、所述丢包率、所述重传率至少之一对所述当前增速系数进行加权计算,得到所述调整后的增速系数,其中,初始的增速系数为预设的基准加权系数值,其中,所述基准加权系数值用于控制发包速率增长的快慢程度。
在一实施例中,所述第二调整子模块,还设置为确定所述调整后的增速系数与所述当前发包速率的乘积;将所述乘积确定为所述调整后的发包速率。
在一实施例中,所述装置还包括:
确定模块,设置为若所述数据类型为非视频数据,将预设的传输速率作为码率信息。
在一实施例中,所述装置还包括:
第二调整模块,设置为根据所述起始发包速率调整TCP协议栈的发送端窗口和接收端窗口。
在一实施例中,所述第二调整模块,还设置为根据起始发包速率计算一个RTT内所发数据需要的接收窗口的大小;如果接收端窗口小于所述接收窗口大小,将所述接收端窗口调整为所述接收窗口的大小;将所述发送端窗口调整为不小于所述接收端窗口的大小。
本公开的实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,其中,该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述计算机可读存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置,包括存储器和处理器,该存储器中存储有计算机程序,该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述电子装置还可以包括传输设备以及输入输出设备,其中,该传输设备和上述处理器连接,该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例,本实施例在此不再赘述。
显然,本领域的技术人员应该明白,上述的本公开的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算
装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本公开不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的优选实施例而已,并不用于限制本公开,对于本领域的技术人员来说,本公开可以有各种更改和变化。凡在本公开的原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。
Claims (10)
- 一种数据传输处理方法,所述方法包括:确定待传输数据的数据类型;若所述数据类型为视频文件,获取所述待传输数据的码率信息;获取当前网络状况;根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率;根据所述调整后的发包速率传输所述待传输数据。
- 根据权利要求1所述的方法,其中,所述获取当前网络状况包括:以预设周期获取传输控制协议TCP协议栈中的往返时间RTT的变换情况和/或当前网络的实际传输速率;和/或以预设周期获取TCP协议栈中的总发包数、总丢包数、总重传数,并根据所述总发包数、所述总丢包数以及所述总重传数确定当前采样周期内的丢包率和重传率,其中,所述当前网络状况包括以下至少之一:所述RTT的变换情况、所述丢包率、所述重传率以及所述当前网络的实际传输速率。
- 根据权利要求2所述的方法,其中,根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率包括:根据所述码率信息确定最小发包速率与最大发包速率;根据所述RTT的变化情况、所述丢包率、所述重传率以及所述当前网络的实际传输速率至少之一调整当前增速系数,得到调整后的增速系数;根据所述调整后的增速系数调整所述当前发包速率,得到所述调整后的发包速率。
- 根据权利要求3所述的方法,其中,根据所述RTT的变化情况、所述丢包率、所述重传率至少之一调整增速系数,得到调整后的增速系数包括:根据所述RTT的变化情况、所述丢包率、所述重传率至少之一对所述当前增速系数进行加权计算,得到所述调整后的增速系数,其中,初始的增速系数为预设的基准加权系数值,其中,所述基准加权系数值用于控制发包速率增长的快慢程度。
- 根据权利要求3所述的方法,其中,根据所述调整后的增速系数调整所述当前发包速率,得到所述调整后的发包速率包括:确定所述调整后的增速系数与所述当前发包速率的乘积;将所述当前发包速率的乘积确定为所述调整后的发包速率。
- 根据权利要求1至5中任一项所述的方法,其中,所述方法还包括:若所述数据类型为非视频数据,将预设的传输速率作为码率信息。
- 根据权利要求1至5中任一项所述的方法,其中,所述方法还包括:根据起始发包速率计算一个RTT内所发数据需要的接收窗口的大小;如果接收端窗口小于所述接收窗口大小,将所述接收端窗口调整为所述接收窗口的大小;将所述发送端窗口调整为不小于所述接收端窗口的大小。
- 一种数据传输处理装置,所述装置包括:确定模块,设置为确定待传输数据的数据类型;第一获取模块,设置为若所述数据类型为视频文件,获取所述待传输数据的码率信息;第二获取模块,设置为获取当前网络状况;第一调整模块,设置为根据所述当前网络状况与所述码率信息调整当前发包速率,得到调整后的发包速率;传输模块,设置为根据所述调整后的发包速率传输所述待传输数据。
- 一种计算机可读的存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求1至7任一项中所述的方法。
- 一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述权利要求1至7任一项中所述的方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210765155.9 | 2022-06-29 | ||
CN202210765155.9A CN117354252A (zh) | 2022-06-29 | 2022-06-29 | 一种数据传输处理方法、装置、存储介质及电子装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2024001763A1 true WO2024001763A1 (zh) | 2024-01-04 |
Family
ID=89367934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2023/100013 WO2024001763A1 (zh) | 2022-06-29 | 2023-06-13 | 一种数据传输处理方法、装置、存储介质及电子装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN117354252A (zh) |
WO (1) | WO2024001763A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117692396B (zh) * | 2024-02-04 | 2024-04-26 | 湖南国科亿存信息科技有限公司 | 一种复杂网络环境下的tcp单边加速方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1655547A (zh) * | 2004-09-09 | 2005-08-17 | 上海川海信息科技有限公司 | 一种流媒体传输系统中的速率控制方法 |
GB2539335A (en) * | 2014-04-03 | 2016-12-14 | Orbital Multi Media Holdings Corp | Data flow control method and system |
US20180123959A1 (en) * | 2016-10-28 | 2018-05-03 | Level 3 Communications, Llc | Systems and methods for adjusting a congestion window value of a content delivery network |
CN110247853A (zh) * | 2018-03-09 | 2019-09-17 | 网宿科技股份有限公司 | Tcp拥塞控制方法、系统、存储介质及网络服务器 |
WO2021114807A1 (zh) * | 2019-12-11 | 2021-06-17 | 华为技术有限公司 | 一种传输速率配置方法及装置 |
CN113242183A (zh) * | 2021-05-20 | 2021-08-10 | 惠州Tcl移动通信有限公司 | 一种数据流发送控制方法、装置、智能终端及存储介质 |
-
2022
- 2022-06-29 CN CN202210765155.9A patent/CN117354252A/zh active Pending
-
2023
- 2023-06-13 WO PCT/CN2023/100013 patent/WO2024001763A1/zh unknown
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1655547A (zh) * | 2004-09-09 | 2005-08-17 | 上海川海信息科技有限公司 | 一种流媒体传输系统中的速率控制方法 |
GB2539335A (en) * | 2014-04-03 | 2016-12-14 | Orbital Multi Media Holdings Corp | Data flow control method and system |
US20180123959A1 (en) * | 2016-10-28 | 2018-05-03 | Level 3 Communications, Llc | Systems and methods for adjusting a congestion window value of a content delivery network |
CN110247853A (zh) * | 2018-03-09 | 2019-09-17 | 网宿科技股份有限公司 | Tcp拥塞控制方法、系统、存储介质及网络服务器 |
WO2021114807A1 (zh) * | 2019-12-11 | 2021-06-17 | 华为技术有限公司 | 一种传输速率配置方法及装置 |
CN113242183A (zh) * | 2021-05-20 | 2021-08-10 | 惠州Tcl移动通信有限公司 | 一种数据流发送控制方法、装置、智能终端及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN117354252A (zh) | 2024-01-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11876714B2 (en) | Method and apparatus for network congestion control based on transmission rate gradients | |
CN102468941B (zh) | 网络丢包处理方法及装置 | |
US7643420B2 (en) | Method and system for transmission control protocol (TCP) traffic smoothing | |
US7656800B2 (en) | Transmission control protocol (TCP) | |
EP3332519B1 (en) | Data packet network | |
US7787379B2 (en) | Integrated flow control | |
WO2024001763A1 (zh) | 一种数据传输处理方法、装置、存储介质及电子装置 | |
KR101981722B1 (ko) | 처리율과 패킷 손실에 기반하여 cwnd를 제어하는 최적화 방법과 시스템 | |
US20080291833A1 (en) | Method for buffer control for network device | |
US9432296B2 (en) | Systems and methods for initializing packet transfers | |
EP3332522B1 (en) | Data packet network | |
CN116566919A (zh) | 带宽探测方法、装置、电子设备及存储介质 | |
CN110290552B (zh) | 缓存深度的测量方法和装置、存储介质、电子装置 | |
CN110381036A (zh) | 一种用于dash流媒体的tcp拥塞控制方法 | |
GB2577610A (en) | Improved congestion response | |
Hisamatsu et al. | Non bandwidth-intrusive video streaming over TCP | |
US11438275B2 (en) | Congestion response | |
Peng et al. | Fast backward congestion notification mechanism for TCP congestion control | |
Li et al. | Upload Your Data Faster: Driver-Queue based Congestion Control for Wireless Networks | |
Pötsch et al. | The Verus Protocol | |
GB2541016A (en) | Data packet network | |
GB2541019A (en) | Data packet network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 23829946 Country of ref document: EP Kind code of ref document: A1 |