Архитектурный анализ ядра Linux

Сетевая подсистема ядра Linux версии 5.10

Сетевая подсистема ядра Linux версии 5.10 (подкаталог net/ дистрибутива ядра Linux) содержит 73 элемента. Ниже модули подсистемы по возможности группируются по их назначению в соответствии с семиуровневой моделью сетевого стека OSI. Такое разбиение довольно условное, поскольку сетевая подсистема состоит из разных моделей сетевого стека (ethernet, x25, decnet, infiniband), и эти модели иногда пересекаются, то есть протоколы, изначально придуманные для одной модели, затем используются в других моделях. Также некоторые протоколы охватывают сразу несколько уровней. Кроме того, использование туннелей на самых разных уровнях, например, ethernet через udp, вообще смешивает всю структуру.

В графическом виде результат представлен на диаграмме:

(ipv6)
6lowpan
(ipv6)...
bridge
bridge
bpfilter
bpfilter
batman-adv
(wifi, ethernet)
batman-adv...
appletalk / aarp, ddp
appletalk / a...
ife
ife
hsr
hsr
ethernet
ethernet
dsa
dsa
dccp
dccp
dcb
dcb
ipv6
ipv6
ipv4 / tcp,udp,icmp
ipv4 / tcp,udp,icmp
l3mdev
l3mdev
l2tp
(udp, atm, ...)
l2tp...
netfilter
netfilter
mpls
mpls
netrom
(ax25)
netrom...
netlabel / cipso,ripso
netlabel / cipso,rip...
qrtr
qrtr
phonet
phonet
openvswitch
(ethernet)
openvswitch...
sctp
sctp
rose
(ax25)
rose...
rfkill
rfkill
smc
smc
devres.c
devres.c
xfrm / IPsec 
xfrm / IPsec 
xdp
xdp
socket.c
socket.c
key / PF_KEYv2
key / PF_KEYv2
psample
psample
packet
packet
strparser
strparser
ethtool
ethtool
sched / QoS
sched / QoS
tls
tls
dns_resolver
dns_resolver
nsh
nsh
mptcp
mptcp
kcm
(tcp)
kcm...
iucv
iucv
rxrpc
(udp)
rxrpc...
rds
(Infiniband,tcp)
rds...
tipc
(Infiniband,udp)
tipc...
sunrpc
sunrpc
vmw_vsock
vmw_vsock
ieee802154
ieee802154
mac80211
mac80211
wireless/802.11
wireless/802.11
mac802154
mac802154
wimax
wimax
nfc
nfc
bluetooth
bluetooth
atm
atm
can
can
ncsi
ncsi
switchdev
switchdev
core
core
sysctl_net.c
sysctl_net.c
compat.c
compat.c
ax25
ax25
netlink
netlink
unix domain sockets
unix domain s...
x25
x25
lapb
(x25)
lapb...
9p / 9p2000
9p / 9p2000
ceph
ceph
Инструментальные компоненты
Инструментальные компоненты
Канальный уровень
Канальный уровень
Сетевой уровень
Сетевой уровень
Протоколы верхних уровней
Протоколы верхних уровней
caif
caif
decnet
decnet
llc
llc
8021q
8021q
802/stp
802/stp
802/psnap
802/psnap
802/garp
802/mrp
802/garp...
802/p8022
802/p8023
802/p8022...
802/fc
802/fddi
802/hippi
802/fc...
Text is not SVG - cannot display

Для некоторых модулей в скобках указаны протоколы, поверх которых работает реализуемый модулем протокол, или для реализации которых он используется. Например, nsh(udp) — обозначает, что протокол NKN Shell работает поверх UDP, а (ipv6)6lowpan — обозначает, что 6LoWPAN используется для реализации IPV6 поверх маломощных беспроводных персональных сетей стандарта IEEE 802.15.4. Для некоторых модулей, например, содержащих реализизации группы протоколов, через слэш приводятся уточняющие данные: ipv4 / tcp, udp, icmp, appletalk / aarp, ddp. Серым цветом выделены модули, играющие вспомогательную роль в доставке пакетов (маршрутизация, резервирование и т. д.). Оранжевым цветом выделены модули, для которых доступен отчет об анализе поверхности атаки. Рамками обведены модули, относящиеся к одному уровню по горизонтали, но сгруппированные, чтобы занимать меньше места.

Результаты анализа поверхности атаки доступны для следующих модулей ядра:

Вспомогательные инструментальные модули

Bpfilter

Модуль обеспечивает функциональность, совместимую с модулем Netfilter, для фильтрации сетевого трафика через BPF (Berkeley Packet Filter).

Зависимости: Net && BPF && Inet.

Xdp

Модуль реализует сокеты XDP, позволяющие создавать каналы взаимодействия между XDP-программами и пользовательскими приложениями. Технология eXpress Data Path (XDP) позволяет выполнять произвольную обработку трафика на сетевых интерфейсах Linux до того, как пакеты поступят в сетевой стек ядра. XDP применяется для таких задач, как защита от DDoS-атак, создание фильтров трафика, сбор статистики. XDP-программы исполняются в виртуальной машине eBPF и имеют ограничения, как на свой код, так и на доступные функции ядра.

Зависимости: BPF_Syscall.

Netfilter

Модуль реализует основную функциональность для фильтрации сетевого трафика.

Зависимости: Net && Inet && Netfilter.

Key

Модуль PF_KEYv2 реализует универсальный интерфейс управления ключами (RFC 2367), предназначенный для служб сетевой безопасности, в первую очередь для IPSec. Модуль реализован в виде отдельного типа сокетов и обеспечивает интерактивный интерфейс между привилегированными приложениями уровня IPSec и внутренним механизмом управления ключами ядра операционной системы, который использует базу данных ассоциаций безопасности (Security Association Database, SADB) и ее объекты, содержащие необходимые атрибуты безопасности.

Sched / QoS (Quality of Service)

Модуль управления потоками (Linux Traffic Control), позволяющий распределять пропускную способность канала между различными типами трафика. Управление пропускной способностью осуществляется с помощью различных алгоритмов и механизмов, присоединяемых к соответствующим сетевым устройствам, включая такие как diffserv (Differentiated Services) и RSVP (Resource Reservation Protocol).

Ethtool

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

Packet

Данный модуль реализует низкоуровневый сетевой протокол для взаимодействия приложений (таких как tcpdump) непосредственно с сетевыми устройствами, минуя сетевой стек ядра Linux.

Psample

Это канал протокола netlink, позволяющий передавать отобранные по шаблону пакеты вместе с некоторыми метаданными из ядра Linux в пространство пользователя. Этот канал может использоваться такими утилитами как tc (traffic control settings), iptables и др. (например, в маршрутизаторах).

Зависимости: Net.

Strparser

