candidate is the address that RTC provides services to the outside. In certain deployment scenarios, we need to configure it in multiple ways.

This is also the only item that RTC must confirm the configuration for, while others can be left at their default settings.

For detailed configuration instructions, please refer to: https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#config-candidate

TRANS_BY_GPT3

Linux GSO can delay the segmentation of multiple UDP packets to improve performance, refer to UDP GSO principle and application.

Note: Linux kernel 4.18.0 and above support GSO. SRS will automatically detect the kernel version. The packets below are captured with GSO enabled and appear the same as when GSO is disabled. As shown in the packet capture below.

rtc-plaintext-linux4-gso-ok.pcapng.zip

rtc-plaintext-multiple-slices-as-one-NALU.pcapng.zip

Note: If GSO is forcibly enabled on a lower version of the kernel, there may be unexpected behavior, as shown in the packet capture below.

rtc-plaintext-linux3-gso-invalid.pcapng.zip

SRS has added an API for packet performance analysis: http://localhost:1985/api/v1/perf.

You can use the tool to analyze it: ./scripts/perf_gso.py http://localhost:1985/api/v1/perf.

No GSO, Fragment at Source

Without turning on GSO, when receiving packets from the source, the messages are divided into RTP packets, and the statistics are as follows:

Note: It can be seen that the number of RTP packets is 1.6 times higher than RTMP. If each packet has to be processed by the kernel, it will have a significant impact on performance.

No GSO, Fragment at Connection

Without enabling GSO, when sending packets (Connection), the messages are divided into RTP packets. The statistics are as follows:

Note: As you can see, it is similar to the previous one. The packet distribution has little impact on the Source and Connection.

GSO, Fragment at Connection

When GSO is enabled, the messages are divided into RTP packets during packet transmission (Connection), and the statistical data is as follows:

Note: It can be seen that after enabling GSO, the number of packets passing through the kernel is fewer than RTMP, and performance is improved. In reality, GSO does not reduce the number of RTP packets, but it can reduce the packets passing through the kernel, so we consider the number of packets to be less.

GSO, Larger FU-Payload

Previously, the length of FU Payload was 1200, and it was changed to 1300, referring to bfc70d64 and b91e07f4.

After the modification, the maximum size of IP packets is 1356 bytes, which is smaller than the 1500 bytes MTU. From the results, it can be seen that the RTP packet size has decreased from 1.56 times to 1.49 times, and the GSO fragmentation is not affected.

GSO, Padding Packets

There are usually more audio packets, and sometimes the difference is not significant. For example, there are three packets: 257 256 255. If some padding can be added, then they can be sent as a single GSO packet, referring to c95a8517.

From a data perspective, by enabling padding (127), you can lower the GSO packet multiplier from 0.74 to 0.67, and improve the efficiency from 0.67 to 0.74.

Note: Enabling padding does not significantly increase the payload. It is at the level of one in ten million (N), as padding is only added to packets when GSO is enabled.

Note: Padding is part of the RTP standard protocol, as referred in RTP Fixed Header Fields. Padding may be necessary for encryption algorithms with fixed block sizes or for transmitting multiple RTP packets in a lower-layer protocol data.

TRANS_BY_GPT3