ККС Часть1
.pdf2.Какое максимальное количество подсетей теоретически возможно организовать, если в вашем распоряжении имеется сеть класса С? Какое значение должна при этом иметь маска?
3.Какие из приведенных адресов не могут быть использованы в качестве IP-адреса конечного узла сети, подключенной к Internet? Для синтаксически правильных адресов определите их класс. (Данные взять у преподавателя.
4.Выясните IPv4-адрес и маску подсети вашего узла. К какому классу относится данная есть?
5.Определите параметры команды ping.
6.Протестируйте работоспособность программного обеспечения стека протоколов TCP/IP при помощи команды ping.
7.Проверьте наличие «эха» от заданного узла с IP-адресом Z. (Значение Z взять у преподавателя).
8.Определите МАС-адрес по известному IP-адресу.
62
Лабораторная работа № 3.
Протоколы для использования потоковых аудиовидеотрансляций
Цель работы: изучить назначение основных протоколов стека протоколов TCP/IP; научиться работать с потоковыми протоколами.
Протокол UDP (User Datagram Protocol) разработан для предоставления прикладным программам транспортных услуг. UDP так же, как и IP обеспечивает негарантированную доставку дейтаграмм (рисунок 3.1) получателю и не поддерживает установку соединений. В модели стека TCP/IP он располагается над протоколом IP.
Рисунок 3.1. Заголовок UDP
Взаимодействие между прикладными программами и протоколом UDP осуществляется через так называемые протокольные порты. Протокольные порты определяют соответствие между абстрактными точками доступа к протоколу UDP и конкретными прикладными программами. Механизм протокольных портов позволяет рабочей станции одновременно поддерживать несколько сеансов связи с удаленными компьютерами и программами в сети. Можно также сказать, что протокольный порт служит для указания программы-получателя информации. Когда рабочая станция получает дейтаграмму с ее IP-адресом, она направляет эту дейтаграмму конкретной программе, используя номер протокольного порта, который определяется во время установки сеанса связи. Следует отметить, что протокольные порты протокола UDP отличаются от протокольных портов протокола TCP.
Назначение портов происходит при участии сетевой операционной системы. Большинство операционных систем обеспечивают параллельный доступ к протокольным портам. Протокольный порт идентифицируется целым положительным числом. Для связи с протокольным портом на другой рабочей станции отправитель должен знать IP-адрес получателя и номер порта на этой рабо-
63
чей станции. Каждое сообщение содержит также номер протокольного порта отправляющей рабочей станции. Таким образом, прикладная программа, получающая сообщения, может напрямую ответить отправителю.
Некоторые номера протокольных портов стандартизированы. Номера вы-
деляются центральным органом– IANA (Internet Assigned Numbers Authority).
Она регулярно публикует список назначений. Эти протокольные порты зарезервированы и их использование контролируется IANA. В большинстве систем они могут использоваться только системными процессами или программами, выполняемыми привилегированными пользователями. Несколько лет назад эти протокольные порты использовали диапазон номеров от 0 до 255. Однако недавно IANA расширила этот диапазон – теперь она отвечает за назначение портов с номерами от 0 до 1023.
Остальные порты могут назначаться динамически. Сетевое программное обеспечение назначает протокольный порт, когда программа в нем нуждается. Такие протокольные порты не контролируются IANA и могут свободно использоваться пользовательскими процессами. Номера этих протокольных портов лежат в диапазоне от 1024 до 65 535. Протокольные порты в диапазоне от 1024 до 5000 называются временными (ephemeral). Хотя IANA не контролирует использование этих протокольных портов, она поддерживает информацию о них в интересах сообщества пользователей Internet.
Протокол RTP (Real-Time Transport Protocol). Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов TCP/IP сейчас весьма актуально. Эту задачу призван решить транспортный протокол реального времени, который является стандартом IETF для передачи таких данных, как голос или видео в реальном времени по сети, не гарантирующей качества обслуживания.
Протокол RTP гарантирует доставку данных одному или нескольким адресатам с задержкой, не превышающей указанное значение. Для этого в заголовке протокола предусмотрены временные отметки, необходимые для успеш-
64
ного восстановления аудио- и видеоинформации, а также данные о способе кодирования информации.
Хотя протокол TCP гарантирует доставку передаваемых данных в нужной последовательности, трафик при этом неравномерен, то есть при доставке дейтаграмм происходят непредсказуемые задержки. Так как протокол RTP учитывает содержимое дейтаграмм и обладает механизмами обнаружения потери данных, он позволяет снизить задержки до приемлемого уровня.
Рисунок 3.2. Заголовок RTP
Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:
v (Версия): 2 бита – это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 - в аудио приложении "vat".
p (Заполнитель): 1 бит. Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.
x (Расширение): 1 бит. Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.
CC(CSRC count - число CSRC): 4 бита. Число CSRC содержит код количества csrc-идентификаторов, которые записаны в пакете.
M (маркер): 1 бит. Интерпретация маркера определяется профайлом. Предполагается разрешить выделять в потоке пакетов существенные со-
65
бытия, такие как границы кадра. Профайл может определить дополнительные маркерные биты или специфицировать отсутствие маркерных битов путем изменения числа битов в поле PT.
PT(Тип данных): 7 бит. Идентифицирует формат поля данных RTP-пакета и определяет интерпретацию его приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле, и может быть расширен в сле-
дующих редакциях стандарта assigned numbers (RFC-1700).
Номер по порядку: 16 бит. Инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов. Начальное значение кода является случайным.
Временная метка: 32 бита. Соответствует времени стробирования для первого октета в информационном RTP-пакете. Время стробирования должно быть получено от часов, показания которых увеличиваются монотонно и линейно, чтобы обеспечить синхронизацию и вычисление временного разброса. Разрешающая способность часов должна быть достаточной для обеспечения приемлемой точности синхронизации (одного тика на видео кадр обычно не достаточно). Частота часов зависит от формата данных и задается статически в профайле, в спецификации поля данных, или динамически средствами, выходящими за пределы спецификации протокола RTP. Если RTP-пакеты генерируются периодически, используется временная привязка, определенная задающим генератором стробирования, а не показаниями системных часов. Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к и тому же видео кадру).
SSRC: 32 бита. Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в преде-
66
лах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.
CSRC-список: от 0 до 15 элементов, по 32 бита каждый. CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.
RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям. RTP/RTCP/RSVP — стандартизованное решение для сетей с передачей данных в реальном времени. Единственным его недостатком является то, что оно предназначено только для IPсетей. Однако это ограничение временное: сети так или иначе будут развиваться в этом направлении. Данное решение обещает решить проблему передачи чувствительных к задержкам данных по Internet.
Протокол TSP (Time Streaming Protocol) представляет собой протокол прикладного уровня, во многом подобный HTTP и FTP в стеке TCP/IP. Его уникальным свойством является то, что он предоставляет пользователю возможность управления медиапотоком. Работает RTSP совместно с протоколами нижнего уровня, такими, как RTP, RSVP, IP и TCP/UDP.
Важно понимать, что он не занимается транспортом данных – это протокол, который, кроме управляющих функций, обеспечивает взаимодействие между оборудованием различных производителей, разными типами файлов и кодировщиками.
RTSP наделен свойствами масштабируемости и взаимодействия, во многом подобными протоколу HTTP. Фактически каждая презентация или мультимедиа поток идентифицируется в протоколе своим URL. Свойства презентации наряду с другими спецификациями сохраняются в файле дескриптора презентации, также имеющего свой собственный URL.
67
Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видео потока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP.
Сервис RTSP поддерживается набором инструкций, которыми обмениваются между собой сервер и клиент. Они отсылаются в виде RTSP-пакетов, содержащих установочные параметры для потока:
DESCRIBE. Клиент требует у сервера описание презентации или медиа объекта, указанное в URL запроса;
ANNOUNCE. Если эта инструкция посылается от клиента серверу, то в ней содержится описание презентации или медиаобъекта, указанное в URL запроса к серверу. Отправленная в обратном направлении, она обновляет описание сессии в режиме реального времени;
SETUP. Клиент запрашивает у сервера ресурсы и начинает RTSPсессию;
PLAY. Клиент просит сервер начать передачу данных в потоке, выделенном с помощью SETUP;
PAUSE. Клиент временно приостанавливает доставку данных без освобождения ресурсов;
TEARDOWN. Клиент просит сервер прекратить доставку указанного потока и освободить связанные с ним ресурсы.
Вначале клиент направляет серверу запрос DESCRIBE, чтобы получить URL файла с описанием медиа данных. После ответа сервера клиент посылает инструкцию SETUP для выделения необходимых ресурсов. Наконец, клиент направляет серверу инструкцию PLAY, чтобы начать воспроизведение.
68
Real-Time Transport Control Protocol (RTCP) выполняет функции управления и, взаимодействуя непосредственно с RTP, поставляет последнему управляющую информацию для диагностики и оптимизации производительности. Вдобавок он осуществляет контроль качества доставки данных. Основные функции протокола следующие:
мониторинг QoS и управление перегрузками канала;
идентификация источника;
внутренняя синхронизация аудиовизуальной информации;
управление масштабированием.
Выполнение двух первых функций является главной задачей RTCP. Паке-
ты, которыми обмениваются пользователи, содержат сведения, позволяющие их приложениям работать в сетях с низкой пропускной способностью, с буферизацией или без нее. Отправитель, основываясь на пакетах обратной связи, генерируемых протоколом RTCP на узле получателя, может настроить скорость передачи данных. Эти пакеты могут быть также использованы сетевым администратором для оценки производительности сети.
Идентификация источника проводится на основании информации, размещающейся в заголовке RTP. Протокол RTCP преобразует 32-битное значение соответствующего поля заголовка в уникальные глобальные имена, которые идентифицируют участников любой сессии.
Для внутренней синхронизации аудиовизуальной информации используются временные метки RTP и соответствующее значение реального времени. Это позволяет, к примеру, синхронизировать голос и изображение в мультимедийных презентациях. Наконец, RTCP производит масштабирование информации, в результате чего ограничивается сетевой трафик.
Чтобы обеспечить выполнение всех этих функций, протокол генерирует ряд специальных управляющих пакетов.
Receiver Report (RR). Эти пакеты создаются участниками сессии, не являющимися активными отправителями. Они содержат такую информацию, как
69
подтверждение получения пакетов, неустойчивость синхронизации между входящими пакетами, задержку, связанную с подтверждением приема.
Sender Report (SR). Такие сообщения посылаются активными отправителями, участвующими в сессии. В дополнение к информации, содержащейся в RR, они включают также данные о внутренней аудиовизуальной синхронизации и количестве отправленных байтов.
Source Description Items (SDES). Пакеты этого типа содержат информацию об участниках сессии.
BYE. "Прощальный" пакет, с помощью которого пользователь отключается от сессии.
APP. В пакет входят сведения о специфических функциях приложения.
Протоколы Multicast, Unicast, P2P. Протоколы Unicast отправляют от-
дельную копию данных каждому клиенту. Unicast подходит для большинства пользователей сети Интернет, но сильно затрудняет масштабирование сервера для большего количества клиентов. При широковещательной передаче одна копия данных передается всем клиентам сервера.
Протоколы Multicast разработаны для снижения нагрузки с серверов на подключения/ширину канала при получении потокового мультимедиа большим количеством клиентов. Эти протоколы отсылают одну порцию данных целой группе клиентов. В зависимости от типа сетевой инфраструктуры, групповая передача данных может быть доступна, а может и не быть. Одним из потенциальных недостатков групповой передачи является отсутствие возможности реализовать функцию видео по запросу. Непрерывное вещание потоковой информации также делает невозможным управление воспроизведением пользователем. Эта проблема может быть решена внедрением в сеть передачи данных кэширующих серверов и буферизирующего принимаемый поток программного обеспечения.
Multicast позволяет передавать один поток информации группе клиентов по сети. Одной из проблем при реализации подобной схемы потокового вещания является корректная настройка маршрутизаторов для передачи широкове-
70
щательных пакетов из одного сегмента сети в другой. Если организация, предоставляющая потоковое вещание, имеет контроль над сетью между сервером и клиентами (например, в образовательной, правительственной или корпоративной сети), то протоколы маршрутизации, такие как IGMP и PIM, могут быть использованы для доставки мультимедиа нескольким клиентам из различных сегментов LAN.
Протоколы P2P могут использоваться при распространении предварительно записанной мультимедиа между компьютерами. Это снимает нагрузку с сервера, однако сеть передачи данных между сервером и одним из клиентов становится узким местом данного варианта реализации потокового вещания информации.
Система вещания на основе VLC Media Player
1. На всех компьютерах необходимо установить VLC Media Player.
2.На компьютере, который будет сервером, открываем плеер и заходим в главное меню «Медиа» - «Потоковое вещание» (рисунок 3.3).
Рисунок 3.3. Меню «Медиа»
3.Добавляем медиа файл в список воспроизведения. Для этого нажимаем кнопку «Добавить» и с помощью проводника Windows выбираем файл.
4.После того, как файл добавлен в плейлист, в нижней части окна нажимаем кнопку «Поток».
5.В следующем окне нажать кнопку «Следующий».
71