Stream_parser – это утилита, которая разбирает сообщения протокола прикладного уровня, работающего поверх потока данных. Утилита работает совместно с верхним уровнем ядра, чтобы обеспечить поддержку ядром сообщений прикладного уровня. Например, мультиплексор соединений ядра (Kernel Connection Multiplexor, KCM) использует эту утилиту для разбора сообщений с помощью программы BPF.

Stream_parser работает в одном из двух режимов: прием обратного вызова (receive callback) или общий режим.

В режиме приема обратного вызова strparser вызывается из обратного вызова data_ready сокета TCP. Сообщения обрабатываются и доставляются по мере их поступления в сокет.

В общем режиме последовательность структур skb (sk_buff) подается в strparser из внешнего источника. Сообщения обрабатываются и доставляются по мере обработки потока данных. Этот режим позволяет применять strparser к произвольным потокам данных.

Netlink

Модуль реализует сокеты Netlink, которые являются гибкой и расширяемой системой передачи сообщений, обеспечивающей обмен данными между ядром и пространством пользователя.

Netlink является одним из интерфейсов, которые Linux предоставляет пространству пользователя. Netlink – это семейство сокетов, которое предлагает средство передачи сообщений на основе интерфейса сокетов BSD. Netlink является более гибким интерфейсом по сравнению с другими интерфейсами ядра Linux, которые использовались в Unix-подобных операционных системах для взаимодействия между ядром и пространством пользователя. Netlink является переносимым, легко расширяемым интерфейсом.

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

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

Система передачи сообщений Netlink ориентирована на передачу дейтаграмм и позволяет передавать сообщения из ядра в пространство пользователя и, наоборот, из пространства пользователя в ядро. Она может использоваться также в качестве системы взаимодействия между процессами (IPC), например, между двумя процессами пространства пользователя или даже между двумя разными подсистемами ядра.

Поскольку Netlink реализуется поверх общеизвестной инфраструктуры сокетов BSD, он поддерживает обычные примитивы, подобные socket(), bind(), sendmsg(), recvmsg(), а также общие механизмы опроса сокетов.

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

Семейство Netlink допускает два вида сообщений, индивидуальные (unicast) и групповые (multicast). Индивидуальные сообщения используются для взаимодействия между какой-либо подсистемой ядра и одним процессом пространства пользователя. Обычно они используются для посылки команд в пространство ядра, приема результатов выполнения команд, а также для запроса некоторой информации у данной подсистемы ядра. Отправителем группового сообщения обычно является ядро, а в пространстве пользователя имеются несколько возможных слушателей группового вещания. Это позволяет реализовать рассылку уведомлений, базирующихся на событиях. В общем случае уведомления о событиях группируются по различным видам, и таким образом Netlink может предлагать несколько групп группового вещания, на которые могут подписываться слушатели пространства пользователя в зависимости от того, в каких видах уведомлений о событиях они заинтересованы. Можно создавать до 2^32 групп группового вещания.

Unix / Unix Domain Sockets

Реализация подсистемы Unix domain socket. Сокеты представляют стандартный для ОС Unix механизм доступа к сети и установления соединений. Однако многие приложения, такие как подсистемы X Window и syslog, используют механизм сокетов даже если сам узел не подключен к сети. Таким образом, все сокеты можно разделить на два класса: сокеты, которые используют сеть, и сокеты, которые этого не делают. Для доступа к сети используются BSD сокеты. В отличие от них, сокеты домена Unix сеть не используют, они предназначены для обмена данными между процессами, выполняемыми в одной операционной системе. Тем не менее, их интерфейс во многом аналогичен интерфейсу BSD сокетов.

Core

Модуль реализует базовую функциональность сетевой подсистемы ядра Linux.

sysctl_net.c

Модуль реализует интерфейс sysctl для сетевой подсистемы Linux, позволяющий изменять настройки ядра в работающей системе (без ее остановки или перезагрузки).

devres.c

Реализация Devres – программного интерфейса, предоставляемого ядром Linux разработчикам драйверов устройств для управления запрашиваемыми и освобождаемыми ресурсами (devres – это сокращение от managed device resources). Использование этого интерфейса позволяет в большинстве случаев не заботиться об освобождении ресурсов, которое осуществляется автоматически при отсоединении драйвера.

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

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

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

Ядро Linux предоставляет управляемые интерфейсы для множества ресурсов, необходимых для работы драйверов, например, для памяти, выделяемой для работы контроллерам DMA и ввода/вывода, обработки прерываний, управления шинами PCI и SPI, различного вида датчиков промышленного ввода/вывода (IIO) и других ресурсов.

Протоколы канального уровня

802

Модуль состоит из 9 самостоятельных подсистем.

  • Три набора функций для управления устройствами соответствующих типов:
    • fc (Fibre Channel),
    • fddi (Fiber Distributed Data Interface),
    • hippi (High Performance Parallel Interface).
  • p8022 – реализация демультиплексирования протоколов 802.2, на основе полей SSAP / DSAP, и их отправка соответствующим зарегистрированным обработчикам.
  • p8023 – реализация протокола Raw 802.3 / IPX. Модуль определяет вариант фрейма Ethernet от Novell, который по-своему интерпретирует заголовок Ethernet 802.3: в нем нет поля для указания вышестоящего протокола, поскольку для этого используется единственный протокол IPX. Два байта поля EtherType превратились в поле Length, указывающее длину пакета. Данный модуль удален в версии ядра Linux 5.15.
  • psnap – реализация протокола доступа к подсетям SNAP (Subnetwork Access Protocol). Протокол представляет собой механизм мультиплексирования в сетях, использующих IEEE 802.2 LLC. SNAP является дополнением заголовка IEEE 802.2 LLC и поддерживает идентификацию протоколов верхнего уровня через поле EtherType. Он используется на сетевых уровнях IEEE 802: IEEE 802.3, IEEE 802.4, IEEE 802.5, IEEE 802.11 и др., а также на сетевых уровнях, использующих 802.2 LLC, такими как FDDI. Протоколы, использующие Ethernet 802.3 SNAP, – все протоколы семейства STP, протоколы CDP, VTP, DTP.
  • stp – реализация демультиплексирования полей SAP протокола STP (Spanning Tree Protocol). STP – семейство сетевых протоколов, предназначенных для автоматического удаления циклов (петель коммутации) из топологии сети на канальном уровне в сетях Ethernet. Первоначальный протокол STP описан в стандарте 802.1D. Позже появилось несколько новых протоколов (RSTP, MSTP, PVST, PVST+), отличающихся некоторыми особенностями в алгоритме работы, в скорости, в отношении к VLAN, но в целом решающих ту же задачу похожими способами. Все их принято обобщённо называть STP-протоколами.
  • garp – реализация протокола IEEE 802.1D GARP (Generic Attribute Registration Protocol). Протокол GARP – базовый протокол регистрации атрибутов, созданный как универсальный транспорт сигнальной информации канального уровня. Протокол обеспечивает рассылку атрибутов подписчикам GARP для регистрации или исключения этих атрибутов у всех участников GARP. Обмен данными между участниками GARP осуществляется на базе сервиса LLC типа 1, с использованием групповых адресов MAC и формата PDU, определенного для приложений GARP. Два основных применения протокола – регистрация VLAN на устройстве и регистрация мультикастовой группы, для чего на основе GARP, как инфраструктуре, были созданы соответственно протоколы GVRP (GARP VLAN Registration Protocol) и GMRP (GARP Multicast Registration Protocol), как расширения для коммутаторов, поддерживающих спецификации VLAN 802.1Q. Протокол GARP считается устаревшим, новый протокол для решения этих задач – MRP.
  • mrp – реализация протокола IEEE 802.1Q MRP (Multiple Registration Protocol, протокол множественной регистрации). Это протокол канального для автоматической настройки виртуальных локальных сетей в коммутируемой сети . MRP определяет общую структуру, рекомендованную IEEE для использования в сетевых мостах, сетевых коммутаторах, или других аналогичных устройствах с возможностью регистрации и перерегистрации специальных атрибутов, таких как идентификаторы VLAN и членство в мультикастовых группах. MRP был разработан как замена GARP и определен стандартом IEEE 802.1ak-2007. Оба приложения GARP были также преобразованы для использования в MRP: GVRP был заменён на MVRP (Multiple VLAN Registration Protocol), GMRP – на MMRP (Multiple MAC Registration Protocol). Все эти изменения вошли в обновлённый стандарт 802.1Q, который изначально разрабатывался для поддержки VLAN. Это также способствовало существенному упрощению основного протокола без больших изменений непосредственно интерфейса приложений, поскольку в протоколах GARP и GVRP регистрация и перерегистрация при отказах требовали довольно много времени, что сказывалось на загрузке полосы пропускания, особенно в больших сетях.
