15432, =) Windows Size тоже зависит от rtt, там в определенный момент будет достигнута точка равновесия, и выше скорость не поднимиться , хотя номинально канал будет больше =)
15432, Если говорить у TCP , во время передачи приходят ack на получение пакетов, если пропущеннно несколько ack передача будет приостановлена, и будут слаться retransmission. Соотвественно если время rtt будет большое, ack будет приходит с задержкой, что скажется на общей скорости соединения.
Так что для tcp rtt влияет на скорость соединения;)
собственно проблема получается между роутером и компьютером.
Может быть зашумлена среда между точками, поставьте приложение на сотовый , которое позволяет видеть все точки доступа в комнате, посмотрите не вклинился ли ктонибудь. Так же wi-fi работает на скорости самого медленного устройства в сети, посмотрите может вы подключили какой-нибудь старый телефон, или телефон гденибудь на кухне, где связь хуже.
Так же проблемы могут быть со свистком на компьютере, посмотрите уровень сигнала в настройках, колеблеться ли он.
В принципе , если хотите делать не прозрачный прокси, то можно поставить его рядом с серверами, а в браузере указываете где прокси. Со стороны роутера запрещаете напрямую выходить в интернет,даете доступ только прокси и vip.
Если хотите прозрачный. Тоже самое но делаете заворот на него с помощью pbr.
Оффтопик, я бы добавил агрегирующий свич на площадке 1. облегчит управление и изменение сетевых потоков.
шлюз , если переводить на язык сетей это маршрут 0.0.0.0/0 via ip addr.
Два шлюза по умолчанию, создают так сказать логическое противоречие, оно обычно разруливается метрикой. Но в один момент времени это будет один шлюз. Поэтому у вас должен быть один шлюз по умолчанию, а остальное разруливается специфичными маршрутами.
Честно говоря странный вывод. Но в принципе EIGRP использует пять величин для вычисления оптимального маршрута. По умолчанию вроде как две используются. Нужно по хорошему смотреть конфигурацию линков.
Bandwidth (Пропускная способность). Минимальная пропускная способность для данного маршрута (а не сумма цен (cost) в отличие от OSPF).
Delay (Задержка). Суммарная задержка на всём пути маршрута.
Reliability (Надежность). Наихудший показатель надёжности на всём пути маршрута, основанный на keepalive.
Loading (Загруженность). Наихудший показатель загруженности интерфейса на всём пути маршрута, основанный на количестве трафика проходящего через интерфейс и настроенном на нём параметре bandwidth.
MTU. Минимальный размер MTU на всём пути маршрута.
Анатолий Палено,
по правилам. Вы сейчас в правилах указали конкретные порты и протоколы. Я предлагаю открыть весь ip деапазон взаимодействия между этими двумя хостами. И посмотреть будет ли в таком виде работать. Если будет то посмотреть реальные порты взаимодействия и скорректировать.
Если это не поможет , то берете ноутбук ставите на него Wireshark. На свиче где подключена камера делаете зеркалирование трафика с порта камеры, подключаетесь ноутбуком и смотрите что камера делает на сетевом уровне. если картина соответствует вашим ожиданиям делаете то же самое перед роутером.
Можете в обратном порядке все это произвести. вначале перед роутером, потом перед камерой.
Но вроде по скриншоту у вас там ppp от провайдера. Так что там надо будет не зеркалить трафик, а что то придумывать как развернуть инкапсуляцию трафика.Хотя может wireshark имеет инструменты для этого.
АртемЪ, это я уже понял. Анатолий Палено, в тестовом режиме выставьте в пропускаемы протокол ip между этими "хостами".
Если не поможет. То нужно брать wireshark смотреть что ходит перед роутером.
Анатолий Палено, какой ip адрес у сервера , где должен быть порт 5555?
То что вы прислали больше похоже на вывод с вышей рабочей станции.
Нужен вывод именно с сервера.