Udp размер пакета: Какой самый большой размер безопасного UDP-пакета в Интернете

Какой самый большой размер безопасного UDP-пакета в Интернете

Учитывая, что IPV6 имеет размер 1500, я бы сказал, что операторы связи не будут предоставлять отдельные пути для IPV4 и IPV6 (они оба являются IP с разными типами), заставляя их использовать оборудование для ipv4, которое будет старым, избыточным, более дорогостоящим в обслуживании. и менее надежный. Это не имеет никакого смысла. Кроме того, это может легко рассматриваться как предоставление преференциального режима для некоторого трафика — нет, нет по правилам, о которых они, вероятно, не заботятся (если их не поймают).

Таким образом, 1472 должен быть безопасным для внешнего использования (хотя это не означает, что такое приложение, как DNS, которое не знает о EDNS, примет его), и если вы говорите о внутренних сетях, вы, скорее всего, знаете свой сетевой макет в этом случае. Размеры jumbo-пакетов применяются для не фрагментированных пакетов, то есть для 4096 — 4068 байт, а для карт Intel с 9014-байтовыми буферами размер пакета … wait … 8086 байт будет максимальным … совпадением? ржание

****ОБНОВИТЬ****

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

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

Так как вопрос был о максимально безопасных значениях, я предполагаю, что они говорят о максимально безопасном значении для пакета UDP, который может быть получен. Поскольку UDP-пакет не гарантирован, если вы получите UDP-пакет, самый большой безопасный размер будет 1 пакетом по IPv4 или 1472 байта.

Примечание. Если вы используете IPv6, максимальный размер будет 1452 байта, так как размер заголовка IPv6 составляет 40 байтов против 20 байтов IPv4 (и в любом случае, для заголовка UDP по-прежнему необходимо разрешить 8 байтов).

Размер пустого пакета UDP и TCP?

Каков размер пустой дейтаграммы UDP? А что с пустым пакетом TCP?

Я могу найти только информацию о MTU, но я хочу знать, каков их размер «base», чтобы оценить потребление полосы пропускания для протоколов поверх них.

tcp

udp

size

Поделиться

Источник

puccio    

04 декабря 2009 в 10:21

4 ответа

• Максимальный размер пакета для соединения TCP

  Каков максимальный размер пакета для соединения TCP или как я могу получить максимальный размер пакета?

• Размер Udp пакетов

  я хочу знать, есть ли у нас простой пакет udp, в котором есть строка, сколько будет размер пакета udp для exmaple у нас есть пакет udp, в котором есть строка строка is:stackoverflow.com хорошо, теперь, сколько будет размер пакета udp? я подумал, что может ли размер пакетов udp, в которых есть…

79

TCP:

Размер кадра Ethernet-24 байта

Размер заголовка IPv4 (без каких-либо опций) — 20 байт

Размер заголовка TCP (без каких-либо опций) — 20 байт

Общий размер кадра Ethernet, несущего IP-пакет с пустым сегментом TCP- 24 + 20 + 20 = 64 байта

UDP:

Размер кадра Ethernet-24 байта

Размер заголовка IPv4 (без каких-либо опций) — 20 байт

Размер заголовка UDP — 8 байт

Общий размер кадра Ethernet, несущего IP-пакет с пустой Датаграммой UDP- 24 + 20 + 8 = 52 байта

Поделиться

Himanshu    

04 декабря 2009 в 10:34

19

Ответ Химаншу совершенно верен.

Что может ввести в заблуждение при рассмотрении структуры кадра Ethernet [см. дальнейшее чтение], так это то, что без полезной нагрузки минимальный размер кадра Ethernet будет be 18 байт: Dst Mac(6) + Src Mac(6) + Length (2) + Fcs(4), Добавление минимального размера IPv4 (20) и TCP (20) дает нам в общей сложности 58 байт.

Что еще не было упомянуто, так это то, что минимальная полезная нагрузка фрейма ethernet составляет 46 байт, поэтому 20+20 байт из IPv4 и TCP-это недостаточная полезная нагрузка! Это означает, что 6 байт должны быть дополнены, вот откуда берется в общей сложности 64 байта.

18 (мин. Ethernet «header» полей) + 6 (заполнение) + 20(IPv4) + 20(TCP) = 64 байты

Надеюсь, это немного прояснит ситуацию.

Дальнейшее Чтение :

Поделиться

Felix    

20 августа 2014 в 13:53

9

См. Раздел Протокол Пользовательских Дейтаграмм . Заголовок UDP имеет длину 8 байт (64 бита).

Mimimum размер голого заголовка TCP составляет 5 слов (32-битное слово), в то время как максимальный размер заголовка TCP составляет 15 слов.

С наилучшими пожеланиями,
Фабиан

Поделиться

halfdan    

04 декабря 2009 в 10:25

• Как отличить пакет DTLS от пакета TCP, UDP

  От RFC 5764 : +—————-+ | 127 < B < 192 -+—> forward to RTP | | packet —> | 19 < B < 64 -+—> forward to DTLS | | | B < 2 -+—> forward to STUN +—————-+ Где B — первый байт пакета. Таким образом, для идентификации пакета DTLS мы делаем следующее…

• Программирование сокетов, что произойдет, если я запишу данные, которые может нести более одного пакета TCP/UDP?

  У меня есть вопрос о программировании сокетов. Когда я использую сокет для отправки данных, мы можем использовать API, например sendto(), для отправки с помощью TCP или UDP. Для sendto() мы даем указатель массива и номер байта, который хотим отправить. В этом случае, если я дал большое число…

0

Если вы намерены рассчитать потребление полосы пропускания и соотнести их с максимальной скоростью вашей сети (например, 1 Гбит / с или 10Gb/s),), то необходимо, как указал никчемный, добавить накладные расходы на фрейминг Ethernet на уровне 1 к числам, вычисленным Феликсом и другими, а именно

• 7 байт преамбулы
• 1 байт start-of-frame разделитель
• Межпакетный зазор 12 байт

то есть в общей сложности еще 20 байт потребляется на пакет.

Поделиться

Evgeniy Berezovsky    

01 июня 2015 в 07:27

Похожие вопросы:

Гарантия TCP Размер Пакета

Мы используем встроенное устройство для отправки пакетов из последовательного порта через конвертер serial-to-Ethernet на сервер. Один производитель, которым мы пользуемся, Moxa, всегда будет…

Каков оптимальный размер пакета UDP для максимальной пропускной способности?

Мне нужно посылать пакеты с одного хоста на другой по сети с потенциальными потерями . Для того, чтобы свести к минимуму задержки пакетов, я не хочу TCP/IP. но, я желаю, чтобы максимизировать…

Высокочастотная Торговля-TCP > UDP?

Мне сказали, что для высокочастотной торговой системы (HFT), которая требует низкой задержки, TCP используется вместо UDP. Мне сказали, что с TCP вы можете делать соединения точка-точка, в то время…

Максимальный размер пакета для соединения TCP

Каков максимальный размер пакета для соединения TCP или как я могу получить максимальный размер пакета?

Размер Udp пакетов

я хочу знать, есть ли у нас простой пакет udp, в котором есть строка, сколько будет размер пакета udp для exmaple у нас есть пакет udp, в котором есть строка строка is:stackoverflow.com хорошо,…

Как отличить пакет DTLS от пакета TCP, UDP

От RFC 5764 : +—————-+ | 127 < B < 192 -+—> forward to RTP | | packet —> | 19 < B < 64 -+—> forward to DTLS | | | B < 2 -+—> forward to STUN…

Программирование сокетов, что произойдет, если я запишу данные, которые может нести более одного пакета TCP/UDP?

У меня есть вопрос о программировании сокетов. Когда я использую сокет для отправки данных, мы можем использовать API, например sendto(), для отправки с помощью TCP или UDP. Для sendto() мы даем…

Понимание ограничения размера пакета TCP с ограничением размера пакета UDP и что это означает на уровне программирования boost::asio

Я использую boost::asio для выполнения UDP , а также TCP communication в моем клиентском приложении & серверных приложений. Я обнаружил, что могу передавать данные размера 65535 bytes только с…