Decnet

Реализация DECnet – семейства сетевых протоколов, разработка которого началась компанией Digital Equipment Corporation (DEC) в 1975 году. В дальнейшем оно стало основной сетевой подсистемой в рамках операционной системы DEC OpenVMS для компьютеров VAX. Семейство DECnet под названием DEC Pathworks было перенесено на системы Ultrix, Apple Macintosh, а также IBM PC под DOS и Microsoft Windows, позволяя им работать в качестве терминальных узлов для подключения к сети компьютеров VAX.

В рамках ОС FreeBSD и Linux были выполнены самостоятельные разработки семейства протоколов DECnet. Например, этот код позволяет Linux-системе стать частью системы OpenVMS, копировать файлы с систем OpenVMS в прямом и обратном направлении, запускать удаленные задания и проверять соединения. Имеется также возможность монтировать директории VMS в качестве файловых систем Linux. Пользователи VMS могут запускать в Linux терминальные сеансы или обращаться к файлам Linux или к внешним смонтированным файловым системам, например, NFS посредством демона FAL. Linux-системы могли использоваться также в качестве дешевых X-терминалов для OpenVMS.

Ncsi

Модуль обеспечивает поддержку NCSI (Network Controller Sideband Interface).

Зависимости: Inet.

Протоколы канального уровня для беспроводной передачи данных

Mac80211

Реализация аппаратно независимого стека протоколов стандарта IEEE 802.11 для беспроводных локальных сетей, больше известного как Wi-Fi.

Зависимости: CFG80211, IEEE802154.

Wireless (cfg80211)

Модуль реализует API для настройки беспроводной локальной сети (стандарта 802.11) в Linux (при наличии соответствующих устройств).

Ieee802154

Модуль реализует IEEE 802.15.4 – стандарт, который определяет физический и канальный уровни передачи данных для беспроводных персональных сетей малого радиуса действия с низкими мощностью, сложностью и скоростью передачи данных. Разработан для организации сетей датчиков, коммутаторов и других автоматических устройств. Максимально допустимая скорость передачи данных составляет 250 кб/с, а рабочее пространство составляет около 10 м. В ядре Linux реализована поддержка протокола 6LoWPAN для сетей IEEE 802.15.4.

Mac802154

Реализация аппаратно независимого стека протоколов стандарта IEEE 802.15.4 для SoftMAC устройств, то есть устройств, реализующих только уровень PHY стандарта IEEE 802.15.4.

Для ядра Linux 5.10.56 данная реализация не является ни сертифицированной, ни функционально полной. Совместимость с другими реализациями не проверена.

Зависимости: IPV6.

Bluetooth

Реализация сетевого стека Bluetooth.

Bluetooth - это недорогая, маломощная технология беспроводной передачи данных малого радиуса действия. Разработана в качестве замены кабелей и других технологий ближнего радиуса действия, таких как IrDA. Bluetooth работает в радиусе до 10 метров.

Подсистема Bluetooth Linux состоит из нескольких уровней:

  • Bluetooth Core
    • HCI device and connection manager, scheduler
    • SCO audio links
    • L2CAP (Logical Link Control and Adaptation Protocol)
    • SMP (Security Manager Protocol) on LE (Low Energy) links
  • HCI Device drivers (интерфейс для устройств)
  • RFCOMM Module (RFCOMM Protocol)
  • BNEP Module (Bluetooth Network Encapsulation Protocol)
  • CMTP Module (CAPI Message Transport Protocol)
  • HIDP Module (Human Interface Device Protocol)

Для использования подсистемы bluetooth в Linux требуется несколько дополнительных утилит, из пакета BlueZ.

Зависимости: Net && !S390, Rfkill || !Rfkill.

Nfc

Реализация поддержки Nfc-устройств (Near field communication), а также стека цифровых протоколов NFC (NFC Digital Protocol stack), необходимого для NFC чипов, прошивка которых реализует только аналоговый уровень NFC.

Зависимости: Net, Rfkill || !Rfkill.

Wimax

Поддержка и настройка устройств беспроводной широкополосной связи, работающих по протоколу WiMAX (IEEE 802.16).

Зависимости: Rfkill || !Rfkill.

Протоколы канального уровня использующие Ethernet

Ethernet

Реализация сетевого уровня Ethernet, для управления соответствующими устройствами.

Для взаимодействия с протоколом Ethernet на верхних сетевых уровнях в Linux предлагается реализация стека протоколов TCP/IP, который, в свою очередь, для взаимодействия с пользовательским уровнем использует интерфейс BSD сокетов.

Протоколы расширения Ethernet

Bridge

Реализация технологии 802.1d Ethernet Bridging (сетевой мост), предназначенной для объединения подсетей (Ethernet сегментов) в единую сеть. Поскольку это сетевой стандарт, мосты Linux корректно взаимодействуют с реализациями мостов сторонних производителей.

