Протокол UDP
— это простой, ориентированный на дейтаграммы протокол без организации соединения, предоставляющий быстрое, но необязательно надежное транспортное обслуживание. Он поддерживает взаимодействия «один со многими» и поэтому часто применяется для широковещательной и групповой передачи дейтаграмм.
Internet Protocol (IP) является основным протоколом Интернета. Transmission Control Protocol (TCP) и UDP — это протоколы транспортного уровня, построенные поверх лежащего в основе протокола.
TCP/IP — это набор протоколов, называемый также «пакетом протоколов Интернета» (Internet Protocol Suite), состоящий из четырех уровней. Запомните, что TCP/IP не просто один протокол, а семейство или набор протоколов, который состоит из других низкоуровневых протоколов, таких, как IP, TCP и UDP. UDP располагается на транспортном уровне поверх IP (протокола сетевого уровня). Транспортный уровень обеспечивает взаимодействие между сетями через шлюзы. В нем используются IP-адреса для отправки пакетов данных через Интернет или другую сеть с помощью разнообразных драйверов устройств.
Прежде чем приступать к изучению работы UDP, обратимся к основной терминологии, которую нужно хорошо знать. Ниже вкратце определим основные термины, связанные с UDP:
Пакеты
В передаче данных пакетом называется последовательность двоичных цифр, представляющих данные и управляющие сигналы, которые передаются и коммутируются через хост. Внутри пакета эта информация расположена в соответствии со специальным форматом.
Дейтаграммы
Дейтаграмма — это отдельный, независимый пакет данных, несущий информацию, достаточную для передачи от источника до пункта назначения, поэтому никакого дополнительного обмена между источником, адресатом и транспортной сетью не требуется.
MTU (Maximum Transmission Unit)
MTU характеризует канальный уровень и соответствует максимальному числу байтов, которое можно передать в одном пакете. Другими словами MTU — это самый большой пакет, который может переносить данная сетевая среда. Например, Ethernet имеет фиксированный MTU, равный 1500 байтам. В UDP, если размер дейтаграммы больше MTU, протокол IP выполняет фрагментацию, разбивая дейтаграмму на более мелкие части (фрагменты) так, чтобы каждый фрагмент был меньше MTU.
Порты
Чтобы поставить в соответствие входящим данным конкретный процесс, выполняемый в компьютере, UDP использует порты. UDP направляет пакет в соответствующее место, используя номер порта, указанный в UDP-заголовке дейтаграммы. Порты представлены 16-битными номерами и, следовательно, принимает значения в диапазоне от 0 до 65 535. Порты, которые также называют конечными точками логических соединений, разделены на три категории:
- Хорошо известные порты — от 0 до 1023
- Регистрируемые порты — от 1024 до 49151
- Динамические / частные порты — от 49152 до 65535
Заметим, что порты UDP могут получать более одного сообщения в каждый промежуток времени. В некоторых случаях сервисы TCP и UDP могут использовать одни и те же номера портов, например 7 (Echo) или 23 (Telnet).
UDP использует следующие известные порты:
| Номер порта | Описание |
|---|---|
| 15 | NETSTAT — Состояние сети |
| 53 | DNS — Сервер доменных имен |
| 69 | TFTP — Простейший протокол передачи файлов |
| 137 | Служба имен NetBIOS |
| 138 | Дейтаграммная служба NetBIOS |
| 161 | SMTP |
Перечень портов UDP и TCP поддерживается агентством IANA (Internet Assigned Numbers Authority).
IP-адреса
Дейтаграмма IP состоит из 32-битных IP-адресов источника и назначения. IP-адрес назначения задает конечную точку для дейтаграммы UDP, а IP-адрес источника используется для получения информации о том, кто отправил сообщение. В пункте назначения пакеты фильтруются, и те из них, адреса источников которых не входят в допустимый набор адресов, отбрасываются без уведомления отправителя.
Однонаправленный IP-адрес уникально определяет хост в сети, тогда как групповой IP-адрес определяет конкретную группу адресов в сети. Широковещательные IP-адреса получаются и обрабатываются всеми хостами локальной сети или конкретной подсети.
TTL
Значение времени жизни, или TTL (time-to-live), позволяет установить верхний предел числа маршрутизаторов, через которые может пройти дейтаграмма. Значение TTL не дает пакетам попасть в бесконечные циклы. Оно инициализируется отправителем и уменьшается на единицу каждым маршрутизатором, обрабатывающим дейтаграмму. Когда значение TTL становится нулевым, дейтаграмма отбрасывается.
Групповая рассылка
Групповая рассылка — это открытый, базирующийся на стандартах, метод одновременного распространения идентичной информации нескольким пользователям. Групповая рассылка является основным средством протокола UDP, она невозможна для протокола TCP. Групповая рассылка позволяет добиться взаимодействия одного со многими, например, делает возможными такие использования, как рассылка новостей и почты нескольким получателям, интернет-радио или демонстрационные программы реального времени. Групповая рассылка не так сильно нагружает сеть, как широковещательная передача, поскольку данные отправляются сразу нескольким пользователям:
Принцип работы UDP
Когда приложение, базирующееся на UDP, отправляет данные другому хосту в сети, UDP дополняет их восьмибитным заголовком, содержащим номера портов адресата и отправителя, общую длину данных и контрольную сумму. Поверх дейтаграммы UDP свой заголовок добавляет IP, формируя дейтаграмму IP:
На предыдущем рисунке указано, что общая длина заголовка UDP составляет восемь байтов. Теоретически максимальный размер дейтаграммы IP равен 65 535 байтам. С учетом 20 байтов заголовка IP и 8 байтов заголовка UDP длина данных пользователя может достигать 65 507 байтов. Однако большинство программ работают с данными меньшего размера. Так, для большинства приложений по умолчанию установлена длина приблизительно 8192 байта, поскольку именно такой объем данных считывается и записывается сетевой файловой системой (NFS). Можно устанавливать размеры входного и выходного буферов.
Контрольная сумма нужна, чтобы проверить были ли данные доставлены в пункт назначения правильно или были искажены. Она охватывает как заголовок UDP, так и данные. Байт-заполнитель используется, если общее число октетов дейтаграммы нечетно. Если полученная контрольная сумма равна нулю, получатель фиксирует ошибку контрольной суммы и отбрасывает дейтаграмму. Хотя контрольная сумма является необязательным средством, ее всегда рекомендуется включать.
На следующем шаге уровень IP добавляет 20 байтов заголовка, включающего TTL, IP-адреса источника и получателя и другую информацию. Это действие называют IP-инкапсуляцией.
Как упоминалось ранее, максимальный размер пакета равен 65 507 байтам. Если пакет превышает установленный по умолчанию размер MTU, то уровень IP разбивает пакет на сегменты. Эти сегменты называются фрагментами, а процесс разбиения данных на сегменты — фрагментацией. Заголовок IP содержит всю информацию о фрагментах.
Когда приложение-отправитель «выбрасывает» дейтаграмму в сеть, она направляется по IP-адресу назначения, указанному в заголовке IP. При проходе через маршрутизатор значение времени жизни (TTL) в заголовке IP уменьшается на единицу.
Когда дейтаграмма прибывает к заданному назначению и порту, уровень IP по своему заголовку проверяет, фрагментирована ли дейтаграмма. Если это так, дейтаграмма собирается в соответствии с информацией, имеющейся в заголовке. Наконец прикладной уровень извлекает отфильтрованные данные, удаляя заголовок.
Недостатки UDP
По сравнению с TCP UDP имеет следующие недостатки:
- Отсутствие сигналов квитирования. Перед отправкой пакета UDP, отправляющая сторона не обменивается с получающей стороной квитирующими сигналами. Следовательно, у отправителя нет способа узнать, достигла ли дейтаграмма конечной системы. В результате UDP не может гарантировать, что данные будут действительно доставлены адресату (например, если не работает конечная система или сеть). Напротив, протокол TCP ориентирован на установление соединений и обеспечивает взаимодействие между подключенными к сети хостами, используя пакеты. В TCP применяются сигналы квитирования, позволяющие проверить успешность транспортировки данных.
- Использование сессий. Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.
- Надежность. UDP не гарантирует, что адресату будет доставлена только одна копия данных. Чтобы отправить конечной системе большой объем данных, UDP разбивает его на небольшие части. UDP не гарантирует, что эти части будут доставлены по назначению в том же порядке, в каком они создавались в источнике. Напротив, TCP вместе с номерами портов использует порядковые номера и регулярно отправляемые подтверждения, гарантирующие упорядоченную доставку данных.
- Безопасность. TCP более защищен, чем UDP. Во многих организациях брандмауэры и маршрутизаторы не пропускают пакеты UDP. Это связано с тем, что хакеры могут воспользоваться портами UDP, не устанавливая явных соединений.
- Управление потоком. В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.
Преимущества UDP
По сравнению с TCP UDP имеет следующие преимущества:
- Нет установки соединения. UDP является протоколом без организации соединений, поэтому он освобождает от накладных расходов, связанных с установкой соединений. Поскольку UDP не пользуется сигналами квитирования, то задержек, вызванных установкой соединений, также удается избежать. Именно поэтому DNS отдает предпочтение UDP перед TCP — DNS работала бы гораздо медленнее, если бы она выполнялась через TCP.
- Скорость. UDP работает быстрее TCP. По этой причине многие приложения предпочитают не TCP, a UDP. Те же средства, которые делают TCP более устойчивым (например сигналы квитирования), замедляют его работу.
- Топологическое разнообразие. UDP поддерживает взаимодействия «один с одним» и «один с многими», в то время как TCP поддерживает лишь взаимодействие «один с одним».
- Накладные расходы. Работа с TCP означает повышенные накладные расходы, издержки, налагаемые UDP, существенно ниже. TCP по сравнению с UDP использует значительно больше ресурсов операционной системы, и, как следствие, в таких средах, где серверы одновременно обслуживают многих клиентов, широко используют UDP.
- Размер заголовка. Для каждого пакета заголовок UDP имеет длину всего лишь восемь байтов, в то время как TCP имеет 20-байтовые заголовки, и поэтому UDP потребляет меньше пропускной способности сети.
Организация UDP через интернет
Добрый день. Ситуация такая: есть VPS, работающий в локальной сети и имеющий внешний статический IP. На VPS запущено серверное ПО, которое обменивается UDP-пакетами с клиентами. В локальной сети все работает нормально. 1) Возможно ли организовать обмен UDP-пакетами с клиентами из внешней сети (например, со смартфонами, подключенными к 3G, у которых IP динамический). Проброс портов из локалки во внешку не помогает, т.к. у клиентов нет статического внешнего IP. 2) Как организовать проверку доступности сервера (если это вообще возможно для UPD)?
Отслеживать
задан 7 июн 2016 в 4:24
75 1 1 серебряный знак 7 7 бронзовых знаков
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
1) Внешние клиенты чаще всего в состоянии достучаться до сервера через NAT. Это мало отличается от того же TCP.
2) Проверка доступности сервера клиентом осуществляется крайне просто — отвечает — значит, доступен.
3) Учтите, что UDP не гарантирует, что отправленные пакеты дойдут, и при этом дойдут в правильном порядке. Есть подозрение, что вы изобретаете TCP.
Отслеживать
ответ дан 7 июн 2016 в 4:51
22.2k 2 2 золотых знака 33 33 серебряных знака 53 53 бронзовых знака
1) Да, из внешки в локалку нет проблема. А если нужно наоборот, передавать пакет из локалки во внешку? Как NAT узнает, куда его отправлять:
Как направить udp пакеты в интернет
Transmission Control Protocol — это протокол, тесно связанный с IP, который используется в аналогичных целях, но на более высоком уровне — транспортном уровне эталонной модели ISO OSI. Часто эти протоколы, по причине их тесной связи, именуют вместе, как TCP/IP. Термин «TCP/IP» обычно означает все, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы TCP, UDP, ICMP, telnet, FTP и многие другие. Иерархия протоколов семейства TCP/IP показана на рисунке . TCP/IP — это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется internet.
Сам протокол TCP занимается проблемой пересылки больших объемов информации, основываясь на возможностях протокола IP. Как это делается? Вполне здраво можно рассмотреть следующую ситуацию. Как можно переслать книгу по почте, если та принимает только письма и ничего более? Очень просто: разодрать ее на страницы и отправить страницы отдельными конвертами. Получатель, руководствуясь номерами страниц, легко сможет книгу восстановить. Этим же простым и естественным методом и пользуется TCP.
TCP делит информацию, которую надо переслать, на несколько частей. Нумерует каждую часть, чтобы позже восстановить порядок. Чтобы пересылать эту нумерацию вместе с данными, он обкладывает каждый кусочек информации своей обложкой — конвертом, который содержит соответствующую информацию. Это и есть TCP-конверт. Получившийся TCP-пакет помещается в отдельный IP-конверт и получается IP-пакет, с которым сеть уже умеет обращаться.
Получатель (TCP-модуль (процесс)) по получении распаковывает IP-конверты и видит TCP-конверты, распаковывает и их и помещает данные в последовательность частей в соответствующее место. Если чего-то не достает, он требует переслать этот кусочек снова. В конце концов информация собирается в нужном порядке и полностью восстанавливается. Вот теперь этот массив пересылается выше к пользователю (на диск, на экран, на печать).
В действительности, это слегка утрированный взгляд на TCP. В реальности пакеты не только теряются, но и могут искажаться при передаче из-за наличия помех на линиях связи. TCP решает и эту проблему. Для этого он пользуется системой кодов, исправляющих ошибки. Существует целая наука о таких кодировках. Простейшим примером такового служит код с добавлением к каждому пакету контрольной суммы (и к каждому байту бита проверки на четность). При помещении в TCP-конверт вычисляется контрольная сумма, которая записывается в TCP-заголовок. Если при приеме заново вычисленная сумма не совпадает с той, что указана на конверте, значит что-то тут не то, — где-то в пути имели место искажения, так что надо переслать этот пакет по-новой, что и делается.
Рисунок: Иерархия протоколов семейства IP
Для ясности и полноты картины, необходимо сделать здесь важное замечание: Модуль TCP разбивает поток байтов на пакеты, не сохраняя при этом границ между записями. Т.е., если один прикладной процесс делает 3 записи в —порт, то совсем не обязательно, что другой прикладной процесс на другом конце виртуального канала получит из своего —порта именно 3 записи, причем именно таких (по разбиению), что были переданы с другого конца. Вся информация будет получена исправно и с сохранением порядка передачи, но она может уже быть разбита по другому и на иное количество частей. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны. TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует ожидания (таймауты) и повторные передачи для обеспечения надежной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще не подтвержденных данных. Количество байт, которое можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является , т.е. данные могут одновременно передаваться в обоих направлениях, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.
Таким образом, протокол TCP обеспечивает гарантированную доставку с установлением логического соединения в виде байтовых потоков. Он освобождает прикладные процессы от необходимости использовать ожидания и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются ftp и telnet. Кроме того, TCP использует система X-Windows (стандартный многооконный графический интерфейс с пользователем), «r-команды».
Большие возможности TCP даются не бесплатно, реализация TCP требует большой производительности процессора и большой пропускной способности сети. Когда прикладной процесс начинает использовать TCP, то начинают общаться модуль TCP на машине пользователя и модуль на машине сервера. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения — виртуального канала. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал этот, как уже указывалось, является дуплексным. Один прикладной процесс пишет данные в TCP—порт, откуда они модулями соответствующих уровней по цепочке передаются по сети и выдаются в TCP—порт на другом конце канала, и другой прикладной процесс читает их отсюда — из своего TCP—порта. эмулирует (создает видимость) выделенную линию связи двух пользователей. Гарантирует неизменность передаваемой информации. Что входит на одном конце, выйдет с другого. Хотя в действительности никакая прямая линия отправителю и получателю в безраздельное владение не выделяется (другие пользователи могут пользовать те же узлы и каналы связи в сети в промежутках между пакетами этих), но извне это, практически, именно так и выглядит.
Как бы хорошо это не звучало, но это не панацея. Как уже отмечалось, установка TCP—виртуального канала связи требует больших расходов на инициирование и поддержание соединения и приводит к задержкам передачи. Если вся эта суета — излишество, лучше обойтись без нее. Если все данные, предназначенные для пересылки, умещаются в одном пакете, и если вас не особенно заботит надежность доставки (? — читайте дальше, — поймете), то можно обойтись без TCP.
Имеется другой стандартный протокол транспортного уровня, который не отягощен такими накладными расходами. Этот протокол называется UDP — User Datagram Protocol — протокол пользовательских дейтаграмм. Он используется вместо TCP. Здесь данные помещаются не в TCP, а в UDP-конверт, который также помещается в IP-конверт. Этот протокол реализует дейтаграммный способ передачи данных.
Дейтаграмма — это пакет, передаваемый через сеть независимо от других пакетов без установления логического соединения и подтверждения приема. Дейтаграмма — совершенно самостоятельный пакет, поскольку сама содержит всю необходимую для ее передачи информацию. Ее передача происходит безо всякого предварения и подготовки. Дейтаграммы, сами по себе, не содержат средств обнаружения и исправления ошибок передачи, поэтому при передаче данных с их помощью следует принимать меры по обеспечению надежности пересылки информации. Методы организации надежности могут быть самыми разными, обычно же используется метод подтверждения приема посылкой эхо-отклика при получении каждого пакета с дейтаграммой.
UDP проще TCP, поскольку он не заботится о возможной пропаже данных, пакетов, о сохранении правильного порядка данных и т.д. UDP используется для клиентов, которые посылают только короткие сообщения и могут просто заново послать сообщение, если отклик подтверждения не придет достаточно быстро. Предположим, что вы пишите программу, которая просматривает базу данных с телефонными номерами где-нибудь в другом месте сети. Совершенно незачем устанавливать TCP связь, чтобы передать 33 или около того символов в каждом направлении. Вы можете просто уложить имя в UDP-пакет, запаковать это в IP-пакет и послать. На другом конце прикладная программа получит пакет, прочитает имя, посмотрит телефонный номер, положит его в другой UDP-пакет и отправит обратно. Что произойдет, если пакет по пути потеряется? Ваша программа тогда должна действовать так: если она ждет ответа слишком долго и становится ясно, что пакет затерялся, она просто повторяет запрос, т.е. посылает еще раз то же послание. Так обеспечивается надежность передачи при использовании протокола UDP.
В отличие от TCP, данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 3 записи в UDP—порт, то процесс-получатель должен будет сделать 3 чтения. Размер каждого записанного сообщения будет совпадать с размером соответствующего прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно целое и не делит одно сообщение на части.
Альтернатива TCP-UDP позволяет программисту гибко и рационально использовать предоставленные ресурсы, исходя из своих возможностей и потребностей. Если нужна надежная доставка, то лучше может быть TCP. Если нужна доставка дейтаграмм, то — UDP. Если нужна эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше использовать TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, лучше всего будет UDP. Если потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Прикладные программы, конечно, могут устранять некоторые недостатки выбранного протокола. Например, если вы выбрали UDP, а вам необходима надежность, то прикладная программа должна обеспечить надежность сама, как описано выше: требовать подтверждения, пересылки утерянных или увечных пакетов и т.д. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять метки в поток байтов так, чтобы можно было различить записи.
Thu Mar 23 22:27:58 MSK 1995
UDP сокеты и выделенный IP
Недавно жизнь связала меня с UDP несколько больше, чем общее понимание разницы UDP / TCP / HTTP , мне пришлось первый раз в жизни начать писать синхронизацию сервера и клиента в одной инди игрушке на python. Для того, чтобы завести это дело я использовал пакет socket . Я конечно всегда знал, что в голом UDP нет такого понятия как connection , сначала я пытался отправить пакет, и сразу же ожидать результата
sock.sendto(b'hi', target) resp = sock.recv(1028) В этот момент я уже понял, что ничего не понял. Код вроде бы работает, но во мне затоился вопрос, а как сервер будет отвечать мне? Чисто из соображений логики
_, addr = self.sock.recvfrom(1024) sock.sendto(b'accepted', addr) И на мое удивление это работает, конечно запустив это все в интернете а не на локальной сети, я увидел ужасных 0 — 20 пакетов в секунду, что не есть приемлемо для данной задачи. Не буду описывать весь процесс моего брейншторма, но я самостоятельно пришел к выводу, что нужно разделить логику на два потока, и скидывать результат в защищенный список, из которого уже третий поток будет доставать необходимые ему данные. Всё завелось, ура, дело было под утро и я ложусь спать, закрываю глаза и вижу это:
# client.py while self.running: resp = sock.recv(1028) Когда я понял, что это мертвое дело, я продолжил свои исследования, ведь я осознал, что у меня нет выделенного IP, подними я HTTP сервер, из интернета его никто не найдет, в тупую сделать socket.bind тоже не получилось, Windows выбрасывает нам эксепшн OSError: Требуемый адрес для своего контекста неверен . И при этом всем, после единственного пакета, который я отправляю на сервер, сервер может получает мой IP и port и затем может использовать его для отправки данных.
# client.py target = ('x.x.x.x', 8080) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP sock.settimeout(1.0) # `Connection` for send ip:port sock.sendto(b'hi', target) while True: try: req = sock.recv(1028) print(req) except socket.timeout: continue # server.py target = ('x.x.x.x', 8080) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP sock.bind(target) i = 0 last = time() print("Waiting message. ") _, addr = sock.recvfrom(1028) while True: sleep(0.1); sock.sendto(b"connect", addr) i += 1 if time() - last > 1: print("> Send <> packages per second to <>:<>".format(i, addr[0], addr[1])) i = 0 last = time() Ну и наконец сам вопрос Каким образом сервер отправляет мне пакеты, если у меня нет выделенного IP? Почему сервер TCP / HTTP без выделенного не видно из интернета, а голый UDP каким-то образом принимает пакеты из интернета на свой IP и свой какой-то случайный порт? И почему socket.bind не работает если я хочу принимать пакеты на определенный порт?