UDP максимальный размер пакета

Я проверил максимальный размер пакета UDP и увидел, что он составляет 65507 байт данных. Это 65535-8 (udp заголовки) — 20 (IP-заголовки). Заголовок длины UDP имеет длину 2 байта, что составляет…

Tcp и udp максимальный размер пакета

При использовании recvfrom(2) для получения пакета из сети я получаю каждый раз 1 пакет. Какова максимальная длина пакета TCP/UDP, получаемого с помощью этой функции?

Протокол UDP

• Bot
• 29.01.2021
• 354
• 0
• 1
• 1
• 0

• Содержание статьи

Что такое протокол UDP?

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

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

Чувствительные ко времени приложения часто используют UDP (видеоданные), так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. Также потеря одного или нескольких кадров, при передаче видеоданных по 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-программы.

интеллектуальный анализ пропускной способности канала.

На этот вопрос вам ответит:

UMBA™ — UDP-чат и модуль интеллектуального анализа пропускной способности канала передачи данных.

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

* — Под пропускной способностью канала понимается количество «полезных» байт, переданных за единицу времени.

Инженерам связи известно, что при использовании пакетной передачи данных, в условиях нестабильной связи, перед отладчиками стоит задача выбрать оптимальный размер пакета, при котором общее количество переданных байт будет максимальным. При слишком большом размере пакета общее количество доставленных пакетов будет низким, а при маленьком размере пакета будет велико количество «технических» байт, что тоже снижает общую пропускную способность канала. Текущий оптимальный размер пакета определяется характеристиками оборудования, расстоянием между узлами передачи, текущими погодными условиями, и т.д. Так, в случае стандартной локальной кабельной ethernet-сети, в обычном режиме оптимальным размером пакета будет максимальный размер — 65565 байт. В случае использования, например, Wi-Fi- соединения, оптимальный размер пакета будет меньше, т.к. вероятность потери пакета возрастает. Если кабельная ethernet-сеть в текущий момент перегружена — оптимальный размер пакета уменьшается, и если в настройках системы выставлен максимально-допустимый размер пакета, количество доставленных полезных данных снизится. При построениии систем телемеханики и связи, в условиях нестабильного, медленного канала, типа GPRS, FM или TETRA, актуальность определения оптимального размера пакета в реальном времени становится особенно высока.

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

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

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

Стоимость базовой конфигруации: 1580

Внешний вид приложения UMBA™:

Данное приложение оптимизированно для всех последних версий операционных систем Windows и Linux, включая Windows 10.

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

Первая миля — научно-технический журнал — Первая миля

В течение почти 20 лет пользователи, имевшие дело со стеком TCP/IP, работали с одним из двух транспортных протоколов: TCP и UDP. Однако наступило время, когда для некоторых приложений потребовалась функциональность, выходящую за рамки той, которую в состоянии предоставить эти два протокола. В 2000 году организация IETF (Internet Engineering Task Force) одобрила в качестве стандарта протокол передачи с управлением потоком SCTP (Stream Control Transmission Protocol), который стал активно внедряться в сетях не так давно.
Протокол SCTP был создан в рамках проекта, начатого рабочей группой SIGTRAN, и в первую очередь предназначался для транспортировки сигнальной информации ОКС-7 по IP-сетям. Строгие требования ОКС-7 к параметрам потерь и соблюдению очередности следования сообщений привели к созданию нового транспортного протокола, свободного от недостатков UDP и TCP [1]. IETF предлагает использовать его в качестве протокола транспортного уровня общего назначения, объединяющего функции TCP и UDP над уровнем IP, поскольку и другие приложения могут использовать некоторые возможности этого протокола.

Как уже было отмечено, все три протокола работают на транспортном уровне эталонной модели взаимодействия открытых систем ВОС (OSI), основная задача которого – реализация сквозной связи между узлами сети, а также при необходимости управление потоком и предотвращение перегрузок сети. Транспортный уровень компенсирует ненадежность, присущую нижним уровням, за счет обработки ошибок, которые вызваны искажением данных, потерей пакетов и их доставкой не по порядку. Протоколы UDP, TCP и SCTP входят в стек TCP/IP, где также работают на транспортном уровне. Соответствие стека модели ВОС показано на рис.1.

Протокол UDP
Протокол дейтаграмм пользователя UDP (User Datagram Protocol) был описан в документе RFC 768 и принят IETF в 1980 году [2]. Он не ориентирован на создание соединения, его главное отличие – отсутствие гарантии доставки и поддержки упорядоченности передаваемых сообщений до места назначения (порядок сообщений может быть изменен из-за особенностей работы и капризов IP-сети)). Эти отличия – следствие логики работы протокола. Приложение, использующее UDP, формирует один пакет, который передается в IP-дейтаграмме. Если дейтаграмма дублируется в сети, то на принимающий узел могут быть доставлены два ее экземпляра. Если же клиент UDP отправляет две дейтаграммы в одно и то же место назначения, то их порядок может быть изменен сетью, и они будут доставлены с нарушением исходного порядка. Поэтому в приложениях, использующих UDP, разработчики должны реализовывать функции, в некоторой степени компенсирующие ненадежность этого протокола: тайм-ауты, повторную передачу, обработку потерянных дейтаграмм и порядковые номера для сопоставления ответов запросам. Этот подход позволяет протоколу гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность сети связи или малое время доставки данных. Но из-за отсутствия контроля перегрузок, возрастающего объема неконтролируемой высокоскоростной нагрузки и использования общей сетевой инфраструктуры с другими сервисами создается реальная опасность перегрузки сети, которая ведет к значительному падению ее производительности. Частично данную проблему призван решить относительно молодой протокол DCCP (Datagram Congestion Control Protocol), описанный в RFC 4340. Этот протокол – альтернатива UDP для приложений, которым необходим сервис одноадресной негарантированной доставки дейтаграмм, высокая скорость работы и реализованные на транспортном уровне механизмы для отслеживания перегрузок в сети без необходимости создавать их на уровне приложений. К сожалению, объем статьи не позволяет остановиться на нем более подробно.

Протокол TCP
Протокол управления передачей TCP (Trans-
mission Control Protocol), разработанный по
заказу агентства перспективных исследовательских программ ARPA, был опубликован в документе RFC 793 [3] в сентябре 1981 года, а уже в 1983 полностью заменил собой протокол NCP (Network Control Protocol) в сети ARPANET (прародителе Интернета) и сегодня стал основным протоколом для передачи данных.
Протокол TCP перед началом передачи данных в обязательном порядке устанавливает соединение и обеспечивает использующим его приложениям надежный упорядоченный двухсторонний байтовый поток. Он поддерживает отправку и прием подтверждений, обработку тайм-аутов, повторную передачу, управление потоком и прочие возможности, которые описаны в ряде документов (RFC 1323, 2581, 2988, 3390 и 5681).
Протокол TCP предлагает приложениям сервис надежной и упорядоченной передачи. Все отправленные данные подлежат обязательному подтверждению встречной стороной, причем формируются подтверждения не для каждого конкретного успешно полученного пакета, а для всех данных от начала посылки до некоторого порядкового номера. Если подтверждение не приходит в течение времени RTO (Retransmission Time Out), то протокол TCP автоматически передает данные повторно и перезапускает таймер вновь. Величина таймера RTO динамически меняется и зависит от времени двухсторонней задержки, определяемой с помощью специальных алгоритмов, типа сети и конкретной реализации протокола. Суммарное время повторных попыток отправки данных в среднем может занимать до 10 минут. Разумеется, TCP не может гарантировать получение данных адресатом, поскольку это в принципе невозможно. Если осуществить доставку невозможно, TCP уведомляет об этом пользователя, прекращает попытки повторной передачи и разрывает соединение. TCP можно условно считать протоколом, надежным на все 100%: он обеспечивает доставку данных или же уведомление о неудаче.
Упорядочивание данных осуществляется привязкой некоторого порядкового номера к каждому отправляемому байту. Предположим, что приложение записывает 2048 байт в сокет TCP, что приводит к отправке двух сегментов: первый из них содержит данные с порядковыми номерами 1–1024, второй – с номерами 1025–2048. Если какой-либо сегмент приходит вне очереди, то принимающий TCP перед отправкой данных приложению заново упорядочит сегменты, используя их порядковые номера. Если TCP получает дублированные данные, то он может их определить и отбросить [6].
Для обеспечения процедуры управления потоком (Flow Control) TCP всегда сообщает встречному узлу, какое буферное пространство он выделил для приема данных, и отправляющий узел не может превышать этого ограничения. Эта процедура получила название «метод скользящего окна». В любой момент времени окно соответствует свободному пространству в буфере получателя. Данный метод гарантирует, что отправитель не переполнит этот буфер, а также позволяет оптимизировать и ускорить процесс передачи больших объемов данных. Окно изменяется динамически по мере считывания принимающим приложением данных из буфера, а значение размера передается отправителю вместе с сообщением о подтверждении. Если принимающий буфер TCP заполнен, то возможна ситуация, при которой размер окна станет нулевым. В этом случае отправитель вынужден ждать, пока получатель не считает данные из буфера. При необходимости данные можно «протолкнуть», используя функцию PUSH. Функция запускается установкой в сообщении флага PSH, после чего все данные с таким флагом и данные в буфере получателя будут переданы принимающему приложению.
Приложение, использующее TCP, имеет возможность отправлять и принимать данные в обоих направлениях на заданном соединении в любой момент времени. Иначе говоря, TCP может работать в полнодуплексном режиме и должен отслеживать порядковые номера и размеры окна для каждого направления потока данных. После установления двухстороннего соединения оно может быть преобразовано в одностороннее.
Протокол TCP, поддерживающийся практически всеми приложениями Интернета, за прошедшие годы был значительно усовершенствован для обеспечения надежности и производительности в сетях различной емкости и качества. Тем не менее, в нем сохранились свойства, которые делают его неподходящим для таких задач, как передача сигнальных сообщений в VoIP-сетях или асинхронная обработка на базе транзакций [3]. TCP требует наличия службы доставки со строго упорядоченной передачей для всех данных, пересылаемых между двумя хостами. Это слишком серьезное ограничение для приложений, которые допускают как последовательную (частичное упорядочивание), так и непоследовательную доставку сообщений. TCP трактует каждую передачу данных как неструктурированную последовательность байтов и не хранит никаких неявных структур в передаваемых потоках данных. Приложения, которые обрабатывают отдельные сообщения, должны добавлять в поток байтов границы сообщений и отслеживать их.
Основанный на механизме TCP-сокетов API-интерфейс не поддерживает множественную адресацию, из-за чего приложение может связать только один IP-адрес другого узла с конкретным TCP-соединением. Если интерфейс, назначенный этому IP-адресу, отключается, то TCP-соединение прерывается, и его необходимо устанавливать заново, что вносит существенные задержки, особенно критичные для приложений реального времени [7].
Когда следует использовать UDP вместо TCP и почему? Мы осознано ставим этот вопрос до рассмотрения протокола SCTP, так как задача сравнения протокола UDP с протоколом TCP или SCTP ничем не отличается ввиду противопоставления ненадежного протокола протоколам гарантированной доставки.
UDP может использоваться для приложений широковещательной и многоадресной передачи (отправки одного пакета нескольким получателям вместо отправки копий пакета через несколько соединений TCP). Если требуется какая-либо форма защиты от потерь и нарушения порядка следования сообщений, то соответствующая функциональность должна быть добавлена приложениями как на клиентской, так и на серверной стороне. Однако приложения часто используют широковещательную и многоадресную передачу, когда некоторое количество потерь вполне допустимо (например, потеря аудио- или видеопакетов). Имеются приложения, требующие надежной доставки, например пересылка файлов при помощи многоадресной передачи, но в каждом конкретном случае разработчик должен решить, компенсируется ли выигрыш в производительности, получаемый за счет использования многоадресной передачи, дополнительным усложнением приложения для обеспечения надежности соединений.
UDP может использоваться для простых приложений запрос-ответ, так как не требует установки и разрыва соединения и поэтому позволяет осуществить обмен запросом и ответом всего в двух пакетах. Это возможно при условии, что пакет не превышает размер MTU (Maximum Transmission Unit), используемый в данной сети на канальном уровне. Но тогда функция обнаружения ошибок должна быть встроена в приложение. Как минимум это означает включение подтверждений, тайм-аутов и механизма повторных передач. Если запросы и ответы имеют разумный размер, то управление потоком бывает не существенно для обеспечения надежности.
UDP не следует использовать для передачи большого количества данных (например, для передачи файлов). В этом случае управление потоком с помощью окна, предотвращение переполнения и медленный старт должны быть встроены в приложение вместе с перечисленными выше функциями. Эти механизмы, осуществляемые отправителем, служат для определения текущей пропускной способности сети и позволяют контролировать ситуацию при ее перегрузке. Опыт, накопленный еще до того, как эти алгоритмы были реализованы в конце 80-х годов, показывает, что протоколы, не снижающие скорость передачи, усугубляют перегрузку сети.