Зависимости: IPV6

Dcb

Реализация поддержки технологии Data Center Bridging.

DCB – это набор усовершенствований Ethernet, который обеспечивает транспортировку данных без потерь и возможность распределения пропускной способности между каналами. DCB позволяет сетевым картам и коммутаторам с поддержкой этой технологии объединять сетевой трафик с различными требования (высокая надежность и отсутствие потерь данных против высокой скорости передачи данных).

Модуль DCB Linux обеспечивает настройку (через сокеты rtnetlink) соответствующей функциональности на адаптерах Ethernet с поддержкой DCB.

Реализованы следующие функции DCB:

Enhanced Transmission Selection (Priority Grouping) – позволяет различным классам трафика назначить гарантированную пропускную способность канала.

Priority-based Flow Control (PFC) – механизм управления потоком (использующий приоритеты стандарта 802.1p), позволяющий приостанавливать передачу данных для каждого класса трафика.

Dsa

Поддержка аппаратных коммутаторов с технологией DSA (Distributed Switch Architecture).

Зависимости: Inet && Netdevices && !S390.

8021q

Реализация поддержки функциональности интерфейсов 802.1q/802.1ad VLAN, включая GVRP (GARP VLAN Registration Protocol) и MVRP (Multiple VLAN Registration Protocol).

Hsr

Модуль обеспечивает поддержку протоколов избыточности (Redundancy) для надежной доставки данных HSR (High-availability Seamless Redundancy) и PRP (Parallel Redundancy Protocol) стандарта IEC 62439. В данной технологии надежность передачи обеспечивается за счет дублирования пакетов. Каждый пакет передается двумя разными независимыми путями, а принимающий узел обрабатывает пакет, пришедший первым, и отбрасывает второй. Такая технология реализуется на конечных узлах, а не на промежуточных сетевых компонентах, и потому не требует изменения топологии сети.

Ife

Реализация поддержки инкапсулирующего протокола IFE (Inter-Forwarding Engine based on IETF ForCES InterFE LFB).

Linux обладает довольно сложной системой управления пропускной способностью, названной Traffic Control (Управление Трафиком). Она поддерживает различные методы классификации, деления по приоритетам, совместного использования, и ограничений как входящего, так и исходящего трафика.

Подсистема классификации и действий системы управления трафиком Linux (Linux Traffic Control Classifier-Action) предоставляет удобный способ формирования политик интерпретации пакетов. Управляющее приложение (например, утилита tc пакета iproute2) определяет политику в виде экземпляра направленного графа, который представляет собой смесь фильтров и действий, через который проходят отобранные пакеты с целью предоставления пакету указанного сервиса.

IFE (Inter-Forwarding Engine) – это один из механизмов управления трафиком. В частности в man tc(8) описаны, так называемые IFE-действия (IFE action), которые обеспечивают инкапсуляцию/декапсуляцию метаданных. IFE action позволяет стороне, посылающей пакеты, инкапсулировать произвольные метаданные, которые затем декапсулируются на стороне приема. Как отправитель, так и получатель должны указывать один и тот же специально подобранный тип в кадре Ethernet – ethertype (0xdead).

В 2001 году Jamal Hadi Salim в рабочей группе IETF ForCEC предпринял попытку стандартизовать Netlink в качестве протокола между частью маршрутизатора, которая разрешает продвижение пакетов (Forwarding Engine Component), и ее ответной частью, которая отвечает за управление и конфигурирование механизма продвижения (Control Plane Component). Эта работа была прекращена, и был разработан протокол, специально реализующий эти функции.

Зависимости: Net.

Протоколы передачи данных через ethernet

Smc

Реализация семейства протоколов SMC (Shared Memory Communications). Различают два типа SMC: SMC-D (DMA) и SMC-R (RDMA). SMC-D используется для локальных соединений (через виртуальные адаптеры), SMC-R - для удаленных соединений. В Linux реализован вариант SMC-R в виде отдельного типа сокетов SMC.

SMC-R предоставляет механизм "сокеты через RDMA", использующий технологию RoCE (RDMA over Converged Ethernet) для прозрачного обновления TCP-соединений. Технология RoCE не требует уникальных сетевых компонентов (сетевых адаптеров, коммутаторов, средств управления безопасностью и т.д.), вместо этого используется существующая сеть Ethernet и сетевые адаптеры и коммутаторы с поддержкой RDMA.

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

Зависимости: Inet && Infiniband.

Протоколы канального уровня не использующие ethernet

ATM

Модуль реализует технологию ATM (Asynchronous Transfer Mode — асинхронный режим передачи данных). В технологии ATM, в которой все сообщения протоколов верхних уровней преобразуются в поток ячеек ATM размером в 53 байта, объединяются возможности коммутации пакетов и коммутации каналов. Важным свойством ATM, которое отличает ее от других технологий, является комплексная поддержка параметров качества обслуживания (QoS) для всех основных видов трафика. В технологии ATM выделено 5 классов трафика, и для каждого класса определен набор количественных параметров, которые приложение должно задать.

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

Модель сети ATM предполагает наличие трех уровней, примерно соответствующих эталонной модели ISO/OSI: уровень адаптации ATM, собственно уровень ATM и физический уровень. В этой модели прикладной уровень или более низкие уровни могут непосредственно взаимодействовать с уровнем адаптации ATM (ATM Adaptation Layer, AAL), который предоставляет им набор протоколов AAL1–AAL5, преобразующих сообщения протоколов верхних уровней сети ATM в ячейки ATM нужного формата в соответствии с поступающим классом трафика. Протоколы AAL работают только на конечных узлах сети.

Коммутаторы ATM осуществляют передачу ячеек по протоколу уровня ATM на основе заранее настроенных таблиц коммутации, построение которых выполняется либо вручную, либо автоматически посредством протокола маршрутизации PNNI (Private NNI), с помощью которого коммутаторы могут строить таблицы маршрутизации с учетом требований конкретного вида трафика. Коммутация ячеек осуществляется по номеру виртуального соединения, который включает идентификатор виртуального пути (Virtual Path Identifier, VPI) и идентификатор виртуального канала (Virtual Channel Identifier, VCI). Физический уровень отвечает за согласование скоростей передачи по различным физическим средам, включая технологии SDH/SONET, а также PDH.

В конце 90-х и начале 2000-х годов с появлением гигабитного Ethernet и других технологий, обеспечивающих более дешевые и эффективные средства передачи и управления разнородным сетевым трафиком, начался процесс постепенного вытеснения технологии ATM с рынка широкополосных сетей интегрированного обслуживания.

Can

CAN (Controller Area Network – сеть из контроллеров) представляет собой комплекс стандартов для построения распределенных промышленных сетей, который использует последовательную передачу данных в реальном времени с очень высокой степенью надежности и защищенности. Центральное место в CAN занимает протокол канального уровня модели OSI. Первоначально CAN был разработан для автомобильной промышленности, но в настоящее время быстро внедряется в область промышленной автоматизации. Начало развития CAN было положено компанией Bosch в 1983 г., первые микросхемы CAN контроллеров были выпущены фирмами Intel и Philipsв 1987 году, в настоящее время контроллеры и трансиверы CAN выпускаются многими фирмами.

CAN охватывает два уровня модели OSI: физический и канальный. Стандарт не предусматривает никакого протокола прикладного (7-го) уровня модели OSI, поэтому для его воплощения в жизнь различные фирмы разработали несколько таких протоколов: CANopen (организации CiA), SDS (фирмы Honeywell Micro Switch Division), CAN Kingdom (фирмы Kvaser), DeviceNet (фирмы Allen-Bradley, ставший Европейским стандартом в 2002 г.) и ряд других.

X25

Модуль реализует семейство протоколов X.25, которое стандартизовано в мировом масштабе (ITU-T) и поддержано соответствующими Российскими стандартами. В течение длительного времени Х.25 была основной технологией для построения, как сетей операторов связи, так и корпоративных сетей и применялась для построения глобальной всемирной сети пакетной коммутации. Эта технология определяет протокол межсетевого взаимодействия, позволяющий объединять сети разных провайдеров, и поддерживает международную систему иерархической адресации X.121, включающую код страны, номер сети и номер терминала в сети. Пакетная коммутация осуществляется посредством установления между абонентами виртуальных соединений. Виртуальные соединения могут быть как постоянными, так и коммутируемыми. Коммутируемое соединение, в отличие от постоянного виртуального соединения, устанавливается в каждом сеансе обмена информацией. Множество виртуальных соединений может быть мультиплексировано в один физический канал (физическое соединение). Виртуальные соединения демультиплексируются на принимающей стороне, и данные посылаются назначенным получателям.

Сети X.25 используют трехуровневый стек протоколов, соответствующий трем нижним уровням эталонной модели OSI. На физическом уровне обычно использовались модемы, подключаемые с помощью стандартизованных последовательных интерфейсов (например, RS 232, v35 и X.21) и работающие на коммутируемых и выделенных телефонных линиях связи, а также интерфейс G.703, обеспечивающий подключение к первичным сетям с плезиохронной и синхронной цифровой иерархией (PDH и SDH, соответственно). Для передачи пакетов стандарта X.25 используется протокол канального уровня – сбалансированный протокол доступа к каналу передачи данных (Link Access Procedure, Balanced, LAPB), обеспечивающий обмен данными по каналу между оконечным оборудованием обработки данных (DTE) и оконечным оборудованием линии связи (DCE). На сетевом уровне семейства протоколов X.25 работает протокол пакетного уровня (Packet Layer Protocol, PLP), обеспечивающий обмен пакетами управления и пользовательских данных между устройствами DTE, формируя сеть пакетной коммутации. Как на канальном, так и на сетевом уровне протоколы стека X.25 поддерживают установление соединений, коррекцию ошибок на основе метода скользящего окна.

Lapb

Реализация протокола канального уровня LAPB.

Link Access Procedure, Balanced (LAPB) – это уровень канала передачи данных (т. е. уровень L2) протокола X.25. Он предлагает надежный сервис передачи данных между сетевыми узлами. Используется для транспортировки протоколов более высокого уровня (в основном протокола PLP X.25, но возможны и другие варианты). Обычно LAPB используется со специализированными сетевыми картами X.21, однако Linux в настоящее время поддерживает LAPB только через Ethernet-соединения.

AX25

АХ.25 представляет собой переработанную специально для радиолюбительских целей версию протокола Х.25. Широко используется в любительских сетях пакетной радиосвязи, и соответствует канальному уровню эталонной модели OSI. Он обеспечивает установление соединений, передачу кадров данных и обнаружение ошибок. Используется также в качестве канала передачи данных сетевого уровня, например, IP-дейтаграмм, и обеспечивает ограниченную форму маршрутизации (возможность реализации ретрансляторов для передачи пакетов между удаленными на большие расстояния абонентами сети).

Rose

Реализация протокола Rose (X.25 PLP).

Протокол ROSE был задуман и впервые реализован Томом Моултоном и является реализацией протокола пакетного уровня (PLP) X.25, но предназначен для работы с AX.25 в качестве протокола канального уровня. Он также обеспечивает сетевой уровень.

Сетевые устройства ROSE – это виртуальные сетевые устройства, инкапсулирующие кадры ROSE в кадры AX.25, для передачи через AX.25-устройства.

Протоколы канального уровня для управления трафиком

Llc

Реализация протокола управления логическим каналом (Logical Link Layer, IEEE 802.2). В модели сетевого стека OSI канальный уровень состоит из двух подуровней: MAC (media access control) и LLC (Logical Link Layer). LLC обеспечивает интерфейс между сетевым уровнем и подуровнем доступа к среде MAC. LLC type 1 – сервис без установления соединения, LLC type 2 – сервис с установлением соединения.

Зависимости: Net.

Openvswitch

Модуль обеспечивает программную реализацию многоуровневого Ethernet коммутатора, которая используется для управления трафиком в системах виртуализации. Помимо поддержки различных функций аппаратных коммутаторов OpenvSwitch использует дополнительные программируемые расширения и управление сетью на основе потоков. Дополнительные компоненты обеспечивают возможность преобразования файлов конфигурации различных форматов в правила обработки пакетов. Имеется поддержка нескольких типов туннелирования: GRE, VXLAN, Geneve.

Зависимости: Inet, !NF_Conntrack || (NF_Conntrack && ((!NF_Defrag_IPV6 || NF_Defrag_IPV6) && (!NF_Nat || NF_Nat) && (!Netfilter_Conncount || Netfilter_Conncount))).

Switchdev

Данный модуль реализует API для коммутаторов и является связующим звеном между сетевым кодом ядра Linux и драйверами подобных устройств. Switchdev поддерживает как стандартные коммутаторы, работающие на сетевых уровнях L2/L3, так и различные микросхемы разгрузки потока (flow offloading chips), включая коммутаторы, встроенные в сетевые карты SR-IOV.

Зависимости: Inet.

Batman-adv

Реализация протокола B.A.T.M.A.N. Advanced для маршрутизации в mesh-сетях. Протокол работает на уровне L2 модели OSI, т.е. не нуждаются в настройке IP-адресов и др. При помощи этого протокола создается своеобразный виртуальный распределенный коммутатор. Протокол может работать как с Wi-Fi, так и с Ethernet адаптерами.

Модуль Batman-adv реализует множество функций, требующих каждая отдельной конфигурации.

Зависимости: Net.

Qrtr

Поддержка протокола Qualcomm IPC Router, который используется для взаимодействия с сервисами, предоставляемыми другими аппаратными узлами в системе. Rfkill (RF kill switch).

Модуль реализует универсальный интерфейс для отключения любого радиопередатчика в системе. Когда передатчик заблокирован, он не должен ничего излучать. Подсистема также предоставляет возможность реагировать на нажатия кнопок и отключать все передатчики определенного типа (или все). Это может понадобиться, например, в самолетах. RF коммутаторы встречаются на многих Wi-Fi и Bluetooth картах.

Phonet

Реализация семейства протоколов Phonet.

Phonet (Phone Network protocol) – пакетно-ориентированный коммуникационный протокол, разработанный компанией Nokia для своих модемов.

Протокол Phonet необходим для ОС Maemo, чтобы использовать сотовую связь для передачи данных. Phonet также может использоваться для управления устройствами Nokia с компьютера Linux, хотя AT команды могут быть проще в использовании.

Протоколы сетевого уровня

L3mdev

Реализация API для устройств уровня L3. Модуль является связующим звеном между сетевым кодом ядра Linux и драйверами таких устройств как VRF (virtual routing and forwarding).

Зависимости: Inet || IPv6.

6LoWPAN (IPv6 over Low power Wireless Personal Area Networks)

Реализация стандарта взаимодействия по протоколу IPv6 для маломощных беспроводных персональных сетей, определяемых стандартами IEEE 802.15.4 и Bluetooth.

Appletalk

Реализация протоколов AARP (AppleTalk Address Resolution Protocol, аналог протокола IP-ARP) и DDP (Datagram Delivery Protocol) из сетевого стека AppleTalk для Ethernet 'ELAP' (EtherTalk Link Access Protocol). AppleTalk — стек протоколов, разработанных компанией Apple Computer. Протоколы AARP и DDP относятся к протоколам сетевого уровня модели OSI, ELAP – к канальному уровню.

Netrom

Реализация протокола NET/ROM. NET/ROM – протокол сетевого уровня L3, работающий поверх протокола AX.25 и обеспечивающий прозрачную маршрутизацию соединений.

Сетевые устройства NET/ROM – это виртуальные сетевые устройства, инкапсулирующие кадры NET/ROM в кадры AX.25, для передачи через AX.25-устройства.

Ipv4

Реализация стека протоколов TCP/IP. Данный модуль помимо самого протокола IP включает также протоколы ARP, ICMP, IGMP, TCP, UDP, UDP-Lite (RFC 3828), CIPSO 2.2 (Commercial IP Security Option, draft-ietf-cipso-ipsecurity-01.txt) и др.

Модуль поддерживает многочисленные механизмы, подключаемые дополнительно. Большинство из них перечислены ниже.

  • IP: multicasting
  • IP: advanced router
  • FIB TRIE statistics
  • IP: policy routing
  • IP: equal cost multipath
  • IP: verbose route monitoring
  • IP: kernel level autoconfiguration
  • IP: DHCP support
  • IP: BOOTP support
  • IP: RARP support
  • IP: tunneling (IP-in-IP)
  • IP: GRE demultiplexer
  • IP: GRE tunnels over IP
  • IP: broadcast GRE over IP
  • IP: multicast routing
  • IP: PIM-SM (Sparse Mode - Protocol Independent Multicast)
  • IP: TCP syncookie (механизм защиты от атак типа "SYN flooding")
  • Virtual (secure) IP: tunneling
  • UDP tunneling
  • IP: Foo (IP protocols) over UDP
  • IP: FOU encapsulation of IP tunnels
  • IP: IPsec AH support
  • IP: IPsec ESP support
  • IP: ESP in TCP encapsulation (RFC 8229)
  • IP: IPComp transformation
  • TCP: advanced congestion control
Ipv6

Реализация стека протоколов TCP/IP для протокола IPv6.

Если подсистема IPv6 собрана как самостоятельный модуль, то при попытке выгрузить его возможно падение операционной системы.

Модуль поддерживает многочисленные механизмы, подключаемые дополнительно. Большинство из них перечислены ниже.

  • IPv6: Router Preference (RFC 4191)
  • IPv6: Route Information (RFC 4191)
  • IPv6: Enable RFC 4429 Optimistic DAD (Duplicate Address Detection)
  • IPv6: IPsec AH support
  • IPv6: IPsec ESP support
  • IPv6: ESP in TCP encapsulation (RFC 8229)
  • IPv6: IPComp transformation
  • IPv6: Mobility (RFC 3775)
  • IPv6: Identifier Locator Addressing (ILA)
  • Virtual (secure) IPv6: tunneling
  • IPv6: IPv6-in-IPv4 tunnel (SIT driver)
  • IPv6: IPv6 Rapid Deployment (6RD)
  • IPv6: IP-in-IPv6 tunnel (RFC2473)
  • IPv6: GRE tunnel
  • IPV6_FOU
  • IPV6_FOU_TUNNEL
  • IPv6: Support Multiple Routing Tables
  • IPv6: source address based routing
  • IPv6: multicast routing
  • IPv6: multicast policy routing
  • IPv6: PIM-SM version 2 support
  • IPv6: Segment Routing Header encapsulation support
  • IPv6: Segment Routing HMAC support
  • IPv6: RPL Source Routing Header support
Mpls

Реализация протокола MPLS (MultiProtocol Label Switching). Технология многопротокольной коммутации с помощью меток (Multiprotocol Label Switching, MPLS) руководствуется принципом разделения функций: для определения топологии сети используются протоколы маршрутизации, а для продвижения данных внутри границ сети одного поставщика услуг применяется техника виртуальных каналов. Объединение техники виртуальных каналов с функциональностью стека TCP/IP реализуется посредством объединения в одном сетевом устройстве функций IP-маршрутизатора и коммутатора виртуальных каналов. Такое устройство получило название коммутирующего по меткам маршрутизатора (Label Switching Router, LSR).

Пограничные устройства LSR в технологии MPLS получили специальное название пограничных коммутирующих по меткам маршрутизаторов (Label Switch Edge Router, LER). Коммутаторы LER – это более сложные устройства. Они принимают трафик от других сетей в виде стандартных IP-пакетов, добавляют к нему метку и направляют по соответствующему пути (Label Switched Path, LSP) к выходному коммутатору LER через несколько промежуточных коммутаторов LSR. При этом продвижение пакетов по пути LSP осуществляется не на основе IP-адреса назначения, а на основе метки. Метка имеет локальное значение в рамках каждого коммутатора LER и LSR, т.е. при передаче с входного интерфейса на выходной выполняется смена метки. MPLS поддерживает иерархию путей за счет применения техники стека меток. При этом число уровней иерархии не ограничено.

