На этом графике показано, как задержка в сети влияет на максимальную скорость при использовании TCP. Проще говоря, если ваш пинг составляет 500 миллисекунд, то при доступной пропускной способности 6, 10, 100, 500 и т. д. мегабиты трафика между двумя хостами не ускорятся выше одного мегабита.
Моя команда оптимизирует каналы коммуникации.
Иногда все можно исправить всего парой ручных кликов, но чаще приходится устанавливать специальные устройства, которые существенно сжимают обмен и делают протоколы более «оптимистичными» или «предсказывающими».
Что такое «оптимистический» протокол? Грубо говоря, это когда удаленный сервер еще не ответил, что следующий кадр можно отправить, но оборудование уже говорит «отправить», поскольку знает, что вероятность успеха составляет 97%.
Если вдруг что-то пойдет не так, он сам отправит нужный пакет, не беспокоя отправляющий сервер.
Окна и задержки
Есть такая штука как RWIN( https://en.wikipedia.org/wiki/TCP_tuning ).Это размер окна.
Раньше, когда транзисторы были большими (это 2004-2005 годы), предел был 64К.
Соответственно скорости, задержки и приложения были разные.
И на этом этапе проблем не было.
Они начали появляться, когда сети стали быстрее, а приложения стали более прожорливыми (в том смысле, что они стали потреблять больше трафика).
Компаниям необходимо расширить свою пропускную способность, чтобы все могло работать быстро.
Однако все работало хорошо лишь до определенных моментов, которые можно уловить на графике ниже.
Более того, современные операционные системы в корпоративных сетях научились автоматически и прозрачно для пользователей решать проблему так называемого «потолка».
Но есть и старые операционки, а еще целые зоопарки разных операционок и стеков.
Первоначально окно приема TCP ограничено 64 КБ (время WinXP).
Современные версии протокола также поддерживают большие размеры кадров (а это часто необходимо), но обмен начинается с малых.
Есть такое понятие как «TCP пила».
Это означает следующее: при обмене данными в TCP каждый раз при отправке нескольких кадров отправляющая сторона увеличивает количество кадров, передаваемых за один раз.
На диаграмме видно, что до определенного момента мы можем увеличить эту сумму, но однажды мы все равно упремся в потолок и начнутся убытки.
При возникновении потерь RWIN автоматически уменьшается вдвое.
Итак, если пользователь скачал файл, то видно, что он вроде бы ускоряется, но потом вылетает. Такое поведение должно быть знакомо многим.
Очень хорошего эффекта для сети со старыми маршрутизаторами и большим количеством беспроводных хопов можно добиться, изменив размер окна: нужно постараться получить максимальный немасштабированный RWIN (до 65535 байт) и использовать минимальный коэффициент масштабирования (RFC 1323).
, масштаб).
Новая Windows сама выбирает размер кадра и делает это хорошо.
Пока все просто: очень упрощенно, передаем 64К, потом ждем ответа, затем передаем 64К.
Если ответ придет от нефтедобывающего комплекса, расположенного на половине планеты и на геостационарной орбите, угадайте, какова будет эффективная скорость.
На самом деле все немного сложнее, но проблема та же.
Вот почему нам нужно больше пакетов.
Работа с RWIN – это самое простое, что можно сделать прямо сейчас на спутниковом канале (одна настройка решает массу проблем).
Пример: если ваши пакеты летят на спутник, потом обратно на землю, дождитесь ответа от сервера, затем летите на спутник и обратно к вам.
Для геостационарного спутника и нормальных к нему приемных станций это означает задержку в 500 мс.
Если прыжок длиннее (станции образуют треугольник), можно получить пару секунд. В моей практике были случаи, когда репитеры отправляли информацию повторно через спутник (на этот раз другой, который не видит первый телепорт в точке отправления за планетой) - там можно поймать 3-4 секунды, но это это отдельный вид коммуникативного ада.
Теперь самое интересное.
Для протоколов кадрового окна максимальная пропускная способность определяется шириной канала и задержкой.
Соответственно, оптимальный размер пакета (или совокупности пакетов в одном кадре, если используется промежуточная оптимизация) должен быть тем больше, чем шире канал, чтобы максимально использовать его возможности.
Значение приложения проще: необходимо знать соотношение RWIN/BDP (Bandwidth Delay Product) — интегральный показатель задержки передачи.
Прямо здесь его можно рассчитать для немасштабированного пакета 64 КБ.
Следующим логическим шагом является определение оптимального окна приема TCP. вот тест, посмотри .
Определение максимального размера сегмента (MSS) и последующая установка его в настройках обмена значительно ускоряют процесс.
Точнее доводит до теоретического максимума с вашей задержкой.
Win7 и 2008 Server делают следующее: начинают с очень маленького окна (около 17520 байт), затем увеличивают его автоматически, если инфраструктура между узлами это позволяет. После этого включается автонастройка RWIN, но она весьма ограничена.
В Win10 немного расширены границы автонастройки.
Вы можете вручную управлять RWIN, и это может иметь значение в медленных сетях.
Как минимум пару раз мы избавили заказчика от покупки дорогостоящего оборудования.
Если окно репликации составляет 24 часа, а получается только через 26, то вполне возможно, что настройка канала и настройка собственного сжатия разных узлов позволит ему снизиться до 18–19, чего будет достаточно.
С оптимизатором можно до 6–7 в болтовне, но иногда проблема уже решена.
Или отложить на пару лет. Оптимизаторы (тогда речь идет о семействе Riverbed Steelhead — я их уже установил сотни на разных месторождениях полезных ископаемых, а потому буду полагаться на практику) — ну они способны «избавить» ПТС от присущих раме недостатков протокол, передавая его в свой транспортный протокол.
Если обмен происходит между двумя узлами Riverbed, то трансляция выглядит так: 
Теперь давайте посмотрим, как эти милые маленькие устройства работают при более высоком уровне оптимизации.
Steelhead обычно использует 3 метода оптимизации: оптимизация данных (дедупликация), оптимизация транспорта (оптимизация транспорта, описанная выше) и оптимизация приложений (об этом ниже).
HTTP — старый добрый протокол для работы с веб-сайтами.
Старый – не то слово, и там есть что оптимизировать.
Например, открытие дополнительных соединений в тот момент, когда станет понятно, какие еще объекты загружать.
Современные браузеры могут сделать это «из коробки»: 
У него очень утомительная аутентификация: 
Который, в оптимистическом случае, можно сжать до двух пакетов — нужно просто запросить все это у узла-отправителя за один раз, затем отдать Riverbed на узле-получателе, и он «поговорит» с тем, кому нужно.
Очень круто для корпоративных порталов.
При нескольких открытых соединениях возникают проблемы с повторной авторизацией при так называемом переключении соединения, когда одно из соединений возвращает 401 и часть запросов на рукопожатие попадает в первое, уже аутентифицированное.
Основные виды оптимизации следующие:
- Отключение сжатия передающих и принимающих узлов и сборки пакетов в пакеты.
Если вы отключите сжатие каждого отдельного пакета, вы сможете прекрасно выполнить дедупликацию нескольких дубликатов.
Фактически это будет означать, что для однажды переданного пакета, похожего на следующий переданный, можно отправить только номер ближайшего похожего и разницу.
Это значительно меньше, чем два сжатых пакета.
- Вставка файлов cookie. Некоторые серверы требуют хранения определенных технических данных, которые примерно одинаковы для всех пользователей и редко меняются.
Их можно кэшировать.
Кроме того, если ваш хост не поддерживает файлы cookie, Оптимизатор трафика может включить эту поддержку.
- Поддержка подключения — здесь все просто: если вы не освободите сессию, вам не придется снова заходить в систему.
- Обучение URL. Пользователи идут по одним и тем же путям, поэтому оптимизатор может быстро изучить привычки офиса и некоторые из них кэшировать, некоторые поставить в быстрый доступ по предварительному запросу и так далее.
- Прогнозирование запроса.
Например, если через Steelhead проходит страница с тегом img, логично предположить, что через несколько миллисекунд принимающий сервер запросит само изображение.
Riverbed придерживается оптимистического подхода и не ждет, а просто просит об этом прямо сейчас.
Когда ваш сервер отправляет запрос, Riverbed перехватывает его и возвращает то, что он уже получил.
- Открытые сеансы также хорошо подходят для предварительной выборки.
- Если возможно, используйте принудительно NTLM (это быстрее).
- Стандартные методы избавления от ненужных заголовков.
- «Gratuitos 401» — браузеры часто выполняют ненужный GET, которого можно избежать.
В нашей практике такое случалось не раз.
В современных версиях ПО для Steelhead есть возможность оптимизировать интернет-трафик, если пользователи постоянно заходят на какие-то защищенные порталы (загонять в оптимизацию весь интернет-трафик нецелесообразно), а также если для выхода в интернет используется прокси-сервер.
Доступна оптимизация Office365. Также вы можете работать с корпоративным прокси.
КИФС/СМБ — протокол 1990 года для обмена файлами между узлами сети.
Также используется для сетевой печати.
Riverbed прослушивает оба своих стандартных порта TCP (445 и 139).
Точные методы оптимизации не раскрываются, но речь идет о сборке пакетов в оптимальные для канала размеры, ненужной блокировке на быстром узле, поддержании часто возникающих сессий (сохранении их открытыми до тех пор, пока это действительно необходимо), переносе части защиты на пару устройств Steelhead вместо собственной нагрузки узлов.
В Win10 и Server16 для SMB 3.1.1 есть механизм целостности предварительной аутентификации — некий его аналог реализован на старых версиях протокола Steelhead. Аналогичные методы используются и для других файловых протоколов.
Устройства поддерживают все версии SMB до 3.1.1, включая Signed-SMB. 
Вот как происходит сжатие и увеличивается полезная нагрузка TCP. Очень полезно для передачи файлов.
МАПИ (через HTTP, Signed-MAPI и Office365) — обмен почтой между клиентами Outlook и серверами Exchange. У него довольно долгая процедура рукопожатия: 
Оптимизация достигается за счет поддержания этой сессии открытой (Riverbed ее перехватывает и удерживает в течение 96 часов), эффективного обмена подтверждениями, потоковой передачи почты и вложений (по сути, кэширования того, что клиент еще не начал получать по факту).
Сам трафик хорошо сжимается/дедуплицируется и избавляется от избыточности: 
В кластерных установках также очень полезен метод предварительного определения портов.
У меня был случай, когда HR-специалист в праздники сбросил всю сеть очень далекого офиса банка.
Расследование показало, что его пожилой коллега отправил по почте открытку в формате BMP объемом 10 Мегабайт. Стилхед «понял», что сотрудники открывают почту в 10 утра и начинают собирать почту для себя ночью.
И заодно сжать эти чёртовы открытки, по сути обеспечив дедупликацию с 10 писем на одно и сжатие этого эталонного образца.
Раньше люди приходили в 10, а начинали работать в 10:30, как только всё «пролезало».
Теперь поводов для грусти нет, начало работ строго по графику.
Банки используют множество систем дистанционного обучения, что очень удобно для сотрудников.
В удаленных филиалах почти вся страница заполнена обучающими видео.
Riverbed с http-потоком может сделать что-то вроде того, что показано на рисунке.
В результате каналы не «страдают» от такого трафика.
Но это предиктивная механика, видео в реальном времени (видеоконференции, например), можно только расставить по приоритетам.
Мы говорим о HTTP-потоке, а не о RTP/RSTP.
Подобные методы используются и в других протоколах.
Следующая механика — «Предварительная популяция».
Если заранее знать - офис есть, и сетевые диски у него есть, и при этом маркетинг работает со своей одной папкой, а оптимизация и контроль сети - со своей.
Если мы также знаем, что в определенной ветке есть определенные отделы, которые используют определенные сетевые папки, то мы можем научить Riverbed заходить к ним самостоятельно (показать ему эти пути).
Он поймет, какие файлы там есть и как быстро они запрашиваются.
Таким образом, многие сессии открываться не будут, Riverbed сам будет «притворяться» клиентом и проходить по сетевым ресурсам, собирать все, что там есть, и брать на себя наиболее часто используемый контент. Итого: на следующий день сотрудник приходит в офис, и он уже без задержек может воспользоваться доступом на дальнюю сторону.
Соответственно, он будет получать обновленную информацию.
Остальные протоколы анализируются по схеме низкоуровневой оптимизации протокола (чаще всего речь идет о размере кадра и установке оптимального времени жизни пакета для канала) — даже если каналу нужны большие кадры, а протокол хочет отправлять маленькие.
, Steelheads умеют все это сортировать в свой формат, дедуплицировать и отправлять по мере необходимости.
Затем поток дедуплицируется, сжимается, кэшируется и прогнозируется.
Болтливые последовательности идентифицируются и преобразуются в оптимистические ответы.
Также существует пул соединений — когда Steelhead держит открытыми уже 20 дополнительных сессий для текущих нужд. Это очень актуально для спутника.
Больше практики
Над стандартным окном 64К до сих пор работает много людей — и это сильно бьет по бирже.Например, между дата-центрами Хабаровска и Москвы по каналу 100 Мбит/с с задержкой 80 мс скорость репликации стандартными средствами составляет 5 Мегабит/с.
Сюрприз! Вам нужно изменить размер окна, а затем сделать все остальное.
Опять же, тот же Office365 имеет ближайшие дата-центры Azure в Амстердаме и Дублине.
С помощью линейки и калькулятора по ссылке выше можно оценить задержку.
Трафик из того же Хабаровска тоже идёт через Москву (хотя через азиатский дата-центр Azure он ближе).
А еще есть потери.
На спутнике это легко 5% погоды.
Некоторые пакеты застревают в тумане, некоторые не проходят сквозь снежинки, но большой и толстый пакет может обогатить голубя информацией.
Или ворона, пришедшая склевать пленку с транспондера (правда, на больших телепортах они, к счастью, быстро закипают и соскальзывают с зеркала).
Кстати, поддержка SCPS помогает. 
Помимо управления размерами фреймов, Riverbed SteelHead может использовать оптимальные механизмы предотвращения перегрузок.
От NewReno до конкретных MX-TCP и HSTCP. Последние помогают избежать проблемы с высоким BDP и проблемы медленного старта TCP, то есть, зная ширину канала, мы можем отдать определенному трафику всю полосу пропускания сразу.
С выходом нового ПО появляются новые возможности.
Начиная с версии 9.0 появился полноценный DPI и можно классифицировать трафик по приложениям.
Встроенные возможности Steelheads по приоритезации и анализу трафика также хорошо использовать для настройки сетевых политик.
Например, на нефтедобывающих площадках часто используется следующая механика: сначала технический трафик, затем управленческие видеопакеты, затем офис, затем личный трафик сотрудников.
Теперь бурильщик Вася, скачав новую 20-мегабайтную гифку с котом, не будет прерывать трафик к руководству.
Или под Ленском был объект. Админы там очень знающие, выжали из канала всё, что можно.
Мы прочитали наши предыдущие посты и попросили протестировать аппаратное обеспечение.
Основная проблема в том, что RDP-подобные соединения не самые быстрые, люди бесятся.
И это их основной способ доступа к бизнес-приложениям.
При высокой загрузке канала (а она еще и несимметрична) у пользователей бизнес-приложений стали возникать проблемы с доступом по RDP. У них уже была встроенная в спутниковые модемы оптимизация, но только на транспортном уровне, поэтому они искали другое решение.
Установили реки - волосы стали мягкими и шелковистыми, нагрузка снизилась в 3 раза.
Тут мы столкнулись с костылем спутникового модема — при отключении встроенной оптимизации по умолчанию устанавливались катастрофически малые длины TCP-очередей.
Это действительно навредило руслам рек.
Мы также подобрали оптимальные параметры.
В результате RPD-подобные системы работают стабильно, файлы загружаются быстрее — люди сидят посменно и что-то делают круглосуточно.
Ситуация такая же, как у бурильщика Васи: он быстрее скачивает 20-мегабайтную гифку с котом, никому не причиняет вреда и все довольны.
Вот еще один пример.
В открытых водах стоят крупные суда – заводы на траулерах.
И там свежевыловленную рыбу сразу консервируют. Производство там контролируется через сеть, а обмен данными является частью процесса.
А просто двойные скачки спутника или неприятные переходы «спутник – 2G – оптика».
Их установили с оптимизаторами - счастье пришло ко всем там.
И компания в плане мониторинга бизнес-процессов, и сотрудники в плане улучшения условий труда, поскольку у них теперь есть возможность общаться с семьями и обмениваться фото/видео.
Где он используется на практике?
Комплект Steelheads в основном берут в следующих случаях:- Там, где технически невозможно увеличить пропускную способность канала.
- Там, где очень большая задержка на широком канале (например, для спутников).
- LFN (длинная толстая сеть, например труба между двумя дата-центрами или географически удаленными офисами, например, Москва — Кипр).
Я перечислил самые распространенные.
Волшебство Riverbed начинает работать на каналах 3G, спутниковых каналах, радиорелейных прыжках 3G, двойных спутниковых прыжках, прыжках 2G-4G, а также широких каналах 10G и с задержкой 2-5 мс.
Лучше всего это окупается в России при использовании спутниковых каналов, которые физически невозможно сделать шире, но это нужно сделать.
Раньше каналы стоили баснословных денег, но сейчас они дешевеют в большинстве регионов страны.
Чаще всего к нам обращаются в основном банки и горнодобывающий сектор.
Для многих до сих пор является открытием, что расширение каналов связи не приводит к повышению их эффективности, что латентность влияет на пропускную способность канала и что канал нельзя расширять бесконечно.
Часто, столкнувшись с такой проблемой, например, медленная репликация, медленные приложения, начинают расширять каналы.
И чаще всего это не помогает. Собственно об этом я и хотел поговорить.
Надеюсь, это сработало.
Теги: #Сетевые технологии #ИТ-инфраструктура #Системное администрирование #riverbed #каналы связи
-
В Codepen Добавлена Поддержка Flutter.
19 Oct, 24 -
Интеграция Asterisk С Active Directory
19 Oct, 24 -
Знакомство Со Шпионом
19 Oct, 24 -
Версия Под Ie
19 Oct, 24
