Реферат: Разработка методов определения эффективности торговых интернет систем

сообщения всех участников сеанса, администратор сети может определить,

касается данная проблема одного участника или носит общий характер. Если

приложение-отправитель приходит к выводу, что проблема характерна для

системы в целом, например, по причине отказа одного из каналов связи, то

оно может увеличить степень сжатия данных за счет снижения качества или

вообще отказаться от передачи видео — это позволяет передавать данные по

соединению низкой емкости.

Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое

описание отправителя. Они предоставляют больше информации об отправителе

пакетов данных, чем случайным образом выбранный идентификатор источника

синхронизации. Кроме того, они помогают пользователю идентифицировать

потоки, относящиеся к различным сеансам.

Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг

и обратной связи с целью управления загруженностью, а также с целью

идентификации отправителя, все участники периодически посылают пакеты

RTCP. Частота передачи этих пакетов снижается с ростом числа участников.

При небольшом числе участников один пакет RTCP посылается максимум

каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому

участники ограничивают частоту RTCP-пакетов в зависимости от общего

числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5%

от общего трафика сеанса.

Формат заголовка протокола RTP

RTP — потоко -ориентированный протокол. Заголовок RTP-пакета создавался с

учетом потребностей передачи в реальном времени. Он содержит информацию о

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

принимающем конце, и временную метку для правильного чередования кадров

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

например, видео и аудио.

Каждый пакет RTP имеет основной заголовок, а также, возможно,

дополнительные поля, специфичные для приложения.

Использование TCP в качестве транспортного протокола для этих приложений

невозможно по нескольким причинам:

• Этот протокол позволяет установить соединение только между двумя конечными точками, следовательно, он не подходит для многоадресной передачи.
• TCP предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет.
• TCP не имеет удобного механизма привязки информации о синхронизации к сегментам — дополнительное требование приложений реального времени.

Другой широко используемый протокол транспортного уровня — LJDP не имеет

части ограничений TCP, но и он не предоставляет критической информации о

синхронизации.

Несмотря на то, что каждое приложение реального времени может иметь свои

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

много общих черт, а это делает определение единого протокола весьма

желательным.

Эту задачу и призван решить новый транспортный протокол реального времени

— RTP (Real-time Transport Protocol), который гарантирует доставку данных

одному или более адресатам с задержкой в заданных пределах, т. е. данные

могут быть воспроизведены в реальном времени.

3.4 Протокол управления передачей RTCP

 

Протокол управления передачей RTCP (Real-Time Transport Control Protocol)

работает с несколькими адресатами для обеспечения обратной связи с

отправителями данных RTP и другими участниками сеанса. RTCP использует тот

же самый базовый транспортный протокол, что и RTP (обычно, UDP), но другой

номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем

остальным участникам сеанса.

RTCP выполняет следующие функции:

• обеспечение качества услуг и обратной связи в случае перегрузки;
• идентификация отправителя;
• оценка размеров сеанса и масштабирование.

Многоадресность RTCP-пакетов дает возможность участникам группы оценить

качество приема и сообщить о своих проблемах (например, утере пакетов,

избыточной неравномерности передачи). Обратная связь с получателями важна

также для диагностики ошибок при распространении пакетов.

RTCP-пакеты содержат стандартное текстовое описание отправителя,

обеспечивающее его идентификацию. Кроме того, они помогают пользователю

идентифицировать потоки, относящиеся к различным сеансам. Например, они

дают возможность определить, что одновременно открыты отдельные сеансы для

передачи аудио- и видеоинформации.

Оценка размера сеанса и масштабирование осуществляются управлением

частотой передачи RTCP-пакетов. При небольшом числе участников один

RTCP-пакет посылается максимум каждые 5 секунд. Цель состоит в том, чтобы

трафик RTCP не превышал 5% от общего трафика сеанса.

3.5 Протокол UDP

Протокол UDP намного проще, чем ТСР; он полезен в ситуациях, когда мощные механизмы обеспечения надежности протокола ТСР не обязательны. Заголовок UDP имеет всего четыре поля: поле порта источника (source port), поле порта пункта назначения (destination port), поле длины (length) и поле контрольной суммы UDP (checksum UDP). Поля порта источника и порта назначения выполняют те же функции, что и в заголовке ТСР. Поле длины обозначает длину заголовка UDP и данных; поле контрольной суммы обеспечивает проверку целостности пакета. Контрольная сумма UDP является факультативной возможностью.

Главным применением протокола UDP являются системы Internet Name Server, и Trivial File Transfer, SNMP.

Структура протокольного блока

Байты	Разряды
	7 6 5 4 3 2 1 0	7 6 5 4 3 2 1 0	7 6 5 4 3 2 1 0	7 6 5 4 3 2 1 0
0	Порт источника		Порт получателя
4	Длина протокольного блока		Проверочная сумма
8 . .	Данные

Номера портов источника и получателя определяют прикладной процесс, инициировавший данное соединение. Закрепление номеров портов осуществляется в соответствии с Рекомендацией RFC-1700.

Мультиплексирование и демультиплексирование прикладных протоколов с помощью протокола UDP

Протокол UDP ведет для каждого порта две очереди: очередь пакетов, поступающих в данный порт из сети, и очередь пакетов, отправляемых данным портом в сеть.

Процедура обслуживания протоколом UDP запросов, поступающих от нескольких различных прикладных сервисов, называется мультиплексированием.

Распределение протоколом UDP поступающих от сетевого уровня пакетов между набором высокоуровневых сервисов, идентифицированных номерами портов, называется демультиплексированием.

Хотя к услугам протокола UDP может обратиться любое приложение, многие из них предпочитают иметь дело с другим, более сложным протоколом транспортного уровня TCP. Дело в том, что протокол UDP выступает простым посредником между сетевым уровнем и прикладными сервисами, и, в отличие от TCP, не берет на себя никаких функций по обеспечению надежности передачи. UDP является дейтаграммным протоколом, то есть он не устанавливает логического соединения, не нумерует и не упорядочивает пакеты данных.

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

3.6 Семиуровневая модель OSI

Модель OSI (Open System Interconnect Reference Model, Эталонная модель взаимодействия открытых систем) представляет собой универсальный стандарт на взаимодействие двух систем (компьютеров) через вычислительную сеть.

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17