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

The hottest function in the current kernel is copy_user_enhanced_fast_string, which mainly copies user space data to the kernel. It can be inferred that this is because the payload of the UDP being sent needs to be copied to the kernel for transmission.

Similarly, TCP is also a bottleneck in this case. In fact, the Linux kernel supports various zero-copy methods, such as sendfile, splice, tee, and MSG_ZEROCOPY. You can find more information about MSG_ZEROCOPY here.

It mentions that there is a cost associated with it, but if a large amount of data needs to be sent, then it is worth considering.

Copy avoidance is not a free lunch. As implemented, with page pinning, it replaces 
per byte copy cost with page accounting and completion notification overhead. As a 
result, MSG_ZEROCOPY is generally only effective at writes over around 10 KB.

If using sendmmsg, for a 600Kbps bitrate stream, when one connection is watching, 50KB of data is sent at once. When 1000 connections are watching, 8.5MB of data is sent at once. When 2000 connections are watching, 14.4MB of data is sent at once. When 3000 connections are watching, 20MB of data is sent at once.

This may require modifying ST to provide support. Please refer to: ossrs/state-threads#13

It was found through actual tests that UDP ZeroCopy is only supported from Kernel 5.0 onwards, and it is currently not mature enough and does not offer any advantages when compared.

TRANS_BY_GPT3