Протокол SCTP
SCTP создает двустороннюю ассоциацию между двумя конечными точками и дает возможность работы с несколькими потоками каждой паре конечных точек, а также обеспечивает поддержку концепции многоинтерфейсного узла на транспортном уровне. Пример такой архитектуры можно видеть на рис.2.
Изначально SCTP проектировался с учетом потребностей растущего рынка IP-телефонии и предназначался, в частности, для передачи сигнальных сообщений ОКС-7 через Интернет. Серви-
сы, предоставляемые SCTP, имеют много общего с сервисами TCP и UDP. Протокол SCTP описывается в RFC 4960 [4], а введение в SCTP приводится в RFC 3286. Несмотря на принципиальную разницу
между SCTP и TCP, для приложения интерфейс «точка–точка» почти ничем не отличается от интерфейса TCP. Подобно TCP, протокол SCTP обеспечива
ет приложениям, взаимодействующим по IP-сети, транспортную службу с гарантией доставки и со-
хранением порядка следования пакетов. Протокол
унаследовал многие функции, разработанные
для TCP за последние три десятилетия, в том чис-
ле возможность контроля перегрузки и восстановления утерянных пакетов. В действительности любое приложение, работающее по протоколу TCP, можно перевести на SCTP без потери функ
циональности. Рассмотрим основные свойства протокола SCTP.
Подобно TCP, протокол SCTP предоставляет приложениям надежную передачу сообщений, упорядочение данных, управление передачей и двухстороннюю связь. Соединение по протоколу SCTP между клиентом и сервером называется ассоциацией (association), так как
это многопотоковый протокол, позволяющий задать несколько IP-адресов и один порт для каждой стороны соединения. Термин «ассоциация» используется вместо слова «соединение» намеренно, потому что соединение всегда устанавливается между двумя IP-адресами, а ассоциация означает взаимодействие двух систем, которые могут иметь по несколько адресов. Каждая из сторон ассоциации в данном контексте называется конечной точкой (endpoint). Наличие у нее нескольких IP-адресов позволяет обеспечить дополнительную устойчивость в случае отказа сети. Избыточные IP-адреса конечной точки могут соответствовать собственному соединению с поставщиком услуг сети Интернет ISP. В такой конфигурации SCTP позволит обойти проблему, возникшую на одном из адресов, благодаря переключению на другой адрес, заранее связанный с данной ассоциацией SCTP. Для сокращения задержек, вызванных переключением с первичного направления на альтернативные, используется механизм контроля работоспособности, который получил название «сердцебиение» (heartbeat). Пока идет передача данных по первичному направлению, протокол SCTP посылает пакеты контроля работоспособности на адреса, находящиеся в режиме ожидания. Протокол декларирует, что IP-адрес будет отключен, как только он достигнет порогового значения невозвращенных подтверждений о работоспособности. Подобной устойчивости можно достичь и в TCP, если воспользоваться протоколами маршрутизации. Например, BGP-соединения внутри домена (iBGP) часто используют адреса, назначаемые виртуальному интерфейсу маршрутизатора в качестве сторон соединения TCP. Протокол маршрутизации домена гарантирует использование любого доступного пути между двумя маршрутизаторами, что невозможно, если используемые адреса принадлежат интерфейсу в сети, где возникли проблемы. Функция множественной адресации SCTP позволяет узлам, а не толь-
ко маршрутизаторам, использовать аналогичный подход, причем даже с подключениями через разных провайдеров, что невозможно при использовании TCP с маршрутизацией. Выбранный подход делает сервер уязвимым, когда клиент открывает ассоциацию, но никаких данных не передает. Для такого клиента будут выделены ресурсы, которые он не использует, а неудачное стечение обстоятельств может привести к DoS-атаке со стороны неактивных клиентов. Для предотвращения подобных ситуаций в SCTP была добавлена функция автоматического закрытия ассоциаций (autoclose). Она позволяет конечной точке SCTP задавать максимальную длительность бездействия ассоциации, которая считается таковой, если по ней не передаются никакие данные ни в одном направлении. Если длительность бездействия превышает установленное ограничение, ассоциация автоматически закрывается реализацией протокола.
SCTP предоставляет разграничение отдельных записей в передаваемом потоке сообщений. В отличие от TCP, протокол SCTP ориентирован не на поток байтов, а на сообщения. Он обеспечивает упорядоченную доставку данных и сохраняет границы сообщений в пакетах приложения, размещая сообщения в одной или нескольких структурах данных SCTP, называемых «фрагментами» (chunk). Несколько сообщений могут объединяться в один фрагмент, а длинное сообщение может быть сегментировано сразу по нескольким фрагментам.
Обладая возможностью формирования не-
скольких потоков сообщений между конечными точками ассоциации, протокол SCTP позволяет контролировать для каждого из них надежность и порядок следования сообщений. Благодаря этому свойству устраняется возможная блокировка линии типа head-of-line, присущая протоколу TCP, так как утрата сообщения в одном из потоков не блокирует доставку сообщений по другим. Этот подход прямо противоположен тому, что имеется в TCP, где потеря единственного байта блокирует доставку всех последующих байтов по соединению до тех пор, пока ситуация не будет исправлена.
С помощью SCTP приложения могут использовать различные модели доставки, в том числе строгий порядок передачи (как TCP), частичное упорядочивание (по потокам) и неупорядоченную доставку (как UDP). Это было сделано, поскольку некоторые приложения не нуждаются в сохранении порядка сообщений при передаче их по сети. Раньше приложению, использующему TCP для обеспечения надежности, приходилось мириться с задержками, вызванными блокированием очереди и необходимостью упорядоченной доставки (хотя само приложение в ней может и не нуждаться). На это стоит обратить особое внимание, так как для SCTP существует различие между надежной и упорядоченной доставкой. При работе с TCP эти два свойства неразрывно связаны, поскольку все данные надежно доставляются (например, утерянные пакеты передаются повторно) узлу-получателю и предоставляются приложению в той последовательности, в какой они передавались. Напротив, в SCTP эти свойства между собой не связаны. Номер последовательности в заголовке SCTP гарантирует, что все сообщения надежно доставляются узлу-получателю, но SCTP предусматривает ряд вариантов того, в каком порядке представлять сообщения приложению-получателю. Это может быть номер потока, применяемый для упорядочивания сообщений по потокам, или передача данных приложению по мере их появления на узле-получателе. И опять-таки этот подход позволяет устранить задержку, вызванную блокировкой вследствие неправильного порядка доставки пакетов [6]. Для восстановления утраченных пакетов используется схема выборочного подтверждения, унаследованная из TCP. Поддерживая обратную связь с отправителем, приемник SCTP сообщает, какие пакеты необходимо отсылать повторно, если они были утеряны. Благодаря сервису частичной надежности отправитель получает возможность указывать время жизни каждого сообщения. Если частичная надежность поддерживается обоими узлами, то недоставленные вовремя данные могут сбрасываться транспортным уровнем, а не приложением, даже если они были переданы и утеряны. Таким образом оптимизируется передача данных в условиях загруженных линий.
Для контроля перегрузки используются стандартные методики, впервые применявшиеся еще в TCP, в том числе медленный старт, предотвращение перегрузки и быстрая повторная передача. Приложения SCTP могут получать свою долю сетевых ресурсов, сосуществуя с приложениями TCP в одной сети.

Когда SCTP
оказывается предпочтительнее TCP?
Хотя протокол SCTP и разрабатывался для передачи сигнальных сообщений ОКС-7 через IP-сеть, в процессе разработки область его применения значительно расширилась. Фактически он превратился в общецелевой транспортный протокол. Являясь эволюционным развитием протокола TCP, SCTP поддерживает почти все его функции и значительно расширяет их новыми сервисам транспортного уровня. Эти сервисы имеют важное значение для передачи сообщений телефонной сигнализации через сеть IP и в то же время могут обеспечивать ряд преимуществ для других приложений, которым требуется надежный транспортный механизм с высоким уровнем производительности.
SCTP лишен двух особенностей TCP. Одна из них – состояние неполного закрытия соединения на своей стороне. Это состояние возникает, когда приложение закрывает свой конец соединения, но разрешает встречной стороне отправлять данные и принимает их. Приложение входит в это состояние для того, чтобы сообщить собеседнику, что отправка данных завершена. Приложения очень редко используют эту возможность, поэтому при разработке SCTP решено было не заботиться о ее поддержке. Также не поддерживается обработка внеочередных данных (urgent data). Для доставки срочных данных в SCTP можно использовать отдельный поток, хотя это и не позволяет в точности воспроизвести поведение TCP в данной ситуации.
Протокол SCTP обеспечивает явную поддержку многоинтерфейсных узлов (см. рис.2), что позволяет значительно повысить уровень надежности ассоциации и уменьшить задержки, возникающие в случае отказа в доступе или сбоев в магистральной сети. Но при этом действующая редакция протокола SCTP [4] не поддерживает распределение нагрузки (load sharing) на альтернативные направления, поэтому данная возможность лишь обеспечивает избыточность направлений передачи для повышения уровня надежности. В IETF сейчас ведутся работы в данном направлении, и документ, имеющий версию 7 и статус экспериментального, был принят в октябре 2013 года [5].
Наконец, TCP-узлы восприимчивы к атакам типа «отказ в обслуживании» DoS (Denial of Service), что вызвано несовершенством механизма установления соединения в TCP, получившего название троекратного рукопожатия (three-way handshake). Для таких атак характерны своего рода «штормы», огромное количество пакетов TCP SYN, сигнализирующих ничего не подозревающему хосту о том, что отправитель хочет установить с ним TCP-соединение. Хост-получатель резервирует память и отвечает на запрос сообщениями SYN ACK. Когда атакующая система не возвращает сообщения ACK, необходимые для завершения троекратной процедуры установки TCP-соединения, ресурсы хоста, подвергнувшегося атаке, остаются не освобожденными. Поэтому он оказывается не готов к обслуживанию легитимных запросов на установку TCP-соединения. При разработке SCTP этот недостаток был устранен в механизме четырехкратного рукопожатия – сервер резервирует необходимые ресурсы только после прохождения процедуры cookie.

