TURN Server - Everything You Need To Know (2024)

November 10, 20234 min read

Link copied

Definition

A TURN (Traversal Using Relays around NAT) server is a network entity used to facilitate communication between two devices or clients located behind Network Address Translation (NAT) systems or firewalls. The TURN server acts as a relay for network traffic, allowing devices that may not be able to establish a direct connection due to NAT or firewall restrictions to communicate with each other. Rerouting traffic through the TURN server ensures that data can be exchanged even in complex network environments where peer-to-peer communication would otherwise be impossible.

What does it mean?

Imagine you're in a busy café trying to talk to your friend across the room. Your first attempt to wave or use a mirror to reflect light to catch their attention represents a STUN server's attempt to establish a direct connection.

History of TURN

What was used before TURN?

Before the establishment of TURN, STUN (Session Traversal Utilities for NAT) was the primary solution employed to address the challenges posed by NAT (Network Address Translation). NAT devices allow multiple endpoints (like personal computers) in a local network to share a single public IP address for accessing resources on the Internet.

STUN is a protocol that aids in the discovery of a device's public IP address and port as seen from the outside of its local network. It operates by querying a STUN server on the Internet, which then provides the device with its public-facing IP address and port number.

What challenges did STUN face?

While STUN worked effectively in many scenarios, it faced challenges, especially with specific NAT types:

Symmetric NATs: With symmetric NATs, the same internal private IP:Port maps to a different external public IP:Port for every distinct destination IP:Port pair. This means that STUN's approach to discovering public IP:Port doesn't work consistently because the mapping keeps changing based on the destination.
Multiple NATs: In cases where multiple NATs are in the path (a condition known as "NAT hairpinning"), STUN might not always provide the correct public address that allows for successful communication.
Stringent Firewalls: Many corporate and institutional firewalls implement policies that prevent unknown external requests from reaching devices inside their network. This restriction hinders the success of direct P2P connections initiated by external peers, even with the knowledge provided by STUN.

How is TURN solving it?

To address the limitations of STUN, TURN (Traversal Using Relays around NAT) was developed. Here's how TURN overcomes the above challenges:

Relaying Data: Instead of merely assisting in the discovery of public IP addresses like STUN, TURN takes a more active role by acting as an intermediary relay for data packets. When two devices can't establish a direct connection, they both connect to the TURN server, which then forwards data between them.
Consistent Endpoint: TURN provides a consistent public endpoint (the TURN server's address) for both communicating peers. This resolves the issue of changing mappings in symmetric NATs, as both peers always send and receive data from the same TURN server's address.
Bypassing Firewalls: Since TURN communication can be initiated from within a restricted network to the TURN server (an allowed action by most firewalls), it provides a way to bypass the inbound restrictions of strict firewalls. Data relayed through TURN appears as regular outbound traffic to the firewall.

How does the TURN Server Work?

TURN servers come into play when other methods, like STUN (Session Traversal Utilities for NAT), fail. STUN is typically the first line of approach, where devices attempt to discover their public-facing IP addresses and ports, allowing for direct communication if possible. However, in more complex network environments, such as those involving symmetric NATs or restrictive firewalls that alter the source port of outbound packets, STUN is insufficient.

This is where TURN servers are employed. These servers act as intermediaries, relaying data between devices when direct connections are not feasible. In practical terms, all traffic between the communicating devices is routed through the TURN server. While ensuring data delivery, this approach introduces added latency due to the additional hop in data transmission.

From a software development perspective, integrating TURN servers into RTC applications involves several key considerations:

Server Maintenance: TURN servers are resource-intensive, handling and relaying substantial volumes of data. This requires robust infrastructure and maintenance.
Latency and Performance: The relay mechanism of TURN servers introduces additional latency. Developers need to balance this with the requirement for real-time communication.
Security Concerns: As data passes through TURN servers, implementing strong encryption and authentication protocols is crucial to maintaining data integrity and privacy.
Cost Management: The high data throughput on TURN servers, especially in cloud-hosted scenarios, can incur significant operational costs.

Developers typically use a combination of STUN and TURN in their applications. STUN is used to establish direct connections wherever possible, with TURN serving as a reliable fallback for scenarios where direct communication is blocked. Tools like Coturn, which provide both STUN and TURN functionalities, are popular among developers for streamlining the implementation of these protocols in RTC applications.

Frequently Asked Questions

What is the difference between TURN and STUN servers?

STUN (Session Traversal Utilities for NAT) servers help devices discover their public IP addresses and ports to facilitate direct communication, typically in simpler network configurations. TURN (Traversal Using Relays around NAT) servers, on the other hand, act as intermediaries, relaying data between devices when direct communication is obstructed by complex NATs or firewalls. While STUN attempts direct connection with minimal overhead, TURN is a fallback that ensures connectivity through data relay but with added latency and resource usage.

What ports are used for the TURN server?

TURN servers typically use port 3478 for both TCP and UDP traffic, and they may also use port 5349 for secured traffic over TLS. Additionally, TURN servers can be configured to use other ports as required by network policies or specific deployment needs.

Does TURN use TCP or UDP?

TURN servers can use both TCP and UDP protocols for relaying traffic. UDP is often preferred for real-time applications due to lower latency, but TCP is used when UDP is restricted or unreliable in certain network environments. This flexibility allows TURN to operate effectively across diverse network conditions.

References

https://www.100ms.live/blog/webrtc-turn-server
https://webrtc.org/getting-started/turn-server
https://webrtcforthecurious.com/docs/03-connecting/#turn
https://datatracker.ietf.org/doc/html/rfc5766
https://datatracker.ietf.org/doc/html/rfc8656