Как: Моделируйте WAN-соединения в собственной тестовой лаборатории бесплатно!

Опубликовано: 24 Апреля, 2023


Введение


Когда я настроен по-философски, я иногда говорю: «Внедрение серверных вычислений — это пустяк, если вы работаете в локальной сети». Хотя это немного грубо, но это правда. Многие вопросы (проблемы), с которыми вы сталкиваетесь при устранении неполадок в средах серверных вычислений, связаны с сетью, через которую подключаются пользователи. Это особенно верно для глобальных подключений (WAN). Когда вам нужно устранить неполадки в такой среде, вам нужно «использовать» нарушающее сетевое соединение. По понятным причинам это не всегда возможно. Есть замечательные устройства, которые можно купить для имитации всевозможных сетей, но обычно они стоят десятки тысяч долларов. В этой статье я покажу вам, как с помощью бесплатных инструментов можно имитировать плохие соединения WAN.


Почему WAN?


Прежде чем мы приступим к моделированию плохого сетевого соединения, нам нужно ответить на вопрос, почему обычно виноваты глобальные сети. Глобальные сети обычно представляют собой более медленные соединения, которые клиенты используют для подключения к серверам терминалов или серверам Citrix. Основные характеристики глобальных сетей заключаются в том, что они имеют ограниченную полосу пропускания и высокую задержку. Хотя ICA и RDP по своей природе не требуют такой большой пропускной способности, они очень чувствительны к задержкам. Фактически, задержка является абсолютным убийцей в средах Terminal Server и Citrix. Это так просто.


Задержка, как вы все знаете, — это время, которое требуется пакету для перемещения к серверу и обратно (время приема-передачи). Клиенты по самой природе протоколов RDP и ICA зависят от ответов сервера на их обновления экрана. Любая задержка обновления экрана влияет на воспринимаемую пользователем производительность. В зависимости от приложения и, что еще более важно, от того, с чем пользователи готовы мириться, вам обычно нужно оставаться ниже задержки около 250 мс, чтобы получить приемлемую производительность. Задержка также увеличивается по мере уменьшения размера пакета. Поскольку Citrix часто отправляет очень маленькие пакеты, это еще больше ухудшает работу пользователя при соединениях с высокой задержкой. Даже если у вас соединение с малой задержкой, нет никакой гарантии, что у вас никогда не будет задержки. Это связано с тем, что задержка и пропускная способность имеют особые отношения. Как только ваша полоса пропускания становится насыщенной, задержка вскоре значительно возрастает. Думайте об этом как о шоссе. Когда шоссе заполнено автомобилями, есть вероятность, что вы не сможете ехать с максимальной скоростью. Вы, вероятно, прибудете (намного) позже в пункт назначения.


Создание медленной сети


Теперь, когда вы знаете, из чего состоит медленное сетевое соединение, давайте создадим его для себя. Что нам нужно, так это инструменты для имитации соединения с низкой пропускной способностью и высокой задержкой, возможно, даже с некоторой потерей пакетов. Сначала давайте начнем с создания соединения с низкой пропускной способностью. Инструмент, который я часто использую для этого, — NetLimiter. Нам понадобится версия Pro. Эта версия не бесплатна, но если вам нужно устранить определенную проблему, вы можете загрузить полнофункциональную 28-дневную пробную версию. NetLimiter — очень классный инструмент (который, кстати, в основном используется для ограничения скорости соединения определенных программ для обмена файлами между одноранговыми узлами), который позволяет вам отслеживать скорость загрузки и загрузки для любого процесса, работающего в вашей системе. Однако самая крутая функция заключается в том, что вы можете ограничить пропускную способность для каждого процесса. Вы можете использовать эту способность двумя способами:




  1. Вы можете установить его на сервер Citrix и ограничить входящую пропускную способность.


  2. Вы можете установить его на клиентскую машину и ограничить исходящую пропускную способность для клиента.

Я предпочитаю использовать второй вариант. Просто загрузите пробную версию NetLimiter на свой клиент и ограничьте клиент ICA (процесс wfica32.exe) пропускной способностью, которую вы хотите имитировать. Используя этот инструмент, вы сможете многое узнать о пропускной способности сети, которую используют различные процессы в вашей системе. Обратите особое внимание на процесс wfica32.exe…



Входящий трафик — это трафик, который вы получаете от сервера Citrix (большая часть отображаемых данных), а исходящий трафик — это трафик, который ваш клиент отправляет на сервер Citrix (движения мыши и нажатия клавиш). Обратите внимание на флажок позади скорости. Здесь вы можете ограничить загрузку или загрузку для каждого процесса.


