|
|
|
|
|
|
|
|
|
|
|
страницы:
1
2
3
4
5
6
Текущая страница: 1
|
|
Непрекращающийся рост Internet и частных сетей предъявляет новые требования к пропускной способности. World Wide Web привел к гигантскому увеличению трафика графической информации. Сегодня еще и голосовые, а также видеоприложения выдвигают свои специфические требования к и без того перегруженным сетям.
Чтобы удовлетворить все эти запросы, одного увеличения емкости сети недостаточно. Что действительно необходимо, так это разумные эффективные методы управления трафиком и контроль загруженности.
Исторически сети на базе IP предоставляли всем приложениям только простейшую услугу по доставке данных по мере возможности. Однако потребности изменились со временем. Организации, потратившие миллионы долларов на установку сети на базе IP для передачи данных между локальными сетями, сталкиваются теперь с тем, что такие конфигурации не способны эффективно поддерживать новые мультимедийные приложения реального времени с многоадресной рассылкой.
ATM - единственная сетевая технология, изначально разрабатывавшаяся для поддержки обычного трафика TCP и UDP наряду с трафиком реального времени. Однако ориентация на ATM означает либо создание новой сетевой инфраструктуры для трафика реального времени, либо замену имеющейся конфигурации на базе IP, причем обе альтернативы обойдутсявесьма недешево.
Поэтому потребность в поддержке нескольких типов трафика с различными требованиями к качеству услуг в рамках архитектуры TCP/IP весьма насущна. Эту задачу призваны решить два ключевых инструмента: транспортный протокол реального времени (Real-Time Transport Protocol, RTP) и протокол резервирования ресурсов (Resource Reservation Protocol, RSVP).
RTP гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это означает, что данные могут быть воспроизведены в реальном времени. RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы для трафика реального времени по протоколу RTP.
Наиболее широко используемый протокол транспортного уровня - это TCP. Несмотря на то что TCP позволяет поддерживать множество разнообразных распределенных приложений, он не подходит для приложений реального времени.
В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, а получатель(-и) должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают аудио- и видеоконференции, распространение живого видео (для немедленного воспроизведения), разделяемые рабочие области, удаленную диагностику в медицине, компьютерную телефонию, распределенное интерактивное моделирование, игры и мониторинг в реальном времени.
Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам. Во-первых, этот протокол позволяет установить соединение только между двумя конечными точками, следовательно, он не подходит для многоадресной передачи. Он предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет. Кроме того, у TCP нет удобного механизма привязки информации о синхронизации к сегментам - другое требование приложений реального времени.
Другой широко используемый протокол транспортного уровня UDP не имеет первых двух ограничений (соединение точка-точка и передача потерянных сегментов), но и он не предоставляет критической информации о синхронизации. Таким образом, UDP не предоставляет сам по себе каких-либо инструментов общего назначения для приложений реального времени.
Несмотря на то что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает определение единого протокола весьма желательным. Стандартный протокол такого рода - RTP, определенный в RFC1889.
В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются им через одинаковые интервалы времени, проходят через сеть и принимаются получателем, воспроизводящим данные в реальном времени по их получении.
Однако ввиду вариации задержки при передаче пакетов по сети они прибывают через нерегулярные интервалы времени. Для компенсации этого эффекта поступающие пакеты буферизуются, придерживаются на некоторое время и затем предоставляются с постоянной скоростью программному обеспечению, генерирующему вывод. Чтобы такая схема работала, каждый пакет получает отметку о времени - таким образом получатель может воспроизвести поступающие данные с той же скоростью, что и отправитель.
RTP поддерживает передачу данных в реальном времени между несколькими участниками сеанса. (Сеанс - это логическая связь между двумя и более пользователями RTP, поддерживаемая в течение всего времени передачи данных. Процесс открытия сеанса выходит за рамки RTP.).
Хотя RTP может использоваться и для одноадресной передачи в реальном времени, его сила в поддержке многоадресной передачи. Для этого каждый блок данных RTP содержит идентификатор отправителя, указывающий, кто из участников генерирует данные. Блоки данных RTP содержат также отметку о времени, чтобы данные могли быть воспроизведены с правильными интервалами принимающей стороной.
Текущая страница: 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
