1632
правки
Изменения
NAT
,rollbackEdits.php mass rollback
=Hole punching=
'''Hole punching''' — метод для прямого соединения двух компьютеровхостов, которые находятся за NAT-ами. Для инициации соединения требуется третья сторона – сервер, который виден обоим компьютерам. Обычно используются публичные STUN-серверы.
'''STUN''' (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT) — это сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT.
Hole punching предполагает, что два клиента, <tex>A</tex> и <tex>B</tex>, уже имеют UDP сессию с сервером <tex>S</tex>. Когда клиент начинает сессию с <tex>S</tex>, сервер сохраняет две пары значений для этого клиента: пару IP адрес и UDP порт, которые клиент указывает при отправке пакета в поле отправителя, чтобы говорить с <tex>S</tex>, и пару IP адрес и UDP порт отправителя, которые сервер наблюдает при получении пакета. Первую пару будем называть приватным адресом, а вторую публичным. Приватный адрес сервер может получить от самого клиента в теле сообщения в поле регистрации клиента, а публичный адрес клиента он может посмотреть в поле отправителя в заголовках IP и UDP этого сообщения. Если клиент не за NAT, то его приватный и публичный адрес должны совпадать.
Предположим , что клиент <tex>A</tex> хочет установить UDP - сеанс сессию непосредственно с клиентом <tex>B</tex>. Hole punching происходит следующим образом :
* <tex>A</tex> изначально не знает , как связаться с <tex>B</tex>, поэтому <tex>A</tex> просит помощи у <tex>S</tex> в создании UDP сессии с <tex>B</tex>.
[[Файл:UDPHolePunching.png]]
==TCP hole punching==
===Алгоритм установления TCP соединения между 2 хостами находящимися за NAT===
Предположим, что клиент <tex>A</tex> хочет установить TCP соединение с клиентом <tex>B</tex>. Как и в UDP, мы предполагаем, что у <tex>A</tex> и <tex>B</tex> уже есть TCP соединения с известным сервером <tex>S</tex>. Сервер записывает приватный и публичный адреса каждого зарегистрированного клиента, так же как и для UDP. На уровне протокола, TCP hole punching работает почти так же, как для UDP:
* Клиент <tex>A</tex> использует TCP соединение с <tex>S</tex>, чтобы попросить о помощи для подключения к <tex>B</tex>.
* <tex>S</tex> отвечает <tex>A</tex>, отправляя приватный и публичный адреса <tex>B</tex>, и в то же время посылает <tex>B</tex> приватный и публичный адреса <tex>A</tex>.
* Из тех же самых локальных портов TCP, которые <tex>A</tex> и <tex>B</tex> используют для соединения с <tex>S</tex>, <tex>A</tex> и <tex>B</tex> каждый асинхронно совершают попытки подключения друг к другу по публичному и приватному адресам, и одновременно слушают эти порты на входящие соединения.
* Когда TCP соединение устанавливается, клиенты идентифицируют друг друга, чтобы убедиться, что они подключены к нужному клиенту. Если проверка подлинности завершается неудачно, клиенты закрывают эту связь и продолжают ожидание. Клиенты используют первое успешное соединение.
В отличие от UDP, где каждый клиент только нуждается в одном сокете, чтобы взаимодействовать с <tex>S</tex> и любым числом хостов одновременно, в TCP приложение должно управлять несколькими сокетами привязаными к одному локальному TCP порту на клиенте. Каждый клиент нуждается в сокете, который соединяет его с <tex>S</tex>, слушающем сокете, который будет принимать входящие соединения, и в двух дополнительных сокетах, с помощью которых клиент будет инициировать исходящие соединения с публичными и приватными TCP адресами другого клиента.
[[Файл:TCPHolePunching.png]]
==Источники информации==
