Какой максимально возможный размер дейтаграммы ip

Как разбиваются данные на куски в протоколе TCP/IP?

Протокол пользовательских датаграмм

IPv4 — IPv4

Протоколы Ш уровня стека ТСРЯР Протокол IPv4

MTU и модель OSI

Зачем нужен MTU?

У протокола TCP есть MSS

функциональность

характеристики

Дейтаграмма UDP

UDP-Lite

Содержание

История

Адресация

Исчерпание адресного пространства

Структура пакета

Фрагментация и повторная сборка

Вспомогательные протоколы

Псевдо заголовки

Расчет контрольной суммы

Представления адресов

Распределение

Адреса специального назначения

Локальная адресация канала

Loopback

Первый и последний адреса подсети

Разрешение адресов

Заголовок

Данные

Фрагментация

Повторная сборка

Частные сети

Изучаю сети. Не понимаю момент про размер кусков (сегмент, пакет, кадр), которые создаются для передачи кадра по сети. Например, tcp-сегмент при использовании технологии передачи ethernet2 может быть максимально 1500 байт. то есть, с прикладного уровня пришли данные с заголовком http (например, веб-сервер отдал документ хтмл), эти данные разбились на куски-сегменты по 1500 байт. потом [заголовок tcp + сегмент] с транспортного уровня передается уровню ip. написано, что максимальный размер пакета уровня ip = 65535 байт. Не понимаю — идет разбиение на куски по 1500 байт на транспортном уровне, зачем указан размер 65535 байт, если передаваемые куски имеют размер 1500 байт?

Затем, что по ip работает не только tcp, но и udp, и icmp. У каждого протокола свой предел.

А сети бывают не только ethernet.

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

Протоколы транспортного уровня (протоколы TCP или UDP), пользующиеся сетевым уровнем для отправки пакетов, считают, что максимальный размер поля данных IP-пакета равен 65535, и поэтому могут передать ему сообщение такой длины для транспортировки. В функции уровня IP входит разбиение слишком длинного для конкретного типа составляющей сети сообщения на более короткие пакеты с созданием соответствующих служебных полей, нужных для последующей сборки фрагментов в исходное сообщение.

В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки — Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI — 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

MTU является характеристикой канального уровня модели OSI. Если IP хочет отослать датаграмму, которая больше чем MTU канального уровня, осуществляется фрагментация (fragmentation), при этом датаграмма разбивается на меньшие части (фрагменты). Каждый фрагмент должен быть меньше чем MTU.

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

Теоретически, максимальный размер IP-дейтаграммы составляет 65 535 байтов, что обусловлено 16-разрядным полем полной длины в IP-заголовке.

Вам пользователь @Smithson сообщил правильный ответ, ведь IP работает не только над Ethernet, в каждой сети свой размер.

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

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

Есть такое понятие, как максимальный Размер TCP Сегмента (MSS), который определяет максимальное количество данных, которые хост желает принимать в единственной TCP/IP датаграмме.

Мало того, эта TCP/IP датаграмма может быть фрагментирована в уровне IP.

Значение MSS посылают как опцию TCP заголовка только в сегменте TCP SYN. Каждая сторона на TCP соединении сообщает свое значение MSS другой стороне. Хост отправитель обязан ограничивать размер данных в единственном TCP сегменте в значение, меньшем или равном MSS, о котором сообщает хост получатель.

Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение. Пример работы MSS:

Машина А сравнивает размер своего буфера интерфейса (16 Кбайт) со значение MTU этого интерфейса (1500-40 = 1460 байт) и использует наименьшее число как MSS при отправке к машине B.
Машина B принимает значение MSS машины A (1460) и сравнивает его со значением MTU своего исходящего интерфейса (4462 — 40 = 4422 байт).
Машина B выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине A.
Машина B сравнивает размер своего буфера интерфейса (8 Кбайт) со значение MTU этого интерфейса (4462-40 = 4422 байт) и использует наименьшее число как MSS при отправке к машине A.
Машина A принимает значение MSS машины B (4422) и сравнивает его со значение MTU своего исходящего интерфейса (1500 — 40 = 1460 байт).
Машина A выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине B.

Таким образом MSS на обеих сторонах установлено равным 1460 байтам, это наиболее частая ситуация.

Например, tcp-сегмент при использовании технологии передачи ethernet2 может быть максимально 1500 байт

Проблемы начинаются где-то здесь. 1 500 — это вполне стандартный размер пакета (любого протокола сетевого уровня, не обязательно АйПи), который умещается в езернетный кадр. Длина сегмента ТиСиПи ещё меньше, вполне обычным значением является 1 460, как раз для того, чтобы конечный пакет (с заголовками ТиСиПи и АйПи), мог уложиться в 1 500 октетов. Стандартный размер, если не согласовано иное, и вовсе 536 (как указано в разделе 4.2.2.6 РФЦ 1122, жаль что нет перевода РФЦ 6691 (англ)).

В принципе, размер сегмента выбирается сетевым стеком ОС, как раз таки с учётом максимальных параметров передачи, потому как и в Езернет может пролазить 9 000 октетов, и не только Езернет бывает в этом мире.

идет разбиение на куски по 1500 байт на транспортном уровне, зачем указан размер 65535 байт, если передаваемые куски имеют размер 1500 байт?

Это же максимальный размер. Максимальный размер сегмента ТиСиПи равен тому же самому значению, кстати говоря, поскольку в обоих случаях используются поля по 16 бит. И если смотреть совсем строго, то сегмент ТиСиПи максимального размера вообще невозможно отправить по протоколу АйПи! Как так получилось? Да просто решили, что 16 бит хватит и тут, и там. Что характерно, не ошиблись, хватает с запасом.

Важно понимать, что вся матрёшка слоёв сетевого стека изначально задумана для жёсткого разделения решаемых в разных слоях вопросов и принципиально подразумевает независимость протоколов разного уровня. И при возникновении подобных вопросов, первое о чём имеет смысл задуматься, это что будет, если вместо протокола А на каком-то уровне будет использоваться неведомый протокол Б. Поэтому, теоретические ограничения на каждом из уровней свои и согласование реальных параметров идёт уже исходя из реальных условий. Например, для АйПи поверх Инфинибэнда типично ограничение по размеру пакета в 2 044 октета (размер сегмента ТиСиПи предлагаю посчитать самостоятельно).

Но ещё интереснее то, как вроде бы недостижимые на проводе максимумы иногда находят неожиданное применение. Например, даже несмотря на то, что в Езернет больше 9 000 не пролазит, вполне реалистично получить пакет длиной около 64К, содержащий внутри сегмент ТиСиПи со столь же близким к 64К значением! Всё за счёт аппаратного (иногда драйверного) ускорения получения данных (для десятигигабитной сети явление повсеместное) — карта снимает с провода набор пакетов "нормальной" длины для одного соединения и переупаковывает их в один такой мега-пакет. В результате, ОС вообще не видит изначального "горошка", для неё пришёл один пакет длиной 64К, с ним она дальше и будет работать. Может и наружу такой же мега-пакет отправить, а реальную сегментацию до нужной длины выполнит уже сетевая карта.

Примером же практически естественного использования МТУ в 64К является интерфейс обратной петли, по умолчанию в Линуксах на нём именно такой МТУ (причём его до 2ГБ можно увеличивать! только это уже как раз бесполезно для рядовых протоколов верхних уровней), и именно на такие куски будет биться тисипишный поток, упаковываясь по дороге в айпишные пакетики (плюс-минус накладные расходы на заголовки).

Протокол пользовательских дейтаграмм или сокращенно UDP — это минимальный сетевой протокол без установления соединения , который принадлежит к транспортному уровню семейства интернет-протоколов . UDP позволяет приложениям отправлять дейтаграммы в компьютерные сети на основе IP .

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

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

Кроме того, UDP предлагает возможность проверки целостности путем отправки контрольной суммы . Это означает, что неправильно переданные дейтаграммы могут быть распознаны и отброшены.

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

Поскольку соединение не требуется устанавливать до начала передачи, один или оба партнера могут начать обмен данными быстрее. Это особенно важно в приложениях, в которых требуется обмен небольшими объемами данных. Простые протоколы вопросов и ответов, такие как DNS (система доменных имен ), в основном используют UDP для разрешения имен, чтобы снизить нагрузку на сеть и, таким образом, увеличить пропускную способность данных. Трехэтапный как и с TCP ( протокол управления передачей ) для установления соединения будет генерировать ненужную нагрузку в этом случае .

