Traversal Using Relays around NAT ( TURN ) ist ein Protokoll, das das Durchqueren von Netzwerkadressenübersetzern (NAT) oder Firewalls für Multimediaanwendungen unterstützt. Sie kann mit dem Transmission Control Protocol (TCP) und dem User Datagram Protocol (UDP) verwendet werden. Dies ist besonders nützlich für Clients in Netzwerken, die von symmetrischen NAT-Geräten maskiert werden. TURN unterstützt nicht das Ausführen von Servern an bekannten Ports im privaten Netzwerk über ein NAT. Es unterstützt die Verbindung eines Benutzers hinter einem NAT mit nur einem einzigen Peer, wie beispielsweise in der Telefonie.
TURN wird von RFC 5766 angegeben. In RFC 6156 wird eine Aktualisierung von TURN für IPv6 angegeben. Das TURN-URI-Schema ist in RFC 7065 dokumentiert.
Einleitung [ edit ]
NATs bieten zwar viele Vorteile, bringen aber auch viele Nachteile mit sich. Der größte Nachteil dieser Nachteile besteht darin, dass sie viele vorhandene IP-Anwendungen beschädigen und die Bereitstellung neuer Anwendungen erschweren. Es wurden Richtlinien entwickelt, die beschreiben, wie "NAT-freundliche" Protokolle erstellt werden, aber viele Protokolle können einfach nicht nach diesen Richtlinien erstellt werden. Beispiele für solche Protokolle sind Multimediaanwendungen und Dateifreigabe.
Session Traversal Utilities für NAT (STUN) bietet eine Möglichkeit für eine Anwendung, ein NAT zu durchlaufen. Mit STUN kann ein Client eine Transportadresse (eine IP-Adresse und einen Port) erhalten, die zum Empfangen von Paketen von einem Peer nützlich sein kann. Von STUN erhaltene Adressen können jedoch möglicherweise nicht von allen Peers verwendet werden. Diese Adressen funktionieren abhängig von den topologischen Bedingungen des Netzwerks. Daher kann STUN an sich keine vollständige Lösung für NAT-Traversal bieten.
Eine vollständige Lösung erfordert ein Mittel, mit dem ein Client eine Transportadresse erhalten kann, über die er Medien von jedem Peer empfangen kann, der Pakete an das öffentliche Internet senden kann. Dies kann nur durch Weiterleiten von Daten über einen Server im öffentlichen Internet erreicht werden. Traversal Using Relay NAT (TURN) ist ein Protokoll, mit dem ein Client IP-Adressen und Ports von einem solchen Relay beziehen kann.
Obwohl TURN fast immer Konnektivität zu einem Client bereitstellt, ist es für den Anbieter des TURN-Servers ressourcenintensiv. Es ist daher wünschenswert, TURN nur als letzten Ausweg zu verwenden, wobei andere Mechanismen (wie STUN oder direkte Konnektivität) bevorzugt werden. Um dies zu erreichen, kann die Interactive Connectivity Establishment (ICE) -Methode verwendet werden, um die optimalen Verbindungsmöglichkeiten zu ermitteln.
Protocol [ edit ]
Der Prozess beginnt, wenn ein Clientcomputer einen Peer-Computer für eine Datentransaktion kontaktieren möchte, dies jedoch nicht, da sowohl Client als auch Peer dies sind hinter jeweiligen NATs. Wenn STUN keine Option ist, da eines der NATs ein symmetrisches NAT ist (ein Typ von NAT, der als nicht STUN-kompatibel bekannt ist), muss TURN verwendet werden.
Zuerst kontaktiert der Client einen TURN-Server mit einer "Allocate" -Anforderung. Die Allocate-Anforderung fordert den TURN-Server auf, einige seiner Ressourcen für den Client zuzuteilen, damit er einen Peer kontaktieren kann. Wenn eine Zuordnung möglich ist, weist der Server eine Adresse zu, die der Client als Relais verwenden soll, und sendet dem Client eine Antwort "Allocation Successful", die eine "zugewiesene weitergeleitete Transportadresse" enthält, die sich auf dem TURN-Server befindet.
Zweitens sendet der Client eine CreatePermissions-Anforderung an den TURN-Server, um ein Berechtigungsprüfungssystem für die Peer-Server-Kommunikation zu erstellen. Wenn ein Peer schließlich kontaktiert wird und Informationen an den TURN-Server zurücksendet, um an den Client weitergeleitet zu werden, verwendet der TURN-Server die Berechtigungen, um zu überprüfen, ob die Peer-to-TURN-Serverkommunikation gültig ist.
Nachdem Berechtigungen erstellt wurden, stehen dem Client zwei Optionen zum Senden der tatsächlichen Daten zur Verfügung: (1) er kann den Sendemechanismus verwenden oder (2) er kann einen Kanal mit der ChannelBind-Anforderung reservieren. Der Sendemechanismus ist unkomplizierter, enthält jedoch einen größeren Header (36 Byte), durch den die Bandbreite in einer durch TURN weitergeleiteten Konversation erheblich erhöht werden kann. Im Gegensatz dazu ist die ChannelBind-Methode leichter: Der Header besteht nur aus 4 Bytes, erfordert jedoch die Reservierung eines Kanals, der unter anderem periodisch aktualisiert werden muss.
Bei einer der beiden Methoden, Senden oder Kanalbindung, empfängt der TURN-Server die Daten vom Client und gibt sie mithilfe von UDP-Datagrammen an den Peer weiter, die als "Quelladresse" die "Allocated Relayed Transport Address" enthalten. Der Peer empfängt die Daten und antwortet erneut mit einem UDP-Datagramm als Transportprotokoll, wobei das UDP-Datagramm an die Relay-Adresse am TURN-Server gesendet wird.
Der TURN-Server empfängt das Peer-UDP-Datagramm, prüft die Berechtigungen und leitet sie an den Client weiter, wenn sie gültig sind.
Dieser Prozess umgeht sogar symmetrische NATs, da sowohl der Client als auch der Peer mindestens mit dem TURN-Server kommunizieren können, der eine Relay-IP-Adresse für die Kommunikation zugewiesen hat.
Während TURN robuster ist als STUN, da es beim Durchlaufen mehrerer NAT-Typen hilft, leitet eine TURN-Kommunikation die gesamte Kommunikation über den Server weiter und erfordert weitaus mehr Server-Bandbreite als das STUN-Protokoll, das normalerweise nur IP-Adressen auflöst Adressieren und Weiterleiten der Informationen an Client und Peer für die direkte Kommunikation. Aus diesem Grund schreibt das ICE-Protokoll die Verwendung von STUN als erste Möglichkeit und die Verwendung von TURN nur für symmetrische NATs oder andere Situationen vor, in denen STUN nicht verwendet werden kann.
Không có nhận xét nào:
Đăng nhận xét