Сравнение возможностей протоколов транспортного уровня

Параметр	UDP	TCP	SCTP
Установка соединения	Нет	Да	Да
Надежная передача	Нет	Да	Да
Сохранение границ сообщения	Да	Нет	Да
Упорядоченная доставка	Нет	Да	Да
Неупорядоченная доставка	Да	Нет	Да
Контрольные суммы данных	Да	Да	Да
Размер контрольной суммы (бит)
Путь MTU	Нет	Да	Да
Управление накоплением	Нет	Да	Да
Многопоточность	Нет	Нет	Да
Поддержка множественных интерфейсов	Нет	Нет	Да
Связка потоков	Нет	Да	Да

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор — 11₁₆ (17).

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

Состав UDP-датаграммы

Первые 64 бита (8 байт) датаграммы представляют собой UDP-заголовок, остальные биты — данные сообщения:

Биты

0-31

Порт отправителя (Source port)

Порт получателя (Destination port)

32-63

Длина датаграммы (Length)

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

64-...

Данные (Data)

Значение поля «длина датаграммы» указывает на длину всего UDP-сообщения, то есть включая и UDP-заголовок. Измеряется в октетах (байтах).

Максимальная длина данных

Для вычисления максимальной длины данных в UDP-сообщении при передаче в IP сетях необходимо учесть, что UDP-сообщение в свою очередь является содержимым области данных IP-сообщения. Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов. Потому максимальная длина UDP-сообщения (за вычетом минимального IP-заголовка) равна 65535 − 20 = 65515 октетов.

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

Перед расчетом контрольной суммы UDP-сообщение дополняется в конце нулевыми битами до длины, кратной 16 битам (псевдозаголовок и добавочные нулевые биты не отправляются вместе с сообщением). Поле контрольной суммы в UDP-заголовке во время расчета контрольной суммы отправляемого сообщения принимается нулевым.

Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.

Нулевое значение контрольной суммы зарезервировано, и означает что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичнымим единицами.

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

Если приложению требуется большая надёжность, то используется протокол TCP или SCTP.

UDP используется в следующих протоколах:

• DNS
• NFS
• DHCP

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340) является транспортным протоколом, который использует двунаправленные уникастные соединения с управлением перегрузкой для ненадежной доставки дейтограмм. Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки данных с сохранением порядка кадров или требуют надежности, или которым нужен механизм подавления перегрузки, отличный от TCP. До настоящего времени такие приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, или UDP и независимого механизма управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит использовать механизм ECN (Explicit Congestion Notification).

Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [Stream Control Transmission Protocol, RFC 2960], таких как упорядоченная доставка при нескольких потоках.

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен. Чтобы облегчить это, DCCP был спроектирован с минимальной избыточностью, как с точки зрения размера заголовка пакета, так и с позиции загрузки ЦПУ машин партнеров. В DCCP была включена минимальная функциональность, при сохранении возможности включения новых функций, таких как FEC (Forward Error Correction), псевдонадежность и множественные потоки, которые могут быть добавлены поверх DCCP, если потребуется.

Протокол DCCP имеет следующие характеристики:

• Реализует поток дейтограмм с подтверждением получения, но без повторной посылки.
• Ненадежный диалог установления и разрыва соединения.
• Надежное согласование параметров.
• Выбор механизмов подавления перегрузки, дружественных по отношению к TCP, включая TCP-подобное управление перегрузкой (CCID 2) и управление потоком, дружественное TCP [RFC 3448] (CCID 3). CCID 2 использует разновидность TCP-механизма управления перегрузкой, и приемлемо для потоков, которые стремятся воспользоваться преимуществами доступной полосы, CCID 3 пригодно для потоков, которые требуют более стабильной скорости передачи.
• Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены ECN [RFC 3168 и RFC 3540], повреждены, или отброшены во входном буфере получателя.
• Управление перегрузкой, снабженное встроенной индикацией явной перегрузки ECN (Explicit Congestion Notification).
• Механизмы, позволяющие серверу избежать поддержки состояний неподтвержденных попыток соединений.
• Выявление MTU пути [RFC 1191].

 

 

Классы IP-адресов.

Классовая адресация сетей — метод IP-адресации. Использование этого метода не позволяет экономно использовать ограниченный ресурс IP-адресов, поскольку невозможно применение различных масок подсетей к различным подсетям.

