`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Светлое будущее FastTCP

0 
 

Недавние сенсационные сообщения о том, что протокол FastTCP, разработанный в Калифорнийском технологическом институте, позволит многократно увеличить скорость сетевого обмена, вряд ли оставили кого-то равнодушным. Одни с готовностью поверили в "светлое будущее", другие придерживаются мнения, что "этого не может быть потому, что этого не может быть никогда". Но крайние точки зрения редко оказываются правильными, тем более не стоит принимать их на веру. Гораздо разумнее хоть немного разобраться в технических деталях и составить собственное мнение по интересующему вопросу.

Протоколы и линии

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

Вторая тонкость заключается в двойственной трактовке понятия "линия связи". Обычный модем не позволяет добиться скорости более 56 Kbps, в то время как показатели DSL на той же проводной линии (без ограничения АЧХ) достигают многих сотен килобитов в секунду. Поэтому под "линией связи" следует понимать не только саму среду передачи (например, медный кабель, оптоволокно, эфир), но и оконечные устройства (модемы, адаптеры). Если на компьютерах установлены 10-мегабитные Ethernet-карты, то за секунду мы сможем переслать по этому каналу не более 10 Mb и никакой протокол не позволит увеличить это значение.


Непроизводительные расходы, и как с ними бороться

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

Светлое будущее FastTCPС развитием Internet возникла новая причина неоптимального использования линий передачи данных. На рисунке приведена схема гипотетического фрагмента Internet, состоящего из шести узлов (они обозначены буквами A -- F) и двух маршрутизаторов (R1 и R2). Пропускная способность линий, соединяющих узлы с маршрутизаторами и маршрутизаторы между собой, приблизительно одинакова. До тех пор пока объем трафика остается относительно небольшим, данные свободно перетекают от одного узла к другому, практически не задерживаясь на маршрутизаторах. Но допустим, начиная с некоторого момента A, B и C пересылают информацию для D, E и F на пределе своих возможностей, вернее, на пределе возможностей своих соединений. В результате R1 уже не успевает обрабатывать все пришедшие пакеты, они накапливаются в очереди, которая неуклонно растет и, в конце концов, заполняет приемный буфер. С этого времени пакеты, поступающие на маршрутизатор, попросту теряются. Возникает ситуация, именуемая переполнением.

Теперь обстановка в сети уже напоминает панику среди пассажиров на тонущем корабле. Не получив вовремя очередной пакет, узлы D, E и F требуют от A, B и C повторной передачи данных. Однако вновь отправляемые пакеты лишь усугубляют положение: как только в буфере появляется свободное место, оно тут же заполняется, и последующие пакеты вновь теряются. Наступает так называемый коллапс вследствие переполнения.

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


TCP решает проблемы сетевого уровня

Существует лишь один способ справиться с переполнением: надо на некоторое время снизить скорость передачи. Но сделать это должны одновременно все или почти все передающие узлы (в нашем примере их три, а в реальной ситуации это сотни и даже тысячи компьютеров). Как же достичь подобного единодушия среди множества автономно работающих устройств? Решение может показаться парадоксальным. Известно, что маршрутизаторы работают с протоколами сетевого уровня, главный среди которых -- IP. Однако управление ситуацией переполнения осуществляют не средства поддержки IP, а программы, реализующие TCP-взаимодействие. Невероятно, но факт: проблема, специфичная для сетевого уровня, решается на транспортном. Именно средства TCP обеспечивают распознавание случаев переполнения и организуют замедление передачи данных.

Алгоритмы управления подобными ситуациями стали появляться уже на ранних этапах развития сетей TCP/IP. В частности, вопросы, связанные с переполнением, и способы его предотвращения обсуждаются в документе RFC 896, опубликованном еще в 1984 г. В качестве одного из вариантов оповещения передающих узлов о возникновении переполнения была предложена рассылка ICMP-пакетов Source Quench. Данное сообщение должно рассылаться в случае, если в буфере маршрутизатора не остается места для очередного пакета.

Со временем появились новые реализации протокола TCP, отличающиеся от предыдущих лишь способом управления ситуациями переполнения. В настоящее время в основном применяются TCP Reno и TCP Vegas. В первой для определения реальной пропускной способности участков сети используется индуктивный вывод, а вторая предсказывает возникновение переполнения, анализируя разность между ожидаемой и реальной скоростью обмена. До недавнего времени считалось, что обе реализации TCP работают вполне удовлетворительно, но...


На сцену выходит FastTCP

FastTCP -- не авантюра, а серьезная разработка серьезных ученых. Строго говоря, FastTCP нельзя назвать протоколом. Это лишь умелая модификация алгоритмов взаимодействия TCP и программных средств управления очередями на маршрутизаторах (Active Queue Management -- AQM), позволяющая резко повысить эффективность передачи данных по быстродействующим каналам. Основополагающая статья по данной теме доступна по адресу http://netlab.caltech.edu/pub/papers/fast-030401.pdf. В ней приводятся теоретическое обоснование и исследования пробной реализации FastTCP. Результаты выглядят просто ошеломляюще: FastTCP обеспечивает производительность, в 3,5 раза превышающую показатели современных реализаций TCP. Другими словами, линии, пропускная способность которых используется на 27%, начинают работать на 95% своих возможностей.

Переворот в сетевых технологиях? Не станем, однако, спешить с выводами, а внимательно изучим таблицу с данными экспериментов из указанной публикации. Оказывается, столь выдающийся результат был показан на линии с пропускной способностью около 1 Gbps. При более скромных характеристиках соединения FastTCP по-прежнему демонстрирует прекрасные результаты, но и эффективность традиционно используемых реализаций TCP резко возрастает. Ниже 100 Mbps FastTCP и TCP Vegas имеют примерно равную производительность.

Сами авторы так характеризуют свою разработку: "Технологии FastTCP оптимизированы для пропускной способности порядка 1 Gbps. На менее быстродействующих линиях (10 и даже 100 Mbps) достаточно эффективными оказываются существующие реализации TCP". Значит, рядовому пользователю не стоит тешить себя иллюзиями. Установив на своем компьютере средства поддержки FastTCP, он не почувствует даже намека на ускорение работы.

Вот почему говорить о революции в области сетевых технологий рановато. Как известно, чудес не бывает, и линии, на которых протокол FastTCP может продемонстрировать все свои возможности, в настоящее время распространены отнюдь не повсеместно. Однако не стоит жить лишь днем сегодняшним. Еще несколько лет назад линии протяженностью несколько сотен километров считались чрезвычайно высокоскоростными, если их пропускная способность достигала 10 Mbps. Будем надеяться, что недалек тот час, когда гигабитные соединения перестанут кого-либо удивлять. Тогда и FastTCP окажется весьма кстати.
0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT