Что характерно для протокола udp

сетевое программирование в Unix. Часть 3. UDP

(спокойно)
Светлое небо, зеленые ели
Тихий капель стук по ступенькам крыльца…
(экспрессивно, с надрывом)
А в полях пожелтевшего белого снега
Озверевший конвой доедает з/к
Они его ручки — ам, они его ручки — ам
(шепотом)
Вот так совсем человечка физически уничтожили.
(король русского шансона Михаил Брюк, из КВН )

Вот мы и подошли к финальной части букваря, к протоколу UDP и методам работы с ним.
Начнем традиционно, с клиента, и закончим, как обычно, сервером.
Напоминаю, что UDP — это модель передачи данных без образования соединения и без проверки корректности передачи. Посему если информация пропала — никто не виноват. Но если канал передачи надежный — почему бы и не использовать UDP?
Данные передаются так называемыми датаграммами (datagram) без сохранения порядка при переносе к получателю.

UDP-клиент

К сожалению стандартных и широко распространенных программок типа telnet не обнаружено. Поэтому в этой роли выступает накарябаный на колене за вечер корявый шедевр. Встречайте:

[udp_client.cpp]

1 #include <sys/types.h>
2 #include <sys/socket.h>
3 #include <netinet/in.h>
4 #include <arpa/inet.h>
5 #include <string.h>
6 #include <unistd.h>
7 #include <stdio.h>

8 int main() {
9 struct sockaddr_in server, client={AF_INET,INADDR_ANY,INADDR_ANY};

10 memset(&server,0,sizeof(server));

11 server.sin_family=AF_INET;
12 server.sin_port=htons(1212);
13 server.sin_addr.s_addr=inet_addr(«127.0.0.1»);

14 int sock;

15 sock=socket(PF_INET,SOCK_DGRAM,0);
16 bind(sock,(sockaddr *)&client,sizeof(client));

17 char buf[81];
18 memset(buf,0,81);
19 strcpy(buf,»request»);
20 sendto(sock,&buf,strlen(buf),0,(sockaddr *)&server,sizeof(server));
21 memset(buf,0,81);
22 recvfrom(sock,buf,80,0,NULL,0);
23 puts(buf);

24 return 0;
25 }

Эта мини-программа посылает слово «request» на порт 1212 по адресу 127.0.0.1 (localhost) и читает, что же ответил сервер.
с 1 по 14 строки — стандартная сокетная обвязка, общая для TCP и UDP. У нас клиент, поэтому в 12 и 13 задаем порт и адрес назначения.
В 15 обратите особое внимание на константу SOCK_DGRAM — мы задаем тип сокета как датаграмный.
16 — уже специфична. Мы явно выполняем привязку адреса и порта к созданному сокету. 9 строка явно указывает, что программисту фиолетово, какой порт занять и через какой из сетевых интерфейсов отсылать данные. Ядро поймет это указание правильно и выдаст порт случайным образом.
20 и 22 строки — следующие специфичные для UDP элементы. Системные вызовы sendto(2) и recvfrom(2) предназначены для отправки и получения сообщений в/из сокета. Их можно использовать даже если сокет находится в несоединенном состоянии. Кстати, несмотря на природу SOCK_DGRAM, здесь можно использовать connect(2) и заменить sendto(2) на write(2) и recvfrom(2) на read(2). Будет сделана виртуальная привязка сокета к пункту назначения, но соединение не будет устанавливаться, т.к. сокет остается по прежнему SOCK_DGRAM.

UDP-сервер

Опять же daytime сервер в DGRAM-реинкарнации. Ждет датаграмму, при приходе оной извлекает адрес отправителя и посылает в ответ текущее время сервера.

[udp_server.cpp]

1 #include <sys/types.h>
2 #include <sys/socket.h>
3 #include <netinet/in.h>
4 #include <arpa/inet.h>
5 #include <string.h>
6 #include <time.h>
7 #include <unistd.h>
9 #include <stdio.h>

10 char * daytime() {
11 time_t now;
12 now=time(NULL);
13 return ctime(&now);
14 }

15 int main() {
16 struct sockaddr_in addr;

17 memset(&addr,0,sizeof(addr));

18 addr.sin_family=AF_INET;
19 addr.sin_port=htons(1212);
20 addr.sin_addr.s_addr=INADDR_ANY;

21 int sock, c_sock;

22 sock=socket(PF_INET,SOCK_DGRAM,0);
23 bind(sock,(struct sockaddr *)&addr,sizeof(addr));
24 for (;;) {
25 struct sockaddr from;
26 unsigned int len=sizeof(from);
27 char buf[81];
28 memset(buf,0,81);
29 recvfrom(sock,&buf,80,0,&from,&len);
30 printf(«udp incoming:%s»,buf);

31 memset(buf,0,81);
32 strncpy(buf,daytime(),80);

33 sendto(sock,buf,strlen(buf),0,&from,len);
34 puts(«answer udp»);
35 }

36 return 0;
37 }

