Сетевые технологии. Кольтюков Н.А - 28 стр.

UptoLike

abort operation (прервать команду), будет передана на сервер по самому скоростному маршруту и соот-
ветственно за минимальное время (оперативно отменив при этом загрузку файла с сервера).
Почему же лишь немногие приложения поддерживают функции байта ToS? Да потому, что большая
часть операционных систем, в среде которых они работают, не обеспечивает надлежащую поддержку
этих функций. И до тех пор, пока Microsoft не модифицирует программный интерфейс WINSOCK.DLL
системы Windows, поставщики приложений вроде Lotus Development, Netscape Communications и Oracle
не смогут реализовать в своих приложениях механизмы управления приоритетами.
Тем не менее существуют способы, позволяющие обходить те проблемы, которые не спешат решать
поставщики операционных систем и приложений. Самый верный из них реализовать службы приори-
тезации трафика IP не в приложениях и операционных системах, а в устройствах сетевой инфраструк-
туры. Администраторы многих крупных и сильно загруженных сетей уже несколько лет осуществляют
приоритезацию с помощью фильтров, устанавливаемых в маршрутизаторах отдельно для каждого при-
ложения.
Так, например, можно вручную определить фильтр, обеспечивающий обслуживание с более высо-
ким уровнем приоритета, скажем, трафика Notes, по сравнению с трафиком FTP. И хотя такой способ не
отличается особым изяществом, его можно использовать, если не в масштабе сети всего предприятия,
то по крайней мере в пределах отдельных её сегментов.
Существует немало средств для реализации в IP-сетях различных механизмов управления приори-
тетами, ориентированных на конкретные приложения. Эти механизмы можно связать со схемой при-
оритезации, определённой в спецификациях 802.1Q и 802.1P.
1.13. ПРОТОКОЛЫ RTP И RSVP
Современные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два про-
токола (RTP и PSVP) позволяют гарантировать своевременность доставки с обеспечением качества ус-
луг.
Непрекращающийся рост Интернета и частных сетей предъявляет новые требования к пропускной
способности. Клиент-серверные приложения далеко превосходят Telnet по объёмам передаваемых дан-
ных. World Wide Web привёл к гигантскому увеличению графика графической информации. Сегодня к
тому же голосовые и видеоприложения выдвигают свои специфические требования к и без того пере-
груженным сетям.
Для того чтобы удовлетворить все эти запросы, одного увеличения ёмкости сети недостаточно. Что
действительно необходимо, так это разумные эффективные методы управления графиком и контроль
загруженности.
Исторически сети на базе IP предоставляли всем приложениям только простейшую услугу по дос-
тавке данных по мере возможности. Однако потребности со временем изменились. Организации, потра-
тившие миллионы долларов на установку сети на базе IP для передачи данных между локальными сетя-
ми, сталкиваются теперь с тем, что такие конфигурации не способны эффективно поддерживать новые
мультимедийные приложения реального времени с многоадресной рассылкой.
АТМ единственная сетевая технология, которая изначально разрабатывалась для поддержки
обычного трафика Transfer Control Protocol (TCP) и User Datagram Protocol (UDP) наряду с трафиком
реального времени. Однако ориентация на АТМ означает либо создание новой сетевой инфраструктуры
для трафика реального времени, либо замену имеющейся конфигурации на базе IP, причём оба варианта
обойдутся весьма недёшево.
Поэтому потребность в поддержке нескольких типов трафика с различными требованиями к каче-
ству услуг в рамках архитектуры TCP/IP весьма насущна. Эту задачу призваны решить два ключевых
инструмента: транспортный протокол реального времени (Real-Time Transport Protocol, RTP) и прото-
кол резервирования ресурсов (Resource Reservation Protocol, RSVP).
RTP гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это
означает, что данные могут быть воспроизведены в реальном времени. RSVP позволяет конечным систе-
мам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы
для трафика реального времени по протоколу RTP.
Наиболее широко используемый протокол транспортного уровня это TCP. Хотя TCP позволяет
поддерживать множество разнообразных распределённых приложений, он не подходит для приложений
реального времени.
В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью,
а получатель(-и) должен предоставлять эти данные приложению с той же самой скоростью. Такие при-