Кроме того, незащищенная передача также предлагает преимущество небольших колебаний задержки передачи: если пакет теряется во время TCP-соединения, он автоматически запрашивается снова. Это требует времени, и поэтому время передачи может колебаться, что плохо для мультимедийных приложений. С VoIP z. B. Произойдут внезапные выпадения или буферы воспроизведения должны быть увеличены. С другой стороны, в случае услуг связи без установления соединения потерянные пакеты не останавливают всю передачу, а только снижают качество.

Теоретически максимальный размер дейтаграммы UDP составляет 65 535 байтов, поскольку длина поля заголовка UDP составляет 16 бит, а наибольшее число, которое может быть представлено 16 битами, составляет 65 535 (= 2 16 -1). Однако такие большие сегменты передаются по IP фрагментированными. На практике максимально возможная длина дейтаграммы UDP подвергается дополнительным ограничениям .

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

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

Исходный порт указывает номер порта отправляющего процесса. Эта информация необходима для того, чтобы получатель мог ответить на посылку. Поскольку UDP не поддерживает соединение, исходный порт является необязательным и может быть установлен на значение «0» (в случае, если не ожидается никаких ответных пакетов, а только пакеты должны быть отправлены получателю). Порт назначения указывает, какой процесс должен получить пакет. Längenfeld определяет длину дейтаграммы, состоящей из данных и заголовка, в октетах . Наименьшее возможное значение — 8 октетов (или байтов). Поле длины определяет теоретический верхний предел 2 16 -1 = 65 535 байтов (8-байтовый заголовок + 65 527 байтов пользовательских данных). Фактически доступная длина пользовательских данных обусловлена лежащим в основе IP-протоколом, однако, 65 507 байтов (65 535 — 8 байтов заголовок UDP — 20 байтов заголовок IP) при использовании IPv4 и 65 487 байтов (65 535 — 8 байтов заголовок UDP — 40 байтов. Заголовок IPv6)) при использовании IPv6 . Поле контрольной суммы также может быть отправлена 16-битная контрольная сумма . Контрольная сумма формируется с использованием так называемого псевдозаголовка, заголовка UDP и данных. Контрольная сумма не является обязательной, но почти всегда используется на практике, в противном случае она устанавливается на «0». Поле данных он содержит фактическую полезную нагрузку, также известную как полезная нагрузка . Поле является необязательным и теоретически может полностью отсутствовать, чего на практике никогда не бывает. Поле данных всегда состоит из четного числа октетов. Октеты, которые остаются свободными в конце, дополняются нулями.

Интернет-протокол (IP) предназначен для передачи пакета UDP . Перед пакетом UDP этот протокол помещает другой заголовок, в котором находятся данные, требуемые IP:

Для генерации контрольной суммы UDP части этого IP-заголовка передаются в так называемый «псевдозаголовок». Он используется только для генерации контрольной суммы и не передается.

В IPv4 псевдозаголовок имеет размер 12 октетов (96 бит) и состоит из IP-адреса источника (32 бита), IP-адреса назначения (32 бита), 8-битного пустого поля и 8-битного идентификатора протокола. (UDP имеет ID 17 ) и длина дейтаграммы UDP (16 бит):

немного	0	32	64	72	80	96
Исходный IP-адрес	IP-адрес получателя	00000000	ID протокола	Длина дейтаграммы UDP
Псевдо-заголовок IPv4

В IPv6 псевдозаголовок имеет размер 40 октетов (320 бит). Он состоит из следующего:

немного	0	128	256	288	312	320
Исходный IP-адрес	IP-адрес получателя	Длина пакета верхнего уровня	0 (24 бит)	Следующий заголовок
Псевдо-заголовок IPv6

Контрольная сумма отправителя рассчитывается по следующему алгоритму:

Установите поле контрольной суммы в заголовке UDP на 0000 0000 0000 0000.
Сгенерируйте 32-битное число без знака для контрольной суммы, инициализируйте его нулями.
Объедините непосредственно соседние байты пакета UDP в 16-битные блоки. Если последний блок меньше 16 бит, то заполняйте его нулями с конца, пока он не станет 16 битов.
Сохраните результат сложения всех 16-битных блоков с переносом контрольной суммы.
Объедините непосредственно соседние байты псевдозаголовка в 16-битные блоки.
Сохраните результат сложения этих 16-битных блоков и предыдущую контрольную сумму с переносом контрольной суммы.
Объедините непосредственно соседние байты контрольной суммы в два 16-битных блока, сложите их и сохраните результат с переносом контрольной суммы до тех пор, пока не закончится перенос в сложении.
Старшие 16 бит 32-битной контрольной суммы теперь нули. Менее значимые биты — это фактическая контрольная сумма; сохраните это как 16-битное число без знака.
Если это 16-битное число не все единицы, то сохраните его дополнение в заголовке UDP (как 1111 1111 1111 1111, так и его дополнение 0000 0000 0000 0000 символизируют число 0). В IPv4 UDP 0000 0000 0000 0000 также используется для сигнализации о том, что контрольная сумма не вычислена. Пакеты IPv6 UDP с контрольной суммой 0000 0000 0000 0000 недействительны ( RFC 6935 ).

Получатель сначала проверяет, состоит ли поле контрольной суммы полученного пакета только нулями. Если это так, он может оценить пакет как правильно полученный, поскольку контрольная сумма отсутствует. В противном случае он применяет алгоритм, описанный выше, к полученному пакету и связанному псевдозаголовку, пропускает последний шаг и добавляет самосчитанную контрольную сумму к контрольной сумме, полученной в поле контрольной суммы, что соответствует вычитанию из- за представления дополнения до единицы. . Если получатель получает 0 в результате сложения (или вычитания), он оценивает полученные данные как такие же, как отправленные.

Протокол облегченных пользовательских дейтаграмм (UDP-Lite) в соответствии с RFC 3828 является разновидностью UDP, особенно для передачи данных, где важна малая задержка, но допускаются меньшие ошибки. Так обстоит дело, например, с передачами аудио и видео в реальном времени , которые часто используют UDP в качестве транспортного протокола. Если бит в пакете данных UDP неисправен, все данные в пакете, т.е. ЧАС. до нескольких тысяч бит, отброшенных. Если, с другой стороны, использовался пакет с ошибочным битом, ошибка была бы неслышной или невидимой , в зависимости от кодека . Использование UDP-Lite должно подавлять проверку определенных частей пакетов данных нижними уровнями, эффективно только для пакетов UDP-Lite. На уровне Ethernet это влияет на проверку CRC пакетов.

UDP-Lite совместим с UDP, но интерпретирует поле длины как длину, по которой вычисляется контрольная сумма ( покрытие контрольной суммы ). Обычный пакет UDP всегда соответствует спецификациям UDP-Lite. И наоборот, это не обязательно так, поскольку UDP-Lite определяет более высокую степень свободы. Длина пакета UDP или UDP-Lite может быть рассчитана с использованием информации уровня Интернет-протокола ; длина IP — это сумма размера заголовка IP и размера пакета UDP. Если IP-заголовок в UDP-Lite длиннее, чем в поле длины заголовка UDP (-Lite), пакет содержит дополнительные непроверенные данные. Например, поле длины восемь означает, что контрольная сумма вычисляется только с использованием заголовка. При нулевом значении контрольная сумма вычисляется по всему пакету. Значения 1,…, 7 недопустимы, т.е. ЧАС. заголовок UDP-Lite всегда включается в контрольную сумму. Ограничение максимального размера пакета от UDP (65 535 байт) больше не применяется. В этом случае контрольная сумма может быть вычислена либо для всего пакета, либо, самое большее, для первых 65 535 байт.

Интернет-протокол версии 4 (IPv4 ) является четвертой версией Интернет-протокола (IP). Это один из основных протоколов основанных на стандартах методов межсетевого взаимодействия в Интернет и других сетях с коммутацией пакетов. IPv4 был первой версией, развернутой для производства на SATNET в 1982 году и на ARPANET в январе 1983 года. Он по-прежнему направляет большую часть интернет-трафика сегодня, несмотря на продолжающееся развертывание протокола-преемника, IPv6.