Сравнение возможностей протоколов
Результаты анализа, который был проведен в данной статье, приведены в таблице.
В заключение можно сделать ряд выводов.
Протокол UDP не обеспечивает надежность доставки и не имеет никаких механизмов подтверждения передачи. Однако существуют приложения, в которых UDP использовать целесообразнее, чем TCP или SCTP. Обладая высокой скоростью передачи и простотой реализации, UDP идеально подходит для многоадресного трафика, сервисов потоковой передачи аудио- и видеоинформации, многопользовательских игр в реаль-
ном времени и некоторых протоколов сигнализации, использующихся в сетях VoIP. При реализации механизмов повышения надежности на уровне приложения, эта задача может решаться на канальном уровне, компенсируя недостатки протокола за счет создания избыточной полосы пропускания. Уже сейчас на уровне доступа по медным и оптическим линиям связи можно использовать каналы со скоростью до 10 Гбит/с, что казалось фантастикой во времена разработки первых протоколов транспортного уровня.
В отличие от UDP, TCP – более сложный в реализации потоковый протокол, обладающий рядом недостатков, которые мы рассмотрели выше. Как и TCP, SCTP обеспечивает надежность передачи, но помимо этого он позволяет задавать границы сообщений, обеспечивает поддержку множественной адресации на транспортном уровне и предлагает расширенные возможности этого уровня, выходящие за рамки тех, которые могут сейчас предоставить TCP и UDP. Многие функции TCP поддерживаются и в SCTP: уведомление о приеме, повторная передача утерянных данных, сохранение последовательности данных, оконное управление передачей, медленный старт и алгоритмы предотвращения перегрузки, а также выборочные уведомления. Протокол SCTP позволяет приложению настраивать транспортный уровень по своим потребностям, причем настройка выполняется для каждой ассоциации в отдельности. Эта гибкость в сочетании с универсальным набором значений по умолчанию (для приложений, не нуждающихся в тонкой настройке транспортного уровня) дает приложению преимущества, которые оно не могло получить при работе с TCP. Протокол SCTP активно внедряется на сетях связи в более широкой области, чем та, для которой он создавался, но, по причине пассивности разработчиков приложений и операционных систем, не теми темпами, на которые рассчитывали его создатели.

Литература
1. Гольдштейн А.Б., Гольдштейн Б.С. Softswitch. – СПб.: БХВ-Санкт-Петербург, 2006.
2. Postel J. User datagram protocol, STD 6, RFC 768, August 1980.
3. Postel J., ed. Transmission control protocol – DARPA Internet program protocol specification, RFC 793, USC/Information Sciences Institute, September 1981.
4. Stewart R. Stream control transmission protocol, RFC 4960, September 2007.
5. Amer P., Becke M., Dreibholz T. Load sharing for the stream control transmission protocol (SCTP), October 07, 2013.
6. Стивенс У.Р., Феннер Б., Рудофф Э.М. UNIX: разработка сетевых приложений. 3-е изд. – СПб.: Питер, 2007.
7. Стюарт Р., Метц К. SCTP. Новый транспортный протокол для TCP/IP. – Открытые системы, 2002, №2.

Тестирование TCP, UDP-трафика в сети Wi-Fi 802.11n/ac

Введение

Стандарт IEEE 802.11n появился еще в «далеком» 2009 году и ключевыми технологиями, которые позволили перевалить за 100 Мбит/сек были OFDM (мультиплексирование с ортогональным частотным разделением каналов) и MIMO (использование множества антенн на прием и антенн на передачу) – эти технологии и составляли физический уровень рассматриваемого Wi-Fi подстандарта. Максимальную скорость передачи данных физический уровень Wi-Fi мог обеспечить в 540 Мбит/сек, для этого необходимо было использовать кодирование MCS 64 и пространственное разделение потоков по схеме MIMO 4×4 (4 антенны на прием и 4 на передачу), а также увеличенную ширину канала до 40 МГц (вместо стандартной ширины в 20 МГц). MCS 64 реализуется посредством использования 64 QAM-модуляции и двоичного свёрточного кода BCC с скоростью кодирования с отношением 5/6.

Тем не менее, максимальная скорость передачи данных коммерческого высокопроизводительного оборудования 802.11n не превышала 450 Мбит/сек.  Отдельное внимание следует обратить на то, что большинство устройств 802.11n были реализованы с использованием не более 3-х антенн, это делалось с целью миниатюризации и уменьшения энергопотребления. Также отметим, что до появления стандарта 802.11ac обслуживание каждого беспроводного устройства в Wi-Fi сети производилось поочередно, а не одновременно.

В связи с требованиями рынка и необходимостью организации многопотоковой передачи данных большому количеству пользователей от Wi-Fi точки доступа, в 2010 году была создана рабочая группа, отвечающая за разработку стандарта 802.11ac, которая должна была обеспечить «плавный переход» от стандарта 802.11n. Результат работы группы был продемонстрирован в июне 2012 года с максимальной скоростью передачи данных до 6933.3 Мбит/сек при работе с MCS9 (256 QAM модуляция и BCC с R=5/6) при этом ширина канала передачи увеличена еще до 160 МГц и защитный интервал в 400 наносекунд, а максимальное количество пространственных потоков MIMO – 8.

В 2015 году количество сетевых устройств, работающих в соответствии со спецификацией 802.11ac, перевалило за миллион. В этой статье мы сравним скорости передачи данных беспроводного оборудования 802.11n и 802.11ac, работающего в сетях IPv4 и IPv6. Если у вас возникают вопросы, зачем сравнивать скорость в сетях IPv6, то ответ последует следующий: во-первых, переход на IPv6 неизбежен из-за нехватки IP-адресов, а, во-вторых, IPv4-протокол имеет меньшую пропускную способность для TCP/UDP-трафика по сравнению с IPv6 для всех операционных систем.

Схема тестирования

Схема, в которой будет проверяться скорость передачи данных в Wi-Fi сети, изображена на рисунке 1.

Рисунок 1 – Схема исследуемой Wi-Fi сети

Схема состоит из двух компьютеров (конфигурация: Intel Core i5 Quad Core 760 с частотой процессора 2.8 ГГц, 8 Гб оперативной памяти DDR3, жесткий диск на 500 Гб (Western Digital), ОС Windows 7 SP1 64 бит). На ПК установлен беспроводной двухдиапазонный адаптер ASUS PCE-AC66 802.11ac, а в качестве точки доступа в эксперименте используется Linksys EA6500, а также двухдиапазонный с поддержкой 802.11ac. Внешний вид устройств указан на рисунке 2.

Рисунок 2 – Внешний вид ASUS PCE-AC66 (слева) и роутера  Linksys EA6500 (справа)

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

Суть эксперимента: компьютерам был присвоен статический IP-адрес IPv4 для тестирования работы в режиме IEEE 802.11n (диапазон 2.4 и 5 ГГц) и в режиме IEEE 802.11ac. Далее IP адрес изменятся на формат IPv6, а все остальные параметры остаются без изменения.

Отдельно следует сказать о конфигурации точки доступа:

Linksys EA6500 поддерживает следующие протоколы безопасности: WEP, WPA Personal, WPA Enterprise, WPA2 Personal, WPA2 Enterprise, и смешанный персональный WPA2/WPA. Но, как известно, применение шифрования сети снижает ее пропускную способность, поэтому для получения максимальной пропускной способности тип шифрования не был задан (то есть тестировалась открытая сеть связи).

Ширина канала, используемая роутером, должна быть такой же, какую используют абоненты: чем выше ширина канала, тем, само собой, выше пропускная способность канала и как следствие – выше скорость передачи данных. В рассматриваемом эксперименте каждая сеть была настроена на максимально возможную ширину канала, которую позволяло дать оборудование – это 20 МГц для 802.11n для диапазона 2.4 ГГц, ширина канала 40 МГц для 802.11n в диапазоне 5 ГГц, и ширина канала 80 МГц для 802.11ac.

Теперь о выборе канала для передачи. Так как в диапазоне 2.4 и 5 ГГц работает большое количество беспроводных устройств и сетей, то их влияние на исследуемую сеть неизбежно. Вместе с тем точка доступа EA6500 имеет хороший алгоритм выбора оптимального (наименее зашумленного) канала передачи, так в диапазоне 2.4 – это каналы в частотном диапазоне от 2.412 до 2.472 ГГц и для диапазона 5 ГГц – от 5.180 до 5.240 ГГц, поэтому канал для передачи будет выбираться точкой доступа автоматически.

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

Софт для генерации трафика и измерений

В качестве софта для генерации трафика был выбран Distributed Internet Traffic Generator (D-ITG) – бесплатное программное обеспечение с открытым исходным кодом, совместим с Windows 7. Также работает под Linux-производными ОС (Ubuntu, Debian и др.) и FreeBSD. D-ITG хорошо зарекомендовал себя в тестировании трафика на беспроводных локальных сетях, включая DNS, Telnet и VoIP.

Результаты

