ИМХО использование :while ( true ) без задержки — лишняя нагрузка на ваш роутер и потеря встроенного функционала scheduler, но каждому своё.
В любом случае, если вы решили использовать этот подход — лучше не писать response на диск, учитывая что у вас там одно короткое сообщение. :local httpResponse [:tool fetch url=$requestUrl as-value output=user]
:local content ($httpResponse->"data");
Можно пропустить через Cloudflare или подобные сервисы.
Первый запрос из зоны будет долгим, потом, из кеша CDN — достаточно быстро.
Прогреть кеш, чтобы небыло долгого первого запроса — можно через сторонние сервисы.
Все верно, в основном, такое происходит именно из-за того, что все тестирование сильно формализированно. Тестировщики раз за разом проверяют одни и те же сценарии.
Чаще всего, такое бывает, когда менеджер проекта забывает выделять время на exploratory testing.
Возможно, я немного поспешил с выводами.
Как показали комментарии, есть много сценариев, где ваш подход выручает (UPnP, пару сотен серверов).
Возьму на заметку, спасибо.
Я выше описал плюсы своего подхода, но да, у него есть и минусы.
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
Если же все на одном сервере, имхо, мой подход проще.
Все верно, давайте я попробую описать плюсы своего подхода (субъективно, конечно).
Опять же, не настаиваю, что это серебряная пуля, просто минусов данного решения я за много лет не нашел.
виден траффик конкретного провайдера и можно определить перекос балансировки (это если у вас на интерфейсе не только сервер)
сервер видит через какой провайдер идут запросы, что тоже, иногда, бывает необходимо
используя vlan-ы можно убрать траффик сервера из локальной сети (это можно сделать и с подходом автора, но тут это вписывается в модель :) )
теоретически, меньшая нагрузка на роутер при большом траффике (с удовольствием бы проверил, но свободной железки нет :( )
Смотрите, объясню, как это всегда работало у меня.
На web-server добавляете ip alias -ы (как я выше написал, можно vlan-ами, но для упрощения объясню с алиасами).
В результате ваш сервер доступен на N внутренних адресах.
На роутере настраиваете DNAT, где каждый внешний ip меняете на свой внутренний ip:
1.2.3.4 -> 192.168.0.2
4.3.2.1 -> 192.168.0.3
5.4.3.2 -> 192.168.0.4
Теперь с помощью ip rule на роутере добавляете:
from 192.168.0.2 lookup ISP1_TABLE
from 192.168.0.3 lookup ISP2_TABLE
from 192.168.0.4 lookup ISP3_TABLE
В таблицах роуты для специфического провайдера.
Вот и все, теперь ваш web-сервер доступен на всех внешних адресах.
Все немного не так, в вашем примере вы используете vlan-ы, чтобы понимать по какому каналу пришел запрос на web-сервер, чтобы отправить ответ по нему-же.
У автора же, сервер принимает на и отвечает с одного и того-же адреса, если я все верно понял.
Однако, это не отменяет того, что автор сильно перемудрил, используя vlan-ы или на худой конец просто alias-ы можно было бы обойтись 3-мя route rule и 3-мя роутами.
:while ( true )без задержки — лишняя нагрузка на ваш роутер и потеря встроенного функционала scheduler, но каждому своё.В любом случае, если вы решили использовать этот подход — лучше не писать response на диск, учитывая что у вас там одно короткое сообщение.
:local httpResponse [:tool fetch url=$requestUrl as-value output=user]
:local content ($httpResponse->"data");
Первый запрос из зоны будет долгим, потом, из кеша CDN — достаточно быстро.
Прогреть кеш, чтобы небыло долгого первого запроса — можно через сторонние сервисы.
Чаще всего, такое бывает, когда менеджер проекта забывает выделять время на exploratory testing.
Как показали комментарии, есть много сценариев, где ваш подход выручает (UPnP, пару сотен серверов).
Возьму на заметку, спасибо.
Если вам нужен UPnP — то остается вариант автора.
Если у вас сервисы на разных серверах, то алиасы/vlan-ы должны быть на каждом.
Если же все на одном сервере, имхо, мой подход проще.
Опять же, не настаиваю, что это серебряная пуля, просто минусов данного решения я за много лет не нашел.
На web-server добавляете ip alias -ы (как я выше написал, можно vlan-ами, но для упрощения объясню с алиасами).
В результате ваш сервер доступен на N внутренних адресах.
На роутере настраиваете DNAT, где каждый внешний ip меняете на свой внутренний ip:
1.2.3.4 -> 192.168.0.2
4.3.2.1 -> 192.168.0.3
5.4.3.2 -> 192.168.0.4
Теперь с помощью ip rule на роутере добавляете:
from 192.168.0.2 lookup ISP1_TABLE
from 192.168.0.3 lookup ISP2_TABLE
from 192.168.0.4 lookup ISP3_TABLE
В таблицах роуты для специфического провайдера.
Вот и все, теперь ваш web-сервер доступен на всех внешних адресах.
У автора же, сервер принимает на и отвечает с одного и того-же адреса, если я все верно понял.
Однако, это не отменяет того, что автор сильно перемудрил, используя vlan-ы или на худой конец просто alias-ы можно было бы обойтись 3-мя route rule и 3-мя роутами.