Продолжение. Часть 6 — здесь.

Две основных (классических) модели трафика через транспортную сеть TCP.

• Интерактивная модель, например, по протоколам SSH или Telnet, когда между двумя всплесками трафика идут долгие периоды неактивности;
• Передача больших файлов, например, загрузка веб-страницы.

Протокол TCP хорошо работает с обеими из них, хотя его механизмы управления перегрузками задействуются только в случае единовременной передачи большого объёма трафика. При работе в Интернет бывает и то, и другое.

В интерактивной модели, могут использоваться операции «запрос-ответ», например, запросы информации из базы данных, или запросы DNS. Здесь также может использоваться TCP, хотя большинство запросов DNS до сих пор ещё используют UDP. Периодически раздаются призывы к разработке специальных протоколов для управления передачей через транспортную сеть. Однако, на данный момент TCP пока ещё хорошо справляются с этой задачей, поскольку заголовок, «навешиваемый» этим протоколом на пакет, сравнительно небольшой.

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

На стриминговом радио буферизация работает немного хуже, поскольку требования к задержке в этом случае жёстче, скажем, секунд десять. Однако, и полоса пропускания для радио ниже.

С другой стороны, проблема для видео-стриминга – требование достаточно высокой полосы пропускания. Большинство стриминговых сервисов оценивают полосу пропускания, доступную в сети, а затем подстраиваются под доступную пропускную способность регулируя качество видео, повышая его, если полосы хватает, и снижая, если полоса недостаточна.

Обычно, стриминговое видео работает по принципу «старт-стоп»: на передающей стороне может включаться пауза в передаче, если буфер на приемной стороне заполнен, и возобновляться, когда заполнение буфера снижается менее установленного порога.

При звонке по Интернет-телефонии, задающий вопрос абонент ожидает обычно немедленного ответа от вызываемого абонента, и любая задержка в буфере воспринимается как разрыв соединения, либо того, что на другой стороне не услышали вопрос. Здесь встает вопрос об организации передачи трафика в реальном времени.

Для минимизации задержек при стриминге часто используется протокол UDP. Помогает также сужение полосы пропускания, для нормальной передачи голоса при телефонном вызове обычно хватает 8 кбайт/с, а при использовании компрессии – и менее. С другой стороны, могут быть также и ограничения по вариации времени доставки пакетов, что известно под названием «джиттер» (англ. Jitter – дрожание).

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

На транспортном уровне практически все соединения предусматривают взаимодействие сервера и клиента. Часто эта модель повторяется и на уровне приложений: клиент контактирует с сервером и инициирует сессию регистрации (login), либо просто просматривает веб-страницу иди смотрит видео. Иногда, однако, на уровне приложений лучше работает модель «peer-to-peer», то есть, обмен между равноправными сторонами. Примеры такого обмена:

• Интернет-телефония: нет никакого смысла назначать «клиентом» вызывающего абонента.
• Прохождение сообщений вызова удаленных процедур через кластер процессоров, RPC (Remote Procedure Call).
• Протоколы коммуникационной маршрутизации (Routing-Update Algorithms): когда маршрутизатор А посылает какое-то служебное сообщение маршрутизатору В, то А можно назвать клиентом. Однако, может происходить поочередный обмен сообщениями от А к В и от В к А и так далее. Поэтому здесь лучше подходит модель «peer-to-peer».
• Так называемый «peer-to-peer file-sharing» (совместный двусторонний доступ к файлам), когда сотрудник обменивается файлами с коллегами по принципу облака (например, Google Disk), только в качестве «облака» выступает сервер организации.

Модели обмена peer-to-peer описаны в RFC 5694.

Сети раздачи контента (Content-Distribution Networks)

Сайты, предназначенные для раздачи большого количества контента, часто используют особую модель, которая называется сетями раздачи контента CDN (Content-Distribution Networks). Для снижения количества трафика, передаваемого на дальние расстояния, или для того, чтобы снизить время отклика на запрос, контент сайта CDN реплицируется во множестве промежуточных дата-центрах, также называемых «точками присутствия» PoP (Points of Presence). Когда пользователь запрашивает какую-то веб-страницу, или видео, запрос маршрутизируется на один из ближайших дата-центров, и контент доставляется оттуда.

Например, серверы CDN NetFlix в 2016 году располагались следующим образом:

Большие веб-страницы обычно содержат как статический, так и индивидуализированный динамический контент. На типичной странице Facebook, например, видео и java-скрипты могут рассматриваться как статический контент, а индивидуальные посты в ленте – как динамический.

Статический контент может кэшироваться на граничных серверах CDN, а динамический контент может поступать из централизованного сервера. Либо, динамический контент может реплицироваться на каждом граничном дата-центре CDN, но при этом могут возникать проблемы с координацией контента.

Если динамический контент не реплицируется, то CDN может устанавливать высокоскоростные соединения между своими узлами, для снижения задержки доставки контента. Либо соединения можно делать просто через публичный интернет. Кроме того, CDN может быть сконфигурирована так, чтобы поддерживать быстрый интерактивный обмен сообщениями между узлами, например, для проведения видеоконференций.

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

В принципе, всё что нужно для создания CDN – это множество дата-центров, с высокоскоростным подключением к Интернету в каждом. Между дата-центрами при этом могут быть организованы и частные линии. На практике многие провайдеры CDN стараются также построить прямые физические соединения с теми провайдерами Интернет, которые обслуживают их клиентов. Например, так поступает сеть Google Edge Network. При этом можно значительно улучшить качество услуг и снизить стоимость трафика.

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

• Граничные серверы имеют разные IP-адреса, и сервер DNS конфигурируется так, чтобы пользователи всегда получали адрес ближайшего к ним сервера.
• Каждый граничный дата-центр имеет один IP-адрес для всех своих серверов, и для направления трафика от пользователя к ближайшему серверу используется anycast-маршрутизация.
• Если пользователь HTTP-приложения запрашивает какую-то веб-страницу, то центральный сервер определяет примерное расположение пользователя и затем направляет веб-страницу на ближайший граничный сервер.

Продолжение здесь.