Когда UDP-соединение рассматривается как UDP-поток

Question

В NAT есть два разных таймаута для сеанса UDP.

• Тайм-аут UDP
• Тайм-аут потока UDP

UDP timeout установленодо 30 seconds в большинстве конфигураций NAT.Однако для UDP stream timeout установлено значение 180 seconds.Я понимаю, что настройки могут быть изменены сетевым администратором.Однако сеанс UDP идентифицируется парой конечных точек источника и назначения.И NAT должен классифицировать соединение как поток.

Мой вопрос: как и когда NAT классифицирует соединение как поток, а когда нет?Хотя кажется, что пара последовательных двунаправленных send() и receive() классифицирует UDP-соединение как поток, я не нашел документально подтвержденных доказательств.

Кроме того, я предполагаю, что разные политики NAT применяют разные алгоритмы.Но есть ли RFC или какой-либо опубликованный документ, который документирует эти алгоритмы?

В следующем ссылка поток определяется как сеанс, который имеет связь в обоих направлениях.Но сколько отправлять и получать требуется?Различается ли это в разных NAT?

В этом контексте «поток» означает, что механизм отслеживания соединений видел пакеты в «обоих направлениях», поэтому время ожидания по умолчанию больше.Если было замечено только одно направление, применяется «другое» время ожидания.

Answer 1

Обычно, когда клиент локальной сети отправляет дейтаграмму UDP в глобальную сеть, NAT связывает поток UDP (он же состояние порта ) с портом, используемым для отправки дейтаграммы в глобальную сеть.Когда NAT получает дейтаграмму UDP от WAN на конкретном порту, он проверяет, есть ли поток UDP, связанный с этим портом, и, если да, он перенаправляет дейтаграмму клиенту локальной сети.В противном случае датаграмма отбрасывается.

Когда два разных клиента ЛВС хотят отправлять дейтаграммы UDP друг другу по глобальной сети, обычной практикой обхода их NAT является пробивание UDP-дырок : оба клиента начинают отправлять дейтаграммы друг другу с одного и того же порта, чтобы их NAT связывали потоки UDP и начинали пересылку дейтаграмм.