[править]Основные понятия

Изначально адресация в сетях IP осуществлялась на основе классов: первые биты определяли класс сети, а по классу сети можно было сказать - сколько бит было отведено под номер сети и номер узла. Всего существовало 5 классов:

Класс A

7-разрядный адрес сети

24-разрядный адрес интерфейса

 

Класс B

14-разрядный адрес сети

16-разрядный адрес интерфейса

 

Класс C

21-разрядный адрес сети

8-разрядный адрес интерфейса

 

Класс D

Адрес многоадресной рассылки

 

Класс E

Зарезервировано

Адресация IP.

Особенностью IP является гибкая система адресации. Плата за это - наличие централизованных служб типа DNS.

Адрес состоит из двух частей – номер сети и номер узла в сети. IP-адрес версии 4 имеет длину 4 байта, записывается в виде четырех десятичных чисел, разделенных точками.

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

Одним из подходов был классовый метод адресации.

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

Класс	Первые биты	Число байт для № сети	Число байт для № узла	Число сетей	Число узлов
A				128 (-2)	16 777 216 (-2)
B				16 384	65 536 (-2)
C				2 097 152	256 (-2)
D		Групповой адрес	268 435 456
E		Зарегистрировано	134 217 728

 

Таблица6. Нумерация IP-сетей.

Класс	Первые биты	Наименьший номер сети	Наибольший номер сети
A		1.0.0.0	126.0.0.0
B		128.0.0.0	191.255.0.0
C		192.0.0.0	223.255.255.0
D		224.0.0.0	239.255.255.255
E		240.0.0.0	247.255.255.255

Нетрудно посчитать, что всего в пространстве адресов IP - 128 сетей по 16 777 216 адресов класса A, 16384 сети по 65536 адресов класса B и 2 097 152 сети по 256 адресов класса C, а также 268 435 456 адресов многоадресной рассылки и 134 317 728 зарезервированных адресов. С ростом сети Интернет эта система оказалась неэффективной и была дополнена CIDR (бесклассовой адресацией).

Метод CIDR

Бесклассовая адресация (англ. Classless Inter-Domain Routing, англ. CIDR) — метод IP-адресации, позволяющий гибко управлять пространством IP-адресов, не используя жёсткие рамки классовой адресации. Использование этого метода позволяет экономно использовать ограниченный ресурс IP-адресов, поскольку возможно применение различных масок подсетей к различным подсетям.

Диапазоны адресов

IP-адрес является массивом битов. Принцип IP-адресации — выделение множества (диапазона, блока, подсети) IP-адресов, в котором некоторые битовые разряды имеют фиксированные значения, а остальные разряды пробегают все возможные значения. Блок адресов задаётся указанием начального адреса и маски подсети. Бесклассовая адресация основывается на переменной длине маски подсети (англ. variable length subnet mask, VLSM), в то время, как в классовой (традиционной) адресации длина маски строго фиксирована 0, 1, 2 или 3 установленными октетами.

Вот пример записи IP-адреса в бесклассовой нотации: 192.0.2.32/27.

Октеты IP-адреса

Биты IP-адреса

Биты маски подсети

Октеты маски подсети

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

Вот ещё один пример записи адреса с применением бесклассовой адресации: 172.16.0.1/12.

Октеты IP-адреса

Биты IP-адреса

Биты маски подсети

Октеты маски подсети

Множество всех адресов соответствует нулевой маске подсети и обозначается /0, а конкретный адрес IPv4 — маске подсети с длиной префикса в 32 бита, обозначаемой /32.

Для упрощения таблиц маршрутизации можно объединять блоки адресов, указывая один большой блок вместо ряда мелких. Например, 4 смежные сети класса C (4 × 255 адресов, маска 255.255.255.0 или /24) могут быть объединены, с точки зрения далёких от них маршрутизаторов, в одну сеть /22. И напротив, сети можно разбивать на более мелкие подсети, и так далее.

В Интернете используются^{[ прояснить ]} только маски следующего вида: n единиц, дальше все нули. Для таких (и только для таких) масок получающиеся множества IP-адресов будут смежными.

Математическое обоснование

