Эндрю Уэзеролл - Компьютерные сети. 5-е издание

С точки зрения протоколов транспортного уровня UDP является хорошей основой для реализации RPC. В простейшем случае запросы и ответы можно отправлять в одном UDP-пакете, а обработка может выполняться очень быстро. Однако для реализации этой идеи потребуются и другие механизмы. На случай потери запроса или ответа клиенту необходим таймер, отсчитывающий время до повторной отправки пакета. Обратите внимание на то, что ответ служит неявным подтверждением запроса, поэтому запрос не требует отдельного подтверждения. Иногда параметры или результаты могут оказаться больше максимального размера UDP-пакета, поэтому для отправки больших сообщений также требуется специальный протокол. Если множественные запросы и ответы могут пересекаться (как в случае параллельного программирования), соответствие ответа запросу должно быть указано с помощью специальной метки.

Проблема более высокого уровня связана с тем, что операция может не быть идемпотентной (то есть не может повторяться без риска сбоя). В простом случае мы имеем дело с идемпотентными операциями, такими как DNS-запросы и ответы. Клиент может повторно без риска передавать такие пакеты сколько угодно раз, до тех пор пока не придет ответ. Не важно, в чем причина: либо пакет не дошел до сервера, либо был потерян ответ. В любом случае ответ, когда он придет, будет одним и тем же (если, конечно, за это время не обновится база данных DNS). Однако не все операции идемпотентны — например, потому, что они могут включать побочные действия наподобие инкрементирования счетчика. RPC для таких операций требует более сложной семантики: при вызове процедуры она не должна выполняться несколько раз. В таких случаях может понадобиться установка TCP-соединения и отправки запроса по TCP, а не по UDP.

6.4.3. Транспортные протоколы реального масштаба времени

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

Так появился на свет протокол RTP (Real-Time Transport Protocol — транспортный протокол реального масштаба времени). Он описан в RFC 3550 и ныне широко используется для мультимедийных приложений. Мы рассмотрим два аспекта транспортировки данных в реальном времени. Первый из них — протокол RTP, использующийся для пакетной передачи аудио и видео. Второй аспект — обработка данных, необходимая для воспроизведения (в основном со стороны получателя). Эти функции входят в стек протоколов, изображенный на рис. 6.26.

RTP обычно работает поверх UDP (в операционной системе). Делается это так. Мультимедийное приложение может состоять из нескольких аудио-, видео-, текстовых и некоторых других потоков. Они прописываются в библиотеке RTP, которая, как и само приложение, находится в пользовательском пространстве. Библиотека уплотняет потоки и помещает их в пакеты RTP, которые, в свою очередь, отправляются в сокет. На другом конце сокета (в операционной системе) генерируются UDP-пакеты, в которые помещаются RTP-пакеты. Они передаются протоколу IP для отправки по каналу (например, Ethernet). На хосте-получателе происходит обратный процесс. В конечном итоге мультимедийное приложение получает данные из RTP-библиотеки. Оно отвечает за воспроизведение мультимедиа. Стек протоколов для описанной ситуации показан на рис. 6.26, а. Система вложенных пакетов показана на рис. 6.26, б.

В результате оказывается непросто определить, к какому уровню относится RTP. Так как протокол работает в пользовательском пространстве и связан с прикладной программой, он, несомненно, выглядит, как прикладной протокол. С другой стороны, он является общим, независимым от приложения протоколом, который просто предоставляет транспортные услуги, не более. С этой точки зрения он может показаться транспортным протоколом. Наверное, лучше всего будет определить его таким образом: RTP — это транспортный протокол, который случайно оказался на прикладном уровне, и именно поэтому мы говорим о нем в этой главе.