Выходной пограничный коммутатор LER удаляет метку и передает пакет в следующую сеть уже в виде стандартного IP-пакета. Таким образом, технология MPLS остается прозрачной для остальных IP- сетей.

Протокол распределения меток (Label Distribution Protocol, LDP) позволяет автоматически создавать в сети пути LSP в соответствии с существующими таблицами маршрутизации.

Для тестирования состояния пути LSP в технологии MPLS разработан протокол LSP Ping, работа которого аналогична работе утилиты ping стека TCP/IP. Мониторинг состояния пути LSP можно выполнять с помощью протокола обнаружения двунаправленного продвижения (Bidirectional Forwarding Detection, BFD).

В сетях MPLS реализованы средства обеспечения отказоустойчивости. Поддерживаются разные методы проектирования сетевого трафика (Traffic Engineering, TE), в частности расширения протоколов маршрутизации OSPF и IS-IS, учитывающие свободную пропускную способность каждого канала связи сети, а также расширения протокола резервирования ресурсов (Resource Reservation Protocol, RSVP), используемые для построения путей LSP, удовлетворяющих определённым требованиям и получивших название RSVP-TE.

Netlabel

Подсистема NetLabel обеспечивает через свои механизмы поддержку протоколов маркировки сетевых пакетов, таких как CIPSO и RIPSO. NetLabel реализует механизмы, которые могут использоваться модулями безопасности ядра для присоединения атрибутов безопасности к исходящим сетевым пакетам, которые создаются пользовательскими приложениями, и считывания атрибутов безопасности из входящих сетевых пакетов. Модуль состоит из трех основных компонентов: уровня коммуникации, механизмов протокола и интерфейса (API) модуля безопасности ядра. Уровень коммуникации предназначен для настройки и мониторинга данного модуля из пользовательского пространства. Для передачи сообщений этого уровня используется протокол на основе транспортного механизма Generic NETLINK. Механизмы протокола отвечают как за добавление, так и за извлечение атрибутов безопасности сетевого пакета. Если атрибуты требуют каких-либо действий, то механизм протокола их выполняет. Другие подсистемы ядра должны воздерживаться от прямого вызова механизмов протокола, а использовать вместо этого интерфейс модуля безопасности NetLabel, предоставляющий универсальный доступ к его механизмам.

Зависимости: Security.

Протоколы верхних уровней

Dccp

Реализация протокола DCCP (Datagram Congestion Control Protocol, RFC 4340). DCCP является протоколом транспортного уровня, реализующим двунаправленные одноадресные (unicast) соединения с ненадежной доставкой данных и механизмом управления перегрузками в сети. DCCP предназначен для использования в таких приложениях, как потоковое мультимедиа, интернет-телефония и онлайн-игры, в которых данные, пришедшие не вовремя, становятся бесполезными и лучше получить новое сообщение, чем пытаться переслать старое.

Зависимости: Inet.

Sctp

Реализация протокола SCTP (Stream Control Transmission Protocol, RFC 2960), который является протоколом транспортного уровня с ненадежной доставкой данных, работающим поверх пакетных сетевых протоколов без установления соединения, таких как IP. Протокол обеспечивает:

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

Зависимости: Inet, IPV6 || IPV6=n

Xfrm / IPsec

Модуль Xfrm реализует IP-платформу (framework) для преобразования пакетов (например, шифрования их содержимого). Xfrm используется протоколами IPSec (для взаимодействия с базами данных SAD (Security Association Database) и SPD (Security Policy Database), которые определяют правила обработки трафика: пропустить без обработки, отбросить, преобразовать), а также протоколами IPComp и Mobile IPv6.

Зависимости: Inet.

Tls

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

Зависимости: Inet.

Kcm

Реализация KCM сокетов. KCM (Kernel Connection Multiplexor) сокеты - это механизм, который обеспечивает для пакетных прикладных протоколов интерфейс для передачи данных по протоколу TCP. Сам протокол TCP передает байтовый поток, не распознавая границы пользовательских сообщений. С помощью KCM приложение может отправлять и получать сообщения прикладного протокола через TCP-соединения, используя интерфейс дейтаграмм (datagram sockets). Это позволяет отправлять и принимать сообщения атомарно, что снижает нагрузку на приложения при выделении сообщений из общего TCP потока и повышает скорость работы протоколов прикладного уровня. Чтобы определять границы сообщений во входящем потоке TCP используется анализатор сообщений на основе фильтра BPF, который подключается к мультиплексору вместе с TCP-сокетом. Он анализирует заголовок прикладного сообщения и возвращает его длину. На основе этого KCM создает сообщение указанной длины и доставляет его в KCM-сокет. К одному мультиплексору можно привязать несколько TCP сокетов и несколько KCM сокетов. Все KCM сокеты, привязанные к мультиплексору, считаются эквивалентными, и операции ввода-вывода в разных сокетах могут выполняться параллельно без необходимости синхронизации между потоками в пользовательском пространстве. Также предполагается, что все подключенные TCP-соединения имеют одинаковый адрес назначения, поэтому разные соединения могут использоваться для балансировки нагрузки при передаче. Механизм KCM также позволяет упростить сетевую модель в многопоточных приложениях.

Зависимости: Inet.

Mptcp

Реализация протокола Multipath TCP. Многопотоковый протокол TCP (Multipath TCP, MPTCP) - это набор расширений TCP для предоставления сервиса многопоточности TCP (RFC 6182), который позволяет транспортному соединению использовать несколько путей одновременно. MPTCP позволяет подключаться сразу к нескольким каналам Ethernet, а на мобильном устройстве использовать одновременно Wi-Fi и 3G.

Такой механизм позволяет:

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

Каждый поток использует протокол TCP, а опции TCP (TCP options) содержат информацию заголовка для MPTCP.

Зависимости: Inet.

Caif

CAIF - это протокол MUX, используемый сотовыми модемами ST-Ericsson для связи между модемом и хостом (MUX - это протокол сеансового уровня, отделяющий транспортный протокол от протоколов прикладного уровня.). На хосте процессы могут открывать виртуальные AT каналы, инициировать GPRS-соединения, видео каналы и служебные каналы. Служебные каналы - это каналы общего назначения между модемом и хостом. Модемы ST-Ericsson поддерживают ряд транспортных механизмов между модемом и хостом.

Ceph

Реализация файловой системы CEPH, которая обеспечивает общую функциональность как для самой файловой системы Ceph, так и для блочного устройства rados (rbd).

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

Зависимости: Inet.

9p / 9p2000

Модуль обеспечивает поддержку (в экспериментальном режиме для текущей версии) совместного использования ресурсов (Resource Sharing) операционной системы Plan 9 по протоколу 9P2000 (сетевой протокол удаленной файловой системы / remote filesystem protocol).

Доступная конфигурация модуля позволяет выбирать следующие транспортные механизмы для протокола 9P.