IPv4 использует адресное пространство 32- бит, которое обеспечивает 4 294 967 296 (2) уникальных адресов, но большие блоки зарезервированы для специальных сетевых методов.

1 История
2 Назначение

3 Адресация

3.1 Представление адресов
3.2 Распределение

3.3 Адреса специального назначения

3.3.1 Частные сети

5.1 Заголовок
5.2 Данные

6.1 Фрагментация
6.2 Повторная сборка

Уровень IP был первоначально разделен в v3 TCP для улучшения дизайна и стабилизирован в версии 4. IPv4 описан в IETF публикации RFC 791 (сентябрь 1981 г.), заменив более раннее определение (RFC 760, январь 1980 г.). В марте 1982 года Министерство обороны США объявило TCP / IP стандартом для всех военных компьютерных сетей.

Интернет-протокол — это протокол, который определяет и включает межсетевое взаимодействие на Интернет-уровне из Internet Protocol Suite. По сути, это Интернет. Он использует систему логической адресации и выполняет маршрутизацию, которая представляет собой пересылку пакетов от исходного хоста к следующему маршрутизатору, который на один шаг ближе к предполагаемому конечному узлу в другой сети.

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

Разложение представления адреса IPv4 с четырьмя точками на его двоичное значение

IPv4 использует 32-битные адреса, которые ограничивают адресное пространство до 4294967296 (2) адресов.

IPv4 резервирует специальные блоки адресов для частных сетей (

270 миллионов адресов).

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

Например, IP-адрес 192.0.2.235, разделенный точками, представляет собой 32-битное десятичное число 3221226219, которое в шестнадцатеричном формате равно 0xC00002EB. Это также может быть выражено в шестнадцатеричном формате с точками как 0xC0.0x00.0x02.0xEB или в восьмеричных байтовых значениях как 0300.0000.0002.0353.

Нотация CIDR объединяет адрес с его префиксом маршрутизации в компактном формате, в котором за адресом следует косая черта (/) и количество ведущих последовательных 1 битов в префиксе маршрутизации (маска подсети).

Другие представления адресов широко использовались, когда классовая сеть практиковалась. Например, адрес обратной связи 127.0.0.1 обычно записывается как 127.1, учитывая, что он принадлежит к сети класса A с восемью битами для маски сети и 24 битами для номера хоста. Если в адресе в виде точек с точками указано менее четырех чисел, последнее значение рассматривается как целое число байтов, которое требуется для заполнения адреса до четырех октетов. Таким образом, адрес 127.65530 эквивалентен 127.0.255.250.

В первоначальном дизайне IPv4 IP-адрес был разделен на две части: сетевой идентификатор был самым значимым октетом адреса, а идентификатор хоста был остальной частью адрес. Последнее также называлось остальным полем. Эта структура позволяла использовать максимум 256 сетевых идентификаторов, что было быстро признано неадекватным.

Чтобы преодолеть этот предел, в 1981 году октет старшего адреса был переопределен для создания сетевых классов в системе, которая позже стала известна как классовая сеть. В пересмотренной системе определены пять классов. Классы A, B и C имели разную длину в битах для сетевой идентификации. Остальная часть адреса использовалась, как и раньше, для идентификации хоста в сети. Из-за разного размера полей в разных классах каждый сетевой класс имел разную емкость для адресации хостов. В дополнение к трем классам для адресации хостов, класс D был определен для адресации многоадресной передачи, а класс E был зарезервирован для будущих приложений.

Разделение существующих классовых сетей на подсети началось в 1985 году с публикации RFC 950. Это разделение стало более гибким с введением масок подсети переменной длины (VLSM) в RFC 1109 в 1987 году. В 1993 году на основе этой работы RFC 1517 представил бесклассовую междоменную маршрутизацию (CIDR), которая выражала количество битов (от наиболее значимого ) как, например, / 24, а схема на основе классов, напротив, была названа классной. CIDR был разработан, чтобы разрешить перераспределение любого адресного пространства, чтобы пользователи могли выделять меньшие или большие блоки адресов. Иерархическая структура, созданная CIDR, управляется Управлением по присвоению номеров Интернета (IANA) и региональными интернет-реестрами (RIR). Каждый RIR поддерживает общедоступную базу данных WHOIS с возможностью поиска, которая предоставляет информацию о назначенных IP-адресах.

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

Специальные адресные блоки

Адресный блок	Диапазон адресов	Количество адресов	Область действия	Описание
0.0.0.0/8	0.0.0.0–0.255.255.255	16777216	Программное обеспечение	Текущая сеть (действительна только в качестве адреса источника).
10.0.0.0/8	10.0.0.0–10.255.255.255	16777216	Частная сеть	Используется для локальной связи в пределах частная сеть.
100.64.0.0/10	100.64.0.0–100.127.255.255	4194304	Частная сеть	Общее адресное пространство для связи между поставщиком услуг и его абонентами при использовании NAT операторского уровня.
127.0.0.0/8	127.0.0.0–127.255.255.255	16777216	Хост	Используется для адресов обратной связи к локальному хосту.
169.254.0.0/16	169.254.0.0–169.254.255.255	65536	Подсеть	Используется для локальных адресов канала между двумя хостами по одному каналу, если не указан другой IP-адрес, например, который обычно был бы получен из DHCP сервер.
172.16.0.0/12	172.16.0.0–172.31.255.255	1048576	Частная сеть	Используется для локальной связи в частной сети.
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Частная сеть	Назначение протокола IETF.
192.0.2.0/24	192.0.2.0–192.0.2.255	256	Документация	Назначено как TEST-NET-1, документация и примеры.
192.88.99.0/24	192.88.99.0–192.88.99.255	256	Интернет	Зарезервировано. Ранее использовалось для ретрансляции IPv6 в IPv4 (включая блок адресов IPv6 2002 :: / 16 ).
192.168.0.0/16	192.168.0.0–192.168.255.255	65536	Частная сеть	Используется для локальной связи в частной сети.
198.18.0.0/15	198.18.0.0–198.19.255.255	131072	Частная сеть	Используется для эталонного тестирования меж- сетевой обмен данными между двумя отдельными подсетями.
198.51.100.0/24	198.51.100.0–198.51.100.255	256	Документация	Назначен TEST-NET-2, документация и примеры.
203.0.113.0/24	203.0.113.0–203.0.113.255	256	Документация	Обозначается как TEST-NET-3, документация и примеры.
224.0.0.0/4	224.0.0.0–239.255.255.255	268435456	Интернет	Используется для многоадресной IP-адресации. (Бывшая сеть класса D).
240.0.0.0/4	240.0.0.0–255.255.255.254	268435455	Интернет	Зарезервировано для использования в будущем. (Бывшая сеть класса E).
255.255.255.255/32	255.255.255.255	1	Подсеть	Зарезервировано для «ограниченного широковещательного адреса назначения.

Из примерно четырех миллиардов адресов, определенных в IPv4, около 18 миллионов адресов в трех диапазонах зарезервированы для использования в частных сетях. Адреса пакетов в этих диапазонах не маршрутизируются в общедоступном Интернете; они игнорируются всеми общедоступными маршрутизаторами. Следовательно, частные узлы не могут напрямую связываться с общедоступными сетями, но для этой цели требуется преобразование сетевых адресов на шлюзе маршрутизации.

Зарезервированные диапазоны частных IPv4-сетей

Имя	CIDR блок	Диапазон адресов	Количество адресов	Классовое описание
24- битовый блок	10.0.0.0/8	10.0.0.0 — 10.255.255.255	16777216	одиночный класс A.
20-битный блок	172.16.0.0/12	172.16.0.0 — 172.31.255.255	1048576	Непрерывный диапазон из 16 блоков класса B.
16-битный блок	192.168.0.0/16	192.168.0.0 — 192.168.255.255	65536	Непрерывный диапазон 256 класса C блоки.

Поскольку две частные сети, например два филиала, не могут напрямую взаимодействовать через общедоступный Интернет, эти две сети должны быть соединены через Интернет через виртуальную частную сеть (VPN) или IP-туннель, который инкапсулирует пакеты, включая их заголовки, содержащие частные адреса, на уровне протокола во время передачи по общедоступной сети. Кроме того, инкапсулированные пакеты могут быть зашифрованы для передачи по общедоступным сетям для защиты данных.

