Как NAT или прокси реагируют на входящий пакет TCP SYN?

В некоторых системах обмена сообщениями два клиента обмена сообщениями отправляют / получают пакеты напрямую друг от друга в чате или голосовом вызове. Я думаю, что основной механизм (например, TCP): эти клиентские программы открывают прослушивающий TCP-сокет и сообщают серверу обмена сообщениями / координирующему серверу свою пару IP / PORT. Затем клиентские программы получают IP / ПОРТ другой стороны от сервера обмена сообщениями / координирующего сервера. И один из них (скажем, A) затем инициирует TCP с другим (скажем, B) с полученной парой IP / PORT B.

Когда пассивный клиент B (который ожидает пакета TCP SYN) не находится за NAT или прокси, это нормально. Но если B находится за NAT или прокси, то пара IP / PORT на самом деле является общедоступным сетевым интерфейсом NAT или прокси.

Итак, мой вопрос: какова его реакция, когда NAT или прокси получает TCP SYN? Как они передают TCP SYN соответствующему хосту / процессу, стоящему за ним?


person user1944267    schedule 02.04.2013    source источник


Ответы (2)


Я сомневаюсь, что ваше первоначальное предположение верно. Скорее всего, они оба открывают активные соединения с сервером, и сервер маршрутизирует данные между ними. Это намного проще, и проблемы, которые вы описываете, исчезают.

person user207421    schedule 02.04.2013

Этот вопрос явно задавался давно, но все же ...

Чат и голосовой / видеозвонок обычно обрабатываются по-разному. В случае чата вы, вероятно, будете использовать протокол XMPP, где оба конца будут подключаться к серверу и обмениваться данными через него. XMPP находится в TCP на уровне 4, поскольку в этом случае надежность имеет более высокий приоритет, чем задержка. Поскольку именно клиенты открывают и поддерживают соединение, в этом случае у вас не будет проблем с NAT.

С другой стороны, голосовые / видеозвонки немного сложнее, поэтому обычно у вас есть:

  • часть сигнализации, в которой вы согласовываете сеть (IP-адрес и порт) и детали кодека, необходимые для настройки вызова (известная как SDP - протокол описания сеанса)
  • медиа-часть, где вы эффективно обмениваетесь голосовым / видеоконтентом между двумя сторонами вызова.

Сигнализация обычно проходит через TCP с использованием некоторых протоколов более высокого уровня, таких как SIP (протокол инициации сеанса). Это сообщение будет проходить через сервер. Медиа проходит через UDP с использованием протоколов более высокого уровня, таких как RTP (транспортный протокол реального времени), и эта часть связи обычно идет в одноранговой сети. Один порт UDP может использоваться как для передачи, так и для приема трафика для одного голосового / видеоканала. Кроме того, вы, вероятно, захотите иметь информацию о качестве звонка во время звонка, чтобы вы могли, например, уменьшите используемую полосу пропускания, чтобы избежать / уменьшить потерю пакетов. Для этой цели вы должны использовать такой протокол, как RTCP (протокол управления транспортировкой в ​​реальном времени). В этом случае решающее значение имеет обход NAT! Поскольку ни один из клиентов не знает свои общедоступные IP-адреса, вам нужен сервер на стороне вашей внутренней сети (в общедоступном Интернете), который мог бы сказать, «как вас видят извне», то есть за NAT. Например, в Мир WebRTC знает этот сервер ICE. После того, как одноранговый узел узнает, как он виден из Интернета, он поместит эту информацию в часть SDP сигнального сообщения, чтобы другой конец мог получить к нему доступ через Интернет. Имейте в виду, что маршрутизатору, который выполняет NAT, также могут потребоваться некоторые дополнительные настройки для отслеживания используемых голосовых / видео UDP-портов (для NAT-возврата трафика из Интернета к вам).

Наконец, в этих случаях используются другие решения, но это зависит от ваших настроек. Если вы пишете программное обеспечение для конечного пользователя, тогда применимы предыдущие объяснения. Однако, если вы пишете программное обеспечение для корпоративного рынка, такие решения, как дополнительный сервер (известный как EDGE) на границе вашей корпоративной сети, будут обычным подходом.

Я могу писать об этом часами, но для начала хватит ... :)

person Marko Andrijevic    schedule 31.08.2017