9P Virtio Transport – Поддержка транспорта для виртуальных систем, использующих платформу (framework) virtio.

9P Xen Transport – поддержка транспорта для 9pfs между двумя доменами Xen.

9P RDMA Transport (Experimental) – поддержка транспорта RDMA.

Зависимости: Net.

Dns_resolver

Модуль DNS Resolver используется при выполнении DNS запросов пользовательскими приложениями, например, для преобразования имени хоста в IP-адрес для CIFS или выполнение DNS-запроса для записей базы данных AFSDB.

DNS Resolver используется модулями CIFS и AFS и позже будет поддерживать SMB2, также он используется при пользовательских вызовах с помощью /sbin/dns.resolver через /etc/request-key.conf.

Зависимости: Net && Keys.

Nsh

Реализация протокола NSH (Network Service Header, RFC 8300), который представляет собой механизм обмена метаданными на основе протокола путей служебных функций (Service Function Paths, SFPs). NSH инкапсулирует кадры данных цепочки сервисных функций (Service Function Chaining, SFC), что необходимо для поддержки архитектуры SFC (RFC 7665). В свою очередь, сам NSH инкапсулируется во внешний транспортный протокол.

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

Текущая реализация в Linux поддерживает только MD type 1 и только с модулем Openvswitch.

L2tp (Layer Two Tunneling Protocol)

Реализует протокол L2TP (L2TP, RFC 2661), который является стандартным методом для туннелирования трафика PPP по IP-туннелям (как определено в RFC 2661). Один IP-туннель может обслуживать тысячи отдельных PPP соединений. L2TP также используется в качестве VPN-протокола.

Модуль ядра управляет только пакетами самого L2TP.

В версии L2TPv3 (RFC 3931) протокол L2TP был адаптирован для туннелирования ряда других протоколов L2 (таких как ATM, Frame Relay, HDLC и даже необработанных (raw) кадров Ethernet).

Протокол L2TPv3 определяет два транспорта для инкапсуляции кадров L2TP: UDP и обычный IP (без UDP).

RFC 4719 определяет туннелирование необработанных (raw) кадров Ethernet по протоколу L2TPv3 через IP-сети. В этом случае L2TPv3 может использоваться в качестве протокола управления (control protocol) и для инкапсуляции данных при создании виртуальных сетей.

Зависимости: IPV6 || IPV6=n, Inet.

Rds

Протокол RDS (Reliable Datagram Sockets) обеспечивает надежную, последовательную доставку дейтаграмм при высокой масштабируемости (сотни тысяч конечных точек, десятки тысяч локальных процессов, сотни узлов). При этом между любыми двумя узлами в кластере используется одно надежное соединение. Это позволяет приложениям использовать один сокет для связи с любым другим процессом в кластере (т.е. в кластере с N процессами вам нужно N сокетов, в отличие от N*N, при использовании транспорта с установкой соединения, такого как TCP).

Протокол не требует больших операционных или сетевых ресурсов для обслуживания конечных точек.

RDS был разработан для поддержки различных видов транспорта. Текущая реализация поддерживает RDS через TCP(не поддерживает операции RDMA) и через Infiniband (с поддержкой операций RDMA).

Зависимости: Inet.

Tipc

Протокол прозрачной межпроцессной коммуникации (Transparent Inter Process Communication, TIPC) разработан специально для внутрикластерной связи и предоставляет сервис межпроцессного взаимодействия (IPC) в масштабе всего кластера.

Он может быть сконфигурирован для передачи своих сообщений либо по протоколу IP/UDP, либо непосредственно через Ethernet, используя устройства типа IP-over-InfiniBand. Протокол гарантирует последовательную доставку сообщений, отсутствие потерь пакетов и управление потоком. Время задержки меньше, чем при использовании любого другого известного протокола, в то время как максимальная пропускная способность сопоставима с пропускной способностью TCP. TIPC поддерживает шифрование своих сообщений.

Зависимости: Inet, IPV6 || IPV6=n.

Rxrpc

Реализация сокетов RxRPC.

RxRPC - это двухуровневый протокол. Сеансовый уровень обеспечивает надежные виртуальные соединения поверх протокола UDP-IPv4/ IPv6 и реализует реальный сетевой протокол. Уровень представления отображает структурированные данные в объекты XDR. Протокол RxRPC используется для выполнения удаленных операций RxRPC. Интерфейс протокола реализован через отдельный тип сокетов AF_RXRPC. AF_RXRPC обеспечивает управление безопасностью Kerberos 4 и AFS kaserver, используя службы хранения ключей ядра Linux. RxRPC используется файловой системой AFS (Andrew File System).

Текущая реализация протокола предоставляет только сеансовый уровень. Представление XDR остается на усмотрение приложения. Кроме этого, данный модуль на данный момент поддерживает только клиентские операции и является незавершенным.

Зависимости: Inet.

Sunrpc

Реализация SUN Remote Procedure Call (RPC) - удаленный вызов процедур, разработанный Sun Microsystems и подробно описанный в RFC 5531. Механизмы аутентификации RPC представлены в RFC 2695, 2203, 2623.

Для представления данных используется формат External Data Representation (XDR), который затем передается через UDP или TCP соединения.

Зависимости: Multiuser.

Vmw_vsock

Реализация протокола виртуального сокета (Virtual Socket Protocol). Данный протокол использует стандартный механизм сокетов и, подобно протоколам TCP/IP, обеспечивает передачу сообщений между виртуальными машинами и гипервизором или хостом. Для использования данного протокола требуется подключение одного или нескольких гипервизор-специфичных транспортных протоколов. Данная реализация поддерживает следующие транспорты для виртуальных сокетов:

  • VMware VMCI (для гипервизоров VMware),
  • Virtio (для виртуальных машин, использующих virtio - платформу (framework) виртуализации ввода-вывода для Linux),
  • Hyper-V (для виртуальных машин, использующих Hyper-V VMBus).
Iucv

Inter User Communication Vehicle (IUCV) - это механизм передачи данных в линейке операционных систем IBM VM. Он был представлен с VM / SP Release 1 в 1980 году. Он позволяет устанавливать каналы связи точка-точка либо между двумя виртуальными машинами, либо между виртуальной машиной и службами гипервизора. IUCV реализуется гипервизором виртуальной машины и контролирует все аспекты установления сеанса, передачи сообщений и управления потоком.

Зависимости: S390.

compat.c

32-битная эмуляция системных вызовов модуля Socket. Основана на архитектуре sparc: arch/sparc64/kernel/sys_sparc32.c.

socket.c

Реализация сетевой подсистемы сокетов, предоставляющей пользовательскому уровню интерфейс доступа к сети. Данный модуль реализует самый верхний уровень интерфейса в парадигме BSD сокетов. Основан на разработках Swansea University Computer Society NET3.039.