RFC 3927 определяет специальный блок адреса 169.254.0.0/16 для локальной адресации канала. Эти адреса действительны только на канале (например, сегменте локальной сети или двухточечном соединении), напрямую подключенном к хосту, который их использует. Эти адреса не маршрутизируемы. Как и частные адреса, эти адреса не могут быть источником или получателем пакетов, проходящих через Интернет. Эти адреса в основном используются для автоконфигурации адреса (Zeroconf ), когда хост не может получить IP-адрес от DHCP-сервера или других внутренних методов настройки.

Когда блок адреса был зарезервирован, не существовало никаких стандартов для автоконфигурации адреса. Microsoft создала реализацию под названием Automatic Private IP Addressing (APIPA), которая была развернута на миллионах машин и стала стандартом де-факто. Много лет спустя, в мае 2005 г., IETF определил формальный стандарт в RFC 3927, озаглавленный «Динамическая конфигурация локальных адресов IPv4».

Сеть класса A 127.0.0.0 (бесклассовая сеть 127.0.0.0/8) зарезервирована для loopback. IP-пакеты, исходные адреса которых принадлежат этой сети, никогда не должны появляться за пределами хоста. Пакеты, полученные на интерфейсе без обратной связи с адресом источника или назначения обратной петли, должны быть отброшены.

Первый адрес в подсети используется для идентификации самой подсети. В этом адресе все биты хоста равны 0. Чтобы избежать двусмысленности в представлении, этот адрес зарезервирован. У последнего адреса все биты хоста установлены в 1. Он используется как локальный широковещательный адрес для одновременной отправки сообщений всем устройствам в подсети. Для сетей размером / 24 или больше широковещательный адрес всегда заканчивается на 255.

Например, в подсети 192.168.5.0/24 (маска подсети 255.255.255.0) для ссылки используется идентификатор 192.168.5.0. ко всей подсети. Широковещательный адрес сети 192.168.5.255.

Двоичная форма	десятичная точка
Сетевое пространство	11000000.10101000.00000101.00000000	192.168.5.0
Широковещательный адрес	11000000.10101000.00000101.11111111	192.168.5.255
Красным цветом показана хостовая часть IP-адреса; другая часть — префикс сети. Хост инвертируется (логическое НЕ), но префикс сети остается неизменным.

Однако это не означает, что каждый адрес, заканчивающийся на 0 или 255, не может использоваться в качестве адреса хоста. Например, в подсети / 16 192.168.0.0/255.255.0.0, что эквивалентно диапазону адресов 192.168.0.0–192.168.255.255, широковещательный адрес 192.168.255.255. Для хостов можно использовать следующие адреса, даже если они заканчиваются на 255: 192.168.1.255, 192.168.2.255 и т. Д. Кроме того, 192.168.0.0 является идентификатором сети и не должен назначаться интерфейсу. Адреса 192.168.1.0, 192.168.2.0 и т. Д. Могут быть назначены, несмотря на то, что они заканчиваются на 0.

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

В сетях меньше / 24 широковещательные адреса не обязательно заканчиваются 255. Например, подсеть CIDR 203.0.113.16/28 имеет широковещательный адрес 203.0.113.31.

Двоичная форма	Точечно-десятичная запись
Сетевое пространство	11001011.00000000.01110001.00010000	203.0.113.16
Широковещательный адрес	11001011.00000000.01110001.00011111	203.0.113.31
Красным цветом показана хостовая часть IP-адреса; другая часть — префикс сети. Хост инвертируется (логическое НЕ), но префикс сети остается неизменным.

В качестве особого случая сеть / 31 имеет емкость только для двух хостов. Эти сети обычно используются для соединений точка-точка. Для этих сетей не существует сетевого идентификатора или широковещательного адреса.

Хосты в Интернете обычно известны по именам, например www.example.com, не в первую очередь по их IP-адресу, который используется для маршрутизации и идентификации сетевого интерфейса. Использование доменных имен требует их преобразования, называемого преобразованием, в адреса и наоборот. Это аналогично поиску номера телефона в телефонной книге по имени получателя.

Преобразование между адресами и доменными именами выполняется системой доменных имен (DNS), иерархической распределенной системой именования, которая позволяет субделегировать пространства имен в другие DNS-серверы.

С 1980-х годов стало очевидно, что пул доступных адресов IPv4 истощается со скоростью, которая изначально не предполагалась в первоначальном проекте сети. Основные рыночные силы, ускорившие истощение адресов, включали быстро растущее число пользователей Интернета, которые все чаще использовали мобильные вычислительные устройства, такие как портативные компьютеры, персональные цифровые помощники (КПК) и смартфоны с услугами IP-передачи данных. Кроме того, высокоскоростной доступ в Интернет был основан на постоянно включенных устройствах. Угроза исчерпания ресурсов побудила к внедрению ряда лечебных технологий, таких как методы бесклассовой междоменной маршрутизации (CIDR) к середине 1990-х годов, повсеместное использование трансляции сетевых адресов ( NAT) в системах провайдеров доступа к сети, а также строгие политики распределения на основе использования в региональных и местных реестрах Интернета.

Пул первичных адресов Интернета, поддерживаемый IANA, был исчерпан 3 февраля 2011 года, когда последние пять блоков были выделены пяти RIR. APNIC был первым RIR, который исчерпал его региональный пул 15 апреля 2011 года, за исключением небольшого количества адресного пространства, зарезервированного для технологий перехода на IPv6, которое должно быть выделено в соответствии с ограниченной политикой.

Долгосрочным решением проблемы исчерпания адресов было Спецификация 1998 г. новой версии Интернет-протокола, IPv6. Он обеспечивает значительно увеличенное адресное пространство, но также позволяет улучшить агрегацию маршрутов через Интернет и предлагает конечным пользователям выделение больших подсетей как минимум из двух адресов хоста. Однако IPv4 не может напрямую взаимодействовать с IPv6, поэтому хосты, поддерживающие только IPv4, не могут напрямую взаимодействовать с хостами, поддерживающими только IPv6. Поэтапный отказ от экспериментальной сети 6bone, начавшийся в 2004 году, постоянное формальное развертывание IPv6 началось в 2006 году. Ожидается, что завершение развертывания IPv6 займет значительное время, так что промежуточное технологии перехода необходимы, чтобы разрешить хостам участвовать в сети Интернет с использованием обеих версий протокола.

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

Заголовок пакета IPv4 состоит из 14 полей, 13 из которых являются обязательными. 14-е поле является необязательным и правильно названо: options. Поля в заголовке упаковываются первым старшим байтом (big endian ), а для схемы и обсуждения наиболее значимые биты считаются идущими первыми (нумерация битов MSB 0 ). Самый старший бит имеет номер 0, поэтому поле версии фактически находится, например, в четырех самых старших битах первого байта.

бит 0: зарезервирован; должен быть равен нулю.
бит 1: не фрагментировать (DF)
бит 2: больше фрагментов (MF)

Примечание: если длина заголовка больше 5 (т. Е. От 6 до 15), это означает, что поле опций присутствует и должно учитываться.
Примечание: скопировано, класс опций и Номер опции иногда называют одним восьмибитным полем, типом опции.

Полезная нагрузка пакета не включается в контрольную сумму. Его содержимое интерпретируется на основе значения поля заголовка протокола.

Некоторые из распространенных протоколов полезной нагрузки:

Номер протокола	Имя протокола	Сокращение
1	Протокол управляющих сообщений Интернета	ICMP
2	Группа Интернета Протокол управления	IGMP
6	Протокол управления передачей	TCP
17	Протокол дейтаграмм пользователя	UDP
41	Инкапсуляция IPv6	ENCAP
89	Сначала откройте кратчайший путь	OSPF
132	Протокол передачи управления потоком	SCTP

Интернет-протокол разрешает трафик между сетями. Дизайн вмещает сети различной физической природы; он не зависит от базовой технологии передачи, используемой на канальном уровне. Сети с разным оборудованием обычно различаются не только скоростью передачи, но и максимальной единицей передачи (MTU). Когда одна сеть хочет передать дейтаграммы в сеть с меньшим MTU, она может фрагментировать свои дейтаграммы. В IPv4 эта функция была размещена на Интернет-уровне и выполняется в маршрутизаторах IPv4, которые, таким образом, не требуют реализации каких-либо более высоких уровней для функции маршрутизации IP-пакетов.