Все меньше и меньше остается незнакомых элементов в программах. Будь я графоманом и/или любителем гонораров — расписывал бы каждую строку :).
В этом примере мы заострим внимание всего на двух строках — 29 и 33. При вызове recvfrom(2) системным вызовом заполняются параметры 5 и 6.

16. Протокол udp, применение

Адрес отправителя и размер структуры для его хранения. Так сервер узнает о существовании клиента и о наличии у него желания пообщаться. И в 33 строке идет подача данных в ответ.

объедки анализа

Наблюдательные дети наверное заметили, что клиент и сервер у UDP практически идентичны по набору используемых вызовов. Отличие всего в двух маленьких детальках, а дьявол всегда прячется в деталях.
Первая деталька: присваивание адреса и порта сокету: сервер явно указывает порт, клиент — саботирует. Ведь чтобы обратиться к серверу — за ним должен быть зафиксирован порт.
Вторая деталька: порядок вызовов recvfrom(2) и sendto(2). Клиент сначала отсылает, потом принимает, сервер, наоборот, принимает а затем отсылает. Клиент-сервер as is: клиент начинает, сервер реагирует на действия.

TCP и UDP — послесловие

Не исключено, что после разбора примеров из 2 и 3 части станут гораздо яснее тезисы, высказанные в 1 части цикла статей.
Теперь мы переходим к дальнейшему сокетному беспределу. В части 4 цикла будут рассмотрены модели организации серверов, с учетом множества клиентов. Многозадачность, синхронизация, неблокируемый ввод/вывод, мультиплексирование и т.д. Буквы изучили — теперь начинаем писать по слогам:).

mend0za.

© Сетевые решения

Подробности
Обновлено: 01 Ноябрь 2014
Просмотров: 14630

User Datagram Protocol (UDP) (протокол пользовательских дейтаграмм) — является протоколом стандарта TCP/IP, определенный в стандарте RFC 768, «User Datagram Protocol (UDP)».

UDP используется вместо TCP для быстрой и ненадежной транспортировки данных между TCP/IP хостами.

UDP протокол обеспечивает обслуживание без установления соединения, таким образом UDP не гарантирует доставку или проверки последовательности для любой дейтаграммы. Хост, который нуждается в надежной связи должен использовать либо протокол TCP либо программу, которая будет сама следить за последовательностью дейтаграмм и подтверждать прием каждого пакета.

Автором протокола UDP является Дэвид П. Рид созданный в 1980 году.

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

Протоколы TCP и UDP

Еще одним преимуществом протокола UDP является то, что длина заголовка UDP составляет 4 байта, а у TCP протокола — 20 байт.

UDP сообщения инкапсулируются и передаются в IP дейтаграммы.

UDP заголовок

На рисунке показаны поля, присутствующие в UDP заголовке.

  • Порт отправителя — в этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из «хорошо известных».
  • Порт получателя — это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент — хост-получатель, то номер порта эфемерный, иначе (сервер — получатель) это «хорошо известный порт».
  • Длина дейтаграммы — поле, задающее длину всей дейтаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-дейтаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется еще 20 на IP-заголовок).
  • Контрольная сумма — поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями.

Рассмотрим структуру заголовка UDP с помощью сетевого анализатора Wireshark:

UDP порты

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

Номер порта — это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.

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

Все номера портов UDP, которые меньше чем 1024 — зарезервированы и зарегистрированы в Internet Assigned Numbers Authority (IANA).
Номера портов UDP и TCP не пересекаются.

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

Вас также могут заинтересовать:

Зарегистрировано ряд портов для стандартного применения и в диапазоне 1024-65535. Например:

Схема вычисления контрольных сумм

Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтограмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдо-заголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае IP-дейтограммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.

Рис. 4.4.2.2.

Протоколы транспортного уровня TCP и UDP. Основные задачи. Принцип работы

Псевдозаголовок, используемый при расчете контрольной суммы

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

Может возникнуть вопрос, зачем вычислять и проверять контрольную сумму, если подтверждение доставки и повторная пересылка в рамках протокола не предусмотрены. Дело в том, что UDP используется не только для мультимедийных задач но и некоторыми другими протоколами (DNS, SNMP и др.), где повторные запросы и отклики могут выполняться на прикладном уровне.

Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее (Ethernet допускает 1508 байт). Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768. Смотри также RFC-2147 (IPv6 Jumbo), RFC-2508 (компрессия заголовков) и RFC-3828 (Lightweight UDP).

Нашел применение UDP и в протоколе Teredo (туннелирование IPv6 для систем NAT).

Транспортный уровень моделей OSI, TCP/IP

Протокол TCP (Transmission Control Protocol) является транспортным протоколом стека протоколов TCP/IP, обеспечивающим гарантированную доставку данных с установлением виртуального соединения.

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

В соответствии с функциональным назначением протокола структура TCP-сегмента предполагает наличие следующих информационных полей:

  • номер порта-отправителя и номер порта-получателя – номера портов, идентифицирующие программы, между которыми осуществляется взаимодействие;

  • поля, предназначенные для обеспечения гарантированной доставки: размер окна, номер последовательности и номер подтверждения (см. Реализация режима гарантированной доставки);

  • управляющие флаги – специальные битовые поля, управляющие протоколом.

 Протокол TCP

 

