In the real Internet network environment, most computer hosts are located behind the firewall or NAT, and only a few hosts can directly access the Internet. Most of the time, we want two hosts on different internal networks to communicate directly, which is called P2P communication, instead of reducing the latency of real-time communication through other public servers. Since the host may be behind a firewall or NAT, we need to check whether and how P2P communication can take place between them before P2P communication can take place. This technique is often referred to as NAT Traversal, and more on NAT is covered briefly in WebRTC NAT Traversal.

If you are not familiar with NAT penetration, it is recommended to review it.

Today, STUN, TURN, and ICE are different technical solutions for NAT penetration.

STUN

STUN, first defined in RFC3489, is a complete NAT Traversal solution (Simple Traversal of UDP Through NATs).

In the new RFC5389 revision, STUN is positioned as a tool for NAT Traversal, rather than a complete solution. Session Traversal Utilities for NAT The biggest difference between STUN in RFC5389 and RFC3489, apart from the name change, is that TCP penetration is supported in the new definition.

STUN is a typical client/server pattern in which the client initiates a request and the server responds with a default port of 3478.

There are two STUN specifications: RFC3489 and RFC5389.

RFC3489 penetrates walls using UDP. Current servers have too many restrictions on UDP, resulting in a low success rate in this mode.

RFC5389 is an updated version of RFC3489, but the meaning is different, a series of through-wall attacks, including TCP through-wall.

All STUN messages contain a 20-byte (8-bit) header with two bytes (16-bit) of message type, two bytes of message length, which does not include the length of the header, and 16 bytes of transaction ID. The request and response transaction IDS are the same.

The message header is followed by the message body, which can be 0 or multiple attributes. Each attribute is TLV encoded, including 16-bit attribute type, 16-bit attribute length, and variable length attribute value.

More specific message interaction protocol is not going to be further studied by the author at present, because my purpose is to learn and use WebRTC, and I have not reached the advanced level of understanding every detail of WebRTC.

STUN can be used to penetrate three of the four main NAT types: full coned NAT, restricted coned NAT, and port restricted coned NAT. Symmetric NAT cannot be used.

TURN the agreement

Symmetric NAT cannot successfully penetrate STUN, so TURN is needed.

The purpose of TURN protocol is to solve the problem that symmetric NAT cannot traverse.

TURN (Traversal Using NAT Relay) is a data transmission protocol. NAT can be penetrated through TCP or UDP. TURN is also a Client/Server protocol and uses the same message format as STUN.

However, the terminal implementing THE TURN Client must interact with the TURN Server before communication starts, and the TURN Server is required to generate a “relay port”, which is a relay forwarding address. At this time, the TURN server will establish a peer, that is, remote endpoints, and start to relay. The TURN client uses the relay port to transmit data to the peer. Then the peer is transferred to the TURN client of the other party.

To put it bluntly, THE author thinks that TURN protocol is more like a relay and forwarding protocol, rather than P2P communication in the real sense.

ICE

ICE (Interactive Connectivity Establishment). ICE defines traversal methods rather than protocols.

Since we can use STUN and TURN for NAT penetration, when do we use STUN and when do we use TURN? That’s what ICE does.

More generally, ICE is more like a NAT penetration manager. The user simply tells ICE I want to go through the wall, and how to go through the wall is up to ICE.

ICE integrates STUN and TURN. ICE makes it easier for the two NAT endpoints to communicate. ICE uses STUN to drill holes. If it fails, it uses TURN for transfer.

Here’s what ICE does:

1. Collect Candidate addresses

A Candidate is an address composed of an IP address and a port. There are three types of candidates:

Host candidate type (the NIC's own IP address and port) Reflection candidate type (the IP address and port after NAT) Relay candidate type (the forwarding address and port opened through the TURN service)Copy the code

2. Sort Candidate pairs

After ICE collects Candidate addresses, each peer has several Candidate addresses of its own and the other, and pairs them to form a Candidate Pair.

Each Candidate Pair has a priority, and ICE needs to sort the priority of each Candidate Pair.

3. Check the connectivity of the candidate address

ICE performs both send and receive checks on Candidate pairs that have been sorted. If the same information can be retrieved after sending a message, connectivity is normal

The resources

P2P technology details (4) : P2P technology STUN, TURN, ICE details

Pay attention to me, progress together, life is more than coding!!

More audio and video related knowledge please pay attention to the public number: ideological consciousness