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

Методы, представленные в предыдущих разделах, направлены на устранение перегрузок и повышение производительности сети. Однако некоторым приложениям (и клиентам) нужны более строгие гарантии качества, чем просто обязательство предоставить «лучшее из возможного в данных обстоятельствах» (иногда это называется подходом best effort). Кроме того, многие приложения требуют определенной минимальной пропускной способности и плохо функционируют, если задержка превышает некоторое пороговое значение. В этом разделе мы продолжим разговор о производительности сети с акцентом на методах обеспечения качества обслуживания, отвечающего требованиям конкретных приложений. Уже долгое время в данной области интернета происходят значительные изменения. В последнее время важную роль приобретает QoE (Quality of Experience — качество пользовательского опыта), поскольку в конечном итоге важен лишь полученный пользователем опыт взаимодействия, а у разных приложений пороговые значения и требования к производительности сети могут сильно различаться. Все большее внимание уделяется способам оценки QoE, когда для наблюдения доступен только зашифрованный сетевой трафик.

5.4.1. Требования приложений к QoS

Последовательность пакетов, передающихся от источника к получателю, называется потоком (flow) (Кларк; Clark, 1988). При этом в сетях, ориентированных на установление соединения, его могут составлять все пакеты канала, а в сетях без установления соединения — все пакеты, отправленные от одного процесса к другому. Каждый поток требует определенных условий, которые можно охарактеризовать четырьмя основными параметрами: пропускная способность, задержка, джиттер и потери. Все вместе они формируют необходимый потоку QoS (Quality of Service — качество обслуживания).

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

Приложение

Пропускная способность (bandwidth)

Задержка (delay)

Джиттер (jitter)

Потери (loss)

Электронная почта

Низкая

Низкая

Низкая

Средняя

Передача файлов

Высокая

Низкая

Низкая

Средняя

Веб-доступ

Средняя

Средняя

Низкая

Средняя

Удаленный доступ

Низкая

Средняя

Средняя

Средняя

Аудио по запросу

Низкая

Низкая

Высокая

Низкая

Видео по запросу

Высокая

Низкая

Высокая

Низкая

Телефония

Низкая

Высокая

Высокая

Низкая

Видеоконференции

Высокая

Высокая

Высокая

Низкая

Илл. 5.27. Строгость требований приложений к QoS

У приложений могут быть разные требования к пропускной способности: для электронной почты, аудио в различных форматах и удаленного доступа они незначительны, тогда как передача файлов и видео в любых формах требует больших ресурсов.

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

Колебание (то есть стандартное отклонение) времени задержки или времени прибытия пакета называется джиттером (jitter). Первые три приложения на илл. 5.27 спокойно отнесутся к неравномерной задержке доставки пакетов. При организации удаленного доступа этот фактор имеет большее значение, поскольку при сильном джиттере обновления экрана будут происходить скачками. Видео- и особенно аудиоданные крайне чувствительны к джиттеру. Если пользователь смотрит видео по сети и все фреймы приходят с задержкой ровно 2,000 с, проблем не возникнет. Но если время передачи колеблется от 1 до 2 с и приложению не удается скрыть джиттер, результат будет просто ужасен. При прослушивании звукозаписей заметен джиттер даже в несколько миллисекунд.