Все измерения, приведенные выше, были проведены для пакетов разной длины от 128 до 524288 байт (точные значения: 128, 512, 2048, 8192, 32768, 131072, 524288 байт). В первом эксперименте измерялась пропускная способность TCP и UDP трафика. На втором – измерялся джиттер (jitter – дрожание) TCP и UDP трафика. На третьем шаге измерялась задержка перечисленных протоколов в сети.

Все тесты оценки эффективности производились в течение 20 секунд. Для обеспечения необходимой точности измерений каждый размер пакета передавался по 3 раза, в отчет шло среднее значений по результатам трех измерений.

Теоретически 802.11ac расширил пропускную способность по сравнению с 802.11n за счет более большего числа пространственных потоков MIMO, с поддержкой многопользовательской MIMO, а также за счет увеличения ширины канала с 40 МГц (режим N) до 80 МГц (режим AC).

Рисунок 3 – Пропускная способность UDP-трафика

Как показано на рисунке 3, режим AC IPv6 достиг наивысшей скорости передачи данных в 120 Мбит/сек. Отдельно отметим, что режим N IPv6 (2.4 ГГц) более чем в 2 раза медленнее, чем в режиме AC IPv6. На рассматриваемом графике самая большая разница между самой высокой точкой для 802.11ac IPv6 и самой низкой для 802.11n 2.4 была замечена для пакета 524288 байт, здесь AC IPv6 обеспечивает скорость на 148.8% выше, чем N 2.4 IPv6 (разница на 73.8 Мбит/сек).

Рисунок 4 – Пропускная способность TCP трафика

Пропускная способность TCP трафика довольно сильно отличается от пропускной способности UDP, как показано на рисунке 4, 802.11n 5,0 ГГц IPv6 достигала наивысшего значения скорость передачи данных всего в 47 Мб/с. Как правило, разница в пропускной способности между наибольшим и наименьшим значением около 10 Mб/сек, согласитесь, не такое уж и большое число.

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

В отличие от IPv6, в заголовке которого содержится специальное поле, анализируя которое маршрутизаторы могут сразу анализировать пакет. Таким образом, это позволяет значительно снизить джиттер в IPv6 по сравнению с IPv4. Это и подтверждается экспериментальными данными на рисунке ниже, джиттер для IPv6 был относительно меньше, чем в IPv4.

Рисунок 5 – Джиттер TCP трафика

По тем же самым причинам на графиках рисунка 6 IPv6 N и AC имеют меньший джиттер и для UDP трафика. На рисунке 6 джиттер N 5.0 IPv6 на 70% (0.002989 секунд) меньше, чем N 2.4 IPv6 для UDP трафика для размера пакета 524288 байт.

Рисунок 6 – Джиттер UDP – трафика

На рисунке 7 представлена задержка TCP трафика для всех экспериментальных схем. N 5,0 v6 имеет самую низкую суммарную задержку пакетов, а 802.11ac IPv4 имеет относительно высокую задержку для большинства размеров рассматриваемых пакетов. В целом отметим, что режим IPv6 имеет более низкую задержку, чем IPv4.

Рисунок 7 – Задержка TCP трафика

На рисунке 8 представлена задержка UDP трафика. В принципе, заключения, сделанные для задержки TCP трафика, справедливы и для UDP. Отметим, что 802.11n 5.0 IPv4 имеет самый высокий уровень задержек в рассматриваемых экспериментах.

Рисунок 8 – Задержка UDP трафика

Заключение

В этом небольшом эксперименте был произведен анализ производительности IEEE 802.11ac и IEEE 802.11n сетей, тестирование было произведено на основе эмпирической модели. Измерялась скорость, задержка и джиттер TCP, UDP трафика. По результатам экспериментов мы можем сделать следующие выводы:

• Естественно 802.11ac имеет более высокую пропускную способность по сравнению с 802.11n как в IPv4, так и в IPv6 сетях. Пропускная способность UDP трафика всегда выше, чем TCP. Скорость передачи UDP в 802.11ac примерно на 148% выше, чем 802.11n на частоте 2.4 ГГц.
• Самая высокая пропускная способность беспроводного канала была получена в режиме IEEE 802.11ac IPv6 для UDP трафика и составила 123 Мб / сек.
• Режимы 802.11ac и 802.11n для сети IPv6 имеют относительно низкое значение джиттера пакета по сравнению с IPv4 сети.
• Режимы 802.11ac и 802.11n для сети IPv6 имеет более низкую задержку по сравнению с IPv4 сетью, при передачи TCP / UDP трафика.

Протокол UDP и UDP-дейтаграммы | Компьютерные сети

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

Рис. 1 Работа протокола UDP на хосте-отправителе

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

Заголовок UDP состоит из четырех 2-байтных полей:

• номер UDP-порта отправителя;
• номер UDP-порта получателя;
• контрольная сумма;
• длина дейтаграммы.

Далее приведен пример заголовка UDP с заполненными полями:

Source Port — 0x0035

Destination Port — 0x0411

Total length — 132 (0x84) bytes

Checksum = 0x5333

В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 — 8) байт, помещено сообщение DNS-сервера, что можно видеть по номеру порта источника (Source Port = 0—0035). В шестнадцатеричном формате это значение равно стандартному номеру порта DNS-сервера — 53.

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

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

Насколько большим может быть пакет?

Сегодня я разместил свой новый сетевой журнал в Интернете! Я очень
взволнован по этому поводу. Если вы заинтересованы в нетворкинге, но не совсем
знаете, как все это сочетается, вы могли бы взглянуть!

Сегодня поговорим о размерах пакетов.

UDP

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

Здесь есть одна интересная особенность: когда вы отправляете UDP-пакет, вы
нужно решить, сколько информации поместить в пакет.16-1, или от 0 до 65535.

Итак, у меня может быть UDP-пакет размером 65535 байт, верно?

Что ж, получается, что если вы отправляете UDP-пакет размером 30 000 байт на
Интернет, вероятно, не дойдет. Почему нет? Это из-за
Ethernet!

Meet: размеры фреймов Ethernet и MTU

Когда вы отправляете пакет на другой компьютер в Интернете, он должен
пройти через кучу кабелей. Некоторые из них представляют собой кабели Ethernet.

Каждый пакет находится в кадре Ethernet.Кадры Ethernet могут содержать только 1500 байтов данных. Это называется
«Максимальная единица передачи» или «MTU»!

Итак, если я попытаюсь отправить пакет UDP 30 000, используя протокол Ethernet с
MTU 1500 байт, что произойдет? Мы не можем отправить 30 000 байт в
1500 байт. Не работает.

Таким образом, произойдет одно из двух: либо пакет потеряет
(не отправляется вообще) или фрагментировано .

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

Иногда сетевые реализации разделяют пакеты на несколько
шт.Итак, если у вас есть пакет размером 15000 байт, вы можете разделить его
до 10 или около того пакетов по 1500 байт.

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

Мне кажется более странным разделить UDP-пакет — если я отправляю вам большой UDP-пакет
и он фрагментируется, как мне его собрать? Что, если части, которые
расстались вышли из строя? Кто-то в Твиттере сказал мне, что вы можете собрать
UDP-пакеты, но я еще не знаю, как это работает.

Я все еще не понимаю, как работает фрагментация пакетов и
в каких случаях это приводит к потере пакетов. (фрагментация хуже для TCP
пакеты или UDP пакеты?)

Как определить свой MTU?

Что делать, если вы хотите знать, какое значение MTU находится между двумя точками?

Оказывается, можно использовать штуку под названием Path MTU.
Открытие. я нашел
это можно сделать, прочитав статью в Википедии как обычно. В основном вы

• отправить большой пакет с пометкой «Никогда не фрагментируйте это!»
• в первой точке, где этот пакет будет фрагментирован, он заметит
  и отправьте обратно ICMP-пакет, в котором говорится, что пакет фрагментирован
  (Пакеты ICMP — это то, что маршрутизаторы используют для отправки подобной метаинформации)
• успехов! Теперь вы знаете первую точку, в которой пакет будет
  фрагментирован!

Оказывается, в Linux есть инструмент, который это сделает, который называется
трассировка .

  $ tracepath google.com
