Изменения

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