Компьютерные сети. 6-е изд.

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

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

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

UDP — это простой протокол, предназначенный для таких важных областей применения, как клиент-серверные взаимодействия и мультимедиа. Однако большинству интернет-приложений требуется надежная, последовательная передача, которую UDP обеспечить не может. Для них следует использовать другой протокол — TCP, «рабочую лошадку» интернета. Далее мы подробно его рассмотрим.

6.5.1. Основы TCP

Протокол управления передачей (Transmission Control Protocol, TCP) был разработан специально для обеспечения надежного сквозного байтового потока по ненадежной интерсети. Интерсеть отличается от отдельной сети тем, что ее участки могут сильно различаться по топологии, пропускной способности, значениям времени задержки, размерам пакетов и другим параметрам. При разработке TCP основное внимание уделялось способности протокола адаптироваться к свойствам интерсети и отказоустойчивости при возникновении всевозможных проблем.

TCP был описан в RFC 793 в сентябре 1981 года. Со временем он был во многом усовершенствован, были исправлены различные ошибки и неточности. На сегодняшний день существует множество других RFC, являющихся дополнениями к RFC 793 (что позволяет судить о распространенности этого протокола). Уточнения и исправления описаны в RFC 1122, расширения для высокой производительности — в RFC 1323, выборочные подтверждения — в RFC 2018, контроль перегрузки — в RFC 2581, использование полей заголовка для QoS — в RFC 2873, усовершенствованные таймеры повторной передачи — в RFC 2988, явные уведомления о перегрузке — в RFC 3168. Поскольку это далеко не полный список, для удобной работы со всеми этими RFC был создан специальный указатель (конечно же, в виде еще одного RFC-документа) — RFC 4614.

Каждый компьютер, поддерживающий TCP, имеет транспортную подсистему TCP, которая является либо библиотечной процедурой, либо пользовательским процессом, либо (чаще всего) частью ядра системы. В любом случае транспортная подсистема управляет TCP-потоками и интерфейсом с IP-уровнем. Она принимает потоки пользовательских данных от локальных процессов, делит их на части, не превышающие 64 Кбайт (на практике это число обычно равно 1460 байтам данных, что позволяет поместить их в один фрейм Ethernet с заголовками IP и TCP), и отправляет их в виде отдельных IP-дейтаграмм. Когда IP-дейтаграммы с TCP-данными приходят на компьютер, они передаются TCP-подсистеме, которая восстанавливает исходный байтовый поток. Для простоты мы иногда будем употреблять «TCP» для обозначения транспортной подсистемы TCP (части программного обеспечения) или протокола TCP (набора правил). Из контекста будет понятно, что имеется в виду. Например, в выражении «Пользователь передает данные TCP» подразумевается, естественно, транспортная подсистема TCP.

Уровень IP не гарантирует правильной доставки дейтаграмм и не накладывает ограничений на скорость их отправки. Именно TCP приходится выбирать правильную скорость отправки (согласно целям эффективного использования пропускной способности и предотвращения перегрузок), следить за истекшими интервалами ожидания и в случае необходимости заниматься повторной передачей дейтаграмм, не достигших адресата. Иногда дейтаграммы доставляются в неправильном порядке. Восстанавливать из них сообщения также обязан TCP. Таким образом, протокол TCP призван обеспечить хорошую производительность и надежность, о которой мечтают многие приложения и которая не предоставляется протоколом IP.

6.5.2. Модель службы TCP