Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Traversal Using Relays around NAT (TURN) — это протокол, помогающий преодолевать сетевые адресные преобразования (NAT) или брандмауэры для мультимедийных приложений. Он может использоваться с протоколом управления передачей (TCP) и протоколом пользовательских данных (UDP). Он наиболее эффективен для клиентов в сетях, находящихся за симметричными NAT-устройствами. TURN не предназначен для запуска серверов на известных портах в частной сети через NAT; он поддерживает соединение пользователя, находящегося за NAT, только с одним пиром, например, в телефонии. Схема URI TURN определена и описана в .
Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example. TURN is specified by The TURN URI scheme is documented in .
Введение
Перевод сетевых адресов (NAT) — механизм, служащий мерой для смягчения проблемы исчерпания адресного пространства IPv4 в процессе перехода к IPv6, — сопряжён с различными ограничениями. Наиболее серьёзным из этих ограничений является то, что NAT нарушает работу многих существующих IP-приложений и усложняет развёртывание новых. Разработаны рекомендации по созданию протоколов, "дружественных к NAT", но многие протоколы просто невозможно построить в соответствии с этими рекомендациями. Примерами таких протоколов являются мультимедийные приложения и файлообмен. Утилиты обхода NAT для сеансов (STUN) предоставляют один из способов прохождения приложения через NAT. STUN позволяет клиенту получить транспортный адрес (IP-адрес и порт), который может быть полезен для приёма пакетов от другого участника. Однако адреса, полученные с помощью STUN, могут быть недоступны для всех участников. Их работоспособность зависит от топологических условий сети. Следовательно, STUN сам по себе не может обеспечить полноценное решение для обхода NAT. Для полного решения требуется механизм, позволяющий клиенту получить транспортный адрес, с которого он сможет принимать медиаданные от любого участника, способного отправлять пакеты в общедоступный Интернет. Этого можно достичь только путём перенаправления данных через сервер, расположенный в общедоступном Интернете. Traversal Using Relays around NAT (TURN) — это протокол, позволяющий клиенту получать IP-адреса и порты от такого ретранслятора. Хотя TURN почти всегда обеспечивает подключение к клиенту, он требует значительных ресурсов от провайдера сервера TURN. Поэтому желательно использовать TURN только в крайнем случае, отдавая предпочтение другим механизмам (таким как STUN или прямое соединение), когда это возможно. Для этого можно использовать методологию установления интерактивного соединения (ICE) для определения оптимального способа установления соединения.
Network address translation (NAT), a mechanism that serves as a measure to mitigate the issue of IPv4 address exhaustion during the transition to IPv6, is accompanied by various limitations. The most troublesome among these limitations is the fact that NAT breaks many existing IP applications, and makes it more difficult to deploy new ones. Guidelines have been developed that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include multimedia applications and file sharing. Session Traversal Utilities for NAT (STUN) provides one way for an application to traverse a NAT. STUN allows a client to obtain a transport address (an IP address and port) which may be useful for receiving packets from a peer. However, addresses obtained by STUN may not be usable by all peers. Those addresses work depending on the topological conditions of the network. Therefore, STUN by itself cannot provide a complete solution for NAT traversal. A complete solution requires a means by which a client can obtain a transport address from which it can receive media from any peer which can send packets to the public Internet. This can only be accomplished by relaying data through a server that resides on the public Internet. Traversal Using Relays around NAT (TURN) is a protocol that allows a client to obtain IP addresses and ports from such a relay. Although TURN almost always provides connectivity to a client, it is resource intensive for the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. To accomplish that, the Interactive Connectivity Establishment (ICE) methodology can be used to discover the optimal means of connectivity.
Протокол
Процесс начинается, когда клиентский компьютер пытается связаться с одноранговым компьютером для обмена данными, но не может этого сделать из-за того, что и клиент, и одноранговый компьютер находятся за своими NAT. Если STUN невозможен, поскольку один из NAT является симметричным (тип NAT, несовместимый с STUN), необходимо использовать TURN. Сначала клиент связывается с сервером TURN, отправляя запрос "Allocate". Этот запрос просит сервер TURN выделить ресурсы для клиента, чтобы он мог связаться с одноранговым компьютером. Если выделение возможно, сервер назначает адрес, который клиент будет использовать в качестве ретранслятора, и отправляет клиенту ответ "Allocation Successful", содержащий "выделенный ретранслируемый транспортный адрес", расположенный на сервере TURN. Затем клиент отправляет запрос CreatePermissions на сервер TURN для создания системы проверки разрешений для связи с одноранговым сервером. Иными словами, когда одноранговый компьютер наконец-то устанавливает связь и отправляет информацию обратно на сервер TURN для пересылки клиенту, сервер TURN использует разрешения для проверки действительности связи между одноранговым компьютером и сервером TURN. После создания разрешений у клиента есть два способа отправки данных: (1) использовать механизм Send или (2) зарезервировать канал с помощью запроса ChannelBind. Механизм Send проще, но имеет больший заголовок – 36 байт, что может значительно увеличить пропускную способность при использовании TURN для ретрансляции. Метод ChannelBind легче: заголовок всего 4 байта, но он требует резервирования канала, который необходимо периодически обновлять, среди прочего. Используя любой из методов – Send или связывание канала – сервер TURN получает данные от клиента и пересылает их одноранговому компьютеру с помощью UDP-датаграмм, в которых в качестве адреса источника указан "выделенный ретранслируемый транспортный адрес". Одноранговый компьютер получает данные и отвечает, также используя UDP-датаграмму в качестве транспортного протокола, отправляя ее на адрес ретрансляции на сервере TURN. Сервер TURN получает UDP-датаграмму от однорангового компьютера, проверяет разрешения и, если они действительны, пересылает ее клиенту. Этот процесс позволяет обойти даже симметричные NAT, поскольку и клиент, и одноранговый компьютер могут по крайней мере взаимодействовать с сервером TURN, который выделил IP-адрес ретранслятора для связи. TURN более надежен, чем STUN, поскольку помогает преодолевать больше типов NAT, но при этом TURN пересылает всю связь через сервер, что требует значительно большей пропускной способности сервера, чем STUN, который обычно только определяет общедоступный IP-адрес и передает информацию клиенту и одноранговому компьютеру для прямой связи. Поэтому протокол ICE предписывает использовать STUN в первую очередь, а TURN – только при работе с симметричными NAT или другими ситуациями, когда STUN не может быть использован.
The process begins when a client computer wants to contact a peer computer for a data transaction, but cannot do so due to both client and peer being behind respective NATs. If STUN is not an option because one of the NATs is a symmetric NAT (a type of NAT known to be non STUN compatible), TURN must be used. First, the client contacts a TURN server with an "Allocate" request. The Allocate request asks the TURN server to allocate some of its resources for the client so that it may contact a peer. If allocation is possible, the server allocates an address for the client to use as a relay, and sends the client an "Allocation Successful" response, which contains an "allocated relayed transport address" located at the TURN server. Second, the client sends in a CreatePermissions request to the TURN server to create a permissions check system for peer server communications. In other words, when a peer is finally contacted and sends information back to the TURN server to be relayed to client, the TURN server uses the permissions to verify that the peer to TURN server communication is valid. After permissions have been created, the client has two choices for sending the actual data, (1) it can use the Send mechanism, or (2) it can reserve a channel using the ChannelBind request. The Send mechanism is more straightforward, but contains a larger header, 36 bytes, that can substantially increase the bandwidth in a TURN relayed conversation. By contrast, the ChannelBind method is lighter: the header is only 4 bytes, but it requires a channel to be reserved which needs to be periodically refreshed, among other considerations. Using either method, Send or channel binding, the TURN server receives the data from the client and relays it to the peer using UDP datagrams, which contain as their Source Address the "Allocated Relayed Transport Address". The peer receives the data and responds, again using a UDP datagram as the transport protocol, sending the UDP datagram to the relay address at the TURN server. The TURN server receives the peer UDP datagram, checks the permissions and if they are valid, forwards it to the client. This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication. While TURN is more robust than STUN in that it assists in traversal of more types of NATs, a TURN communication relays the entire communication through the server requiring far more server bandwidth than the STUN protocol, which typically only resolves the public facing IP address and relays the information to client and peer for them to use in direct communication. For this reason, the ICE protocol mandates STUN usage as a first resort, and TURN usage only when dealing with symmetric NATs or other situations where STUN cannot be used.