Чтение онлайн

Когда хост-отправитель получает сдерживающий пакет, он должен уменьшить трафик к указанному получателю, к примеру, на 50 %. В дейтаграммной сети случайный выбор, скорее всего, приведет к тому, что сдерживающие пакеты дойдут до самых быстрых отправителей, поскольку именно их пакеты составляют большую часть очереди. Такая неявная обратная связь позволяет предотвратить перегрузку, не мешая тем источникам, действия которых не вызывают проблем. По той же причине есть вероятность, что многочисленные сдерживающие пакеты будут отправлены на нужный хост и адрес. В течение фиксированного интервала времени (пока уменьшение трафика не подействует) хост будет игнорировать дополнительные пакеты. Затем новые сдерживающие пакеты сообщат ему, что сеть все еще перегружена.

На ранних этапах развития интернета в качестве сдерживающего пакета использовалось сообщение SOURCE QUENCH (Постел; Postel, 1981). Оно не прижилось отчасти потому, что не были четко определены условия и результаты его рассылки. В современном интернете применяется другая схема уведомлений, о которой мы поговорим позже.

Явное уведомление о перегрузке

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

Этот метод называется явным уведомлением о перегрузке (Explicit Congestion Notification, ECN) и используется в интернете (Рамакришнан; Ramakrishnan, 1988). Это усовершенствованный вариант ранних протоколов подобного рода, в частности бинарной схемы обратной связи (Рамакришнан и Джейн; Ramakrishnan and Jain, 1988), применявшейся в архитектуре DECnet. На информацию о перегрузке в заголовке пакета отводится два бита. В момент отправки пакет не имеет метки (илл. 5.25). При проходе через перегруженный маршрутизатор пакет получает отметку о перегрузке. Затем получатель передает эти сведения отправителю, добавив явное уведомление в следующий ответный пакет. На рисунке этот процесс обозначен пунктирной линией, чтобы показать, что он происходит над IP-уровнем (например, на уровне TCP). Далее, как и в случае со сдерживающими пакетами, отправитель должен начать регулировать трафик.

Илл. 5.25. Явное уведомление о перегрузке

Обратное давление на ретрансляционных участках

При высоких скоростях или больших расстояниях до хостов множество новых пакетов может быть передано даже после отправки уведомлений о перегрузке, поскольку реакция на них занимает некоторое время. Рассмотрим, к примеру, хост в Сан-Франциско (маршрутизатор A на илл. 5.26), посылающий поток данных на хост, расположенный в Нью-Йорке (маршрутизатор D на илл. 5.26), со скоростью OC-3 155 Мбит/с. Если у нью-йоркского хоста станет заканчиваться буферная память, сдерживающему пакету потребуется около 40 мс на то, чтобы вернуться обратно в Сан-Франциско и сообщить, что необходимо снизить объем трафика. Явное уведомление о перегрузке займет еще больше времени, поскольку оно доставляется через получателя. На илл. 5.26 (а) распространение сдерживающего пакета схематично показано на второй, третьей и четвертой диаграммах. За те 40 мс, пока пакет движется по сети, в сторону нью-йоркского маршрутизатора передается еще 6,2 Мбит данных, с которыми надо как-то справиться. Только к седьмой диаграмме (илл. 5.26 (а)) маршрутизатор заметит замедление потока.

Однако есть альтернативный метод, позволяющий бороться с этой проблемой. Он заключается в том, что сдерживающий пакет влияет на трафик каждого маршрутизатора, через который он проходит. Это показано на последовательности диаграмм на илл. 5.26 (б). Как только сдерживающий пакет достигает

Илл. 5.26. (а) Сдерживающий пакет влияет только на источник. (б) Сдерживающий пакет влияет на все промежуточные участки

точки F, поток данных от F в сторону D должен снизиться. Таким образом, F резервирует для соединения большее количество буферной памяти: источник все еще продолжает заваливать это направление своими данными. Нагрузка на D мгновенно снижается, как головная боль — от таблетки в телевизионной рекламе. На следующем шаге сдерживающий пакет, продолжая свой путь, достигает E и приказывает уменьшить поток в сторону F. В результате точке E приходится выдерживать повышенную нагрузку, но зато F немедленно становится легче. Наконец, победный марш сдерживающего пакета приводит его к источнику всех бед — точке A, и теперь поток снижается по-настоящему.

Результат применения этой схемы — максимально быстрое устранение перегрузки на самом проблемном участке за счет использования большего объема буферной памяти промежуточных маршрутизаторов. Таким образом, проблема решается без потери пакетов. Эта идея обсуждается более подробно в работе Мишры и др. (Mishra et al., 1996).

5.4. QoS и QoE приложений

Методы, представленные в предыдущих разделах, направлены на устранение перегрузок и повышение производительности сети. Однако некоторым приложениям (и клиентам) нужны более строгие гарантии качества, чем просто обязательство предоставить «лучшее из возможного в данных обстоятельствах» (иногда это называется подходом 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

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

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