Напротив, IPv6, следующее поколение Интернет-протокола, не позволяет маршрутизаторам выполнять фрагментацию; хосты должны определить MTU пути перед отправкой дейтаграмм.

Когда маршрутизатор получает пакет, он проверяет адрес назначения и определяет исходящий интерфейс для использования и MTU этого интерфейса. Если размер пакета больше, чем MTU, а бит Do not Fragment (DF) в заголовке пакета установлен в 0, то маршрутизатор может фрагментировать пакет.

Маршрутизатор разделяет пакет на фрагменты. Максимальный размер каждого фрагмента равен MTU за вычетом размера IP-заголовка (минимум 20 байтов; максимум 60 байтов). Маршрутизатор помещает каждый фрагмент в свой собственный пакет, причем каждый пакет фрагмента имеет следующие изменения:

Поле общей длины — это размер фрагмента.
Флаг дополнительных фрагментов (MF) устанавливается для всех фрагментов, кроме последнего one, which is set to 0.
The fragment offset field is set, based on the offset of the fragment in the original data payload. This is measured in units of eight-byte blocks.
The header checksum field is recomputed.

For example, for an MTU of 1,500 bytes and a header size of 20 bytes, the fragment offsets would be multiples of 1500 − 20 8 = 185 <\displaystyle <\frac <1500-20><8>>=185> . These multiples are 0, 185, 370, 555, 740.

It is possible that a packet is fragmented at one router, and that the fragments are further fragmented at another router. For example, a packet of 4,520 bytes, including the 20 bytes of the IP header (without options) is fragmented to two packets on a link with an MTU of 2,500 bytes:

Fragment	Size. (bytes)	Header size. (bytes)	Data size. (bytes)	Flag. More fragments	Fragment offset. (8-byte blocks)
1	2500	20	2480	1	0
2	2040	20	2020	0	310

The total data size is preserved: 2480 bytes + 2020 bytes = 4500 bytes. The offsets are 0 <\displaystyle 0>and 0 + 2480 8 = 310 <\displaystyle <\frac <0+2480><8>>=310> .

On a link with an MTU of 1,500 bytes, each fragment results in two fragments:

Fragment	Size. (bytes)	Header size. (bytes)	Data size. (bytes)	Flag. More fragments	Fragment offset. (8-byte blocks)
1	1500	20	1480	1	0
2	1020	20	1000	1	185
3	1500	20	1480	1	310
4	560	20	540	0	495

Again, the data size is preserved: 1480 + 1000 = 2480, and 1480 + 540 = 2020.

Also in this case, the More Fragments bit remains 1 for all the fragments that came with 1 in them and for the last fragment that arrives, it works as usual, that is the MF bit is set to 0 only in the last one. And of course, the Identification field continues to have the same value in all re-fragmented fragments. This way, even if fragments areповторно фрагментированные, получатель знает, что изначально все они начали с одного и того же пакета.

Последнее смещение и последний размер данных используются для вычисления общего размера данных: 495 × 8 + 540 = 3960 + 540 = 4500 <\ displaystyle 495 \ times 8 + 540 = 3960 + 540 = 4500>.

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

установлен флаг «больше фрагментов», что верно для всех фрагментов, кроме последнего.
Поле «смещение фрагмента» не равно нулю, что верно для всех фрагментов, кроме первого.

Получатель идентифицирует совпадающие фрагменты, используя внешний и локальный адрес, идентификатор протокола и поле идентификации. Получатель повторно собирает данные из фрагментов с тем же идентификатором, используя как смещение фрагмента, так и флаг дополнительных фрагментов. Когда получатель получает последний фрагмент, для которого флаг «больше фрагментов» установлен в 0, он может вычислить размер полезной нагрузки исходных данных, умножив смещение последнего фрагмента на восемь и прибавив размер данных последнего фрагмента. В данном примере это вычисление было 495 * 8 + 540 = 4500 байт.

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

IP-адреса не связаны каким-либо постоянным образом с идентификацией оборудования, и, действительно, сетевой интерфейс может иметь несколько IP-адресов в современных операционных системах. Хостам и маршрутизаторам требуются дополнительные механизмы для определения взаимосвязи между интерфейсами устройств и IP-адресами, чтобы правильно доставить IP-пакет на хост назначения по каналу. Протокол разрешения адресов (ARP) выполняет преобразование IP-адреса в аппаратный адрес для IPv4. (Аппаратный адрес также называется MAC-адресом.) Кроме того, часто требуется обратная корреляция. Например, когда IP-узел загружается или подключается к сети, ему необходимо определить свой IP-адрес, если адрес не настроен заранее администратором. Протоколы для таких обратных корреляций существуют в Internet Protocol Suite. В настоящее время используются следующие методы: Протокол динамической конфигурации хоста (DHCP), Протокол начальной загрузки (BOOTP) и, нечасто, обратный ARP.

Исходный порт

Порт назначения

Контрольная сумма

Формат заголовка дейтаграммы UDP

Так как обработка дейтаграммы происходит с помощью программного обеспечения, оборудование не накладывает никаких ограничений на ее содержимое и формат. Например, первое 4-битовое поле «Версия» в дейтаграмме содержит версию протокола IP, используемую при создании дейтаграммы. Оно используется отправителем, получателем, и всеми маршрутизаторами между ними для уверенности подтверждения того, что все они используют один и тот же формат дейтаграммы.

Поэтому можно рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если маршрутизатор знает более чем один маршрут к указанному назначению, он может

Рис. 5.17. Формат поля «Тип сервиса» IPv4

