Как сделать задержку отправки пакетов
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Популярное и похожее
Курс по Asterisk
Рассказываем про FXO и FXS
DHCP: Опция 150 и 66
VoIP кодеки – подробное описание и характеристики
Описание протокола SIP
BRI (basic rate interface)
Версус: сравнение виртуальной и офисной АТС
Что такое 3CX Phone System?
Еженедельный дайджест
QoS в сетях
Качество обслуживания в Enterprise
Современные IP сети должны обеспечивать надежную передачу пакетов сети VoIP и других важных служб. Эти сервисы должны обеспечивать безопасную передачу, определенную долю предсказуемости поведения трафика на ключевых узлах и конечно гарантированный уровень доставки пакетов. Сетевые администраторы и инженеры обеспечивают гарантированную доставку пакетов путем изменения параметров задержки, джиттера, резервирования полосы пропускания и контроля за потерей пакетов с помощью Quality Of Service (QoS).
Размер полосы пропускания
где A – доступная полоса пропускания, Bmax – максимальная полоса пропускания, а F – количество потоков. Наиболее правильным методом при расчете пропускной способности является расчет с запасом в 10-20% от расчетной величины. Однако, увеличение пропускной способности вызывает удорожание всей сети и занимает много времени на осуществление. Но современные механизмы QoS могут быть использованы для эффективного и оптимального увеличения доступной пропускной способности для приоритетных приложений.
С помощью метода классификации трафика, алгоритм QoS может отдавать приоритет вызову в зависимости от важности, будь то голос или критически важные для бизнеса приложения. Алгоритмы QoS подразумевают предоставление эффективной полосы пропускания согласно требованиям подобных приложений; голосовой трафик должен получать приоритет отправки. Перечислим механизмы Cisco IOS для обеспечения необходимой полосы пропускания:
Другой алгоритм эффективного использования канала передачи это компрессия заголовков. Сжатие заголовков особенно эффективно в тех сетях, где большинство пакетов имеют маленькое количество информационной нагрузки. Другими словами, если отношение вида (Полезная нагрузка)/(Размер заголовка) мало, то сжатие заголовков будет очень эффективно. Типичным примером компрессии заголовков может стать сжатие TCP и Real-time Transport Protocol (RTP) заголовков.
Задержка пакетов из конца в конец и джиттер
Рисунок ниже иллюстрирует воздействие сети передачи на такие параметры как задержка пакетов проходящих из одной части сетевого сегмента в другой. Кроме того, если задержка между пакетом с номером i и i + 1 есть величина, не равная нулю, то в добавок к задержке «end-to-end» возникает джиттер. Потеря пакетов в сети при передаче трафика происходит не по причине наличия джиттера, но важно понимать, что его высокое значение может привести к пробелам в телефонном разговоре. Каждый из узлов в сети вносит свою роль в общую задержку:
Рассмотрим пример, в котором маршрутизаторы корпоративной сети находятся в Иркутске и Москве, и каждый подключен через WAN каналом передачи 128 кбит/с. Расстояние между городами около 5000 км, что означает, что задержка распространения сигнала по оптическому волокну составит примерно 40 мс. Заказчик отправляет голосовой фрейм размером 66 байт (528 бит). Отправка данного фрейма займет фиксированное время на сериализацию, равное:
tзс = 528/128000=0,004125с=4.125 мс.
Также, необходимо прибавить 40 мс на распространение сигнала. Тогда суммарное время задержки составит 44.125 мс. Исходя из рисунка расчет задержки будет происходить следующим способом:
Если канал передачи будет заменен на поток Е1, в таком случае, мы получим задержку серилизации, равную:
В этом случае, общая задержка передачи будет равнять 40,258 мс.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Популярное и похожее
Курс по Asterisk
Руководство по команде grep в Linux
15 примеров CURL в Linux
Рекурсивно найти слово в файлах и папках Linux
Создание и форматирование разделов жестких дисков в Linux
5 инструментов для сканирования Linux-сервера
Мониторинг пропускной способности и скорости сети в Linux
Как установить права доступа в Linux
Еженедельный дайджест
15 примеров команды PING для диагностики сети
Благодаря Linux, у нас есть очень много инструментов облегчающих администрирование и диагностику сети. В этом плане команда PING является одним из самых полезных инструментов для системных и сетевых администраторов.
Сама базовая возможность этой утилиты – определить доступен ли тот или иной хост. Тем не менее в этом материале мы приведем примеры расширенных возможностей этой команды в системе Linux.
Для чего используется команда PING?
Команда ping один из базовых инструментов для работы с сетью. Наряду с проверкой доступности удаленного хоста, эта команда даёт возможность выполнять и другие диагностические задачи в том числе:
Как видно, эта команда очень необходима для администрирования сети и серверов.
Как работает команда PING?
Принцип работы команды Ping прост: она посылает серию пакетов маленького размера на указанное устройство.
Для тестирования устройства может быть использован либо IP-адрес, либо имя хоста. После отправки пакета, утилита проверяет и измеряет время ответа целевого устройства.
Как вы могли предположить, время ответа зависит от нескольких условий в том числе географическое расположение или устройств, расположенных между источником и целевым устройством.
Например, в локальной проводной сети команда вернет лучший результат по времени, чем в сети с несколькими маршрутизаторами и сетевыми мостами.
Однако, на основе полученной информации утилита будет судить о состоянии целевого устройства.
Синтаксис команды следующий:
Ниже приведены некоторые полезные и часто используемые ключи для этой команды:
Можно ли использовать PING с прокси-сервером?
Прокси – это сервер или приложение играющее роль посредника для соединения двух хостов в сети. Это своего рода «человек посередине», который отправляет запросы прямо к хосту.
Проблема в том, что команда PING требует прямого соединения между устройствами. Таким образом, команда Ping не может функционировать если перед ним стоит прокси-сервер.
Ping IPv6 адресов
По умолчанию, когда запускаем команду PING, мы используем IP версии 4. Однако, с появлением протокола IPv6, все чаще стали встречаться адреса такого формата.
Ядро Linux поддерживает IPv6 начиная с версии 2.2, так что все дистрибутивы Linux поддерживают этот протокол.
Базовый синтаксис таков:
Как и при работе с IPv4, ключом –c можем указать число пакетов, для отправки, а ключ –i – определяет интерфейс для исходящих запросов.
Ping конкретного порта
Чтобы проверить доступность порта просто введите следующую команду:
Ping с выводом времени
Хотя команда ping дает много полезной информации, но этого может быть недостаточно. Тем не менее, есть возможность настроить команду так, чтобы она показала дату и время отправки пакета. Это может сделать вывод приятней и полезней для скриптов и логирования.
Как видно из скриншота, команда показывает дату и время отправки каждого пакета.
Ping всех устройств в указанной подсети
Командой Ping можно посылать сигнал всем хостам в сети или подсети. Для этого нужно запустить ping с ключом –b на широковещательный адрес, который заканчивается на 255. Например:
Итак, если хост назначения недоступен, значит либо там блокируются ICMP пакеты, либо есть проблемы с сетью или таблицей маршрутизации.
Как завершить команду PING?
После этого команда немедленно остановится.
Завершение работы команды по счетчику
Вы можете ограничить число посылаемых пакетов. Например, если поставить число пакетов равным 10, то после отправки указанного числа пакетов выполнение команды прекратится.
Где расположена утилита PING?
В Unix-подобных системах таких, как Linux бинарные файлы обычно располагаются по пути
В этой папке можно найти все множество бинарных файлов, которые мы используем как команды в терминале. В других ОС семейства Linux, они могут быть расположены в:
Проверить это можем командой ls :
На скриншоте видно, что команда ping находится в папке
Другой метод, которым можно найти место расположения команд это which :
На выводе она даст следующую информацию:
Проверка задержки командой PING
Одна из возможностей, предоставляемых командой PING, является возможность измерения времени отклика сети. По-другому это называется задержка или время ожидания.
Чтобы измерить задержку введи указанную команду и обратите внимание на ввыод:
Как вы могли заметить, каждый пакет был отправлен с конкретным временем ответа. В конце же есть строка, которая начинается на:
Второе значение после знака равенства – это время задержки. В нашем случае он равен 6,798.
С помощью этого показателя мы можем определить хосты, связь с которыми хуже и приять соответствующие меры.
Поиск идеального значения MTU
MTU (Maximum Transmission Unit) это максимальный размер пакета, который может быть передан по сети.
Сегодня, в целях безопасности, в сетях создаются препятствия для работы MTU. Но большинство локальных сетей на основе Ethernet использует MTU размером 1500 байт.
Если нужно найти самый подходящий размер MTU с помощью команды Ping, следует определить начальное значение и уменьшать его до тех пор, пока прекратятся ошибки. Если значение большое, мы получим следующую ошибку:
Чтобы сделать это запустите следующую команду:
В нашем случае, значение размера пакета слишком большое. Поэтому уменьшаем его до 1472 байтов.
Если получите другое сообщение, начальное значение должно быть уменьшено по единице до тех пор, пока не получите требуемый результат.
Если значение MTU известно, оно может быть использовано для улучшения сети. Особенное если сеть большая вплоть до городских сетей.
Ping на 2-ом уровне OSI (использование arping)
С помощью команды ping диагностика проводится на основе IP-адреса конкретного узла в сети. Это связано с тем, что команда ping работает на третьем сетевом уровне модели OSI.
Синтаксис команды следующий:
В результате получите что-то подобное:
Вывод команды показывает размер отправленного пакета, затем MAC адрес узла назначения, а также время ответа.
Отметим, что эта команда не предустановлена на системе Debian и производных.
Ping по имени узла
По умолчанию, команда ping посылает пакеты на узел назначения используя IP адрес или имя узла назначения. Также нужно отметить, что большинство реализаций утилиты ping на Linux не разрешают DNS в обратном направлении.
Например, если мы запустим команду ping, указав IP адрес, он вернёт только IP узла. И наоборот, если параметром передадим имя узла, то команда вернет его IP адрес. Посмотрите вывод введя команду ниже:
Ping маршрута (traceroute)
Сама по себе команда ping не показывает пути от источника к узлу назначения. Но это было бы очень кстати в том случае, когда узел назначения не отвечает, чтобы определить где именно теряется связь.
Команда tracert (Windows) или traceroute работают аналогично ping. Преимуществом этой команды является то, что он показывает весь путь следования пакета от источника до узла назначения.
В принципе traceroute посылает тот же ICMP пакет, что и Ping. Но в случае traceroute, в отличии от ping начально значение TTL пакета выставляется равным единице. Пакет доходит до первого узла по пути к узлу назначения. Устройство уменьшает TTL на одну единицу и если получается нуль, то возвращает сообщение об ошибке истечения времени пакета. В сообщение так же содержится IP адрес и имя хоста. Отправитель получает данное сообщение. Если оно не от узла назначения, то посылает второй пакет с TTL на один больше предыдущего. И так до тех пор, пока не получит ответ от узла назначения. Для получения пути нужно ввести команду:
Запустить команду если ping вернул ошибку
Представьте, что вам нужно получить оповещение если узел назначения перестал отвечать на запросы команды ping. Для этого нужно включить команду ping в bash скрипт и прописать нужные команды. Например, скрипт ниже позволяет вам проверить отвечает ли узел на запросы ping:
Установление размера пакета ping
По умолчанию, размер пакетов ICMP равен 56 байтам. Это позволяет не влиять на работу сети во время проверки. Но при необходимости можно изменять это значение. Для этого достаточно запустить команду ping с ключом –s и требуемым размером. Например:
Если нужно установить значение пакета равным 100 байтам, нужно прописать команду ниже:
Отключение команды ping
Если вы обслуживаете сеть, то вам может быть необходимо отключить ответ на ping запросы в любое время. Это можно сделать как временно, так и постоянно, в зависимости от ваших нужд. Для временного отключения команды ping нужно ввести команду ниже от имени root-а:
Она выключить возможно ответа на ICMP запросы до перезагрузки системы. Но если нужно навсегда отключить эту возможность, то придется отредактировать файл
и добавить следующую строку:
Сохраните файл и, для применения изменений введите команду:
Заключение
В этом материале мы рассмотрели, как команда ping работает в системе Linux. Ping одна из самых легких команд. Она позволяет лицам, ответственным в обеспечении нормально работы сети, выявлять проблемы и устранять их.
Полезно?
Почему?
😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.
😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.
Отправка UDP-пакетов по таймеру
Всем доброго времени суток.
Есть ли в Linux механизм, который позволил бы из userspace отдать ядру UDP-пакет и указать момент времени, в который он должен быть отправлен?
Время, когда нужно послать пакет, известно точно, но время, когда есть возможность его послать — плавает, из-за случайной задержки (
5мс) между моментом истечения таймера в ядре и моментом передачи управления потоку в userspace, который вызовет sendto().
Интересуют способы уменьшения этого джиттера. Настойщий real-time не требуется.
Есть ли в userspace варианты кроме nice, SCHED_RR, etc?
Можно попробовать использовать RAW-sockets, но тогда придётся самому формировать заголовки фреймов.
Гм, а чем тут помогут RAW-sockets?
Тут, разве что, самому в ядро лезть и реализовывать.
Ну да, но этого делать не хочется.
время, когда есть возможность его послать — плавает, из-за случайной задержки (
ну так убирайте задержку, рефакторинг вам в зубы
ну так убирайте задержку, рефакторинг вам в зубы
Так это задержка на переключение контекста, выполнение других процессов, etc.
Предлагаете сделать как-то по-другому?
Так это задержка на переключение контекста
Переключение контекста длится десятки микросекунд.
Решается выставлением планировщика реального времени и нужного приоритета.
невозможно советовать не понимания архитектуры,
а по вашему псевдокоду, достаточно убрать random delay here, ну так уберите их и задержка пропадет
Переключение контекста длится десятки микросекунд.
Решается выставлением планировщика реального времени и нужного приоритета.
по вашему псевдокоду, достаточно убрать random delay here, ну так уберите их и задержка пропадет
— это комментарий, кода там нет 🙂
все зависит от сложности приложение, если не детская поделка то делайте отдельный асинхронный треид, в котором в пуле ожидания будете держать пакеты на отправку и ихнее время, а банальным select выгребаем и отправляем
или все тоже самое, только всю архитектуру перевести на асинхронное io
или вместо nanosleep поэкспериментировать с select/poll/итд
отдельный асинхронный треид, в котором в пуле ожидания будете держать пакеты на отправку и ихнее время
или вместо nanosleep поэкспериментировать с select/poll/итд
А чем это поможет? Учитывая, что отправлять пакеты нужно не при первой возможности, а при наступлении нужного момента времени.
или все тоже самое, только всю архитектуру перевести на асинхронное io
Асинхронное io — это aio(7)? Тоже не понимаю, чем он здесь поможет, тем более что у меня итак поток.
У вас там именно nanosleep? Не пробовали clock_nanosleep?
Решается выставлением планировщика реального времени и нужного приоритета.
Осталось понять, что это единственный способ ограничить джиттер на загруженной системе.
так что ли? где queue очередь уже от
это ж насколько должна быть система прогружена?
что то мне кажется сильно надуманым
Подозреваю, что плавающая задержка у ТС где-то до вызова nanosleep, а не после.
Осталось понять, что это единственный способ ограничить джиттер на загруженной системе.
Гипотетический механизм, озвученный в топике, чем-то плох концептуально или просто не был никем реализован?
(функция вроде sendto_at(buffer, address, time))
У вас там именно nanosleep? Не пробовали clock_nanosleep?
Не пробовал, спасибо, попробую.
так что ли? где queue очередь уже от
Подозреваю, что плавающая задержка у ТС где-то до вызова nanosleep, а не после.
Я пришел к выводу, что именно после. Записываю clock_gettime() до и после nanosleep(), и аргумент nanosleep.
что то мне кажется сильно надуманым
Да, это модельная ситуация (искусственная нагрузка). Мне просто интересно, какие есть решения таких проблем о общем случае, или почему их нет.
полистайте sleep vs nanosleep
Гипотетический механизм, озвученный в топике, чем-то плох концептуально или просто не был никем реализован?
(функция вроде sendto_at(buffer, address, time))
Это не механизм, а кнопка «сделать збс».
что то мне кажется сильно надуманым
У ТС может быть хилый встроенный процессор.
Записываю clock_gettime() до и после nanosleep(), и аргумент nanosleep
разверни nanosleep под свои нужды: надо считать таймер, вычислить время когда «проснуться», взять пакет из очереди,установить таймер, уйти в wait и наконец-то отправить. Будет точнее, хотя подводных камней хренова гора.
Я имел в виду, что clockget_time() вызываю для профилировки.
Код примерно такой:
Это не механизм, а кнопка «сделать збс».
Ну, проблема ведь более-менее общая — IO, привязанный ко времени?
Я подумал, что возможно есть и какие-то решения для IO.
Спасибо, будем читать.
Ну, проблема ведь более-менее общая — IO, привязанный ко времени?
Общая, да. Для ее решения есть таймеры и вызовы IO.
Ы. Ты знаешь, что для не-RT процессов промежуток времени округляется до ближайшего такта планирования?
Я имел в виду, что clockget_time() вызываю для профилировки.
вызывай его чтобы отметить «начало» твоего таймаута в 50ms, который ставится непосредственно ПЕРЕД pop() а не после него. Так ты уйдёшь от непредсказуемых задержек (может так приоритетная очередь, или изъятие единственного элемента значительно больше типового)
Общая, да. Для ее решения есть таймеры и вызовы IO.
Ы. Ты знаешь, что для не-RT процессов промежуток времени округляется до ближайшего такта планирования?
Не понял, к чему этот вопрос. В RT ведь будет тот же sleep. Вы предлагаете использовать что-то вместо sleep?
вызывай его чтобы отметить «начало» твоего таймаута в 50ms, который ставится непосредственно ПЕРЕД pop() а не после него.
Я наверное непонятно объяснил что делает calc_time(). Можно считать, что она возвращает абсолютное время, которое известно заранее и не зависит от того, когда был вызван pop(). Можно считать, что pop() вообще нет, отправляем нули.
Я наверное непонятно объяснил что делает calc_time(). Можно считать, что она возвращает абсолютное время, которое известно заранее и не зависит от того, когда был вызван pop(). Можно считать, что pop() вообще нет, отправляем нули.
тогда вообще непонятно зачем тебе sleep/nanosleep. Получил время, взвёл таймер, лёг баиньки 🙂 вызвал send() прям из сигнала.
Вопрос был риторический.
Вы предлагаете использовать что-то вместо sleep?
Я даже не знаю, что уже предлагать. Нужные ключевые слова уже сказаны: SCHED_RR, таймеры. Если ты путаешь таймеры и sleep, предлагаю учить матчасть.
Я даже не знаю, что уже предлагать. Нужные ключевые слова уже сказаны: SCHED_RR, таймеры.
Да не надо предлагать, я в курсе про SCHED_RR, а топик создал, чтобы узнать, не придумали ли что-то еще.
Если ты путаешь таймеры и sleep, предлагаю учить матчасть.
Неудобная у вас форма общения, каждый раз надо думать, что же вы имеете в виду.
Может быть путаю. Я знаю одно отличие: аргумент для sleep() будет вычислен с ошибкой из-за того что неизвестно точное текущее время. Вы об этой ошибке или еще о чем-то?
тогда вообще непонятно зачем тебе sleep/nanosleep. Получил время, взвёл таймер, лёг баиньки 🙂 вызвал send() прям из сигнала.
А в чем принципиальная разница?
я в курсе про SCHED_RR, а топик создал, чтобы узнать, не придумали ли что-то еще.
Может быть путаю. Я знаю одно отличие: аргумент для sleep() будет вычислен с ошибкой из-за того что неизвестно точное текущее время. Вы об этой ошибке или еще о чем-то?
Но без SCHED_RR проблемы у, например, timerfd и clock_nanosleep (с TIMER_ABSTIME) одинаковые, а с SCHED_RR они должны работать одинаково хорошо?
Я вечером проведу тесты, но пока не вижу разницы между sendto сразу после sleep, либо сразу после wait, либо в обработчике сигнала.
Но без SCHED_RR проблемы у, например, timerfd и clock_nanosleep (с TIMER_ABSTIME) одинаковые, а с SCHED_RR они должны работать одинаково хорошо?
Угум, мысль я понял.
По поводу clock_nanosleep vs nanosleep vs select: видимо в современном Linux разницы нет и все три могут работать на интервалах меньше HZ.