Еще одно явление, которое вам может понадобиться смоделировать в вашем соединении, — это задержка. Это круто. Талантливый г-н Тим Манган создал *бесплатный* инструмент, позволяющий моделировать задержку в сети. Вы даже можете имитировать потерю пакетов! Этот инструмент называется TMnetsim, и его можно бесплатно загрузить с его сайта Tmurgent.com. Опять же, у вас есть несколько вариантов, где вы можете реализовать этот инструмент. Вы можете установить его на клиенте или на сервере Citrix. Я предпочитаю использовать этот инструмент на сервере Citrix. Инструмент работает как прокси-сервер. Когда вы запускаете его на своем сервере, вам нужно настроить порт, который он прослушивает, а затем настроить порт, на который он должен перенаправлять соединение. Прежде чем он перенаправляет трафик клиента на «фактический» сервер Citrix (порт 1494), он добавляет задержку, которую вы настроили. На типичном сервере Citrix установка будет выглядеть так:



В левом верхнем углу TMnetsim (входящее соединение) вы настраиваете порт, который прослушивает «прокси» TMnetsim. Это порт, к которому вам нужно подключиться. Справа от него находится исходящее соединение. В этом случае он перенаправляет соединение с локальным хостом (поскольку TMnetsim работает на самом сервере Citrix) на истинный порт Citrix (1494). В центре вы можете видеть, что я указал задержку 250 мс с дрожанием 25 мс. Это означает, что задержка варьируется от 225 до 275 мс. Это очень реалистичная симуляция, потому что часто задержка далеко не статична. Таким образом, любой, кто подключается через TMnetsim, испытывает задержку, которую я настроил. Обратите внимание, что задержка применяется к входящему трафику (на сервер Citrix).


Единственное, что вам нужно сделать после этого, это настроить ваш клиент ICA для подключения к порту, который прослушивает TMnetsim. Самый простой способ сделать это — сохранить файл ICA опубликованного приложения Citrix и отредактировать его. Вам нужно найти Адрес строка в файле ICA. См. выделенный жирным шрифтом раздел этого примера файла ICA ниже. Вам нужно добавить номер порта, который вы настроили в TMnetsim, с точкой с запятой.







[ВФКлиент]
Версия=2
TcpBrowserAddress = 130.144.222.5
PersistentCachePath=C:UsersMichelAppDataRoamingICAClientCache


[Серверы приложений]
Рабочий стол=


[Рабочий стол]
Адрес=Рабочий стол:1495
InitialProgram=#Рабочий стол
КлиентАудио=Вкл.
Аудиобандвидслимит=2
Сжатие = Вкл.
ЖелаемыйHRES=800
ЖелаемаяВРЭС=600
Желаемый цвет = 4
ТранспортДривер=TCP/IP
WinStationDriver=ICA 3.0
Экранный процент = 0


После того, как вы настроите эту настройку, вы можете начать тестирование того, что вы хотите протестировать. Итак, как узнать, что ваше соединение действительно отстает из-за задержки? Что ж, пусть Citrix скажет вам. Просто запустите монитор производительности на сервере Citrix и найдите объект сеанса ICA. Выберите счетчик «Задержка последней записи» и выберите подключенный сеанс Citrix. Если вы все настроили правильно, теперь вы должны увидеть задержку вашего соединения, которую вы настроили в TMnetsim (плюс-минус несколько миллисекунд).



Если вы все правильно настроите, то сможете даже менять характеристики соединения на лету. Поэкспериментируйте с ним и посмотрите, как задержка и/или ограниченная пропускная способность влияют на ваше соединение. Особенно интересно наблюдать за комбинацией ограниченной полосы пропускания и соответствующей задержки. Я буду публиковать предварительную версию Thincomputing.net, в которой рассматриваются такие вопросы.


Эта настройка, конечно же, предназначена не только для сред Terminal Server или Citrix. Например, вы можете протестировать его, чтобы увидеть, как определенные топологии репликации справляются с плохим сетевым подключением или как новое веб-приложение вашей компании реагирует на большие задержки.


Вывод


В этой статье я показал вам, как можно быстро и легко имитировать плохое сетевое подключение, не тратя тысячи долларов. Это относится не только к средам Terminal Server или Citrix, но и ко всем видам различных сред. Давай, попробуй. Вы многому научитесь в процессе!