использовать поле типа передачи для выбора пути с характеристиками наиболее близкими требуемым. Например, предположим, что маршрутизатор может выбирать между низкоскоростной арендованной линией или высокоскоростной (но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, могут иметь установленным бит Т, запрашивая передачу по высокоскоростной спутниковой линии. Важно понимать, что алгоритмы маршрутизации должны выбирать одну из возможных используемых физических сетевых технологий, которые имеют определенные характеристики задержки, пропускной способности и надежности. Часто данная технология использует компромисс между этими характеристиками (например, высокой скоростью передачи и большей задержкой). Поэтому, идея состоит в том, чтобы дать алгоритму указание о том, что наиболее важно; не имеет смысла указывать все три типа сервиса. Таким образом, спецификацию типа передачи следует рассматривать как указание алгоритму маршрутизации, которое помогает выбрать один путь к сети назначения из возможных на основе знаний об аппаратных технологиях, использующихся на этих путях. Интернет не гарантирует выполнения запрошенного транспортного сервиса. Инкапсуляция дейтаграмм. В отличие от кадров физической сети, которые должны распознавать оборудование, дейтаграммы обрабатываются программным обеспечением. Их длина не должна превышать 6S53S октетов. Более жесткие ограничения на размер дейтаграммы накладывают параметры сетей.

При передаче дейтаграммы от одной машины к другой, ее должны транспортировать базовые физические сети. Для эффективности межсетевой передачи нужно быть уверенным в том, что каждая дейтаграмма передается в отдельном физическом кадре. Передача одной дейтаграммы в одном кадре называется инкапсуляцией. Для базовой сети дейтаграмма выглядит так же, как и любое сообщение, посылаемое от одной машины к другой. Оборудование как не знает формата дейтаграммы, так и не понимает LP-адреса назначения. Поэтому, когда одна машина посылает IP-дейтаграмму другой, вся дейтаграмма передается как часть данных кадра (рис. 5.18).

Рис. 5.18. Инкапсуляция IP-дейтаграммы в кадр 352

Рис. 5.19. Пример применения фрагментации

В идеальном случае вся IP-дейтаграмма помещается в одном физическом кадре, что делает передачу по физической сети более эффективной. Каждая технология коммутации пакетов устанавливает фиксированную верхнюю границу количества данных, которые могут быть переданы в одном физическом кадре. Такие ограничения называют «максимальная единица передачи» — MTU (Maximum Transfer Unit). Значение MTU может быть довольно маленьким: некоторые аппаратные технологии ограничивают размер передачи до 128 октет или даже меньше. Маленькие части, на которые делится дейтаграмма, называются фрагментами, а процесс деления дейтаграммы — фрагментацией. Как показывает рис. 5.19, фрагментация обычно осуществляется маршрутизатором где-либо на пути между отправителем дейтаграммы и ее истинным получателем. Маршрутизатор принимает дейтаграмму из сети с большим MTU и должен передать ее по сети, в которой MTU меньше, чем размер дейтаграммы. На рисунке оба компьютера Н_А и Н_в напрямую присоединены к сетям Ethernet (Сеть 1 и Сеть 3), которые имеют MTU в 1500 октет.

Поэтому оба компьютера могут генерировать и посылать дейтаграммы до 1500 октет длины. Путь между ними, тем не менее, включает сеть с MTU = 620 октет. Если Н_А посылает Н_в дейтаграмму длиннее 620 октет, маршрутизатор R, будет фрагментировать эту дейтаграмму. Аналогично, если Н_в посылает большую дейтаграмму Н_А, маршрутизатор R₂ будет фрагментировать эту дейтаграмму. Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспортироваться в одном кадре. Кроме того, так как IP передает значение смещения данных в восьмерках октетов, размер фрагмента должен быть выбран кратным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее близкого к сетевой MTU, не обязательно делит дейтаграмму на равные части; последняя часть часто короче, чем остальные. Фрагменты должны собираться для воссоздания полной копии исходной дейтаграммы перед тем, как она будет обрабатываться у получателя. Протокол IP как не ограничивает дейтаграммы до маленького размера, так и не гарантирует, что большие дейтаграммы будут доставлены без фрагментации. Отправитель может выбрать любой размер дейтаграммы. Фрагментация и сборка производятся автоматически, не требуя специальных действий от отправителя. Спецификация IP устанавливает, что маршрутизаторы должны

Рис. 5.20. Исходная дейтаграмма, несущая 1400 октетов данных (а) и три фрагмента для сети с MTU= 620 (б)

принимать дейтаграммы с размерами, не превосходящими MTU сетей, к которым они присоединены. Кроме того, маршрутизаторы должны всегда обрабатывать дейтаграммы размером до 576 октет. Фрагментация дейтаграммы означает разделение ее на несколько частей. Рис. 5.20 иллюстрирует результат фрагментации. Каждый фрагмент содержит заголовок дейтаграммы, дублирующий большую часть заголовка исходной дейтаграммы (кроме бита в поле «Флаги», который показывает, что это фрагмент), и столько данных, сколько может содержать фрагмент, чтобы общая длина была меньше, чем MTU сети, по которой он путешествует.

Сборка фрагментов. В сетях TCP/IP после фрагментирования дейтаграммы, ее фрагменты передаются как отдельные дейтаграммы на всем протяжении пути до места назначения, где они собираются. Сохранение фрагментации на всем протяжении пути имеет два недостатка. Во-первых, так как дейтаграммы не собираются сразу же после прохождения сети с маленьким MTU, маленькие фрагменты будут передаваться с места фрагментации до места назначения. Сборка дейтаграмм в месте назначения может привести к неэффективности: даже если некоторые сети, проходимые после фрагментации, имеют большое значение MTU, их будут пересекать только маленькие фрагменты. Во-вторых, если какой-либо фрагмент будет потерян, дейтаграмму нельзя будет восстановить. Принимающая машина запускает таймер сборки при приеме первого фрагмента. Если таймер обнуляется до того, как приняты все фрагменты, принимающая машина удаляет оставшиеся части, не обрабатывая дейтаграмму. Поэтому вероятность потери дейтаграммы увеличивается при использовании фрагментации, так как потеря одного фрагмента приводит к потере всей дейтаграммы. Несмотря на эти недостатки, выполнение сборки в месте назначения хорошо работает. Оно позволяет независимо маршрутизировать фрагменты и не требует от промежуточных маршрутизаторов хранения собираемых фрагментов. Управление фрагментацией. Три поля в заголовке дейтаграммы — Идентификация, Флаги и Смещение фрагмента — управляют фрагментацией и сборкой дейтаграмм (см. рис. 5.16). Поле «Идентификация» содержит уникальное целое число, которое идентифицирует дейтаграмму. Напомним, что когда шлюз или маршрутизатор фрагментирует дейтаграмму, он копирует большую часть полей в заголовке дейтаграммы в каждый фрагмент. Поле «Идентификация» позволяет получателю узнать, какой дейтаграмме принадлежат прибывающие фрагменты. Когда появляется фрагмент, получатель для идентификации дейтаграммы использует поле «Идентификация» вместе с полем адреса источника. Компьютер, посылающий IP-дейтаграммы, должен генерировать уникальное значение поля «Идентификация» для каждой отдельной дейтаграммы (в теории, повторные передачи дейтаграммы должны содержать то же самое значение в поле «Идентификация», что и в исходной дейтаграмме; на практике, протоколы высокого уровня обычно выполняют повторную передачу как новую дейтаграмму со своим значением поля «Идентификация»). Один из модулей, используемых в программном обеспечении IP, хранит глобальный счетчик в памяти, инкрементирует его каждый раз, когда создается новая дейтаграмма, и копирует результат в поле «Идентификация» дейтаграммы. Напомним, что каждый фрагмент имеет точно такой же формат, что и полная дейтаграмма. Для фрагмента поле «Смещение фрагмента» указывает смещение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряемое в 8 октетах (смещения измеряются в восьмерках октетов для сохранения места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы это поле должно получить назначение во всех фрагментах, начиная с фрагмента со смещением 0 до фрагмента с наибольшим смещением. Фрагменты необязательно прибывают по порядку, и не существует прямого взаимодействия между маршрутизатором, который фрагментирует дейтаграммы, и получателем, который пытается собирать их. Младшие два бита из трехбитового поля «Флаги» управляют фрагментацией. Обычно прикладное программное обеспечение, использующее TCP/IP, не заботится о фрагментации, так как и фрагментация, и сборка являются автоматическими процедурами, выполняемыми на низком уровне в операционной системе незаметно для пользователя. Тем не менее, для тестирования межсетевого программного обеспечения или отладки рабочих программ может оказаться важной проверка размеров дейтаграмм, для которых осуществляется фрагментация. Первый управляющий бит помогает при таком тестировании, указывая возможность фрагментации дейтаграммы. Он называется битом «не фрагментировать», так как установка его в единицу указывает, что дейтаграмму нельзя фрагментировать. Приложение может выбрать запрет фрагментации, когда нужна лишь целая дейтаграмма. Всякий раз, когда маршрутизатору нужно фрагментировать дейтаграмму с установленным битом «не фрагментировать», он удаляет дейтаграмму и посылает обратно источнику сообщение об ошибке. Младший бит в поле «Флаги» указывает, содержит ли фрагмент данные из середины дейтаграммы или из конца. Он называется битом «еще фрагменты». Поясним необходимость наличия этого бита. Программное обеспечение IP у получателя будет получать фрагменты ( возможно не по порядку), и ему нужно будет знать, когда оно получит все фрагменты дейтаграммы. Когда поступает очередной фрагмент, поле «Общая длина» в заголовке указывает размер фрагмента, а не размер всей дейтаграммы, поэтому получатель не может использовать поле «Общая длина» для того, чтобы определить, собрало ли он все фрагменты. Бит «еще фрагменты» легко решает проблему: как только получатель получает фрагмент со сброшенным битом «еще фрагменты», он знает, что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На основе полей «Смещение фрагмента» и «Общая длина» оно может вычислить длину исходной дейтаграммы. Проверив «Смещение фрагмента» и «Общая длина» у всех прибывших фрагментов, получатель может определить, содержат ли фрагменты все данные, требуемые для сборки исходной дейтаграммы. Время жизни дейтаграммы. Поле «Время жизни» указывает, сколько секунд может оставаться дейтаграмма в межсетевой системе. Эта идея является насколько простой, настолько и важной: всякий раз, когда машина передает дейтаграмму в Интернет, она устанавливает максимальное время существования дейтаграммы. Шлюзы и маршрутизаторы, обрабатывающие дейтаграмму, должны декрементировать поле «Время жизни» по мере того, как идет время, и удалять дейтаграмму из Интернета, когда время вышло. Оценить время точно трудно, так как маршрутизаторы обычно не знают время передачи между физическими сетями. Принятые соглашения упрощают обработку и делают легкой обработку дейтаграмм без синхронизации часов. Во-первых, каждому маршрутизатору на пути от источника к назначению требуется декрементировать поле «Время жизни» на единицу, когда он обрабатывает заголовок дейтаграммы. В случае, когда маршрутизаторы перегружены, что приводит к большим паузам при передаче, каждый маршрутизатор хранит локальное время прихода дейтаграммы и декрементирует «Время жизни» на число секунд, в течение которого дейтаграмма находилась в маршрутизаторе, ожидая обслуживания. Всякий раз, когда поле «Время жизни» обнуляется, маршрутизатор удаляет дейтаграмму и посылает сообщение об ошибке обратно источнику. Поле «Время жизни» гарантирует, что дейтаграммы не смогут вечно путешествовать по Интернету, даже если таблицы маршрутизации разрушатся и маршрутизаторы будут маршрутизировать дейтаграммы по кольцу. Значение в поле «Протокол» указывает, какой протокол высокого уровня использовался при создании сообщения, передаваемого в области «Данные» дейтаграммы. По существу, значение в «Протокол» специфицирует формат области «Данные». Соответствие между протоколом высокого уровня и целым числом, используемым в поле «Протокол», должно устанавливаться ответственным центром, чтобы гарантировать действие соглашения по всему Интернету.Поле «Контрольная сумма заголовка» удостоверяет целостность значений полей заголовка. Контрольная сумма IP формируется путем представления заголовка как последовательности 16-битовых чисел (с сетевым порядком байт), сложения их вместе, используя арифметику с дополнительным представлением отрицательных чисел, и получения отрицания числа. При вычислении контрольной суммы поле «Контрольная сумма заголовка» предполагается равным нулю. Необходимо помнить, что эта контрольная сумма применима только к числам, находящимся в заголовке IP, а не в данных. Разделение контрольной суммы для заголовка и для данных имеет свои преимущества и недостатки. Так как заголовок обычно занимает меньше октетов, чем данные, наличие отдельной контрольной суммы для него уменьшает время обработки в маршрутизаторах, которые вычисляют только контрольную сумму заголовка. Это разделение также позволяет протоколам более высокого уровня выбирать свои собственные схемы расчета контрольной суммы для данных. Главным недостатком является то, что протоколы более высокого уровня вынуждены добавлять свои контрольные суммы или рисковать тем, что они не смогут обнаружить искажения данных. IP-адреса. Поля «Адрес отправителя 1Р» и «Адрес получателя 1Р» содержат 32-битовые IP-адреса отправителя и конечного получателя дейтаграммы IPv4. Хотя дейтаграмма может проходить через большое число промежуточных шлюзов или маршрутизаторов, поля отправителя и получателя никогда не изменяются; они указывают IP-адреса истинного источника и конечного назначения. IP-адрес состоит из адреса сети и адреса узла в этой сети и принадлежит одному из пяти классов (рис. 5.21). Класс данного IP-адреса можно определить по первым трем старшим битам, причем первых двух бит достаточно для определения принадлежности адреса к одному из трех основных классов. Адреса класса А выделяют под адрес сети 7 бит, а под адрес узла 24 бит. Адреса класса В выделяют 14 бит под адрес сети и 16 бит под адрес узла. И наконец, сети класса С, состоящие менее чем из 256 узлов, выделяют 21 бит под адрес сети и только 8 бит под адрес узла. Маршрутизаторы используют для маршрутизации поле «Адреса сети». Характеристики классов IP-адресов представлены в табл. 5.8.

0 8 16 24 31

Таблица5.8. Классы IP-адресов

Когда обычные компьютеры имеют два или более физических соединений, их называют многоадресными (multi-homed). Многоадресные узлы требуют нескольких адресов IP. Каждый адрес соответствует одному из соединений этой машины с сетью. Так как IP-адреса кодируют как сеть, так и узел в этой сети, они не описывают конкретную машину, а только соединение ее с сетью. Поэтому маршрутизатор, соединяющий N сетей, имеет N различных 1Р-адре- сов, по одному на каждое сетевое соединение. Межсетевые адреса могут использоваться для указания как на сети, так и на отдельные узлы. По соглашению адрес сети имеет поле «адреса узла», равное нулю. IP-адреса могут использоваться для указания широковещания и отображения его в аппаратное широковещание. По соглашению, широковещательный адрес имеет поле адреса узла со всеми битами, равными «1». Такой широковещательный адрес называют направленным (directed) широковещательным адресом, так как он содержит как корректный идентификатор сети, так и корректный широковещательный адрес узла. Направленный широковещательный адрес может однозначно интерпретироваться в любой точке Интернета, так как он идентифицирует уникальным образом сеть получателя помимо указания на широковещание в этой сети. Направленные широковещательные адреса обеспечивают мощный (и чем-то опасный) механизм, позволяющий удаленной системе посылать один пакет, который будет распространен в режиме широковещания в указанной сети. С точки зрения адресации, главным недостатком направленного широковещания является то, что оно требует знаний об адресе сети. Другая форма широковещательного адреса, называемая ограниченный широковещательный адрес или локальный сетевой широковещательный адрес, обеспечивает широковещательный адрес для локальной сети (сети отправителя), независимо от назначенного ей IP-адреса. Локальный широковещательный адрес состоит из 32 единиц (поэтому он иногда называется широковещательным адресом из всех единиц). Узел может использовать ограниченный широковещательный адрес в процессе своего запуска, до того, как он узнает свой IP-адрес или IP-адрес локальной сети. Как только узел узнает IP-адрес своей сети, он может использовать направленное широковещание. Если поле адреса, состоящее из единиц, может интерпретироваться как «все узлы» в сети, то поля, состоящие из нулей, межсетевое программное обеспечение интерпретирует как символ «это». Поэтому IP-адрес с адресом узла, равным «О», обозначает «этот узел», а межсетевой адрес с идентификатором сети «О» обозначает «эта сеть». Конечно, использовать эти адреса нужно только в том контексте, в котором они интерпретируются однозначно. Помимо широковещания схема адресов IP поддерживает специальную форму групповой доставки, известную как групповая доставка (multicasting). Групповая доставка особенно полезна для сетей, в которых аппаратная технология поддерживает групповую доставку. При описании IP-адресов принято использовать точечную десятичную нотацию. IP-адреса записывают как четыре десятичных числа, разделенных десятичными точками, и каждое из этих чисел представляет значение одного октета IP-адреса. Например, IP-адрес 195.190.21.45 соответствует узлу 45 сети 195.190.21.0 класса С. Сетевой адрес класса А 127.0.0.0 зарезервирован для обратной связи и введен для тестирования взаимодействия между процессами на одной машине. Когда какая-либо программа использует адрес обратной связи для передачи данных, протокольное программное обеспечение в компьютере возвращает эти данные, ничего не посылая по сети. Таким образом, пакет, посланный в сеть с адресом 127, не будет передаваться ни по какой сети. Более того, узел или маршрутизатор никогда не должен распространять информацию о маршрутах для сети с номером 127; этот адрес не является адресом сети. Интерпретация выделенных адресов IPv4 представлена в табл. 5.9.

Таблица 5.9. Интерпретация адресов И*

Поле «Данные», представленное на рис. 5.16, показывает начало области данных в дейтаграмме. Его длина зависит от того, что посылается в дейтаграмме. Поле «Опции 1Р», рассматриваемое ниже, имеет переменную длину. Поле «Заполнение» зависит от выбранных опций. Оно представляет собой биты, содержащие нули, которые могут потребоваться для дополнения заголовка дейтаграммы до длины, кратной 32 бит (напомним, что поле длины заголовка указывает ее в 32-битных словах). Межсетевые опции дейтаграммы. Поле «Опции 1Р», следующее за адресом назначения, не нужно каждой дейтаграмме; опции включаются, в основном,для тестирования или отладки сети. Обработка опций, тем не менее, является составной частью протокола IP, поэтому все стандартные реализации включают ее. Длина поля «Опции 1Р» зависит от выбранных опций. Когда в дейтаграмме есть опции, они размещаются друг за другом, без специальных разделителей между ними. Каждая опция состоит из кода опции длиной 1 октет, за которым может следовать длина опции (тоже занимает 1 октет) и группы октетов данных для этой опции. Октет кода опции делится на три поля: 1-битовый флаг «Копировать», 2-битовый «Класс опции» и 5-битовый «Номер опции» (рис. 5.22). Флаг «Копировать» управляет тем, как маршрутизаторы рассматривают опции при фрагментации. Когда бит «Копировать» установлен в 1, он указывает, что эта опция должна копироваться во все фрагменты. Когда он установлен в 0 — опцию нужно копировать только в первый фрагмент, а не во все.

Биты «Класс опции» и «Номер опции» указывают общий класс опции и номер опции внутри этого класса. В табл. 5.10 представлено значение номера класса. В табл. 5.11 приведен список возможных опций в IP-дейтаграммах и указаны для них значения полей «Класс опции» и «Номер опции». Как видно из этого списка, большая часть опций предназначена для управления.

Рис. 5.23. Формат опции записи маршрута

Опция записи маршрута. Опции маршрутизации и временных меток являются самыми интересными, так как они обеспечивают способ наблюдения или управления тем, как маршрутизируются дейтаграммы. Опция запись маршрута позволяет источнику создать пустой список IP-адресов и заставить каждый маршрутизатор, обрабатывающий дейтаграмму, добавлять свой IP-адрес к этому списку. Рис. 5.23 иллюстрирует формат опции записи маршрута. Как описано выше, поле «Код» содержит номер опции и класс опции (7 — для записи маршрута). Поле «Длина» указывает общую длину опции в том виде, в котором она представлена в IP-дейтаграмме, включая первые три октета. Поля, начиная с поля, помеченного «Первый IP-Адрес», составляют область, зарезервированную под хранение межсетевых адресов. Поле «Указатель» определяет смещение внутри опции первого свободного слота в списке. Всякий раз, когда машина обрабатывает дейтаграмму, имеющую опцию записи маршрута, она добавляет свой адрес к списку записи маршрута (в опции должно быть выделено достаточно места исходным отправителем для того, чтобы поместились все нужные элементы). При добавлении своего адреса к списку машина сначала сравнивает поля указателя и длины. Если указатель больше, чем длина, то список полон, и машина отправляет дейтаграмму, не добавляя нового элемента. Если список не полон, машина вставляет 4-байтовый IP-адрес в позицию, определенную «Указателем», и увеличивает значение «Указателя» на четыре. При прибытии дейтаграммы машина-получатель должна выделить и обработать список IP-адресов. Если получатель обрабатывает дейтаграмму обычным образом, он будет игнорировать записанный путь. Следует отметить, что отправитель должен разрешить наличие опции записи маршрута, а получатель должен быть согласен обработать полученный список; сама по себе машина не получит информацию о пройденном пути автоматически, если она включит опцию записи маршрута. Опции пути источника. Идея, лежащая в основе маршрутизации источника, заключается в том, чтобы отправитель мог определять путь в Интернете. Например, для тестирования пропускной способности конкретной физической сети N-системные администраторы могут использовать маршрутизацию источника для направления IP-дейтаграмм через сеть N, даже если маршрутизаторы обычно выбирают путь, не включающий ее. Возможность делать такие тесты особенно важна в производственной среде, так как позволяет сетевым администраторам маршрутизировать дейтаграммы пользователей по сетям,

0 8 16 24

про которые известно, что они работают корректно, и параллельно с этим проверять другие сети. Конечно, такая маршрутизация полезна только для сетевых администраторов или квалифицированных пользователей, которые понимают топологию сети. Протокол IP поддерживает две формы маршрутизации источника. Одна форма, названная строгой маршрутизацией источника, определяет путь с помощью включения последовательности IP-адресов в эту опцию (рис. 5.24). Строгая маршрутизация источника означает, что адреса определяют точный путь, которым должна следовать дейтаграмма при передаче ее к месту назначения. Путь между двумя последовательными адресами в списке должен состоять из одной физической сети; если маршрутизатор не может выполнить строгую маршрутизацию источника, возникает ошибка. Другая форма, называемая слабой маршрутизацией источника, также включает последовательность IP-адресов. Она определяет, что дейтаграмма должна следовать через эту последовательность IP-адресов, но допускает наличие нескольких переходов через сети между последовательными адресами в списке. Обе опции маршрутизации источника требуют от маршрутизаторов на всем пути заменять элементы списка адресов своими сетевыми адресами. Поэтому, когда дейтаграмма поступает к получателю, она содержит список всех посещенных адресов, точно такой же, как и список, создаваемый опцией записи маршрута. Формат опции маршрутизации источника напоминает показанный выше формат опции записи маршрута. Каждый маршрутизатор проверяет поля «Указатель» и «Длина», чтобы обнаружить переполнение списка. Если это произошло, указатель будет больше, чем длина, и маршрутизатор будет маршрутизировать дейтаграмму к ее назначению обычным образом. Если список заполнен еще не до конца, маршрутизатор на основании указателя выделяет 1Р-адрес, заменяет его на свой адрес (маршрутизатор имеет по одному адресу для каждого интерфейса; он записывает адрес, соответствующий сети, по которой он отправляет дейтаграмму) и маршрутизирует дейтаграмму, используя адрес, полученный из списка. Опция временных меток. Эта опция работает аналогично опции записи маршрута в том отношении, что опция временных меток содержит вначале пустой список, а каждый шлюз на всем протяжении пути от источника к назначению заполняет элемент в этом списке. Каждый элемент в списке состоит из

Рис. 5.25. Формат опции временных меток

двух 32-битных частей: IP-адреса маршрутизатора, заполнившего этот элемент, и 32-бигового целого числа — временной метки. На рис. 5.25 приведен формат опции временных меток. На этом рисунке поля «Длина» и «Указатель» использованы для указания длины зарезервированного места и местонахождения следующего неиспользованного слота (как в опции записи маршрута). 4-битовое поле «Переп» содержит целое число шлюзов, которые не смогли записать временные метки из-за слишком маленького размера опции. Значение в 4-битовом поле «Флаги» определяет точный формат опции и говорит маршрутизаторам, как записывать временнйе метки. Допускаются следующие значения поля «Флаги»: 0 — только запись временных меток, IP-адреса опускаются; 1 — указывать перед каждой временной меткой IP-адрес (формат, показанный на рис. 5.25); 3 — IP-адреса указывает отправитель, маршрутизатор только записывает временную метку, если следующий IP-адрес в списке соответствует IP-адресу маршрутизатора. Временные метки определяют время и дату, когда маршрутизатор обрабатывал дейтаграмму, и выражаются в миллисекундах после полуночи по Гринвичу. Если стандартное представление времени невозможно, маршрутизатор может использовать любое представление локального времени при условии, что он устанавливает старший бит в поле временной метки. Конечно, временные метки, записываемые независимыми компьютерами, не всегда согласованы, даже если представлены во времени по Гринвичу; каждая машина сообщает время согласно своим локальным часам, а часы могут идти по-разному. Поэтому, временные метки всегда рассматриваются как приблизительные оценки, независимо от их представления. Может показаться странным, что опция временных меток включает механизм, заставляющий маршрутизатор записывать их IP-адреса вместе с временными метками, так как опция записи маршрута обеспечивает эту возможность. Тем не менее, запись IP-адресов вместе с временными метками позволяет избежать неоднозначности. Одновременная запись маршрута с временными метками также полезна потому, что она позволяет приемнику узнать точно, какой путь прошла дейтаграмма. Обработка опций при фрагментации. При фрагментации дейтаграммы маршрутизатор повторяет некоторые IP-опции во всех фрагментах, в то время как другие помещаются только в один фрагмент. Например, рассмотрим оп цию, используемую для записи маршрута дейтаграммы. При передаче каждый фрагмент будет обрабатываться как независимая дейтаграмма, поэтому не гарантировано, что все фрагменты будут следовать по одному и тому же пути к месту назначения. Если все фрагменты содержат опцию записи маршрута, получатель может получить свой список шлюзов от каждого фрагмента. Он не сможет создать одного списка для собранной дейтаграммы. Поэтому, стандарт IP определяет, что опция записи маршрута должна копироваться только в один из фрагментов. С другой стороны, рассмотрим, например, опцию маршрутизации источника, которая определяет, как должна передаваться дейтаграмма через Интернет. Информация о маршрутизации источника должна находиться в заголовках всех фрагментов, иначе фрагменты не будут следовать указанным путем. Поэтому, поле кода для маршрутизации источника указывает, что эта опция должна копироваться во все фрагменты.