Выпускная квалификационная работа бакалавра



страница5/8
Дата18.11.2016
Размер3.41 Mb.
Просмотров1140
Скачиваний1
ТипПояснительная записка
1   2   3   4   5   6   7   8

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


Сетевая подсистема ядра является более разветвлённее интерфейсов устройств Linux. Но, несмотря на обилие возможностей (например, если судить по числу обслуживающих сетевых утилит: ifconfig, ip, netstat, route ... и до нескольких десятков иных) — сетевая подсистема Linux, с позиции разработчика ядра, логичнее и прозрачнее, чем, например, тот же интерфейс устройств. Сетевая подсистема Linux ориентирована в большей степени на обслуживание протоколов Ethernet на канальном уровне и TCP/IP на транспортном уровне, но эта модель расширяется с равным успехом и на другие типы протоколов, таким образом покрывая весь спектр возможностей. Сеть TCP/IP, как известно, весьма условно вписывается в 7-уровневую модель OSI взаимодействия открытых систем (она и разработана раньше модели OSI, и, естественно, они не соответствуют друг другу). В Linux сложилась такая терминология разделения на подуровни, что:

всё, что относится к поддержке оборудования и канальному уровню — описывается как сетевые интерфейсы;

протоколы сетевого уровня OSI (IP/IPv4/IPv6, IPX, ICMP, RIP, OSPF, ARP, ... ) — как сетевой уровень стека протоколов (или L2);

всё, что выше (UDP, TCP, SCTP ...) - как протоколы транспортного уровня (или L3);

всё же то, что относится к выше лежащим уровням (сеансовый, представительский, прикладной) модели OSI (например: SSH, SIP, RTP, ...) — никаким образом не проявляется в ядре, и относится уже только к области клиентских и серверных утилит пространства пользователя.

Сетевая реализация построена так, чтобы не зависеть от конкретики протоколов. Основной структурой данных описывающей сетевой интерфейс (устройство) является struct net_device, к ней мы вернёмся позже, описывая устройство [3].

А вот основной структурой обмениваемых данных (между сетевыми уровнями), на движении которой построена работа всех сетевых уровней — есть буферы сокетов (определения в ). Буфер сокетов состоит их двух частей: данные управления struct sk_buff, и данные пакета (указываемые в struct sk_buff указателями head и data). Буферы сокетов всегда увязываются в очереди (struct sk_queue_head) посредством своих двух первых полей next и prev. В листинге 3.1 предоставлены некоторые поля структуры.

Листинг 3.1 – Пример структуры sk_buf на языке Си




typedef unsigned char *sk_buff_data_t;

struct sk_buff {

struct sk_buff *next; /* These two members must be first. */

struct sk_buff *prev;

...

sk_buff_data_t transport_header;



sk_buff_data_t network_header;

sk_buff_data_t mac_header;

...

unsigned char *head,



*data;

...


};


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



буфер сокета и его связи с другими структурами

Рисунок 3.4 – Пример структуры sk_buff

Как можно заметить, несколько структур sk_buff для данного соединения могут быть связаны вместе рисунок 3.4. Каждая из них идентифицирует структуру устройства (net_device), которому пакет посылается или от которого получен. Так как каждый пакет представлен в sk_buff, заголовки пакетов удобно определены набором указателей (th, iph и mac для Управления доступом к среде (заголовок Media Access Control или MAC). Поскольку структуры sk_buff являются центральными в организации данных сокета, для управления ими был создан ряд функций поддержки. Существуют функции для создания, разрушения, клонирования и управления очередностью sk_buff.

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


3.7Сетевые интерфейсы


Роль сетевого интерфейса в системе аналогична таковой для смонтированного блочного устройства. Блочное устройство регистрирует в ядре свои диски и методы и затем "передаёт" и "получает" блоки по запросу, означающему вызов его функции request. Аналогичным образом сетевой интерфейс должен зарегистрировать себя в определённых структурах данных ядра, чтобы быть вызванным, когда происходит обмен пакетами с внешним миром[5].

Есть несколько важных различий между смонтированными дисками и интерфейсами доставки пакеты. Начнём с того, что диск существует в виде специального файла в каталоге /dev, в то время как сетевой интерфейс не имеет такой точки входа. Нормальные операции с файлами (чтение, запись и так далее) не имеют смысла применительно к сетевым интерфейсам, так что невозможно применять к ним подход Unix "всё есть файл". Таким образом, сетевые интерфейсы существуют в их собственном пространстве имён и экспортируют другой набор операций.

Хотя вы можете возразить,что при использовании сокетов приложения используют системные вызовы read и write, эти вызовы на программное обеспечение объекта, который отличается от интерфейса. На одном физическом интерфейсе может быть мультиплексировано несколько сотен сокетов[4].

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

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

Сетевая подсистема ядра Linux разработана так, чтобы быть полностью независимой от протокола. Это относится как к сетевым протоколам (Интернет-протокол [IP] по сравнению с IPX и другими протоколами) и аппаратным протоколам (Ethernet по сравнению с Token Ring и другими). Взаимодействие между сетевым драйвером и ядром имеет дело должным образом с одним сетевым пакетом за раз; это позволяет проблемам протокола быть аккуратно скрытыми от драйвера и физической передаче быть скрытой от протокола[7].





Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал