NAT желісінен өту үшін релелерді пайдалану (TURN) протоколы
Traversal Using Relays around NAT
TURN протоколы: NAT-тан өтуге көмектеседі, мультимедиа қосымшалары үшін TCP/UDP қолдайды. Симметриялық NAT желілерінде тиімді, байланыс үшін өте маңызды.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
NAT (TURN) айналасындағы релейлерді пайдалану арқылы өту – мультимедиялық қосымшалар үшін желілік адресті аударушыларды (NAT) немесе өрт қабырғаларын аралауға көмектесетін хаттама. Оны Трансмиссияны басқару протоколы (TCP) және Пайдаланушы деректемелер протоколы (UDP) арқылы пайдалануға болады. Бұл симметриялық NAT құрылғылары арқылы маскаланған желілердегі клиенттер үшін ең пайдалы. TURN жеке желідегі белгілі порттардағы серверлерді NAT арқылы іске қосуға көмектеспейді; ол NAT артындағы пайдаланушының тек бір теңдесімен қосылуын қолдайды, мысалы, телефония сияқты. TURN URI схемасы белгілі бір құжатта сипатталған.
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) – IPv6-ға өту кезінде IPv4 адрес таусылу мәселесін азайтуға арналған механизм, бірақ ол әртүрлі шектеулермен бірге келеді. Осы шектеулердің ең маңыздысы – NAT көптеген қолданыстағы IP қосымшаларын жұмыссыз қылып, жаңаларын енгізуді қиындатады. "NAT-қа қабілетті" протоколдарды қалай құруға болатынын сипаттайтын нұсқаулар жасалған, бірақ көптеген протоколдар осы нұсқауларға сәйкес жасалмайды. Мұндай протоколдарға мультимедиалық қосымшалар және файл алмасу жатады. NAT үшін сессияны бағыттайтын құралдар (STUN) қосымшаға NAT арқылы өтудің бір жолын ұсынады. STUN клиентке әріптесінен пакеттерді алуға пайдалы болатын тасымалдау адресін (IP-адрес және порт) алуға мүмкіндік береді. Дегенмен, STUN арқылы алынған мекенжайларды барлық әріптестер пайдалана бермейді. Бұл мекенжайлар желінің топологиялық жағдайларына байланысты жұмыс істейді. Сондықтан STUN өзі NAT-тің толық шешімі бола алмайды. Толық шешімге клиентке кез келген әріптестен медиа алуға және қоғамдық интернетке пакеттер жіберуге мүмкіндік беретін тасымалдау адресін алу құралы қажет. Бұл тек деректерді қоғамдық интернетке орналасқан сервер арқылы жіберу арқылы мүмкін болады. 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-мен үйлесімсіз NAT түрі) болса, TURN қолданылуы керек. Біріншіден, клиент TURN серверіне "Allocate" сұранысын жібереді. "Allocate" сұранысы TURN серверінен клиент үшін ресурстарды бөлуді сұрайды, осылайша ол әріптесімен байланыса алады. Егер бөлу мүмкін болса, сервер клиентке реле ретінде пайдалану үшін бір адресті бөліп береді және "Allocation Successful" жауабын жібереді, онда TURN серверінде орналасқан "бөлінген ретрансляциялық мекенжай" болады. Екіншіден, клиент TURN серверіне "CreatePermissions" сұранысын жібереді, ол әріптестік серверлермен байланыс үшін рұқсаттарды тексеру жүйесін құруға арналған. Яғни, әріптес байланысқа шығып, TURN серверіне клиентке қайта жіберу үшін ақпаратты жібергенде, TURN сервері рұқсаттарды пайдаланып, әріптестік серверден TURN серверіне жасалған байланыстың дұрыс екенін тексереді. Рұқсаттар құрылғаннан кейін, клиент нақты деректерді жіберу үшін екі таңдауға ие: 1) "Send" механизмін пайдалану немесе 2) "ChannelBind" сұранысын пайдаланып арнаны резервтеу. "Send" механизмі қарапайым, бірақ 36 байттық үлкен тақырыпты қамтиды, бұл TURN арқылы ретрансляцияланған әңгімелесуде жолақтықтың кеңдігін айтарлықтай арттыруы мүмкін. Керісінше, "ChannelBind" әдісі жеңіл: тақырып тек 4 байтты құрайды, бірақ ол, басқа факторлармен қатар, мерзімді жаңартуды қажет ететін арнаны резервтеуді талап етеді. "Send" немесе арнаны байланыстыру әдісін пайдалана отырып, TURN сервері клиенттен деректерді қабылдайды және оларды UDP датаграммаларын пайдаланып әріптеске жібереді, олардың бастапқы мекенжайы "бөлінген ретрансляциялық мекенжай" болады. Әріптес деректерді қабылдайды және жауап береді, тасымалдау протоколы ретінде тағы да 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.