С точки зрения бесклассовой двоичной адресации пространство IP-адресов рассматривается как ультраметрическое. Разные блоки адресов являются в нём шара́ми, радиус которых убывает с увеличением n, и сами они формируют направленное двоичное дерево. То есть, от каждого блока (/n, для IPv4) можно «перейти» на один из двух блоков меньшего размера (/ n +1), из которых он состоит.

Возможные маски

IPv4 CIDR
IP/маска	До последнего IP в подсети	Маска	Количество адресов	Класс
a.b.c.d/32	+0.0.0.0	255.255.255.255		1/256 C
a.b.c.d/31	+0.0.0.1	255.255.255.254		1/128 C
a.b.c.d/30	+0.0.0.3	255.255.255.252		1/64 C
a.b.c.d/29	+0.0.0.7	255.255.255.248		1/32 C
a.b.c.d/28	+0.0.0.15	255.255.255.240		1/16 C
a.b.c.d/27	+0.0.0.31	255.255.255.224		1/8 C
a.b.c.d/26	+0.0.0.63	255.255.255.192		1/4 C
a.b.c.d/25	+0.0.0.127	255.255.255.128		1/2 C
a.b.c.0/24	+0.0.0.255	255.255.255.000		1 C
a.b.c.0/23	+0.0.1.255	255.255.254.000		2 C
a.b.c.0/22	+0.0.3.255	255.255.252.000		4 C
a.b.c.0/21	+0.0.7.255	255.255.248.000		8 C
a.b.c.0/20	+0.0.15.255	255.255.240.000		16 C
a.b.c.0/19	+0.0.31.255	255.255.224.000		32 C
a.b.c.0/18	+0.0.63.255	255.255.192.000	16 384	64 C
a.b.c.0/17	+0.0.127.255	255.255.128.000	32 768	128 C
a.b.0.0/16	+0.0.255.255	255.255.000.000	65 536	256 C = 1 B
a.b.0.0/15	+0.1.255.255	255.254.000.000	131 072	2 B
a.b.0.0/14	+0.3.255.255	255.252.000.000	262 144	4 B
a.b.0.0/13	+0.7.255.255	255.248.000.000	524 288	8 B
a.b.0.0/12	+0.15.255.255	255.240.000.000	1 048 576	16 B
a.b.0.0/11	+0.31.255.255	255.224.000.000	2 097 152	32 B
a.b.0.0/10	+0.63.255.255	255.192.000.000	4 194 304	64 B
a.b.0.0/9	+0.127.255.255	255.128.000.000	8 388 608	128 B
a.0.0.0/8	+0.255.255.255	255.000.000.000	16 777 216	256 B = 1 A
a.0.0.0/7	+1.255.255.255	254.000.000.000	33 554 432	2 A
a.0.0.0/6	+3.255.255.255	252.000.000.000	67 108 864	4 A
a.0.0.0/5	+7.255.255.255	248.000.000.000	134 217 728	8 A
a.0.0.0/4	+15.255.255.255	240.000.000.000	268 435 456	16 A
a.0.0.0/3	+31.255.255.255	224.000.000.000	536 870 912	32 A
a.0.0.0/2	+63.255.255.255	192.000.000.000	1 073 741 824	64 A
a.0.0.0/1	+127.255.255.255	128.000.000.000	2 147 483 648	128 A
0.0.0.0/0	+255.255.255.255	000.000.000.000	4 294 967 296	256 A

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

Адреса пакетов IPv6

Адресное пространство IPv6 будет распределяться IANA (Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (Internet Architecture Board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).

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

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

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

IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

• Расширение адресации. В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.

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

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

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

• Идентификация и защита частных обменов. В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации.

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885 и RFC-4861 (обновленная версия). Протокол ICMPv6 выполняет также функцию получения данных о соседях (аналог протокола ARP). Для этой цели используется посылка мультикастинг-сообщений.

2. Формат заголовка IPv6

Версия	4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6)
Приор.	8-битный код приоритета
Метка потока	24-битный код метки потока (для мультимедиа)
Размер поля данных	16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций.
Следующий заголовок	8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700].
Предельное число шагов	8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется.
Адрес отправителя	128-битовый адрес отправителя пакета. См. RFC-1884.

Cообщения об ошибках ICMP6

Формат пакета ICMP