1 ?: [LOCALHOST] pmtu 1500
1: OpenWrt.lan 1,705 мс
1: OpenWrt.lan 1.973 мс
2: 10.252.42.193 9.116 мс
3: 10.170.192.58 8.046 мс
asymm 4
  

Я думаю, что MTU в моей локальной сети составляет 1500 байт. Что имеет смысл, я
Угадай! Моя локальная сеть в норме.

Дэвид Мюррей рассказал о Path MTU Discovery на Papers We Love
Сиэтл, который выглядит довольно интересно.

jumbo-кадров

Иногда вы можете отправлять огромные пакеты! В целом в Интернете
вы не можете рассчитывать на отправку пакетов размером более 1500 байт, но если вы
владеете всем центром обработки данных и всей сетевой инфраструктурой? Почему
нет!

Более новые версии Ethernet поддерживают «jumbo-кадры», что означает, что вы
может отправлять большие пакеты.

Эта документация о MTU внутри AW действительно интересна, если вы запускаете экземпляры AW и задаетесь вопросом, как все это применимо к AWS.

это все

Наверное, я где-то тут что-то ошибся. Я думаю факт
что есть эти ограничения на размер пакетов в Интернете — это супер
интересно! Я нашел статьи в Википедии по этой теме довольно удобочитаемыми.

tcpip — Как MTU составляет 65535 в UDP, но Ethernet не позволяет размер кадра более 1500 байт

UDP ничего не знает о MTU. Пакеты UDP могут иметь любой размер от 8 до 65535 байт. Уровни протокола ниже UDP могут либо отправить пакет определенного размера, либо отклонить отправку этого пакета с ошибкой, если он слишком большой.

Уровень ниже UDP обычно IP, IPv4 или IPv6. И IP-пакет может иметь любой размер от 20 (IPv4) / 40 (IPv6) до 65535 байт, что соответствует максимальному размеру UDP. Однако IP поддерживает механизм, называемый фрагментацией . Если размер IP-пакета превышает размер, который может транспортировать нижележащий уровень, IP может разбить один пакет на несколько пакетов, называемых фрагментами. Каждый фрагмент фактически является собственным IP-пакетом (имеет собственный IP-заголовок) и также отправляется отдельно по назначению; тогда задача места назначения — собрать все фрагменты и заново построить из них полный пакет перед передачей полученных данных на следующий более высокий уровень (например,грамм. UDP).

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

Обычно следует избегать фрагментации, так как

• — это пустая трата ресурсов на стороне отправителя.
• он тратит ресурсы на стороне получателя.
• он увеличивает накладные расходы протокола для того же количества данных полезной нагрузки.
• : при потере одного фрагмента теряется весь пакет.
• : если поврежден один фрагмент, поврежден весь пакет.
• : в случае повторной отправки все фрагменты должны быть отправлены повторно.

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

Для UDP, однако, это будет задачей самого приложения, поскольку UDP — это «тупой» протокол, у него нет собственной логики управления, что делает его очень гибким, быстрым и простым.

Единственный размер UDP, на который вы можете положиться, чтобы быть всегда переносимым, составляет 576 минус 8 байтов UDP-заголовка и минус 20 (v4) / 40 (v6) байтов IP-заголовка, поскольку стандарт IP требует, чтобы каждый IP-хост мог получать IP-пакеты. с общим размером 576 байт.Реализация вашего протокола не будет соответствовать стандарту, если она не может принимать пакеты, по крайней мере, такого размера. Однако обратите внимание, что в стандарте не указано 576 без фрагментации, поэтому даже 576-байтовый IP-пакет может быть фрагментирован между двумя хостами.

Единственный размер пакета, который вы можете передать без фрагментации, составляет 24 байта для IPv4 и 56 байтов IPv6, так как наименьшие заголовки IP для фрагмента составляют 20/48 байтов (v4 / v6), а фрагмент должен иметь не менее 4 / Данные полезной нагрузки 8 байтов (v4 / v6).Таким образом, транспортная система ниже уровня IP, которая не может транспортировать, по крайней мере, пакеты такого размера, не может использоваться для транспортировки IP-трафика.

И прежде чем кто-либо прокомментирует, что заголовок IPv6 имеет только 40 байтов: это правильно, но, в отличие от заголовка IPv4, стандартный заголовок IPv6 не имеет полей заголовка для фрагментации. Если пакет должен быть фрагментирован, то заголовок расширения фрагментации должен быть добавлен под базовым заголовком IPv6, и этот заголовок расширения имеет длину 8 байтов. Также, в отличие от IPv4, смещения фрагментации в IPv6 подсчитываются по 8 байтов, а не по 4 байта, поэтому в случае IPv6 фрагмент может нести полезную нагрузку, кратную 8 байтам.

Какой самый большой безопасный размер UDP-пакета в Интернете?

Этот вопрос, в частности слово «безопасный», несколько неоднозначен. Первоначальный запросчик пояснил, что их намерение состояло в том, чтобы запросить наибольший размер пакета UDP, который можно использовать без фрагментации IP. Это связано с двумя соображениями: фрагментация IP-кадров на пути через Интернет и способность хостов на обоих концах успешно дефрагментировать.

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

Самая большая дейтаграмма IPv4, которая гарантированно никогда не подвергнется фрагментации, очень мала — из RFC 791:

Каждый интернет-модуль должен иметь возможность пересылать датаграмму из 68 октетов без дальнейшей фрагментации. Это связано с тем, что интернет-заголовок может иметь длину до 60 октетов, а минимальный фрагмент — 8 октетов.

IPv6 более требователен и требует, чтобы каждый канал поддерживал MTU не менее 1280 октетов; маршрутизаторы могут свободно использовать ссылки с физически меньшими MTU, но должны повторно собрать любые фрагменты перед повторной пересылкой полного кадра IPv6.

Однако маловероятно, что какой-либо путь через Интернет попадет в канал с таким низким значением MTU. Обычно можно ожидать, что физические ссылки, используемые в общедоступном Интернете, будут иметь MTU в 1500 октетов. Это значение является MTU по умолчанию для 802.3 Ethernet, хотя существуют расширения для поддержки гораздо больших MTU, например 9000 октетов (так называемые jumbo-кадры). Однако способ, которым IP фактически передается по таким каналам, часто включает туннели различных типов, такие как VLAN, MPLS и VPN; все они добавляют небольшие накладные расходы к каждому пакету, поэтому MTU часто составляет от 4 до 12 или более октетов меньше 1500.

На практике единственный надежный способ определить MTU для пути — использовать обнаружение MTU; это достаточно сложная тема сама по себе, и мы не будем здесь ее обсуждать.

Сборка:

В IPv4 узлы должны иметь возможность повторно собирать IP-кадры длиной до 576 октетов; в IPv6 минимум такой же, как и минимальный MTU, равный 1280 октетам. На практике большинство хостов могут повторно собирать IP-кадры гораздо большего размера.

Итак, чтобы ответить на вопрос, «безопасным» размером UDP-пакета будет такой, который позволит избежать любой фрагментации; К сожалению, это просто невозможно в IPv4, поскольку любой UDP-пакет с полезной нагрузкой потенциально может быть фрагментирован — очень маловероятно, но возможно.Учитывая это, PMTUD (определение MTU пути) — лучший способ минимизировать вероятность фрагментации. Даже это может привести к фрагментации, если обновления маршрутизации изменят путь, чтобы включить ссылку с меньшим MTU. Таким образом, «безопасный» можно интерпретировать как «гарантированно возможность повторной сборки в случае фрагментации», на что ответ 576 для IPv4 и 1280 для IPv6.

Размер полезной нагрузки UDP для сообщений DNS

Размер полезной нагрузки UDP для сообщений DNS

Размер полезной нагрузки UDP для сообщений DNS
draft-madi-dnsop-udp4dns-00

Классическая полезная нагрузка UDP размером 512 байт для передачи сообщений DNS является встроенной зависимостью от IPv4.Поскольку инфраструктура Интернета развивается до IPv6, само ограничение, проистекающее из IPv4, может быть снято на основании того, что IPv6 требует MTU в 1280 байтов. Этот документ определяет новый минимальный размер пакета UDP для передачи сообщения DNS, что делает реализации DNS в будущем более адаптивными как для приложений, основанных на Интернете, так и для инфраструктур, поддерживающих Интернет.

Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.