Реализация режима гарантированной доставки

Для обеспечения гарантированной доставки протокол TCP использует механизм отправки подтверждения. С целью снижения загрузки сети протокол TCP допускает посылку одного подтверждения сразу для нескольких полученных сегментов. Объем данных, которые могут быть переданы в сеть отправителем до получения подтверждения, определяется специальным параметром протокола TCP — размером окна. Размер окна согласуется при установлении соединения между отправителем и получателем и может автоматически изменяться программными модулями протокола TCP в зависимости от состояния канала связи. Если в процессе передачи данных потери происходят достаточно часто, то размер окна уменьшается, и наоборот – окно может иметь большой размер, если высока надежность канала данных.

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

 

 Скользящее окно TCP

 

Установление соединения

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

 

UDP пакет

Протоколы UDP и TCP относятся к транспортному уровню модели стека TCP/IP

ПротоколUDP (User Datagram Protocol) не требует подтверждения получения, не обеспечивает гарантированности доставки и, следовательно, целостности переданных данных (сборки данных из разных пакетов). Протокол используется для передачи команд и сетевой информации (например, при разрешении имен в DNS), а также для передачи вышележащим протоколам, обеспечивающим гарантированность доставки и целостность данных своими средствами. Структура UDP пакета приведена в таблице 1.

Таблица 1.

Протоколы передачи данных TCP и UDP.

UDP пакет.

←————————————————————————— Слово 32 бита (4-е байта) ————————————————————→

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

Порт источника

Порт получателя

Длина

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

Данные

. . . .

Данные

Порты источника и получателя – 16-и битовые (2-х байтовые) идентификаторы прикладных протоколов источника и получателя соответственно. Эти идентификаторы необходимы для разделения данных при одновременной работе различных прикладных процессов. Например, при одновременном приёме файлов (протокол FTP) и просмотре web-страницы (протокол HTTP) на одном и том же узле. За известными протоколами (по умолчанию) закреплены первые 1024 порта (например, FTP – 21 порт, HTTP – 80 и т.д.), но номера портов могут быть и переназначены произвольным образом. Совокупность прикладного протокола, IP адресов и номеров портов узлов назначения и источника называется сокетом (socket – гнездо). В сокете номер порта указывается за IP адресом после двоеточия (например, 212.46.206.2:80). Совокупность параметров сокета необходима для организации взаимодействия процессов (программ) в конечных узлах компьютерной сети.

Длина – длина всего (с заголовком) UDP пакета. Максимальная длина UDP пакета есть максимальный размер данных в IP пакете минус минимальная длина заголовка UDP пакета, т.е. (65 535 – 20) – 8 = 65 507 байт.

Контрольная сумма – дополнение до нуля всех двухбайтовых слов пакета и псевдозаголовка.

Перед заголовком для фиксации сокета на транспортном уровне вставляется псевдозаголовок, дополняющий номера портов недостающими значениями IP адресов и индикатором протокола (см. таблицу 2).

Таблица 2. Псевдозаголовок UDP пакета

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

1

2

3

4

5

6

7

8

IP адрес источника

IP адрес получателя

0

Протокол

Длина

Протокол – идентификатор протокола (например, 17 – UDP, 6 – TCP).

Длина – длина UDP/TCP пакета.


Похожие страницы:

  1. Комплекс сетевой защиты

    Реферат >> Информатика

    … значения пропустить или отбросить. Тип пакета — TCP, UDP или ICMP. Флаги — … для TCP и UDPпакетов. В первую очередь, фильтры отбрасывают пакеты ICMP, UDP и входящие пакеты SYN/ACK … же, что и для протоколов TCP и UDP – в пакете сначала идёт заголовок IP, затем …

  2. Организация ЛВС на базе OS WINDOWS

    Реферат >> Информатика

    … эхоотклика при получении каждого пакета с дейтаграммой. UDP проще TCP, поскольку он … просто уложить имя в UDPпакет, запаковать это в IP-пакет и послать. На другом … телефонный номер, положит его в другой UDPпакет и отправит обратно. Что произойдет, если …

  3. Internet прошлое и будущее

    Реферат >> Информатика

    … можете просто уложить имя в UDPпакет, запаковать это в IP-пакет и послать. На другом … телефонный номер, положит его в другой UDPпакет и отправит обратно. Что произойдет, если … TCP-связь и общаются через TCP и UDPпакеты. Взаимодействие это очень не простое …

  4. Контрольная работа по Программированию (1)

    Контрольная работа >> Информатика

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

  5. Состав и ресурсы Internet

    Реферат >> Информатика

    … эхоотклика при получении каждого пакета с дейтаграммой. UDP проще TCP, поскольку он … просто уложить имя в UDPпакет, запаковать это в IP-пакет и послать. На другом … телефонный номер, положит его в другой UDPпакет и отправит обратно. Что произойдет, если …

Хочу больше похожих работ…

Добавить комментарий

Закрыть меню