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

Современные чипсеты, такие как Barefoot Tofino, позволяют выполнять протоколонезависимую обработку нестандартных пакетов на входе и на выходе (илл. 5.45). Благодаря этому можно анализировать временные параметры очередей (например, время нахождения в очереди отдельных пакетов), а также производить нестандартную инкапсуляцию и декапсуляцию. Кроме того, можно применять метод активного управления очередью (к примеру, RED) к выходным очередям, используя метаданные, получаемые из входных очередей. В настоящее время исследуются способы использования этой архитектуры для управления трафиком и перегрузками, в частности, путем мелкоструктурной оценки параметров очередей (Чэнь и др.; Chen et al., 2019).

Такая степень программируемости оказалась наиболее полезной в сетях дата-центров. Благодаря своей архитектуре они способны извлечь выгоду из широких возможностей настройки. С другой стороны, данная модель обеспечивает общее повышение эффективности и расширение функциональности. Она позволяет включать в пакеты информацию о состоянии самой сети с помощью внутриполосной сетевой телеметрии (In-band Network Telemetry, INT) (например, величину задержки на каждом транзитном участке пути).

Илл. 5.45. Реконфигурируемые конвейеры сопоставления действий на этапах входа и выхода

На сегодняшний день существуют программируемые сетевые карты, комплект разработчика плоскости данных (Data Plane Development Kit, DPDK) от Intel и другие библиотеки, а также гибкие конвейеры обработки (например, чипсет Barefoot Tofino, программируемый на языке P4 (Босхарт и др.; Bosshart et al., 2014)). Благодаря этому операторы сетей разрабатывают нестандартные протоколы и производят расширенную обработку пакетов в самом коммутационном оборудовании. P4 — высокоуровневый язык для программирования протоколонезависимых обработчиков пакетов (например, RMT-чипов). Также были разработаны программируемые плоскости данных для виртуальных коммутаторов (точнее, это произошло задолго до появления программируемых аппаратных коммутаторов). Еще одним важным шагом в области программируемого управления коммутаторами стала разработка открытой программной реализации Open vSwitch (OVS), которая позволяет обрабатывать пакеты на нескольких уровнях и работает в виде модуля ядра Linux. OVS предлагает целый ряд возможностей, от VLAN до IPv6. Операторы сетей получили возможность настраивать переадресацию в дата-центрах, в частности, запуская OVS в качестве коммутатора в гипервизоре серверов.

5.6.4. Программируемая сетевая телеметрия

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

Программируемое коммутационное оборудование, представленное в предыдущем разделе, обеспечивает более гибкий сбор телеметрии. Одна из тенденций, к примеру, заключается в предоставлении операторам сетей возможности запрашивать данные о сетевом трафике на высокоуровневом языке с использованием таких фреймворков, как MapReduce (Дин и Гемават; Dean and Ghemawat, 2008). Этот подход изначально рассчитан на обработку данных в крупных кластерах. Поэтому с его помощью можно запрашивать информацию о сетевом трафике (например, количество байтов или пакетов, отправленных на определенный адрес или порт в заданном временном интервале). К сожалению, программируемое коммутационное оборудование еще (пока) не настолько совершенно, чтобы поддерживать сложные запросы. Иногда их нужно разделять между потоковым процессором и сетевым коммутатором. Для этого существует несколько технологий (Гупта и др.; Gupta et al., 2019). Вопрос об эффективном способе отображения высокоуровневых абстракций и конструкций запросов на коммутационное аппаратное и программное оборудование более низкого уровня остается открытым.

Наконец, крупной проблемой в сфере программируемой сетевой телеметрии в ближайшие годы будет все большее распространение в интернете зашифрованного трафика. С одной стороны, это обеспечивает конфиденциальность, затрудняя несанкционированный доступ к пользовательским данным. Но с другой стороны, невозможность увидеть содержимое трафика усложняет задачу сетевого администрирования для операторов. К примеру, рассмотрим отслеживание качества видеопотоков. Если трафик не зашифрован, можно узнать битрейт и разрешение видео. В противном случае эти сведения приходится логически выводить на основе тех свойств сетевого трафика, которые доступны для непосредственного наблюдения (например, интервалы получения пакетов и объем трафика в байтах). В недавних исследованиях были представлены способы автоматического логического вывода высокоуровневых свойств трафика сетевых приложений на основе низкоуровневой статистики (Бронзино и др.; Bronzino et al., 2020). Рано или поздно операторам потребуются более эффективные модели, позволяющие логически оценить влияние перегрузки и других факторов на производительность приложений.

5.7. Сетевой уровень интернета

Теперь самое время подробно поговорить о сетевом уровне интернета. Но прежде чем перейти к деталям, имеет смысл познакомиться с принципами, которые легли в его основу при разработке и обеспечили его дальнейший успех. В наше время ими все чаще пренебрегают. Между тем эти принципы пронумерованы и включены в документ RFC 1958, который стоит изучить (а разработчики просто обязаны его прочитать и сдать по нему экзамен). Этот документ использует идеи, изложенные в работах Кларка (Clark, 1988) и Зальцера и др. (Saltzer et al., 1984). Ниже мы приведем 10 основных принципов, начиная с самых важных.

1. Убедитесь в работоспособности. Нельзя считать разработку (или стандарт) законченной, пока не осуществлен ряд успешных соединений между прототипами. Очень часто разработчики сначала пишут тысячестраничное описание стандарта, утверждают его, а потом обнаруживается, что он еще очень сырой или вообще неработоспособен. Тогда пишется версия 1.1. Так быть не должно.

2. Упрощайте. Если есть сомнения, выбирайте самое простое решение. Уильям Оккам (William Occam) декларировал этот принцип еще в XIV веке (так называемая «Бритва Оккама»). Его можно кратко выразить так: «Борись с излишествами». Если какое-то свойство не является абсолютно необходимым, забудьте о нем, особенно если того же эффекта можно добиться комбинированием уже имеющихся свойств.

3. Всегда делайте четкий выбор. Если есть несколько способов реализации одного и того же, выбирайте только один из них. Увеличение количества способов приведет к проблемам. В стандартах часто можно встретить несколько опций, режимов или параметров лишь потому, что при разработке несколько авторитетных сторон настаивали на своем. Разработчики должны решительно сопротивляться подобным тенденциям. Надо