With the rapid development of computer networks, real-time audio and video services have been widely used. The webrtc protocol stack is one of the most advanced solutions. This solution solves the problems of network penetration, delay, jitter and packet loss. The payload relay scheme of webrtc plays an important role in webrtc. Today, from the perspective of turn implementation, I will briefly describe some places in turn rfc that are easily overlooked.
1. Multi-layer namespace
According to the rfc suggestion, turn marks each client session with a 5-tuple, a single node is a realm, and each node allocates a port for the client between 49152 and 65535, so in this case, each node can only allocate 16383 port.
Node/Realm(Local)/Port(49152 - 65535)
In the scenario of a large-scale video meeting, each client needs to allocate ports for all peers in the current room. At this time, it is easy to run out of port numbers. In the final analysis, I think it is because rfc design did not consider turning large-scale For cluster problems, it is very important to introduce multi-layer namespace division at this time. Each session is bound to a group id. If the group id is U32, U32::MAX * 16383 ports can be allocated under a single realm.
Node/Realm(Local)/Group(Number)/Port(49152 - 65535)
2. Internal address mapping table
In the turn protocol, the client sends an AllocateRequest requesting the turn server to allocate a port. Currently, some turn servers (such as Janus) implement direct allocation of real UDP ports. The advantage of this method is that it is simple to implement, but the problem is that the host will There are a large number of open udp ports, which is a nightmare for security and system operation and maintenance. In fact, there is another solution here. Only a single port can be allocated to correctly handle the payload reflect and relay of all sessions, and the turn server is only open to the outside world. A real udp port, the allocate port of each session is stored in the port alloc table (HashMap) inside the server, the mapping relationship can be used to record the binding relationship between peer sessions through the subsequent CreatePermissionRequest, so that it does not need to consume the port of the physical machine, a single A physical machine can host multiple server instances:
base: HashMap<SocketAddr, Node>
peers: HashMap<Group, (Port, Port)>3. Multi-thread optimization
Modern computer systems generally adopt multi-core architecture, and network programming also widely uses multi-threaded processing net handle to improve performance and system utilization, but udp is different from tcp, because udp uses syscall to ensure the security of multi-threaded calls, and is controlled by atomic The problem of competition for reading and writing, udp handle can not afford lock-free reading and writing in multiple threads, but at the same time, because of the existence of syscall, multi-threaded reading and writing may not improve the throughput efficiency of udp, multi-threaded processing udp handle It may not bring significant performance improvement, but because the actual business needs to process udp payload, my opinion is to use cpu core number to create a thread pool. Too many threads will bring more serious burden due to thread switching and wake-up .
4. Seamless switching across network segments
Nowadays, the development of mobile terminals is changing with each passing day. The proportion of mobile devices in the entire Internet is increasing, and the network environment is becoming more and more severe. Mobile terminals often have cross-network segments, lost network connections, etc., and packet loss and IP address changes are commonplace. In this case, when the network segment is switched, the client needs to re-register and allocate a session port because of the change of the IP address. This is unacceptable in real-time audio and video calls. In severe cases, the call may be interrupted. How to maintain a smooth network connection in the case of frequent switching network environments becomes very important.
When cross-network occurs, the client socketaddr changes, because turn relies on 5-tuples to record session information, and the new network packet will be rejected by the turn server as an unregistered session packet. At this time, it is necessary to change the 5-element in rfc Group definition, the unique id should be switched from socketaddr to other information that has nothing to do with the network address, such as using the username of the client session authorize as the unique id, when cross-network occurs, the username will not change, and the peer-to-peer mapping relationship can be maintained normally .
However, there are certain security issues in this implementation. When the session sends data packets with a new socketaddr address, the new address is refreshed by changing the address information in the internal registry. The solution to this problem is also very simple, but it needs to be changed. Client implementation, when the client is cross-network, the next data packet is sent to the server with username and message integrity, and the server verifies the validity of the session information, and then refreshes the internal address table after verifying that it is the same user, so as to prevent the middleman from forging information refresh Drop the normal peer-to-peer session.
Client TURN Server
192.168.1.1:8080 -----------------------------------------> Handler Payload
192.168.3.1:8080(Change) --{Username, MessageIntegrity}---> Assert MessageIntegrity
192.168.3.1:8080 -----------------------------------------> Handler Payloadsummary
The author found the above problems and improvement plans when implementing the TURN server by himself. If there are problems in some parts, please point out the problems and discuss them together. Finally, welcome to star my project
★The business card at the end of the article can receive audio and video development learning materials for free, including (FFmpeg, webRTC, rtmp, hls, rtsp, ffplay, srs) and audio and video learning roadmaps, etc.
see below!