Internet-Drafts являются рабочими документами Инженерной группы Интернета (IETF).Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов находится на http://datatracker.ietf.org/drafts/current/.

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

Срок действия этого Интернет-проекта истекает 29 февраля 2016 года.

Авторские права (c) 2015 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

Этот документ регулируется BCP 78 и Правовыми положениями IETF Trust, касающимися документов IETF (http://trustee.ietf.org/license-info), действующими на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать упрощенный текст лицензии BSD, как описано в разделе 4.e Правовых положений Trust и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

С годами размер ответного сообщения DNS увеличился за пределы MTU IPv4, отчасти потому, что DNS-серверы, поддерживающие DNSSEC, будут автоматически пытаться возвращать ресурсы KEY в качестве дополнительной информации вместе с фактически запрошенными записями ресурсов [RFC2535]. Записи IPv6 также увеличивают размер ответа, наряду с NAPTR и другими типами записей.Другие новые функции, добавленные в DNS, также могут принести больше данных в ответы DNS в ближайшие дни.

Классическая полезная нагрузка UDP размером 512 байт для передачи сообщений DNS является встроенной зависимостью от IPv4. Поскольку инфраструктура Интернета развивается до IPv6 [ipv6-info], само ограничение, проистекающее из IPv4, может быть снято на основании того, что IPv6 требует MTU в 1280 байтов. Больший минимальный размер PDU DNS был бы более адаптивным к изменяющейся эволюции инфраструктуры и отражал бы эволюционирующий характер передачи IP.

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

В этом разделе явно указывается новый минимальный размер пакета UDP для сообщений DNS, обновляя ограничение 512-UDP.

1232 байта — это минимальный размер полезной нагрузки UDP для сообщений DNS в соответствии со спецификациями IPv6 MTU. То есть, в дополнение к 40-байтовому заголовку IPv6 и 8-байтовому заголовку UDP, минимальная пропускная способность, которую пакет IPv6 предлагает для прикладного уровня, составляет 1232 байта.

На основе этого усовершенствования обмены сообщениями DNS будут обладать большей емкостью блока данных протокола, уменьшая количество IP-пакетов, что объясняет некоторое увеличение уровня трафика, обрабатываемого промежуточными устройствами на пути запроса DNS / обмены ответами. Программное обеспечение DNS и промежуточные устройства должны поддерживать 1232 байта в качестве минимального размера полезной нагрузки UDP для сообщений DNS.

В этом разделе рассматриваются некоторые проблемы совместимости, связанные с новым минимальным размером полезной нагрузки UDP для сообщений DNS.Однако решения этих проблем выходят за рамки этого документа.

IPv4 будет сосуществовать с IPv6 долгое время. Это предложение ДОЛЖНО хорошо работать с инфраструктурой IPv4, связанной с обработкой пакетов промежуточными устройствами и MTU на рассматриваемом пути. Как и ожидалось, несоответствующие сети будут воспринимать 1232 байта как аномалию.

Некоторые наблюдения, описанные в приложении, показывают, что 1232 байта будут безопасным минимальным размером полезной нагрузки UDP для сообщений DNS в средах IPv4.

Встроенная зависимость от IPv4 MTU, классическая 512-байтовая полезная нагрузка UDP для передачи сообщений DNS связана с некоторыми реализациями DNS. Таким образом, отказ от классической 512-байтовой полезной нагрузки UDP привел бы к некоторой несовместимости. При обмене прайминга, среди прочего, могут возникнуть некоторые проблемы. Первичный обмен теперь выполняется с предположением, что весь ответ DNS должен соответствовать классической 512-байтовой полезной нагрузке UDP. Учитывая, что корневой сервер имеет двойной стек и принимает запросы на инициализацию на основе 1232-байтовых полезных данных UDP, классическая реализация DNS МОЖЕТ рассматривать этот тип пакета как аномалию, которую следует игнорировать, или ей нужно знать, как обрезать сообщение, чтобы получить запрос DNS или ему необходимо согласовывать с рекурсивными серверами, чтобы каким-то образом повторно инициировать сам процесс.

TBD

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

Для проведения самих тестов на MTU сообщения DNS клиент и сервер реализованы на Python и Erlang. Для сравнения, клиент запрограммирован на отправку как несемантически UDP-пакетов, так и DNS-пакетов без индикатора EDNS0 соответственно. Полезная нагрузка UDP для всех отправленных пакетов рассчитана на более 512 байт и отправляется все большего размера с переменными байтами, например, 32 или 16, в качестве шага.В то время как функциональность самого сервера заключается в том, чтобы прослушивать 53 порта и 5333 порт (кроме традиционного порта DNS) и пересылать полученные пакеты клиенту. Таким образом, соответствующий клиент может знать, могут ли его отправленные пакеты перемещаться по сети на сервер.

Два сервера развернуты в Пекине, один вышестоящий ISP — это сеть China Science & Technology, а другой — China Unicom. Чтобы добиться разнообразия, клиенты размещены в ZDNS в Пекине, TWNIC в Тайбэе, местном интернет-провайдере в Чэнду, China Mobile в Пекине, TCI в Москве и JPRS в Токио.Тесты проводились в соответствии с комбинацией серверов и клиентов.

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

Как правило, межсетевые экраны блокируют сообщения DNS, которые приводят к фрагментации IP-адресов.

Йоширо ЙОНЕЯ, JPRS

Най-Вен HSU, TWNIC

КОВАЛЕНКО Дмитрий, ТЦИНЕТ

 Linux% sock -u -i -n1 -w1471 10.0.0.3 отказаться
Linux% sock -u -i -n1 -w1472 10.0.0.3 отказаться
Linux% sock -u -i -n1 -w1473 10.0.0.3 отказаться
Linux% sock -u -i -n1 -w1474 10.0.0.3 отказаться
 

 1 23: 42: 43.562452 10.0.0.5.46530> 10.0.0.3.9:
        udp 1471 (DF) (ttl 64, id 61350, len 1499)
2 23: 42: 50.267424 10.0.0.5.46531> 10.0.0.3.9:
        UDP 1472 (DF) (TTL 64, ID 62020, Len 1500)
3 23: 42: 57.814555 10.0.0.5> 10.0.0.3:
        udp (frag 37671: [защита электронной почты]) (ttl 64, len 21)
4 23: 42: 57.814715 10.0.0.5.46532> 10.0.0.3.9:
        UDP 1473 (фрагмент 37671: [защита электронной почты] +) (ttl 64, len 1500)
5 23: 43: 04.368677 10.0.0.5> 10.0.0.3:
        udp (frag 37672: [электронная почта защищена]) (ttl 64, len 22)
6 23: 43: 04.368838 10.0.0.5.46535> 10.0.0.3.9:
        UDP 1474 (фрагмент 37672: [защита электронной почты] +) (ttl 64, len 1500)
 

  импорт IN, socket, sys
s = socket.socket (socket.AF_INET, socket.SOCK_DGRAM)
МАКС = 65535
ПОРТ = 1060
если len (sys.argv)! = 2:
  print >> sys.stderr, 'usage: big_sender.py host'
  sys.exit (2)
hostname = sys.argv [1]
s.connect ((имя хоста, ПОРТ))
s.setsockopt (socket.IPPROTO_IP, IN.IP_MTU_DISCOVER, IN.IP_PMTUDISC_DO)
пытаться:
  s.send ('#' * 65000)
кроме socket.error:
  print 'Сообщение не дошло'
  option = getattr (IN; 'IP_MTU'; 14)
  напечатайте 'MTU:', s.getsockopt (socket.IPPROTO_IP, параметр)
еще:
  print 'Большое сообщение отправлено! Ваша сеть поддерживает действительно большие пакеты! '
  

  [электронная почта защищена]: ~ / Python_files # python big_sender.py 127.0.0.0
Сообщение не дошло
MTU: 1500