ОСОБЕННОСТИ РЕАЛИЗАЦИИ АЛГОРИТМА ДРОБЛЕНИЯ ПАКЕТОВ В ТРАНСПОРТНЫХ ПРОТОКОЛАХ

АННОТАЦИЯ

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

В современных компьютерных сетях используется стек протоколов TCP/IP, который включает два основных транспортных протокола для передачи данных – Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). Все современные устройства и сетевое оборудование работают только с двумя существующими протоколами, поэтому, как правило, реализация альтернативного транспортного протокола осуществляется поверх UDP [1].

При этом протокол UDP обладает ограничением на максимальный размер передаваемого пакета. Чтобы быть уверенным, что UDP пакет будет принят любым хостом, размер данных не должен превышать 508 байт [2]. Теоретически, пакеты бо́льших размеров могут быть фрагментированы на уровне протокола IP, однако на практике далеко не всё сетевое оборудование поддерживает работу с фрагментированными IP пакетами, поэтому целесообразно реализовать алгоритм фрагментирования (дробления) таких пакетов на уровне транспортного протокола.

В общем случае схему взаимодействия можно представить в следующем виде (рисунок 1).

Рисунок 1. Схема взаимодействия

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

Количество частей k, на которые необходимо фрагментировать исходный пакет, можно получить по формуле:

где d – размер исходного пакета, m – максимально допустимый размер пакета для передачи по сети (обычно 508 байт), s – размер служебного заголовка.

Также для малых k (k < 5) имеет смысл фрагментировать исходный пакет на равные части:

где d_k – размер одного фрагмента.

Например, необходимо передать пакет размером d = 1100 байт. Положим s = 8 байт, тогда по формуле (1) получим 2,2, т.е. исходный пакет необходимо разделить на 3 пакета. При «грубом» разделении получим пакеты длинной 500, 500 и 100 байт соответственно. Такой резкий кратковременный всплеск пакетов с максимальной длиной в условиях низкоскоростного соединения может негативно сказаться на алгоритмах работы допустимой пропускной способности. Данный всплеск можно «сгладить», разделив пакет на равные части по формуле (2), тогда получим d_k = 366,7. То есть получим пакеты длиной 367, 367 и 366 байт соответственно.

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

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

- уникальный идентификатор фрагментированного пакета;

- порядковый номер фрагмента;

- общее число фрагментов.

На данном этапе важным является то, каким количеством битов следует закодировать каждое из полей служебного заголовка, чтобы, с одной стороны, минимизировать накладные расходы при передаче фрагментированных пакетов, а с другой стороны – обеспечить достаточные возможности при передаче. Так, например, уникальный идентификатор можно закодировать 4 битами, тогда исходя из формулы Хартли [3]:

получим, что в буфере отправки/приёма может находиться не более 16 уникальных пакетов, фрагментированных на более мелкие. В большинстве случаев этого должно быть достаточно. При этом, если выбрать такое же количество бит для кодирования числа фрагментов, то исходный пакет можно будет разделить на не более чем 16 фрагментов. Исходя из формулы (1) получим, что максимальный допустимый передаваемый пакет будет ограничен ~8 кб, что существенно мало. При кодировании порядкового номера 8 битами (1 байтом), допустимый размер возрастёт до ~126 кб.

Таким образом, подбор данных параметров зависит от требований прикладного приложения, в котором будет задействован транспортный протокол. Для широкого спектра задач целесообразно закодировать каждое поле служебного заголовка соответственно 1, 1, 2 и 2 байтами. В таком случае s = 6.

При разработке алгоритма фрагментации также весьма важным является вопрос приоритизации трафика по гарантии доставки, рассмотренный в статье [4]. Выделены 4 основных класса гарантии доставки: «ненадёжные», «ненадёжные последовательные», «надёжные», «надёжные упорядоченные». Исходя из описания первых двух классов следует, что если пакет будет утерян, то его повторная отправка не производится. В случае фрагментирования такого пакета это означает, что если одна из частей пакета будет утеряна, то весь пакет следует считать утерянным, при этом успешно доставленные части могут оставаться «висеть» в буфере приёма. Чем больше отправляемый пакет, тем выше вероятность, что он не будет доставлен успешно, следовательно, не имеет смысла отправлять большие пакеты с такой гарантией доставки. Наиболее рациональным является класс «надёжные», как с точки зрения передачи больших пакетов, так и с точки зрения передачи служебных пакетов с фрагментированными частями. В данном классе гарантируется доставка данных, но не гарантируется порядок.

Однако если необходимо соблюдать порядок (т.е. использовать класс «надёжные упорядоченные»), то могут возникнуть следующие сложности:

- необходимо кодировать уникальный идентификатор бо́льшим количеством битов (для возможности однозначной идентификации каждого пакета), что ведёт к увеличению размера служебного заголовка s, и, как следствие, увеличивает накладные расходы на все передаваемые фрагментируемые пакеты;

- пришедшие вне очереди фрагментированные пакеты необходимо удерживать в буфере приёма, что может привести к его переполнению;

- необходимо согласовывать фрагментированные и нефрагментированные «надёжные упорядоченные» пакеты.

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

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

Список литературы:

1. Белов Е.А., Пак В.В. АНАЛИЗ НЕДОСТАТКОВ ТРАНСПОРТНЫХ ПРОТОКОЛОВ В СОВРЕМЕННЫХ КОМПЬЮТЕРНЫХ СЕТЯХ И МЕТОДОВ ИХ УСТРАНЕНИЯ // Вопросы технических и физико-математических наук в свете современных исследований: сб. ст. по матер. XXXIV междунар. науч.-практ. конф. № 12(27). – Новосибирск: СибАК, 2020. – С. 5-9.
2. UDP // Википедия URL: https://ru.wikipedia.org/wiki/UDP (дата обращения: 31.10.2021).
3. Формула Хартли // Википедия URL: https:// ru.wikipedia.org/wiki/Формула_Хартли (дата обращения: 31.10.2021).
4. Белов Е.А. ВОПРОСЫ ПРИОРИТИЗАЦИИ ТРАФИКА ПРИ РАЗРАБОТКЕ ТРАНСПОРТНОГО ПРОТОКОЛА ДЛЯ СЕТЕВЫХ ПРИЛОЖЕНИЙ, ЧУВСТВИТЕЛЬНЫХ К СЕТЕВЫМ ЗАДЕРЖКАМ // Вопросы технических и физико-математических наук в свете современных исследований: сб. ст. по матер. XXXIX междунар. науч.-практ. конф. № 5(31). – Новосибирск: СибАК, 2021. – С. 6-10.