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

Решение этой проблемы состоит в буферизациипакетов на приемнике перед их воспроизведением. В примере, изображенном на рис. 6.28, мы видим поток пакетов, прибывающих на место назначения с достаточно большим джиттером. Пакет 1 был передан с сервера в момент времени t = 0 с и прибыл к клиенту в момент времени t = 1 с. Пакет 2 задерживается и прибывает через 2 с. По прибытии пакеты помещаются в буфер на машине клиента.

В момент времени t = 10 с начинается воспроизведение. В буфере уже находятся пакеты с 1 по 6, поэтому их можно доставать оттуда через равные промежутки времени и тем самым обеспечить равномерное воспроизведение. В общем случае равные промежутки времени использовать не обязательно, так как метки времени RTP содержат информацию о том, когда следует начать воспроизведение.

К сожалению, пакет 8 задерживается настолько, что не успевает прибыть к тому моменту, когда он должен быть воспроизведен. В таком случае возможны два варианта. Проигрыватель может пропустить восьмой пакет и перейти к воспроизведению следующих пакетов. Или же он может остановить воспроизведение до тех пор, пока не прибудет восьмой пакет, и тем самым создать неприятную паузу в музыке или фильме. Если приложение работает в режиме реального времени (например, при звонке через Интернет), то пакет, скорее всего, будет пропущен. Такие приложения не очень хорошо работают в режиме ожидания. В приложениях, работающих с потоковым мультимедиа, проигрыватель может на время остановить воспроизведение. Чтобы улучшить ситуацию, можно начать воспроизведение еще позже и использовать буфер большего размера. Проигрыватели потокового аудио и видео часто используют буферы размером около 10 с, чтобы все пакеты (кроме тех, которые были потеряны) успели прийти вовремя. Приложения, работающие в реальном времени (например, видеоконференции) и требующие быстрой ответной реакции, используют маленькие буферы.

Рис. 6.28. Выравнивание выходного потока с помощью буферизации пакетов

При равномерном воспроизведении ключевую роль играет задержка воспроизведения( playback point), то есть время, которое получатель должен ждать медиаданных, прежде чем начать их воспроизведение. Этот параметр зависит от джиттера. Различие между соединением с маленьким и большим джиттером показано на рис. 6.29. Средняя задержка может отличаться не сильно, однако при большом джиттере может потребоваться задержка воспроизведения, захватывающая 99 % пакетов — гораздо больше, чем при маленьком джиттере.

Чтобы правильно подобрать задержку воспроизведения, приложение может измерять джиттер, вычисляя разницу между значениями меток времени RTP и временем прибытия. Эта разница (плюс некоторая константа) и составляет задержку каждого отдельного пакета. Однако некоторые факторы, такие как конкурирующий трафик и изменение маршрутов, могут стать причиной изменения времени задержки. Приложения должны учитывать это и при необходимости менять задержку воспроизведения. Но при неправильной реализации такое изменение может вызвать сильные помехи. Одно из возможных решений для аудио состоит в том, чтобы корректировать задержку воспроизведения между сегментами речи( talkspurts), то есть во время пауз. Разница между короткой паузой и чуть более длинной вряд ли будет заметна. Чтобы это было возможным, RTP позволяет приложениям отмечать начало нового сегмента речи с помощью маркера M.

Рис. 6.29.Джиттер: а — большой; б — маленький

Ситуация, в которой медиаданные не проигрываются слишком долго, представляет серьезную проблему для приложений, работающих в реальном времени. Не существует способа уменьшить задержку распространения, если уже и так используется кратчайший путь. Задержку воспроизведения можно снизить за счет увеличения доли пакетов, опаздывающих к началу проигрывания. Если это недопустимо, остается последний вариант: уменьшить джиттер, запросив более высокое качество обслуживания — например, дифференцированный сервис с приоритетной доставкой. Иными словами, для этого требуется сеть с лучшими параметрами.

6.5. Транспортные протоколы Интернета: TCP

UDP является простым протоколом и имеет очень важную область применения. В первую очередь, это клиент-серверные взаимодействия и мультимедиа. Тем не менее большинству интернет-приложений требуется надежная, последовательная передача. UDP не удовлетворяет этим требованиям, поэтому необходим иной протокол. Такой протокол называется TCP, и он является рабочей лошадкой Интернета. Ниже мы рассмотрим его детально.