Компрессия данных в сетях X.25

Михаил Беребеня, Алексей Демидов

Когда пропускной способности ведомственной сети снова не хватает, администратору приходится искать ответ на вопрос “что делать?”. Есть три типовых решения: ничего не делать; просить денег на новые скоростные модемы и каналы: подумать и обойтись минимумом затрат.

Остановимся на последнем варианте. Для примера возьмем типичную схему ведомственной сети: две локальные сети, объединенные через некую среду передачи данных (СПД) - обычно это выделенные, коммутируемые, радиоканалы (реже спутниковые) или сети общего пользования (WAN). Сама сеть строится по принципу intranet и представляет собой “Internet в миниатюре”. Как правило, маршрутизатором и сервером доступа/безопасности такой сети является сервер Windows NT; протокол TCP/IP используется как на сетевом, так и на межсетевом уровне. В наиболее “передовых” решениях можно встретить маршрутизаторы Cisco.

Казалось бы, а что тут плохого? Представим, что все оборудование настроено и согласовано оптимальным образом (чего на практике встречать не приходилось). Как показывают исследования, если применяется протокол без установления соединения, то IP-трафик при применении в качестве межсетевого протокола расходует впустую до 30% всей пропускной способности.

На мегабитных каналах или в пределах локальной сети эту “мелочь” можно не замечать, однако на низкоскоростных каналах, особенно с оплатой трафика, даже 10% - это много. И это еще не самое главное! Далеко не везде имеются “чистые” IP-сети, т. е. использующие в качестве базового транспортного протокола IP. Наиболее распространенными, особенно в регионах, являются сети X.25 и Frame Relay, передающие IP путем инкапсуляции (вложения) в свой базовый протокол.

Здесь начинается самое интересное - наши исследования показали, что трафик типа “IP поверх X.25” обладает уже как минимум двукратной избыточностью, и на 1 Мб реальных данных по каналу передается дополнительно до 2 - 3 Мб служебной и большей частью ненужной информации! При этом даже предварительная компрессия данных не дает особого эффекта. Та же картина наблюдается на радио- и спутниковых каналах.

Еще один подводный камень кроется в особенностях самой аппаратуры: далеко не все помнят о том, что производительность коммуникационного оборудования измеряется в пакетах в секунду, а более привычная характеристика Кб(Мб)/с определяется для конкретного размера пакетов. Измерения показывают, что размеры пакетов практически не влияют на производительность, а реальная скорость обмена при этом может меняться почти на порядок! Напрашивается вывод: чем больше размер пакета, тем выше скорость передачи. Однако здесь необходимо учитывать ряд факторов: зашумленность каналов связи и влияние методов управления потоком данных на число повторных передач пакетов; характер самих данных (передача “коротких” сегментов данных большими пакетами только уменьшит скорость) и особенности оборудования.

По нашим оценкам, варьирование размера пакетов позволяет увеличить скорость передачи данных на 20 - 25%, однако применительно к транзитной WAN-среде этот путь трудно реализовать, поскольку для этого необходима оптимизация настроек на всем пути передачи данных.

Наиболее эффективным способом увеличения скорости передачи является компрессия потока данных “на проходе”. Подобными средствами оснащается большинство современных маршрутизаторов, пакетных коммутаторов и межсетевых экранов (МЭ). Насколько они эффективны? Как правило, такая компрессия обеспечивает уменьшение объема данных в 1,3 - 1,5 раза. Однако в последнее время появляется все больше устройств, ориентированных в первую очередь именно на повышение эффективности использования каналов доступа к сетям и магистральных каналов WAN.

Например, семейство устройств Datamizer компании Symplex Communication (www.symplex.com) обеспечивает сжатие в 2 раза и более, в сочетании с возможностью выравнивания нагрузки по нескольким линиям.

Попробуем разобраться в особенностях работы подобных компрессоров.

Самый простой в реализации вариант - сжимать тело пакета. Именно так работает большинство устройств компрессии, однако при этом коэффициент сжатия объема пакета сильно зависит от его размера и даже при больших пакетах двукратное сжатие практически недостижимо. В специализированных устройствах применяются более сложные механизмы, с меньшей зависимостью от размера пакетов и обеспечивающие более высокие коэффициенты сжатия.

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

Компрессор должен осуществлять разборку и сборку пакетов, что позволило бы иметь на входе и выходе устройства пакеты различного размера, выравнивать нагрузку на входе и выходе, а также использовать механизмы интеллектуальной маршрутизации и фильтрации, в частности для отсеивания “неполноценных” пакетов, ненужных вызовов и подтверждений.

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

Справедливость приведенных выше требований была экспериментально подтверждена при эксплуатации межсетевых экранов “ФПСУ-Х.25” производства российской компании “Амикон” (www.orc.ru/~amicon), оснащенных таким компрессором. Так, для трафика данных в сети Х.25 возможно сжатие передаваемых данных в 2 - 4 раза, для несжимаемого (шифрованного) Х.25 - на 5 - 10% (за счет оптимизации и фильтрации пакетов), для инкапсулированного в Х.25 TCP/IP-трафика - в 4 - 5 раз, для инкапсулированного в Х.25 несжимаемого (шифрованного) TCP/IP трафика - почти вдвое.