Протокол управления RTP (RTCP - Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.
Функции с первой по третью являются обязательными, когда RTP используется в IP-мультивещании, и рекомендуемыми во всех остальных случаях. Разработчикам приложений RTP рекомендуется избегать механизмов, работающих только в двустороннем режиме и не масштабируемых для увеличения числа пользователей.
4.1. Требования к пакетам RTCP
Для передачи различного рода информации управления определено несколько типов пакетов RTCP, в том числе:
- SR: отчет отправителя, для статистической информации о передаче и приеме участников, которые являются активными отправителями;
- RR: отчет получателя, для статистики приема от участников, которые не являются активными отправителями;
- SDES: пункты описания источника, включая CNAME;
- BYE: указатель завершения участия в телеконференции;
- APP: функции, определяемые приложением.
Каждый пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP). За ней следуют структурные элементы, которые могут иметь переменную длину согласно типа пакета, но всегда выравниваются по 32-разрядной границе. Требование выравнивания и включение поля длины в фиксированную часть предназначены обеспечить «наращиваемость» пакетов RTCP. Несколько пакетов RTCP могут соединяться без каких-либо разделителей, формируя составной пакет RTCP, который передается в одном блоке данных протокола нижележащего уровня, например протокола UDP. Какого-либо указателя на количество отдельных пакетов RTCP в составном пакете не предусмотрено, так как протоколы нижележащего уровня для определения окончания составного пакета содержат сведения о его полной длине.
Каждый отдельный пакет RTCP в составном пакете может обрабатываться отдельно без каких-либо требований относительно порядка или комбинации пакетов. Однако для корректного выполнения функций протокола существуют следующие требования.
Статистика приема (в пакетах отчета отправителя SR или получателя RR) должна посылаться так часто, как позволяет полоса пропускания, чтобы максимизировать точность статистики: следовательно, в каждый составной пакет RTCP должен включаться пакет отчета.
Новые участники телеконференции должны получить каноническое имя (CNAME) источника как можно скорее, чтобы опознать источник и начать согласовывать формат мультимедийных данных, так что каждый составной пакет RTCP должен также включать пакет описания источника SDES с пунктом CNAME.
Число типов пакетов, которые могут появляться первыми в составном пакете, должно быть ограничено, чтобы увеличить число постоянных битов в первом слове и уменьшить вероятность ошибок при распознавании пакетов RTCP среди пакетов других протоколов.
Таким образом, все пакеты RTCP должны передаваться в составном пакете, включающем, по крайней мере, два индивидуальных пакета (SR/RR и SDES), со следующим рекомендуемым форматом.
Префикс шифрования. Если и только если составной пакет должен быть зашифрован, то ему предшествует произвольная 32-разрядная величина, повторно передаваемая в каждом составном пакете.
SR или RR. Первый пакет RTCP в составном пакете должен всегда быть пакетом отчета, чтобы облегчить проверку корректности заголовка. Это требуется, даже если никакие данные не были ни посланы, ни получены и если единственный пакет RTCP в составном пакете - это пакет BYE (тогда посылается пустой пакет RR).
Дополнительные пакеты RR. Если число источников, для которых передается статистика приема, превышает 31 (максимальное число источников, отмечаемых в одном пакете SR или RR), то за начальным пакетом отчета должны следовать дополнительные пакеты RR.
SDES. Пакет SDES, содержащий пункт CNAME, должен включаться в каждый составной пакет RTCP. Если требуется конкретным приложением, то дополнительно и другие пункты описания источника могут быть включены в пакет SDES в соответствии с ограничениями полосы пропускания (см. ).
BYE или APP. Другие типы пакетов RTCP могут следовать в любом порядке, за исключением того, что пакет BYE должен быть последним пакетом, посланным с данным SSRC/CSRC.
Для трансляторов и микшеров желательно объединять индивидуальные пакеты RTCP из множества источников, с которыми они работают, в один составной пакет всякий раз, когда это возможно, чтобы уменьшить избыточность и не передавать лишние заголовки пакета (см. раздел 5). Если полная длина составного пакета превышает величину максимального блока передачи (MTU - maximum transmission unit) сетевого пути, то составной пакет может быть сегментирован на множество более коротких составных пакетов, которые будут переданы в отдельных блоках данных протокола нижележащего уровня. Заметим, что и в этом случае каждый из составных пакетов должен начинаться с пакета SR или RR.
Приложение может игнорировать входящие пакеты RTCP с неизвестными ему типами. Дополнительные типы пакетов RTCP могут быть зарегистрированы в Сообществе назначения номеров Internet IANA (Internet Assigned Numbers Authority).
4.2. Интенсивность передачи пакетов RTCP
Протокол RTP позволяет приложению автоматически масштабировать представительность сеанса связи в пределах от нескольких участников до нескольких тысяч. Например, в аудиоконференции трафик данных, по существу, является самоограничивающим, потому что только один или два человека могут говорить одновременно, и при групповом распределении скорость передачи данных на любой линии связи остается относительно постоянной, независящей от числа участников. Однако, трафик управления самоограничивающим не является. Если отчеты приема от каждого участника посылаются с постоянной интенсивностью, то трафик управления с ростом числа участников будет расти линейно. Следовательно, должен быть предусмотрен специальный механизм понижения частоты передачи управляющих пакетов.
Для каждого сеанса предполагается, что трафик данных соответствует агрегированному пределу, называемому полосой пропускания сеанса связи, которая совместно используется всеми участниками. Эта полоса пропускания может быть зарезервирована, и ее предел установлен сетью. Полоса пропускания сеанса не зависит от типа кодирования мультимедийных данных, но выбор типа кодирования может быть ограничен полосой пропускания сеанса связи. Параметр полосы пропускания сеанса, как ожидается, будет обеспечен приложением управления сеанса, когда оно вызовет мультимедийное приложение, но мультимедийные приложения могут также устанавливать значение по умолчанию, основанное на полосе пропускания данных с единственным отправителем для типа кодирования, выбранного для данного сеанса.
Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.
Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5%. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.
Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики.
Отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов.
Требуется, чтобы расчетный интервал между пакетами RTCP, как минимум, превышал 5 секунд, чтобы избежать пачек пакетов RTCP, превышающих позволенную полосу пропускания, когда число участников мало, и трафик не сглаживается согласно закону больших чисел.
Интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание непреднамеренной синхронизации всех участников. Первый пакет RTCP, посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи.
Для автоматической адаптации к изменениям в объеме передаваемой информации управления вычисляется динамическая оценка среднего размера составного пакета RTCP с использованием всех полученных и посланных пакетов.
Этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае, параметр полосы пропускания сеанса - это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5% от этой величины.
4.2.1. Учет числа участников сеанса связи
Вычисление величин интервалов передачи пакетов RTCP зависит от оценки числа участников сеанса связи. Новые участники учитываются, когда они отмечаются в работе и когда для каждого в таблице создается запись с соответствующим идентификатором SSRC или CSRC (см. раздел 6.2). Новые записи не могут иметь силу, пока не будет получено множество пакетов, содержащих новый SSRC. При получении пакета BYE с соответствующим идентификатором SSRC записи из таблицы удаляются.
Участник может пометить другой сайт как неактивный или удалить соответствующую ему запись, если никаких пакетов RTP или RTCP не было получено для некоторого числа интервалов передачи отчетов RTCP (предлагается пять интервалов). Это обеспечивает некоторую устойчивость к потерям пакетов. Все сайты для того, чтобы работать правильно, должны вычислять приблизительно одну и ту же величину периода передачи отчетов RTCP в соответствии с заданным таймаутом.
Если сайт, признанный участником телеконференции, впоследствии отмечается, как неактивный, то состояние этого сайта еще какое-то время должно сохраняться неизменным, и сайт все еще должен учитываться в общем числе сайтов, совместно использующих полосу пропускания RTCP. Для данного таймаута предложено значение, равное 30 минутам. Заметим, что это все же больше, чем умноженная на 5 самая большая ожидаемая и приемлемая величина интервала отчетности RTCP, приблизительно равная от 2 до 5 минут.
4.2.2. Выделение полосы пропускания для пакетов описания источника SDES
В дополнение к обязательному пункту CNAME пакетов описания источника (SDES - source description) в данной статье рассмотрены и другие пункты, такие как NAME (персональное имя), EMAIL (адрес электронной почты) и т.п. Приложения должны учитывать возможность передачи дополнительных пунктов при распределении полосы пропускания RTCP, потому что это замедлит скорость, с которой будут передаваться отчеты о приеме и CNAME, таким образом, ухудшая характеристики протокола. Рекомендуется, чтобы для передачи дополнительной информации использовалось не более 20% полосы пропускания RTCP, выделенной одному участнику. Кроме того, не требуется, чтобы все пункты SDES использовались каждым приложением. За теми из них, которые включены в использование, должны быть закреплены некоторые части полосы пропускания.
Например, приложение может быть разработано так, чтобы включать в пакеты SDES только пункты CNAME, NAME, EMAIL и никаких других. Пункту NAME может быть назначен гораздо более высокий приоритет, чем пункту EMAIL, потому что NAME будет индицироваться непрерывно в интерфейсе пользователя данного приложения, в то время как пункт описания пользователя EMAIL будет показываться только по требованию. В каждом интервале RTCP посылается пакет RR и пакет SDES с пунктом CNAME. Для сеанса с малым числом пользователей, работающего с минимальным интервалом отчетности, это было бы в среднем каждые 5 секунд. Каждый третий интервал (15 секунд), один дополнительный пункт был бы включен в пакет SDES. Семь из восьми раз это будет пункт NAME, а каждый восьмой раз (2 минуты) - пункт EMAIL.
Если несколько приложений функционируют одновременно, взаимодействуя между собой через общий для всех пункт CNAME (например, в мультимедийной конференции, составленной из сеансов RTP для каждого типа трафика), то дополнительная информация SDES может представляться только в одном сеансе RTP. Во всех остальных сеансах передается только пункт CNAME.
4.3. Пакеты отчетов отправителя и получателя (SR и RR)
Получатели RTP обеспечивают обратную связь - оценку качества приема, используя пакеты отчета RTCP, которые могут принимать одну из двух форм в зависимости от того, является получатель также и отправителем или нет. Единственная разность между формами отчета отправителя (SR - sender report) и отчета получателя (RR - receiver report), помимо кода типа пакета, - это то, что отчет отправителя включает 20-байтовый раздел информации отправителя для использования активными отправителями. SR передается, если сайт посылал любые пакеты данных в течение интервала, начиная с передачи последнего или предыдущего отчета, в противном случае передается RR.
Формы SR и RR включают нуль или более блоков отчета приема, один для каждого из источников синхронизации, от которых получатель принял пакеты данных RTP, начиная с последнего отчета. Для включаемых источников, перечисленных в списке CSRC, отчеты не выпускаются. Каждый блок отчета приема обеспечивает статистику относительно данных, полученных от конкретного источника, обозначенного в этом блоке. Так как максимум 31 блок приемных отчетов возможен в пакетах SR или RR, то дополнительные пакеты RR могут быть помещены в стек после начальных пакетов SR или RR. Это необходимо, чтобы содержать отчеты приема для всех источников, отмечаемых в течение интервала отчетности, начиная с последнего отчета.
Следующие разделы определяют форматы пакетов отчетов двух типов (отправителя и получателя), как они могут быть расширены определяемым профилем способом, если приложение требует дополнительной информации обратной связи, и как отчеты могут использоваться. Детали приема отчетов от трансляторов и микшеров приведены в разделе 5.
4.3.1. Формат пакета отчета отправителя (SR)
Пакет отчета отправителя содержит три основных секции и может содержать дополнительную четвертую определяемую профилем секцию расширения. Первая секция, заголовок, имеет длину 8 октетов (см. таблицу). Ее поля имеют следующие значения.
Версия (V - version): 2 бита. Идентифицирует версию RTP, которая является одинаковой в пакетах RTCP и информационных пакетах RTP. В данной статье рассматривается протокол версии 2.
Дополнение (P - padding): 1 бит. Если бит дополнения установлен в 1, то этот пакет RTCP в конце содержит некоторые октеты дополнения, которые не являются частью информации управления. Последний октет дополнения - это счетчик дополнительных октетов, которые должны игнорироваться. Дополнение может требоваться некоторыми алгоритмами шифрования с фиксированными размерами блока. В составном пакете RTCP дополнение должно использоваться только в последнем индивидуальном пакете, потому что составной пакет шифруется в целом.
Счетчик отчетов приема (RC - reception report count): 5 бит. Число блоков отчетов приема, содержащихся в данном пакете. Нуль - возможное значение RC.
Тип пакета (PT - packet type): 8 бит. Содержит константу 200 для идентификации пакета, как пакета SR протокола RTCP.
Длина: 16 бит. Длина данного пакета RTCP в 32-разрядных словах минус одно слово, включая заголовок и любое дополнение (смещение на единицу делает нуль допустимой величиной и предотвращает возможность бесконечного зацикливания при просмотре составного пакета RTCP, с другой стороны, подсчет 32-разрядных слов исключает проверку допустимости значения длины на предмет кратности четырем).
SSRC: 32 бита. Идентификатор источника синхронизации для источника данного пакета SR.
Вторая секция, информация отправителя, имеет длину 20 октетов и присутствует в каждом пакете отчета отправителя. Она подытоживает факты передачи данных от этого отправителя. Поля второй секции имеют следующие значения.
Временная метка NTP: 64 бита. Указывает абсолютное время, когда был послан этот отчет, так, что она может использоваться в комбинации с временными метками, возвратившимися в отчетах приема от других получателей, чтобы измерить время передачи на маршруте туда и обратно для этих получателей. Получатели должны ожидать, что точность измерения временной метки может быть принята гораздо меньшей, чем разрешение временной метки NTP. Неопределенность измерения для временной метки не обозначается, поскольку она не может быть известна. Отправитель, который может следить за прошедшим временем, но не имеет данных об абсолютном времени, вместо этого может использовать время, прошедшее с начала соединения сеанса. Оно должно быть меньше, чем 68 лет, - тогда старший разряд будет иметь нулевое значение. Для оценки прошедшего абсолютного времени допустимо использование таймера дискретизации. Отправитель, который не имеет никаких данных об абсолютном или прошедшем времени, может устанавливать временную метку NTP в нуль.
Временная метка RTP: 32 бита. Соответствует тому же самому времени, что и временная метка NTP (см. выше), но выражается в тех же единицах и с тем же самым случайным смещением, что и временные метки RTP в информационных пакетах. Это соответствие может использоваться для внешней и внутренней мультимедийной синхронизации источников, чьи временные метки NTP синхронизированы и могут использоваться независимыми от типа трафика получателями для оценки номинальной частоты таймера RTP. Заметим, что в большинстве случаев эта временная метка не будет равна временной метке RTP в любом соседнем информационном пакете. Она вычисляется из соответствующей временной метки NTP с использованием связи между счетчиком временной метки RTP и реальным временем, которое поддерживается периодически контролем абсолютного времени в моменты дискретизации.
Счетчик пакетов отправителя: 32 бита. Общее количество информационных пакетов RTP, переданных отправителем от момента начала передачи вплоть до времени генерации пакета SR. Счетчик сбрасывается, если отправитель изменяет свой идентификатор SSRC.
Счетчик октетов отправителя: 32 бита. Общее число октетов трафика (то есть октетов пакета, не включая заголовок и дополние), переданных в информационных пакетах RTP отправителем с момента начала передачи вплоть до времени генерации этого пакета SR. Счетчик обнуляется, если отправитель изменяет свой идентификатор SSRC. Это поле может использоваться для оценки средней скорости передачи трафика.
Третий раздел пакета SR содержит нуль или более блоков отчета приема (начиная с последнего отчета) в зависимости от количества других источников, которых «видит» этот отправитель. Каждый блок отчета приема передает статистическую информацию о приеме пакетов RTP из одного источника синхронизации. Получатели не переносят статистику, когда источник изменяет свой идентификатор SSRC вследствие коллизий. Эта статистика включает следующую информацию.
SSRC_n (идентификатор источника): 32 бита. Идентификатор SSRC источника, к которому относится информация в этом блоке отчета приема.
Доля потерь: 8 бит. Часть информационных пакетов RTP из источника SSRC_n, потерянных, начиная с момента отправки предыдущего пакета SR или RR, представленная в виде целого числа с фиксированной точкой без знака (в виде целой части числа после умножения доли потерянных пакетов на 256). Эта доля определяется как число потерянных пакетов, разделенное на число ожидаемых пакетов. Если величина потерь - отрицательная из-за наличия дубликатов пакетов, то доля потерь приравнивается к нулю.
Общее число потерянных пакетов: 24 бита. Общее число информационных пакетов RTP из источника SSRC_n, которые были потеряны с момента начала приема. Это число является разностью между числом пакетов, ожидаемых к получению, и числом фактически полученных пакетов. В число полученных пакетов входят любые пакеты, в том числе опоздавшие и дубликаты. Таким образом, пакеты, которые прибывают поздно, не причисляются к числу потерянных, а число потерь может быть отрицательным, если имеются дубликаты. Число ожидаемых пакетов определяется как разность последнего полученного порядкового номера и начального полученного порядкового номера.
Расширенный наибольший полученный порядковый номер: 32 бита. Младшие 16 битов содержат наибольший порядковый номер, полученный в информационном пакете RTP из источника SSRC_n, а старшие 16 битов расширяют этот порядковый номер соответствующим счетчиком циклов порядкового номера. Заметим, что различные получатели в рамках одного и того же сеанса генерируют различные расширения порядкового номера, если время начала для них значительно различается.
Джиттер прибытия: 32 бита. Это - статистическая оценка разницы относительного времени прибытия информационных пакетов RTP, измеряемая в единицах временной метки и выражаемая целым числом без знака. Джиттер прибытия J определяется как средняя величина (сглаженное абсолютное значение) разности D времени между поступлениями двух пакетов получателю и времени между моментами передачи этих пакетов. Как показано в уравнении ниже, это эквивалентно разности относительного времени передачи для двух пакетов (относительное время передачи - это разность между временной меткой пакета RTP и значением таймера получателя во время поступления, выраженным в тех же самых единицах).
Если Si - это временная метка RTP из пакета i, а Ri - время поступления в единицах временной метки RTP для пакета i, то для двух пакетов i и j, D может быть выражено как
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si).
Джиттер прибытия вычисляется непрерывно по мере того, как каждый информационный пакет i поступает от источника SSRC_n, с использованием этой разности D для этого пакета и предыдущего пакета i-1 в порядке поступления (не обязательно в последовательности передачи), согласно формуле
J=J+(|D(i-1,i)|-J)/16.
Всякий раз, когда передан отчет приема, определяется текущая величина J. Вычисление джиттера, описанное здесь, позволяет независимым от профиля мониторам делать корректные интерпретации отчетов, поступающих от различных реализаций. Этот алгоритм является оптимальным оценивателем первого порядка, и весовой коэффициент 1/16 дает хороший коэффициент уменьшения шума при поддержании приемлемой скорости сходимости.
Временная метка последнего SR (LSR): 32 бита. Средние 32 бита из 64 битов временной метки NTP (как показано в разделе 2.4), полученные как часть самых последних пакетов отчетов отправителя RTCP (SR) из источника SSRC_n. Если SR еще не был получен, то временная метка LSR имеет нулевое значение.
Задержка с момента последнего SR (DLSR): 32 бита. Задержка в приемнике пакетов, выраженная в единицах, равных 1/65536 секунды, между получением последнего пакета SR из источника SSRC_n и посылкой этого блока отчета о приеме. Если пакет SR еще не был получен от SSRC_n, то поле DLSR имеет нулевое значение.
С помощью значений временной метки последнего SR (LSR) и задержки в приемнике с момента последнего SR (DLSR) источник SSRC_n может вычислять задержку распространения пакетов на пути к получателю SSRC_r и обратно (круговую задержку). При поступлении отчета приема источник SSRC_n фиксирует время этого события Т. Затем он вычисляет общее время двойного прохода Т-LSR с использованием поля временной метки последнего SR (LSR) и вычитает задержку DLSR, в результате получая время распространения пакета туда и обратно (Т-LSR-DLSR). Это может использоваться как приблизительная мера расстояния до кластера получателей, хотя некоторые линии имеют очень асимметричные задержки. отчета
Формат пакета отчета получателя RR (receiver report) такой же, как и формат пакета SR, за исключением того, что поле типа пакета содержит константу, равную 201, а пять слов информации отправителя отсутствуют (временные метки NTP и RTP и счетчики пакетов и октетов отправителя). Оставшиеся поля имеют то же самое значение, что и для пакета SR.
Когда нет никакой передачи данных или приема, о которых можно было бы сообщить, во главу составного пакета RTCP помещается пустой пакет RR (RC = 0).
4.3.3. Расширение отчетов отправителя и получателя
Если имеется дополнительная информация об отправителе или получателях, которая должна регулярно сообщаться, то профиль должен определять расширения к отчету отправителя и получателя. Использовать этот метод предпочтительнее, чем определять другой тип пакета RTCP, потому что он требует меньше избыточности:
- меньше октетов в пакете (не требуется ни заголовка RTCP, ни поля SSRC);
- более простой и быстрый анализ, потому что приложения, выполняющиеся в соответствии с данным профилем, могут программироваться так, чтобы всегда рассматривать поля расширения в непосредственно доступном месте после отчетов приема.
Если требуется дополнительная информация отправителя, то она должна быть включена в первую очередь в расширение отчетов отправителя, но не должна присутствовать в отчетах приема. Если должна быть включена информация о получателях, то данные могут быть структурированы, как массив блоков, параллельный существующему массиву блоков отчета приема. Число блоков должно быть обозначено полем RC.
4.3.4. Анализ отчетов отправителя и получателя
Обратная связь качества приема полезна не только для отправителя, но также для получателей и мониторов третьей стороны. Отправитель может модифицировать свои передачи на основе обратной связи; получатели могут определять, являются ли проблемы локальными, региональными или глобальными; диспетчеры сети могут использовать независимые от профиля мониторы, которые получают пакеты RTCP, чтобы оценить характеристику сетей для группового распределения.
В информации отправителя и в блоках отчета приема используются кумулятивные счетчики потерянных пакетов. Разность значений счетчиков в двух полученных отчетах может использоваться для оценки текущего качества передачи пакетов на протяжении коротких и длинных интервалов времени с обеспечением устойчивости к потере отчетов. Данные временной метки NTP позволяют вычислять интенсивность потерь из этих разниц на интервале между двумя отчетами. Так как эта временная метка не зависит от тактовой частоты кодирования данных, можно использовать, независимые от кодирования и профиля мониторы.
Рассмотрим пример вычисления интенсивности потерь пакета на интервале между двумя отчетами приема. Разность значений кумулятивных счетчиков потерянных пакетов дает количество пакетов, потерянных в течение этого интервала. Разность в последних полученных расширенных порядковых номерах дает число пакетов, ожидаемых в течение интервала. Отношение этих двух величин - это доля потерь пакетов на интервале. Это отношение должно равняться значению поля доли потерь, если эти два отчета являются последовательными, в противном случае - нет. Число потерь пакетов за 1 секунду может быть получено путем деления доли потерь на разность временных меток NTP, выраженную в секундах. Количество полученных пакетов - это число ожидаемых пакетов минус число потерянных. Количество ожидаемых пакетов может также использоваться для определения статистической достоверности любых оценок потерь. Например, потеря одного пакета из пяти имеет более низкую представительную ценность, чем потеря 200 пакетов из 1000.
Из информации отправителя монитор третьей стороны без получения данных может вычислять среднюю на интервале скорость передачи трафика и среднюю частоту передачи пакетов. Отношение этих двух величин дает средний размер поля данных. Если вероятность потери пакета не зависит от его размера, то число пакетов, принятых конкретным получателем, умноженное на средний размер поля данных (или соответствующий размер пакета) дает производительность этого получателя.
В дополнение к кумулятивным счетчикам, которые обеспечивают определение потерь пакетов на протяжении длительных интервалов времени на основе разницы в отчетах, поле доли потерь обеспечивает краткосрочное измерение на базе одного отчета. Это становится более важным по мере роста числа участников телеконференции, поскольку информация о состоянии приема может не обеспечиваться для всех получателей, а интервал между отчетами становится достаточно длительным.
Поле джиттера прибытия обеспечивает второй краткосрочный критерий оценки перегрузки сети. Потери пакета отслеживают устойчивую перегрузку, в то время как на основе джиттера может прослеживаться кратковременная перегрузка. Критерий джиттера может указывать на перегрузку прежде, чем это приведет к потерям пакетов. Так как поле джиттера прибытия содержит только мгновенный срез джиттера в момент формирования отчета, может быть необходим анализ нескольких отчетов, поступивших от одного получателя через какое-то время или от множества получателей, например, внутри одной сети.
Глава 6
Прошлое, настоящее
и будущее протокола TCP/IP
По прочтении этой главы и после выполнения практических заданий вы сможете:
· рассказать историю появления TCP/IP;
· объяснить принципы работы протоколов TCP и IP, а также методы использования протоколов UDP вместо TCP;
· рассказать об адресации IP и понять способы ее реализации в локальных и глобальных сетях;
· рассказать о новом протоколе IP version 6 и его назначении;
· обсудить способы использования прикладных протоколов, входящих в стек TCP/IP;
· понять назначение прикладных протоколов стека TCP/IP;
· соотнести реализацию TCP/IP с эталонной моделью OSI.
Когда компьютеры общаются через Интернет, то в качестве языка общения они используют Transmission Control Protocol/Internet Protocol (TCP/IP). Также протоколы TCP/IP широко распространены в большинстве средних и крупных сетей. Эти протоколы поддерживают сети на основе платформ Novell NetWare, UNIX и Windows, в особенности – развивающиеся сети и сети, в которых используются клиент-серверные или веб-ориентированные приложения. Широкое распространение, проверенные технологии и возможности расширения делают TCP/IP удачным выбором для большинства проектов, обеспечивающих взаимодействие локальных и глобальных сетей. Даже в небольших сетях развертывание TCP/IP может оказаться жизненно важным для дальнейшего развития сети.
В данной главе будет подробно рассказано о протоколах TCP/IP, включая описание пакетов TCP и IP, а также способы адресации IP. Также вы узнаете об альтернативе TCP – протоколе User Datagram Protocol (UDP), который применяется тогда, когда подтверждение переданных данных не так важно, как скорость и малая нагрузка на сеть. В главе обсуждается новейшая версия протокола IP, названная IPv6, и сравнивается с предшествующей версией, IPv4. Кроме того, рассказывается о прикладных протоколах входящих в стек TCP/IP и предназначенных для эмуляции терминалов передачи файлов и сообщений электронной почты , преобразований и назначения IP-адресов, а также для управления сетями. И, наконец, вы узнаете как архитектура TCP/IP соотносится с эталонной моделью OSI.
Краткая история стека TCP/IP
В конце 1960-х годов управление ARPA работало над тем, чтобы сделать сеть ARPANET доступной для общего пользования, обеспечивая компьютерам университетов, исследовательских учреждений и Министерства обороны возможность взаимодействия через глобальную сеть. Одним из заметных препятствий на пути достижения этой цели было наличие собственных стандартов у производителей компьютеров, и информацию о принципами боты своих систем производители охраняли как коммерческую тайну .
Первая попытка создания средств взаимодействия различных компьютеров была предпринята несколькими университетами, которые разработали сетевой протокол, названный Network Control Protocol (NCP ) и позволивший хост-компьютерам разных компаний, включая DEC и IBM, обменивал информацией. NCP был простейшим протоколом, который обеспечивал различным типам компьютеров DEC и IBM возможность сетевых взаимодействий и запуска приложений через сеть, в которой хосты были географически удалены друг от друга. Например, одним из приложений протокола NCP была передача файлов между компьютерами. Это было хорошее начало, однако протокол NCP не мог обеспечить достаточно надежной передачи данных, поэтому управление ARPA для его модернизации запустило проект. Разработанный протокол на самом деле являлся комбинацией двух протоколов – Transmission Control Protocol (TCP ) и Internet Protocol (IP ) названия которых обычно сокращаются до аббревиатуры TCP/IP.
Примечание
Протокол NCP по-прежнему используется в старых сетях DEC и IBM, хотя его очень сложно конфигурировать. Этот протокол создает большую нагрузку на центральный процессор, поскольку он содержит некоторый уровень коммуникаций при выполнении сетевых операций, который не используется протоколом TCP
Внимание
Компания IBM использует аббревиатуру NCP для названия Программы управления сетью – Network Control Program. Эта программа представляет собой приложение, выполняющееся на оконечном процессоре (небольшом компьютере) или на шлюзе SNA, который подключен к мэйнфрейму, обеспечивая последнему возможность сетевых взаимодействий.
Основы стека TCP/IP
Протокол TCP, описанный в RFC 793, первоначально был разработан для двухточечных взаимодействий между компьютерами одной сети, а протокол IP (RFC 791) предназначался для обеспечения коммуникаций между компьютерами, подключенными к разным сетям или к глобальным сетям. Вскоре после своего появления оба протокола были объединены как стек TCP/IP для использования в популярных операционных системах Berkeley UNIX и были встроены в ОС Virtual Memory System (VMS, ныне – OpenVMS) компании DEC и Multiple Virtual Storage (MVS, ныне – OpenMVS) компании IBM.
С момента своего появления в начале 1970-х годов стек TCP/IP широко применялся в сетях в разных странах мира. Он реализован для PC-совместимых компьютеров, рабочих станций UNIX, мини-ЭВМ, компьютеров Macintosh и сетевых устройств, связывающих клиентов и хосты. TCP/IP обеспечивает тысячам открытых и коммерческих сетей подключение к Интернету, которым могут пользоваться миллионы людей.
TCP/IP – это многоуровневый стек протоколов, напоминающих уровни протоколов OSI, но не эквивалентных им. Стек TCP/IP содержит около ста стандартизованных протоколов, позволяющих обеспечить надежную и эффективную передачу данных между системами. Базовыми протоколами в стеке TCP/IP являются следующие:
· Transmission Control Protocol (TCP);
· User Datagram Protocol (UDP);
· Internet Protocol (IP).
Каждый из этих протоколов подробно рассматривается в последующих разделах.
Функционирование протокола TCP
TCP – это транспортный протокол, с помощью которого устанавливаются сеансы передачи данных между процессами прикладных программ, запускаемых клиентами сети. TCP предназначен для надежной доставки данных, для чего осуществляется контроль за правильностью приема фреймов и выполняется управление потоком данных. Для решения этих задач в протоколе предусмотрено упорядочение фреймов и подтверждение их приема.
Два взаимодействующих устройства задают порядковый номер для каждом переданного фрейма, и этот номер записывается в заголовок фрейма TCP Порядковый номер не только показывает местоположение фрейма в потом фреймов, но и указывает на длину данных, содержащихся в этом фрейме. Получив фрейм, принимающий узел проверяет порядковый номер и убеждается в том, что получен правильный фрейм в правильной очередности. Если узел назначения принимает фрейм, он передает подтверждение передающему узлу. Пакет подтверждения не только свидетельствует об успешном приеме фрейма, но и содержит порядковый номер следующего фрейма передачу которого ожидает принимающий узел.
Количество байтов данных, переданных во фрейме, называется скользящим окном (sliding window), поскольку это количество может увеличиваться или уменьшаться в процессе обмена информацией по взаимному соглашению между взаимодействующими узлами. Размер скользящего окна определяется, узлами динамически, при этом учитываются два фактора:
· текущий сетевой трафик;
Коммерческие кооперативы (принадлежащие работающим в них сотрудникам)
Образовательные
Правительственные
Организации, занимающиеся регистрацией доменных имен
Организации, созданные согласно международным договорам
Музейные
Домены для личного пользования
Поставщики сетевых услуг
Некоммерческие
Профессиональные (например, объединения врачей, бухгалтеров или юристов)
Таблица 6.4. Доменные имена ДМШ
Таблица 6.5. Предлагаемые глобальные доменные имена первого уровня (TLD )
Распознаватели имен DNS и пространства имен
Для работы службы DNS необходимы распознаватели доменных имен на каждом клиенте, а также сервер доменных имен, установленный на одном или нескольких хостах. DNS-серверы поддерживают пространство имен (namespace) для предприятия и реализуют механизм разрешения имен компьютеров и доменов в IP-адреса, а также и обратное преобразование. Пространство имен представляет собой логическую область сети, содержащую перечень именованных объектов (например, компьютеров) и позволяющую выполнять разрешение имен.
Использование зон
DNS-серверы поддерживают информационные таблицы, с помощью которых имена компьютеров или доменов связаны с IP-адресами. Эти таблицы ассоциируются с разделами DNS-сервера, называемыми зонами и содержащими ресурсные записи. Каждая зона представляет собой таблицу (файл зоны или базу данных зоны) ресурсных записей различного типа (например, записей, связывающих серверы домена со службами; которые на этих серверах функционируют). Другие ресурсные записи связывают имена компьютеров и IP-адреса.
Зона, ассоциирующая имена компьютеров с соответствующими JH адресами, называется зоной прямого просмотра (forward lookup zone). Эта зона содержит записи имен хостов, называемые адресными записями. Каждый сервер и клиент IP-сети должен иметь адресную запись, позволяющую найти его с помощью DNS. Например, если DNS-сервер называется NetAdmin и имеет адрес 129.70.10.1, то зона прямого просмотра связывает имя NetAdmin с адресом 129.70.10.1. Для протокола IPv4 запись хоста называется ресурсной записью адреса хоста (типа A) (host address (A) resource record). Для протокола IPv6 такая запись называется ресурсной записью адреса хоста (типа АААА) (IPv6 host address (АААА) resource record).
Примечание
При установке службы каталога (например, Active Directory) вы должны иметь в сети хотя бы один DNS-сервер, поскольку эта служба является частью пространства имен, используемого для хранения информации о сетевых объектах (таких как компьютеры, принтеры и общие ресурсы). Для обновления этой информации служба каталога должна взаимодействовать с DNS-сервером.
В другой зоне, называемой зоной обратного просмотра (reverse lookup zone) хранятся ресурсные записи указателей (типа PTR ) (pointer (PTR) resourse record), которые связывают IP-адреса с именами хостов. Зоны обратного просмотра используются не так часто, как зоны прямого просмотра, однако не следует создавать в тех случаях, когда для обеспечения сетевых коммуникаций требуется связывать IP-адрес с некоторым компьютерным именем (например для мониторинга сети с использованием IP-адресов ).
Роли DNS -серверов
Обычно DNS-сервер в сети играет одну из двух ролей: он может выступать или в качестве основного DNS-сервера, или выполнять функции дополнительного DNS-сервера. Основным DNS -сервером (primary DNS server) считается сервер, отвечающий за некоторую зону и поэтому называющийся авторитетным (authoritative) сервером для этой зоны. Например, если на некотором DNS-сервере первый раз создается зона прямого просмотра ДД домена, то при этом создается ресурсная запись начала зоны (SOA ) (start of authority (SOA) resource record), идентифицирующая данный сервер в качестве авторитетного DNS-сервера для домена., Это означает, что все изменения зоны (например, создание ресурсных записей адреса хоста (типа А)) должны выполняться на этом сервере.
В средних и крупных сетях обычно устанавливают один или несколько резервных DNS-серверов, называемых (по отношению к основному DNS-се веру) дополнительными, или вторичными DNS -серверами (secondary DNS server). Дополнительный DNS-сервер содержит копию файла зоны, хранящейся на основном DNS-сервере, при этом данная копия не может использоваться для административных задач. Для обновления копии выполняются пересылки зоны по сети. В процессе пересылки зоны содержимое зоны передается с основного DNS-сервера на дополнительный.
Дополнительные DNS-серверы выполняют три важные задачи. Во-первых, они позволяют получить копию данных основного DNS-сервера в случае отказа этого сервера. Во-вторых, они позволяют распределять нагрузку на службу DNS (позволяя обращаться к общим ресурсным записям) между основным и дополнительными DNS-серверами. Распределение нагрузки означает, что если из-за перегрузки основной DNS-сервер не может выполнить разрешение имени, то повторный запрос на разрешение имени может быть обработан дополнительным DNS-сервером, что ускоряет получение ответов на запросы клиентов. В-третьих, дополнительные DNS-серверы можно разместить в разных областях сети (например, в разных подсетях или на территориально удаленных площадках), в результате чего снижается нагрузка на отдельные участки сети.
Совет
Для обеспечения отказоустойчивости в средних и крупных сетях рекомендуется создать по меньшей мере по одному дополнительному ONS-серверу в каждой подсети, отличной от той подсети, где находится основной DNS-сервер.
Чтобы познакомиться с зонами, ресурсной записью начала зоны (SOA) и другой информацией, хранящейся на DNS-сервере, выполните практическое задание 6-8.
Стандарты DNS
Авторитетные серверы обычно поддерживают два стандарта DNS: ресурсные записи служб и протокол динамического обновления DNS. Ресурсная запись службы (типа SVR ) (service resource record (SVR RR)) описана в RFC 2052 и представляет собой тип DNS-записи, позволяющей DNS распознавать различные серверы и определять местоположение широко используемых служб TCP/IP, выполняющихся на конкретных серверах. SRV-записи позволяют DNS-серверу генерировать список серверов сети, предоставляющих услуги TCP/IP-сервисов. Также эти записи сообщают о протоколах, поддерживаемых этими серверами, и позволяют определить предпочтительный сервер для некоторой службы. Формат SRV-записи содержит информацию о типе службы, выполняющейся на некотором сервере, имени домена, который обслуживается этим сервером, а также о протоколе, используемом сервером.
Протокол динамического обновления DNS (DNS dynamic update protocol) описан в RFC 2136, с его помощью можно автоматически обновлять информацию на 1 DNS-сервере. Примером может служить рабочая станция под управлением Windows ХР Professional, обновляющая свой IP-адрес, полученный от сервера DHCP. Протокол динамического обновления DNS может сэкономить сетевому администратору массу времени, поскольку ему не понадобится вручную регистрировать каждую новую рабочую станцию или выполнять регистрация компьютера каждый раз по истечении срока арендованного ему 1Р-адресзи при получении нового адреса.
Совет
В сети, где работает служба Microsoft Active Directory, SRV-записи позволяют рабочим станциям быстро находить ближайший сервер для аутентификации запросов входа в сеть. Это - позволяет уменьшить ненужный сетевой трафик.
Dynamic Host Configuration Protocol (DHCP)
Протокол Dynamic Host Configuration Protocol (DHCP ) (Протокол динамически конфигурации хоста) позволяет автоматически назначать в сети 1Р-адреса с помощью DHCP-сервера. Когда новый компьютер, настроенный на работу с DHCP, подключается к сети, он обращается к DHCP-серверу, который выделяет (сдает в аренду) компьютеру IP-адрес, передавая его посредством протокола DHCP. Длительность аренды устанавливается на DHCP-сервере сетевым администратором. Например, срок аренды для настольного компьютера может составлять от нескольких дней до нескольких недель (поскольку компьютер постоянно подключен к сети). Срок аренды для портативного компьютера может составлять от нескольких часов до одного дня (поскольку портативный компьютер часто отключается от сети или перемещается на другие участки сети). И, наконец, хост-компьютер или сервер может получить адрес в бессрочную аренду , т. к. их адрес никогда не меняется.
Совет
Чтобы упростить сетевое администрирование, устанавливайте совместимые друг с другом серверы DNS и DHCP, которые поддерживают протокол динамического обновления DNS. Это гарантирует автоматическое обновление DNS зон DHCP-сервером или клиентами DHCP и освобождает администратора от необходимости делать это вручную.
Address Resolution Protocol (ARP)
В большинстве случаев для отправки пакета принимающему узлу отправитель должен знать как IP-адрес, так и МАС-адрес. Например, при групповых передачах используются оба адреса (IP и MAC). Эти адреса не моя совпадать и имеют разные форматы (десятичный с разделительными точками и шестнадцатеричный соответственно).
Address Resolution Protocol (ARP ) (Протокол разрешения адресов) позволяет передающему узлу получить МАС-адреса выбранного принимающего узла перед отправкой пакетов. Если исходному узлу нужен некоторый МАС-адрес, то он посылает широковещательный ARP-фрейм, содержащий свой собственный МАС-адрес и IP-адрес требуемого принимающего узла. Принимающий узел отправляет обратно пакет ARP-ответа, содержащий свой МАС-адрес.
Вспомогательным протоколом является Reverse Address Resolution Protocol (RARP ) (Протокол обратного разрешения имен), с помощью которого сетевой узел может определить свой собственный IP-адрес. Например, RARP используется бездисковыми рабочими станциями, которые не могут узнать свои адреса иначе как выполнив RARP-запрос к своему хост-серверу. Кроме того, RARP используется некоторыми приложениями для определения IP-адреса того компьютера, на котором он выполняются.
Simple Network Management Protocol (SNMP)
Simple Network Management Protocol (SNMP ) (Простой протокол сетевого управления) позволяет администраторам сети непрерывно следить за активностью сети. Протокол SNMP был разработан в 1980-х годах для того, чтобы снабдить стек TCP/IP механизмом, альтернативным стандарту OSI на управление сетями – протоколу Common Management Interface Protocol (CMIP ) (Протокол общей управляющей информации).
Хотя протокол SNMP был создан для стека TCP/IP, он соответствует эталонной модели OSI. Большинство производителей предпочли использовать SNMP, а не CMIP, что объясняется большой популярностью протоколов TCP/IP, а также простотой SNMP. Протокол SNMP поддерживают многие сотни сетевых устройств, включая файловые серверы, карты сетевых адаптеров, маршрутизаторы, повторители, мосты, коммутаторы и концентраторы. В сравнении с этим, протокол CMIP применяется компанией IBM в некоторых сетях с маркерным кольцом, однако во многих других сетях он не встречается.
Достоинства SNMP
Важным достоинством SNMP является то, что он работает независимо от сети, т. е. ему не нужно двунаправленное соединение с другими сетевыми объектами на протокольном уровне. Благодаря этому SNMP может анализировать сетевую активность, например, обнаруживать неполные пакеты и отслеживать широковещательные посылки, при этом на его работе не сказывается ошибочная информация, которая может поступить от неисправного Узла. По сравнению с этим, протокол CMIP подключается к сетевым узлам на уровне протокола, и это означает, что его способность обнаруживать проблемы зависит от работоспособности некоторого узла, который может оказаться неисправным.
Еще одно достоинство SNMP состоит в том, что контрольные функции выполняются на некоторой станции управления сетью. В этом SNMP отличается от протокола CMIP, для которого функции управления распре делены между отдельными сетевыми узлами, которые одновременно являются и объектами мониторинга. Кроме того, SN. MP требует меньше оперативной памяти, чем CMIP. Для работы CMIP нужно до 1,5 Мбайт памяти на каждом исследуемом узле, a SNMP требует только 64 Кбайт.
Типы узлов, используемых протоколом SNMP
Протоколом SNMP предусмотрены два типа узлов: станция управления сетью (network management station, NMS) и агенты сети (network agents). Станция управления сетью следит за сетевыми устройствами, поддерживающими SNMP. На этих устройствах выполняется агентское программное обеспечение, взаимодействующее со станцией. Большинство устройств, подключаемых к современным сетям, являются агентами. К их числу относятся маршрутизаторы, повторители, концентраторы, коммутаторы, мосты, персональные компьютеры (через свои сетевые адаптеры), серверы печати, серверы доступа и источники бесперебойного питания.
С помощью консоли на станции управления сетью можно посылать команды сетевым устройствам и получать данные о производительности (статистику). Станция управления сетью может построить блок-схему всей сети. Если в сети появляется новое устройство, станция может немедленно его обнаружить. Программные средства станции управления сетью могут обнаружить момент когда агент выключен или работает неверно. Значок такого агента может высвечиваться на блок-схеме другим цветом или может раздаваться предупредительный сигнал. Обычно программы станции управления сетью имеют графический пользовательский интерфейс и с ними очень легко работать.
Многие программные пакеты станций управления сетью могут в графическом виде предоставлять показания счетчиков, отображающих степень использования сети, поток пакетов и другие статистические данные. При возникновении неисправности графические обозначения помогают понять серьезность проблемы и определить тип отказавшего агента. Некоторые пакеты имеют интерфейсы прикладного программирования (API), позволяющие взаимодействовать с программным обеспечением и запрограммировать специфические задачи с использованием простого языка (например, Visual Basic).
Каждый агент сети хранит информационную базу, содержащую количество посланных или полученных пакетов, число пакетных ошибок и другие данные. Такая база называется базой управляющей информации (Management Information Base, MIB). У станции управления сетью имеется множество команд, позволяющих обращаться к данным этой базы и управлять ею. Такие команды передаются с помощью OSI-совместимых модулей данных протокола (PDU) и содержат тип сообщения (например, запрос на получение, запрос на получение следующих данных, ответ на запрос, запрос на присваивание значения и системное прерывание). Получаемые данные позволяют определить, включено ли устройство и имеются ли сетевые проблемы. Станция управления сетью обеспечивает даже удаленную перезагрузку устройства. Сообщения между станцией и агентом передаются поверх протокола UDP, к пакетам которого добавляется заголовок SNMP. Полезная нагрузка SNMP содержит групповое имя (community name), представляющее собой некоторый пароль, общий для станции управления сетью и агента.
В базе управляющей информации хранятся сведения о сетевых объектах (таких как рабочие станции, серверы, мосты, маршрутизаторы, концентраторы и повторители). Основной набор переменных, содержащихся в этой базе, представлен в табл. 6.6. Изначально таблица базы MIB была описана в стандарте Management Information Base-I. Этот стандарт определяет сведения об устройстве и множество соответствующих переменных. Стандарты MIВ разрабатываются Проблемной группой проектирования Интернета (IETF).
Таблица 6.6. Переменные базы управляющей информации (Ml В)
Переменные MIB | Назначение |
Address translation group (группа преобразования адресов) | Преобразует сетевые адреса в адреса подсетей или физические адреса |
Electronic gateway protocol group (Группа шлюзового протокола электронных устройств) | Обеспечивает сведения об узлах в том же сегменте, в котором находится агент сети |
Interfaces group (Группа интерфейсов) | Отслеживает количество сетевых адаптеров и количество подсетей |
Internet control message protocol group (Группа протокола управляющих сообщений Интернета) | Собирает данные о количестве. сообщений, посланных агентом и полученных им |
Internet protocol group (Группа протокола Интернета) | Отслеживает количество входных принятых датаграмм и количество отвергнутых датаграмм |
SNMP group (Группа SNMP) | Собирает данные об обращениях к базе MIB |
System group (Системная группа) | Содержит информацию об агенте сети |
Transmission control protocol group (Группа протокола управления передачей) | Предоставляет информацию о ТСР-соединениях в сети, включая данные об адресах и тайм-аутах |
User datagram protocol group (Группа пользовательского протокола данных) | Предоставляет информацию о слушающем агенте, с которым станция управления сетью взаимодействует в данный момент |
Новый, более совершенный стандарт MIB-II описывает дополнительные средства безопасности, поддержку сетей с маркерным кольцом и высокоскоростных интерфейсов, а также поддержку для телекоммуникационных интерфейсов. Стандарт MIB-II принят многими производителями сетевого оборудования.
Новые возможности протокола SNMPv 2
Первая версия протокола SNMP имела некоторые недостатки, которые были устранены во второй версии, названной SNMPv2. Возможно, главным из недостатков SNMP является отсутствие механизмов защиты. При использовании SNMP групповое имя передается станцией управления сетью без шифрования и в случае перехвата этот пароль можно использовать для получения доступа к важным командам управления сетью. В результате такой утечки злоумышленник может удаленно изменить настройки маршрутизатора или концентратора и дискредитировать безопасность сети.
SNMPv2 позволяет шифровать групповое имя, улучшить обработку ошибок и обеспечить взаимодействие со многими протоколами. Он поддерживает также IPX и AppleTalk. Кроме того, SNMPv2 обеспечивает быструю передачу информации и позволяет одновременно получать больше данных из базы MIB-II.
Мониторинг с использованием протоколов SNMP и SNMPv 2
Протоколы SNMP и SNMPv2 можно применять для управления любыми сетями: локальными, глобальными и смешанными. Имеется множество средств и программных пакетов для сетевого мониторинга, которые используют SNMP и SNMPv2. В их число входят программы Sniffer компании Network Associates (см. www . sniffer . com ) и Network Monitor компании Microsoft (см. www.).
Важным SNMP-совместимым инструментом, используемым для мониторинга локальных сетей, соединенных через глобальные сети, является разработанный в начале 1990-х годов стандарт Remote Network Monitoring (RMON ) (удаленный мониторинг сети). RMON не только использует протокол SNMP, но также задействует специальную базу данных для удаленного мониторинга, называемую RMON MIB-II. Эта база позволяет удаленным сетевым узлам собирать сетевую статистику практически в любой точке локальной или глобальной сети. Эти удаленные узлы являются агентами, или зондами. Информация, полученная агентами, может быть передана на некоторую станцию управления, которая заносит ее в базу данных. В настоящее время стандарты RMON MIB-II адаптированы к сетям FDDI, Ethernet и Token Ring.
Другие прикладные протоколы стека TCP/IP
Имеются и другие протоколы или прикладные программы, входящие в стек TCP/IP - Они упрощают работу интернет-служб, передачу данных мультимедиа-приложений, управление сетью и поиск неисправностей. Эти дополнительные протоколы и приложения перечислены в табл. 6.7.
Таблица 6.7. Приложения и протоколы стека TCP/IP
Протокол или приложение | Описание |
Приложение, позволяющее пользователю стека TCP/IP находить FTP-сайты, содержащие информацию по определенной тематике |
|
Bootstrap Protocol (ВООТР) | Протокол, используемый бездисковыми рабочими станциями для определения своего IP-адреса и для взаимодействия с сервером, с которого копируются файлы операционной системы, необходимые для загрузки этих станций |
Distance Vector Multicast Routing Protocol (DVMRP) | Протокол групповой маршрутизации, используемый вместе с протоколом RIP для определения узлов, подписанных на определенные групповые посылки приложений мультимедиа (см. главу 10) |
С помощью данной утилиты сетевой пользователь может определить, какие еще пользователи и хосты активны в сети |
|
Приложение, предлагающее список тем, из которых пользователи могут получить доступ к другому меню или текстовым файлам (например, к файлу, содержащему список телефонов). В настоящее время службы Gopher встречаются редко, поскольку, в первую очередь, их заменили веб-серверы |
|
Hypertext Transfer Protocol (HTTP) | Протокол для передачи документов HTML (Hypertext Markup Language) через Интернет по запросам от веб-браузеров; эти документы могут включать в себя аудио - и видеофайлы, а также изображения и графику |
Internet Group Management Protocol (IGMP) | Протокол, позволяющий передавать групповые пакеты их получателям и маршрутизаторам. Определяет, какие рабочие станции принадлежат к определенной группе мультивещания (см. главу 10) |
Multicast Open Shortest Path First Protocol (MOSPF) | Протокол групповой маршрутизации, позволяющий определить кратчайший маршрут от источника к пункту назначения при групповых передачах |
Open Shortest Path First Protocol (OSPF) | Протокол, используемый маршрутизаторами для обмена данными таблиц маршрутизации и для оценки сетевых маршрутов при передаче данных с учетом определенных критериев (например, стоимости маршрута) |
Утилита, позволяющая сетевому узлу взаимодействовать с другим узлом, находящимся в той же или в удаленной сети, и определять, имеется ли связь с указанным узлом и отвечает ли тот на запросы. Сетевой администратор может использовать утилиту ping для быстрой проверки соединений с глобальной сетью связываясь с каким-нибудь удаленным узлом |
|
Real-Time Protocol (RIP) | Этот протокол служит для эффективного управления групповым потоковым мультивещанием, ведущимся в реальном масштабе времени и используемым для организации видеоконференций или для работы аналогичных приложений мультимедиа (см. главу 10) |
Real-Time Transport Control Protocol (RTCP) | Позволяет управлять сетевым трафиком, упрощая использование приложений мультимедиа, работающих в реальном масштабе времени (см. главу 10) |
Resource Reservation Protocol (RSVP) | Протокол, позволяющий выделять сетевые ресурсы для определенных приложений (например, резервировать полосу пропускания для приложений мультимедиа) (см. главу 10) |
Routing Information Protocol (RIP) | С помощью данного протокола маршрутизаторы передают друг другу содержание таблиц маршрутизации и определяют наименьшее количество ретрансляций от одного узла сети к другому |
Simple Network Management Protocol (SNMP) | Протокол, обеспечивающий сбор сетевой статистики, хранит эту информацию в базе данных |
Traceroute (tracert) | Приложение, позволяющее пользователю определить количество ретрансляций между двумя узлами сети |
В практических заданиях 6-9 и 6-10 вы можете попрактиковаться в работе с командой ping, а в заданиях 6-11 и 6-12 вы узнаете, как с помощью команд tracert и ping определить количество ретрансляций от одной точки сети до другой.
Сравнение архитектуры стека TCP/IP и эталонной модели OSI
Как показано на рис. 6.11, компоненты стека TCP/IP, о которых рассказывалось в этой главе, соответствуют уровням эталонной модели OSI. По мере развития стека TCP/IP его компоненты все в большей степени следуют модели OSI. Например, на Физическом и Канальном уровнях стек TCP/IP совместим с сетями Ethernet, Token Ring, FDDI и ATM, а также с шинными сетями с передачей маркера (token bus). На Физическом уровне стек TCP/IP поддерживает коаксиал, витую пару и оптоволокно, а также беспроводные коммуникации. Кроме того, на Канальном уровне стек совместим со стандартом IEEE 802.2 на управление логическим каналом и МАС-адресацию.
Эквивалентом Сетевого уровня в стеке TCP/IP является протокол IP. Следующим уровнем совместимости служит Транспортный уровень, на этом уровне могут работать оба протокола – TCP и UDP. Верхние уровни модели OSI представляются прикладными протоколами TCP/IP. Например, протокол Telnet функционирует на уровне, эквивалентном Сеансовому, а протоколы SMTP и FTP работают на уровнях, аналогичных Представительскому и Прикладному уровням OSI.
Резюме
· TCP/IP является самым распространенным в мире сетевым протоколом. Он является основой для Интернета и позволяет взаимодействовать между собой миллионам компьютеров и серверов, расположенных по всей планете. Протокол TCP был создан для надежной передачи данных, для чего устанавливаются соединения между узлами и используются сигналы, подтверждающие прием пакетов.
· Протокол UDP является альтернативой TCP. За счет того, что соединения между узлами не устанавливаются, он генерирует меньше служебной информации, но при этом менее надежен, чем TCP. Для передачи пакетов принимающим узлам в локальных и глобальных сетях применяется протокол IP. Он имеет методы адресации для идентификации узда и сети, в которой тот находится. Последней версией IP является протокол IPv6, имеющий расширенный формат адреса, что позволяет охватить большое количество новых адресов сетей и узлов, которые появляются, благодаря быстрому росту Интернета и различных сетей.
· Для надежной доставки пакета необходимо, чтобы каждый IP-адрес был уникальным. Для идентификации конкретного узла и сети, к которой он принадлежит, используются методы адресации IP.
· Важно понимать, что главное назначение протокола IPv6 – обеспечит логический переход от IPv4, чтобы приложения и сетевые устройства могли справляться с новыми требованиями по мере их возникновения
· Фактически TCP/IP является стеком протоколов и приложений, предоставляющих важные возможности. Для подключения рабочих станций к хост-компьютерам используется протокол Telnet (при этом рабочие станции выступают в роли терминалов). FTP – протокол, который миллионы клиентов используют ежедневно для загрузки файлов из Интернета. Протокол SMTP обеспечивает работу почтовых служб, a DNS преобразует имена компьютеров в их IP-адреса. Протокол DHCP автоматически назначает IP-адреса сетевым компьютерам. Протокол SNMP важен для сетей, поскольку может собирать информацию о производительности сети и может использоваться для поиска неисправностей. Протокол ARP позволяет компьютерам или устройствам определять МАС-адрес другого компьютера или устройства.
· Количество интернет-программ, приложений локальных и глобальных сетей, а также их возможности продолжают расти. Протокол TCP/IP сыграл важную роль в развитии сетей, и в будущем его значение сохранится. По мере того как увеличивается число пользователей сетей и сетевых приложений, да к тому же растет пропускная способность сетей, протокол TCP/IP, по всей вероятности, будет существенно модифицироваться особенно когда все большее число клиентов будут использовать Интернет-телевидение, голосовые технологии IP-сетей и средства мультимедиа
· Нужно заметить, что по мере развития протокола TCP/IP некоторые его компоненты стали в большей степени соответствовать эталонной модели OSI.
1. TCP протокол семейства TCP/IP
TCP - это один из самых широко используемых протоколов транспортного уровня. IP не предполагает установление соединения. Он просто передает дейтаграмму от узла к узлу, а при каком-либо нарушении она просто отбрасывается, о чем отправитель уведомляется ICMP-сообщением. Проверка принятых данных и повторная передача данных, не дошедших до получателя, ложится на TCP. Он следит за доставкой данных протоколом IP.
Главная функция TCP заключается в доставке сообщений без потерь. Для этого предварительно устанавливается соединение между приложением-отправителем и приложением-получателем, осуществляя надежную доставку дейтаграмм. Именно TCP производит повторную передачу искаженного или утерянного пакета.
TCP регламентирует передачу данных с прикладного уровня на уровень межсетевого взаимодействия и обратно. TCP должен отвечать за соблюдение приоритетов и защиту данных, за завершение приложения на более высоком уровне, ожидающего дейтаграммы, за обработку ошибок нижних уровней. за ведение таблиц состояний для всех потоков как в самом TCP, так и на других уровнях. Выделение всех этих функций в отдельный уровень освобождает разработчиков прикладных программ от решения задач управления потоком и обеспечения надежности передачи данных. Без TCP перечисленные функции пришлось бы реализовывать в каждой прикладной программе.
TCP является протоколом, ориентированным на соединение, обеспечивая сквозную передачу данных от машины-отправителя машине-получателю. Поскольку в нем применяется соединение, адресат, получивший дейтаграмму, должен уведомить отправителя об этом. Обычно используется термин виртуальный канал, чтобы указать, что машина-отправитель и машина-получатель обмениваются сообщениями, большинство из которых являются подтверждениями о получении или кодами ошибок.
TCP получает поток байтов и собирает его в пакеты, называемые также сегментами, добавляя заголовки в начало сегментов. В заголовок записывается контрольная сумма и порядковый номер пакета данных. Длина сегмента обычно определяется TCP или выбирается администратором системы. (В большинстве случаев длины сегмента TCP и дейтаграммы IP никак не связаны друг с другом.)
Процесс установления соединения начинается с передачи запроса на установления соединения от машины-отправителя машине-получателю. В запросе содержится число, называемое номером сокета. В ответ приложение-получатель посылает номер своего сокета. Номера сокетов отправителя и получателя однозначно определяют соединение между приложениями.
После установления соединения TCP начинает передавать сегменты сообщения IP-модулю, который преобразует каждый из них в одну или несколько дейтаграмм. Эти операции производятся без какого-либо участия TCP. Пройдя через сеть от машины-отправителя к машине-получателю, дейтаграммы поступают к IP-уровню последней. Он собирает из них отправленный сегмент и передает его TCP. В свою очередь сообщение от TCP поступает к приложению-получателю через используемый протокол прикладного уровня.
Если сообщение состоит из нескольких ТСР-сегментов (не путайте с IP-дейтаграммами), TCP на машине-получателе собирает его, исходя из порядковых номеров сегментов, хранящихся в заголовке. Если сегмент утерян или поврежден (последнее обнаруживается с помощью контрольной суммы в заголовке сегмента), отправителю посылается сообщение, содержащее порядковый номер ошибочного или потерянного сегмента. В этом случае отправитель повторно передает сегмент.
Если сообщение состоит только из одного сегмента TCP, то после сравнению полученной и вычисленной контрольных сумм программное обеспечение TCP на машине-получателе посылает отправителю подтверждение-квитанцию (АСК - acknowledgement). Выдача квитанции в ответ на принятый сегмент называется квитированием.
Как и для большинства протоколов с установлением соединения, важную роль в TCP играют таймеры. Сообщение считается переданным не полностью, если квитанция не поступила в течение заданного периода ожидания. Тем самым сокращаются затраты времени на бесполезное ожидание подтверждения в случае потери данных. При этом обычно производится повторная передача соответствующих сегментов.
В TCP не предусмотрена передача квитанции, если сегмент доставлен искаженным. Пропажу сегмента обнаруживают с помощью таймера повторной передачи: если квитанция на сегмент не поступила вовремя, он считается потерянным и передается повторно.
Вместе с тем применение таймеров обусловливает ряд проблем. Согласно протоколу TCP, квитанция на принятый сегмент выдается только после поступления всех отправленных ранее сегментов того же сообщения. Иначе говоря, квитанция подтверждает получение всех ранее отправленных сегментов сообщения. Так как сегменты доставляются машине-получателю в произвольном порядке, выдача квитанции может задержаться до получения всего сообщения, а это в свою очередь может привести к повторной передаче правильно принятых сегментов.
Повторно доставленные копии сегментов, отправленные из-за истечения установленного времени ожидания квитанций, отбрасываются программным обеспечением машины-получателя. При этом уведомление отправителю не высылается, так как ему важно лишь знать, что сегмент получен.
В передающей машине данные, получаемые программным обеспечением TCP от прикладного уровня, накапливаются в буфере. Момент их упаковки в сегмент обычно определяется на уровне TCP. Данные из буфера могут быть также отправлены в срочном порядке по требованию обслуживаемого процесса прикладного уровня. Эта операция называется выталкиванием. Ее применение вызывается установкой специального флажка в заголовке протокола прикладного уровня.
2. Порты и сокеты
Приложение, использующие TCP (или UDP), однозначно определяется некоторым числом, которое называется номером порта. В принципе номера портов можно выбирать произвольно, но для облегчения взаимодействия между различными реализациями программного обеспечения TCP, приняты соглашения о номерах портов, закрепленных за определенными службам.
Как правило, порты между 0 и 255 отводят системным процессам, а порты выше 255 - пользовательским. В Internet распределением портов занимается Управление Internet по нумерации (Internet Assigned Numbers Authority, IANA). Список номеров портов для служб Internet может быть найден в соответствующем рабочем предложении (RFC). Выдержки из него приведены в таблице. Порты 0 и 255 зарезервированы.
Любой канал связи в слое TCP однозначно определяется двумя числами, эта комбинация называется сокетом. Сокет определяется IP-адресом машины и номером порта, используемым программным обеспечением TCP. При соединении любая машина однозначно определена IP-адресом, а каждый выполняющийся процесс - портом, таким образом, соединение между двумя / процессами однозначно определяется сокетом.
3. Таймеры TCP
Таймеры нужны для того, чтобы избежать чрезмерных задержек и состояний ожидания. Они позволяют легко обойти некоторые подводные камни при передаче данных. Роль различных таймеров, используемых TCP, в передаче данных рассматривается в последующих разделах.
Таймер повторной передачи. Таймер повторной передачи отмеряет время ожидания квитанции на отправленный сегмент (retransmission timeout, RTO). Этот параметр устанавливается с учетом типа сети и скоростей доставки сообщений. Если квитанция не поступает вовремя, сегмент отправляется вновь, а период повторной передачи увеличивается по экспоненциальному закону. Так повторяется несколько раз пока период повторной передачи не достигнет некоторого заданного предела, после чего обслуживаемому процессу выдается сообщение об ошибке.
Начальное время ожидания квитанции путем устанавливается измерения времени между отправлением сегмента и получением квитанции на него. Эта величина называется временем двойного прохода. Математическое ожидание (то есть среднее значение) измеренных значений называется сглаженным временем двойного прохода. Оно вычисляется по формуле и может быть увеличено, чтобы учесть непредвиденные задержки.
Таймер задержки. Получателю могут поступать сегменты и после того, как соединение было им закрыто. Таймер задержки (quiet timer) исключает повторное открытие только что закрытого порта, вызываемое прибывшими сегментами. Длительность задержки обычно выбирают равной удвоенному значению максимального времени жизни сегмента (оно совпадает со значением поля времени жизни в заголовке IP-дейтаграммы). Задержка может достигать 30 секунд. В ответ на каждый пришедший в этот период сегмент, отправляется сообщение об ошибке.
Таймер запросов. Таймер запросов (persistence timer) предусмотрен для такого довольно редкого случая, когда получатель, приостановивший передачу данных путем посылки сегмента с нулевым размером окна, отправляет своему партнеру сообщение о возобновлении работы, но тот его не получает. Чтобы продолжить передачу, отправитель с периодом, задаваемым таймером, посылает запросы с одним байтом данных. В ответ на них он получает сегменты, где указан размер окна. Если размер окна нулевой, адресат по-прежнему занят, а если нет, то он готов принимать полезную информацию, после чего передача данных возобновляется. Период повторения запросов определяются таймером запросов.
Таймер контроля и таймер разъединения. Эти таймеры предназначены для проверки соединения. Таймер контроля (keep-alive timer) вызывает периодическую выдачу сегментов без поля данных, а таймер разъединения (idle timer) задает максимальное время ожидания ответа. По истечении этого срока соединение считается разорванным.
Как правило период таймера контроля устанавливается на прикладном уровне, его значения лежат между 5 и 45 секундами. Максимальное время ожидания обычно принимается равным 360 секундам.
4. Сегменты данных протокола TCP
TCP взаимодействует с нижележащим уровнем по протоколу IP и с прикладным уровнем, расположенным выше, с помощью сервисных примитивов. Кроме того он должен взаимодействовать с программным обеспечением TCP на других машинах. Для последней задачи используются протокольные блоки данных, которые на языке TCP называются сегментами. Заголовок сегмента состоит из следующих полей:
Порт отправителя (Source Port), 16-разрядное поле, идентифицирующее локальный порт-источник (обычно это пользовательский процесс прикладного уровня).
Порт получателя (Destination Port), 16-разрядное поле с номером порта-получателя
Позиция сегмента (Sequence Number). Поле содержит порядковый номер j первого байта данных сегмента в сообщении.
Первый ожидаемый байт (Acknowledgement Number). Используется 1 тогда, когда сегмент служит квитанцией (флаг АСК=1). Содержит по- / рядковый номер первого ожидаемого байта. Все байты сообщения с меньшими порядковыми номерами считаются квитированными.
Смещение данных (Data Offset). Длина заголовка, измеренная в 32-раз- / рядных словах. Служит указателем на начало поля данных.
Резерв (Reserved). Пока не используется и должно быть обнулено. Размер поля 6 бит.
Флаги. В состоянии 1 они означают следующее.
Флаг URG. Поле срочности данных подлежит обработке. Флаг АСК. Сегмент служит квитанцией.
Флаг PSH. Сегмент должен быть "вытолкнут" - послан в первую очередь.
Флаг RST. Сегмент служит запросом на установку первоначальных параметров соединения.
Флаг SYN. Сегмент служит для синхронизации счетчиков переданных данных при установлении соединения.
Флаг FIN. Означает, что отправлен последний байт сообщения. Эквивалент маркера конца передачи (EOT) в кодировке ASCII.
Размер окна (Window). Указывает, сколько байтов готов принять получатель.
Контрольная сумма (Checksum), 16-разрядная контрольная сумма определяется для блока данных, состоящего из псевдозаголовка и самого сегмента, 96-разрядный псевдозаголовок, предшествует заголовку TCP и создается в процедуре вычисления контрольной суммы. Псевдозаголовок содержит IP-адрес отправителя, IP-адрес получателя, идентификатор протокола и длину сегмента. Эти параметры передаются IP при отправке сегмента и используются протоколом IP при его получении. Процедура подсчета контрольной суммы занимает довольно много времени.
Указатель срочности данных (Urgent Pointer). Используется, когда флаг URG=1. Представляет собой смещение относительно номера последовательности в заголовке. Специальная обработка срочных данных производится на прикладном уровне, а не на уровне TCP.
Опции (Options). Подобно одноименному полю в IP-заголовке каждая опция содержит свой номер (один байт), свою длину в байтах и значение. В настоящее время имеется только три опции:
О - Конец списка опций (End of Option List);
1 - Отсутствие операции (No Operations);
2 - Максимальный размер сегмента (Maximum Segment Size).
Заполнитель (Padding). Дополняет заголовок до целого числа 32-разрядных слов.
За заголовком следует поле данных, длина которого не фиксирована. Благодаря опции Максимальный размер сегмента программное обеспечение TCP получателя может выбрать подходящий размер буфера данных.
5. Соединение по протоколу TCP
Обмен данными по протоколу TCP регулируется многочисленными правилами. Процедуры установления соединения, передачи полезной информации и разрыва соединения обычно представляют конечными автоматами. (TCP - это протокол, управляемый состояниями, и потому его операции зависят от состояний флагов или аналогичных структур). Вместо них я буду использовать простые схемы взаимодействия.
Существует два варианта установления соединений: собственно соединение и принятие соединения. Перед запуском соединения необходимо инициализировать и запустить WSA - Windows Socket Architecture. Выполним для этого функцию
1. WSAStartup (wVersionRequested, lpWSAData): Integer;
где:
wVersionRequested - необходимый номер версии для запуска приложения. В нашем случае этот параметр должен быть равен $0101.
lpWSAData - сруктура, в которой разъём WSA возвращает: номер версии, описание, статус, максимальное количество разъёмовсокетов, информация разработчика и т. д. Эта структура значения для нас не имеет.
Код ошибки, прозошедшей в случае неудачного выполнения любой функции, связанной с разъёмами сокетами можно получить с помощью функции WSAGetLastError. Расшифровка этих кодов находится в файле sock.hlp, входящем в поставку Delphi.
Вариант "Соединение"
Прежде чем соединять разъёмы,сокеты, нужно создать разъём сокет функцией
2. Socket (af, type, protocol) : Integer;
где:
af - семейство адресов, в нашем случае af:= PF_INET.
type - тип разъёма сокета (SOCK_STREAM, базирующийся на семействе адресов TCP и ориенти рованный на соединения и SOCK_DGRAM, базирующийся на семействе адресов UDP и работающий без соединений (используем SOCK_STREAM, т. к., он более надежный)).
protocol - параметр, определяющий некоторые особенности протокола, в нашем случае - 0.
После выполнения функция возвращает значение типа Integer, который является указателем на новый разъёмсокет. Далее, следует становить опции структуры TSockAddrIn, в которой содержится информация о соединении. У этой структуры много полей, нас же интересуют только три из них:
sin_family - содержит имя семейства адресов. Этот параметр аналогичен af.
sin_port - адрес номер порта, через который идет обмен с разъёмомсокетом. Адрес порта должен быть больше 1024, т. к. меньшие значения зарезервированы для существующих приложений. Номер порта должен быть задан в так называемом сетевом формате, когда старшие байты идут по младшим адресам. Это отличается от принятом в x86 (Intel) архитектуре хранении, поэтому необходимо выполнить преобразование с помощью функции htons() из формата данной архитектуры в сетевой (htons расшифровывается, как Host To Network, Short (т.е. 16-бит)). Обратный перевод можно выполнить с помощью функции ntohs().
sin_addr - у этого поля есть подполе s_addr: integer, которому мы должны присвоить значение функции inet_addr(iAddr). Эта функция преобразует строковый адрес IP в 4-байтовое число, т. е., iAddr - адрес компьютера, с которым мы хотим связаться. Получить адрес можно, выполнив на искомом компьютере команду NETSTAT -r. Адрес также должен быть представлен в сетевом формате, однако функция inet_addr() уже возвращает результат в сетевом формате и выполнять преобразование в этом случае не нужно. Если это необходимо выполнить, то можно использовать функции htonl() и ntohl(). Примечание: при передаче по сети данных в двоичном формате следует помнить о разной интерпретации порядка байт в слове на различных архитектурах и преобразовывать данные в сетевой формат.
Теперь, когда мы заполнили структуру адреса, выполняем функцию
3. Connect(Sock, SA, SASize): Integer;
где:
SASize - размер SA.
Если в результате выполнения Connect"a возвратился SOCKET_ERROR, то функция выполнилась неправильно. (см. Пример) В противном случае, возвращается 0.
После установления соединения можно применять функции приема и пересылки данных, такие, как recv, send.
Функция коннект через API посылает сообщение к драйверу протокола ТСР, а тот, в свою очередь, через протоколы нижнего уровня посылает инициализационный пакет компьютеру-адресату для установления соединения. Функция завершается, когда соединение установлено.
4. Recv(Sock, Buf, BufSize, Flags) : Integer;
где:
Sock - результат выполнения функции Socket.
Buf - буфер, куда попадут принятые данные.
BufSize - размер буфера.
Flags - флаги. Может иметь значения MSG_PEEK или MSG_OOB. Установим это поле в 0.
5. Send(Sock, Buf, BufSize, Flags) : Integer;
где:
Sock - результат выполнения функции Socket.
Buf - буфер посылаемых данных.
BufSize - размер буфера.
Flags - флаги. Равно 0.
Если не произошло ошибки, возвращается количество принятых байт, если произошло корректное закрытие соединения - 0, иначе в случае разрыва - возвращается отрицательное число.
Для завершения работы соединения применим функцию
6. CloseSocket(Sock) : Integer;
где:
Sock - результат выполнения функции Socket.
Вариант "Принятие cоединения"
Другим вариантом установления соединения является его принятие. Вообще говоря, в любом соединении должны присутствовать оба варианта - соединения и приема соединения (один компьютер является сервером, он выполняет прием, друго клиентом, он инициирует прием) . Порядок действий по инициализации сервера такой же, как и у клиента, с той разницей, что:
вместо адреса другого компьютера в структуру TSockAddrIn мы заносим свой адрес или "0.0.0.0" для принятия всех приходящих соединений.
вместо Connect"a выполняем функци:
7. Bind(Sock, SA, SASize) : Integer;
где:
Sock - результат выполнения функции Socket.
SA - заполненная нами структура TSockAddrIn.
SASize - ее размер.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Эта функция привязывает наш разъём сокет к указанному нами адресу.
8. Listen(Sock, Backlog) : Integer;
где:
Sock - результат выполнения функции Socket.
Backlog - максимальный размер очереди ожидающих соединений.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Эта функция устанавливает разъём сокет в режим прослушивания канала.
9. Accept(Sock, SA, SASize) : Integer;
где:
Sock - результат выполнения функции Socket.
SA - заполненная нами структура TSockAddrIn.
SASize - размер SA.
Если в результате выполнения Accept"a возвратился SOCKET_ERROR, то функция выполнилась неправильно. (см. Пример) В противном случае, возвращается 0.
После установления соединения можно применять функции приема и пересылки данных, такие, как recv, send. Функция завершается, когда устанавливается соединение.
После соединения
После соединения можно приступать к обмену информацией с помощью вышеуказанных функций recv и send. Можно также добавить, что разъёмы сокеты классифицируются, как блокирующиеся и неблокирующиеся. Первые ждут окончания операции, вторые - не ждут.
Для установки разъёмов сокетов в неблокируемое состояние используют функцию:
ioctlsocket(Sock, CMD, Value) : Integer;
где:
Sock - результат выполнения функции Socket.
CMD - команда управления разъёмом сокетом (в нашем сучае - константа FIONBIO).
Value - ее значение 0 - вкл, 1 - выкл.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
При непосредственной работе с разъемами сокетами вы далеко не всегда получите на приёмнике именно то количество байт, которое посылали, и вы должны через некоторое время "дочитать" байты из разъёмасокета. Это объясняется принципом организации потоковых разъемовсокетов, которые воспринимаются в данном случае как файлы. Можно, однако отключить алгоритм NAGLE, который управляет разбиением сообщений на дейтаграммы с помощью следующей функции:
setsockopt(Sock, Level, Parameter, PChar(Value), ValueSize) : Integer;
где:
Sock - результат выполнения функции Socket.
Level - уровень команды.
Parameter - команда управления разъёмом сокетом (в нашем сучае - константа TCP_NODELAY).
Value - ее значение (0 - вкл, 1 - выкл).
ValueSize - размер Value.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Определить адрес корреспондента можно из структуры TSockAddrIn после выполнения команды accept (см. Выше) либо с помощью функции getpeername (см. Delphi sock.hlp).
Определить имя компьютера по адресу можно с помощью функции GetHostByAddr (см. Delphi sock.hlp).
В современном мире информация распространяется за считанные секунды. Вот только что появилась новость, а через секунду она уже доступна на каком-либо сайте в сети интернет. Интернет считается одной из самых полезных разработок человеческого разума. Чтобы пользоваться всеми благами, которые предоставляет интернет, необходимо подключиться к этой сети.
Мало кто знает, что простой процесс посещения веб-страничек подразумевает незаметную для пользователя, сложную систему действий. Каждый переход по ссылке активирует сотни различных вычислительных операций в сердце компьютера. В их числе передачи запросов, прием ответов и многое другое. За каждое действие в сети отвечают так называемые протоколы TCP/IP. Что они собой представляют?
Любой протокол интернета TCP/IP работает на своем уровне. Иными словами, каждый занимается своим делом. Все семейство TCP/IP протоколов одновременно выполняет колоссальную работу. А пользователь в это время видит только яркие картинки и длинные строки текста.
Понятие стека протоколов
Стек протоколов TCP/IP - это организованный набор основных сетевых протоколов, который иерархическим способом разделен на четыре уровня и представляет собой систему транспортного распределения пакетов по компьютерной сети.
TCP/IP - это наиболее известный стек сетевых протоколов, который используется на данный момент. Принципы стека TCP/IP применяются как в локальных, так и в глобальных сетях.
Принципы использования адресов в стеке протоколов
Стек сетевых протоколов TCP/IP описывает пути и направления отправки пакетов. Это основная задача всего стека, выполняющаяся на четырех уровнях, которые взаимодействуют между собой протоколированным алгоритмом. Для правильной отправки пакета и его доставки ровно в ту точку, которая его запросила, была введена и стандартизирована адресация IP. Этому послужило наличие следующих задач:
- Адреса различного типа, должны быть согласованы. Например преобразование домена сайта в IP адрес сервера и обратно, или преобразование имени узла в адрес и обратно. Таки образом становится возможен доступ к точке не только с помощью IP адреса, но и по интуитивному названию.
- Адреса должны быть уникальны. Это вызвано тем, что в некоторых частных случаях пакет должен попасть только в одну конкретную точку.
- Необходимость конфигурирования локальных вычислительных сетей.
В малых сетях, где используется несколько десятков узлов, все эти задачи выполняются элементарно, с помощью простейших решений: составление таблицы с описанием принадлежности машины и соответствующего ей IP адреса, или можно вручную раздать всем сетевым адаптерам IP адреса. Однако для крупных сетей на тысячу или две тысячи машин задача ручной выдачи адресов не кажется такой выполнимой.
Именно поэтому для сетей TCP/IP был изобретен специальный подход, который и стал отличительной чертой стека протоколов. Было введено понятие - масштабируемость.
Уровни стека протоколов TCP/IP
Здесь существует определенная иерархия. Стек протоколов TCP/IP предусматривает четыре уровня, каждый из которых обрабатывает свой набор протоколов:
Прикладной уровень : создан для обеспечения работы пользователя с сетью На этом уровне обрабатывается все то, что видит и делает пользователь. Уровень позволяет пользователю получить доступ к различным сетевым службам, например: доступ к базам данных, возможность прочитать список файлов и открыть их, отправить электронное сообщение или открыть веб-страницу. Вместе с пользовательскими данными и действиям, на этом уровне передается служебная информация.
Транспортный уровень: это механизм передачи пакетов в чистом виде. На этом уровне совершенно не имеет значения ни содержимое пакета, ни его принадлежность к какому бы то ни было действию. На этом уровне имеет значение только адрес узла отправки пакета и адрес узла, на который пакет должен быть доставлен. Как правило, размер фрагментов, передаваемых с использованием разных протоколов, может изменяться, потому на этом уровне блоки информации могут дробиться на выходе и собираться в единое целое в точке назначения. Этим обусловлена возможная потеря данных, если в момент передачи очередного фрагмента произойдет кратковременный разрыв соединения.
Транспортный уровень включает в себя много протоколов, которые делятся на классы, от простейших, которые просто передают данные, до сложных, которые оснащены функционалом подтверждения приема, или повторного запроса недополученного блока данных.
Данный уровень, предоставляет вышестоящему (прикладному) два типа сервиса:
- Осуществляет гарантированную доставку, с помощью протокола ТСР.
- Осуществляет доставку по возможности по протоколу UDP.
Чтобы обеспечить гарантированную доставку, согласно протоколу TCP устанавливается соединение, которое позволяет выставлять на пакетах нумерацию на выходе и подтверждать их прием на входе. Нумерация пакетов и подтверждение приема - это так называемая служебная информация. Этот протокол поддерживает передачу в режиме "Дуплекс". Кроме того, благодаря продуманному регламенту протокола, он считается очень надежным.
Протокол UDP предназначен для моментов, когда невозможно настроить передачу по протоколу TCP, либо приходится экономить на сегменте сетевой передачи данных. Также протокол UDP может взаимодействовать с протоколами более высокого уровня, для повышения надежности передачи пакетов.
Сетевой уровень или "уровень интернета": базовый уровень для всей модели TCP/IP. Основной функционал этого уровня идентичен одноименному уровню модели OSI и описывает перемещение пакетов в составной сети, состоящей из нескольких, более мелких подсетей. Он связывает соседние уровни протокола TCP/IP.
Сетевой уровень является связующим между вышестоящим транспортным уровнем и нижестоящим уровнем сетевых интерфейсов. Сетевой уровень использует протоколы, которые получают запрос от транспортного уровня, и посредством регламентированной адресации передают обработанный запрос на протокол сетевых интерфейсов, указывая, по какому адресу направить данные.
На этом уровне используются следующие сетевые протоколы TCP/IP: ICMP, IP, RIP, OSPF. Основным, и наиболее популярным на сетевом уровне, конечно же является протокол IP (Internet Protocol). Основной его задачей является передача пакетов от одного роутера к другому до тех пор, пока единица данных не попадет на сетевой интерфейс узла назначения. Протокол IP разворачивается не только на хостах, но и на сетевом оборудовании: маршрутизаторах и управляемых коммутаторах. Протокол IP работает по принципу негарантированной доставки с максимальными усилиями. Т. е., для отправки пакета нет необходимости заранее устанавливать соединение. Такой вариант приводит к экономии трафика и времени на движении лишних служебных пакетов. Пакет направляется в сторону назначения, и вполне возможно, что узел останется недоступным. В таком случае возвращается сообщение об ошибке.
Уровень сетевых интерфейсов: отвечает за то, чтобы подсети с разными технологиями могли взаимодействовать друг с другом и передавать информацию в том же режиме. Реализовано это двумя простыми шагами:
- Кодирование пакета в единицу данных промежуточной сети.
- Преобразование информации о месте назначения в стандарты необходимой подсети и отправка единицы данных.
Этот подход позволяет постоянно расширять количество поддерживаемых технологий построения сетей. Как только появляется новая технология, она сразу попадает в стек проколов TCP/IP и позволяет сетям со старыми технологиями передавать данные в сети, построенные с применением более современных стандартов и способов.
Единицы передаваемых данных
За время существования такого явления, как протоколы TCP/IP, установились стандартные термины по части единиц передаваемых данных. Данные при передаче могут дробиться по-разному, в зависимости от технологий, используемых сетью назначения.
Чтобы иметь представление о том, что и в какой момент времени происходит с данными, нужно было придумать следующую терминологию:
- Поток данных - данные, которые поступают на транспортный уровень от протоколов вышестоящего прикладного уровня.
- Сегмент - фрагмент данных, на которые дробится поток по стандартам протокола TCP.
- Датаграмма (особо безграмотные произносят как "Дейтаграмма") - единицы данных, которые получаются путем дробления потока с помощью протоколов, работающих без установления соединения (UDP).
- Пакет - единица данных, производимая посредством протокола IP.
- Протоколы TCP/IP упаковывают IP-пакеты в передаваемые по составным сетям блоки данных, которые называются кадрами или фреймами .
Типы адресов стека протоколов TCP/IP
Любой протокол передачи данных TCP/IP для идентификации узлов использует один из следующих типов адресов:
- Локальные (аппаратные) адреса.
- Сетевые адреса (IP адреса).
- Доменные имена.
Локальные адреса (MAC-адреса) - используются в большинстве технологий локальных вычислительных сетей, для идентификации сетевых интерфейсов. Под словом локальный, говоря о TCP/IP, следует понимать интерфейс, который действует не в составной сети, а в пределах отдельно взятой подсети. Например, подсеть интерфейса, подключенного к интернет - будет локальной, а сеть интернет - составной. Локальная сеть может быть построена на любой технологии, и независимо от этого, с точки зрения составной сети машина, находящаяся в отдельно выделенной подсети, будет называться локальной. Таким образом, когда пакет попадает в локальную сеть, дальше его IP адрес ассоциируется с локальным адресом, и пакет направляется уже на MAC-адрес сетевого интерфейса.
Сетевые адреса (IP-адреса). В технологии TCP/IP предусмотрена собственная глобальная адресация узлов, для решения простой задачи - объединения сетей с разной технологией в одну большую структуру передачи данных. IP-адресация совершенно не зависит от технологии, которая используется в локальной сети, однако IP адрес позволяет сетевому интерфейсу представлять машину в составной сети.
В итоге была разработана система, при которой узлам назначается IP адрес и маска подсети. Маска подсети показывает, какое количество бит отводится под номер сети, а какое количество под номер узла. IP адрес состоит из 32 бит, разделенных на блоки по 8 бит.
При передаче пакета ему назначается информация о номере сети и номере узла, в который пакет должен быть направлен. Сначала маршрутизатор направляет пакет в нужную подсеть, а потом выбирается узел, который его ждет. Этот процесс осуществляется протоколом разрешения адресов (ARP).
Доменные адреса в сетях TCP/IP управляются специально разработанной системой доменных имен (DNS). Для этого существуют серверы, которые сопоставляют доменное имя, представленное в виде строки текста, с IP адресом, и отправляет пакет уже в соответствии с глобальной адресацией. Между именем компьютера и IP адресом не предусмотрено соответствий, поэтому, чтобы преобразовать доменное имя в IP адрес, передающему устройству необходимо обратиться к таблице маршрутизации, которая создается на DNS сервере. Например, мы пишем в браузере адрес сайта, DNS сервер сопоставляет его с IP адресом сервера, на котором сайт расположен, и браузер считывает информацию, получая ответ.
Кроме сети интернет, есть возможность выдавать компьютерам доменные имена. Таким образом, упрощается процесс работы в локальной сети. Пропадает необходимость запоминать все IP-адреса. Вместо них можно придумать каждому компьютеру любое имя и использовать его.
IP-адрес. Формат. Составляющие. Маска подсети
IP адрес - 32-битное число, которое в традиционном представлении записывается в виде чисел, от 1 до 255, разделенных между собой точками.
Вид IP адреса в различных форматах записи:
- Десятичный вид IP адреса: 192.168.0.10.
- Двоичный вид того же IP адреса: 11000000.10101000.00000000.00001010.
- Запись адреса в шестнадцатеричной системе счисления: C0.A8.00.0A.
Между ID сети и номером точки в записи нет разделительного знака, но компьютер способен их разделять. Для этого существует три способа:
- Фиксированная граница. При этом способе весь адрес условно делится на две части фиксированной длины побайтно. Таким образом, если под номер сети отдать один байт, тогда мы получим 2 8 сетей по 2 24 узлов. Если границу сдвинуть еще на байт вправо, тогда сетей станет больше - 2 16 , а узлов станет меньше - 2 16 . На сегодняшний день подход считается устаревшим и не используется.
- Маска подсети. Маска идет в паре с IP адресом. Маска имеет последовательность значений "1" в тех разрядах, которые отведены под номер сети, и определенное количество нулей в тех местах IP адреса, которые отведены на номер узла. Граница между единицами и нулями в маске - это граница между идентификатором сети и ID узла в IP-адресе.
- Метод классов адресов. Компромиссный метод. При его использовании размеры сетей не могут быть выбраны пользователем, однако есть пять классов - А, В, С, D, Е. Три класса - А, В и С - предназначены для различных сетей, а D и Е - зарезервированы для сетей специального назначения. В классовой системе каждый класс имеет свою границу номера сети и ID узла.
Классы IP адресов
К классу А относятся сети, в которых сеть идентифицируется по первому байту, а три оставшихся являются номером узла. Все IP адреса, которые имеют в своем диапазоне значение первого байта от 1 до 126 - это сети класса А. Количественно сетей класса А получается совсем мало, зато в каждой из них может быть до 2 24 точек.
Класс В - сети, в которых два высших бита равны 10. В них под номер сети и идентификатор точки отводится по 16 бит. В результате получается, что количество сетей класса В в большую сторону отличается от количества сетей класса А количественно, но они имеют меньшее количество узлов - до 65 536 (2 16) шт.
В сетях класса С - совсем мало узлов - 2 8 в каждой, но количество сетей огромно, благодаря тому, что идентификатор сети в таких структурах занимает целых три байта.
Сети класса D - уже относятся к особым сетям. Он начинается с последовательности 1110 и называется групповым адресом (Multicast adress). Интерфейсы, имеющие адреса класса А, В и С, могут входить в группу и получать вдобавок к индивидуальному еще и групповой адрес.
Адреса класса Е - в резерве на будущее. Такие адреса начинаются с последовательности 11110. Скорее всего, эти адреса будут применяться в качестве групповых, когда наступит нехватка IP адресов в глобальной сети.
Настройка протокола TCP/IP
Настройка протокола TCP/IP доступна на всех операционных системах. Это - Linux, CentOS, Mac OS X, Free BSD, Windows 7. Протокол TCP/IP требует только наличия сетевого адаптера. Разумеется, серверные операционные системы способны на большее. Очень широко, с помощью серверных служб, настраивается протокол TCP/IP. IP адреса в в обычных настольных компьютерах задаются в настройках сетевых подключений. Там настраивается сетевой адрес, шлюз - IP адрес точки, имеющий выход в глобальную сеть, и адреса точек, на которых располагается DNS сервер.
Протокол интернета TCP/IP может настраиваться в ручном режиме. Хотя не всегда в этом есть необходимость. Можно получать параметры протокола TCP/IP с динамически-раздающего адреса сервера в автоматическом режиме. Такой способ используют в больших корпоративных сетях. На DHCP сервер можно сопоставить локальный адрес к сетевому, и как только в сети появится машина с заданным IP адресом, сервер сразу даст ему заранее подготовленный IP адрес. Этот процесс называется резервирование.
TCP/IP Протокол разрешения адресов
Единственный способ установить связь между MAC-адресом и IP адресом - ведение таблицы. При наличии таблицы маршрутизации каждый сетевой интерфейс осведомлен о своих адресах (локальном и сетевом), однако встает вопрос, как правильно организовать обмен пакетами между узлами, применяя протокол TCP/IP 4.
Для чего был придуман протокол разрешения адресов (ARP)? Для того, чтобы связывать семейство TCP/IP протоколов и других систем адресации. На каждом узле создается таблица соответствия ARP, которая заполняется путем опроса всей сети. Происходит это после каждого выключения компьютера.
ARP таблица
Так выглядит пример составленной ARP таблицы.
Команда netstat -p протокол выводит статистику по указанному протоколу (udp , tcp , sctp , ip , icmp), который может быть задан либо по имени, либо по псевдониму.
Имена и псевдонимы некоторых протоколов указаны в файле /etc/protocols . Пустой отчет означает, что информация об указанном протоколе отсутствует. Если для указанного протокола не установлена функция сбора статистики, то выдается сообщение о том, что задан неизвестный протокол.
Ниже приведен пример вывода команды для протокола ip: # netstat -p ip ip: 45775 пакетов получено 0 с ошибками контрольной суммы заголовка 0 с размером меньше минимального 0 с размером данных < длины данных 0 с длиной заголовка < размера данных 0 с длиной данных < длины заголовка 0 с неправильными параметрами 0 с неправильным номером версии 0 фрагментов получено 0 фрагментов отброшено (повтор или нехватка памяти) 0 фрагментов отброшено после истечения тайм-аута 0 пакетов успешно пересобрано 45721 пакет для данного хоста 51 пакет неизвестных/не поддерживаемых протоколов 0 пакетов переслано 4 пакета не удалось переслать 0 перенаправлений 33877 пакетов отправлено с данного узла 0 пакетов отправлено с искусственным заголовком ip 0 исходящих пакетов отброшено из-за отсутствия буферов и пр. 0 исходящих пакетов отброшено из-за отсутствия маршрута 0 дейтаграмм вывода фрагментировано 0 фрагментов создано 0 дейтаграмм не удалось разбить на фрагменты 0 многоцелевых пакетов IP отброшено из-за отсутствия получателя 0 успешных циклов поиска путей MTU 1 повторная попытка цикла поиска путей MTU 3 оценки поиска путей MTU без ответа 3 оценки поиска путей MTU с ответом 1 снижение количества операций поиска путей MTU 8 пакетов поиска путей MTU отправлено 0 сбоев выделения путей поиска путей MTU 0 переполнений ipintrq 0 с неверным источником 0 пакетов обработано нитями 0 пакетов отброшено нитями 0 пакетов отброшено по причине переполнения буфера входящих пакетов сокета 0 пакетов обнаружения сбоев в работе шлюза отправлено 0 ошибок выделения пакетов функции обнаружения сбоев в работе шлюза 0 ошибок выделения шлюзов функции обнаружения сбоев в работе шлюза
- Пакетов получено
Общее число полученных дейтаграмм IP.
- Неправильных контрольных сумм заголовка
или Фрагментов отброшено
Если значение в поле неправильных контрольных сумм заголовка или фрагментов отброшено из-за повтора или нехватки памяти отлично от нуля, то либо пакеты повреждаются при передаче по сети, либо размер очереди приема драйвера устройства недостаточен.
- Фрагментов получено
Общее число полученных фрагментов.
- Отброшено из-за тайм-аута
Ненулевое число фрагментов, отброшенных из-за тайм-аута, означает, что из-за высокой загруженности сети счетчик TTL фрагментов ip достигает нулевого значения до того, как будут получены все фрагменты дейтаграммы. Для того чтобы исправить эту ошибку, увеличьте значение параметра ipfragttl с помощью команды no . Другая возможная причина - отсутствие свободных буферов. В этом случае нужно увеличить значение thewall .
- Пакетов отправлено этим хостом
Число дейтаграмм IP, созданных и отправленных из локальной системы. Этот счетчик не учитывает пересланные (транзитные) дейтаграммы.
- Фрагментов создано
Число фрагментов, созданных в локальной системе при отправке дейтаграмм.
При просмотре статистики протокола IP обратите внимание на отношение числа полученных пакетов к числу полученных фрагментов. В сетях с небольшим значением MTU должно фрагментироваться не более 10 процентов пакетов. Большое число фрагментов означает, что протоколы более высокого уровня на удаленных хостах передают данные блоками, превышающими размер MTU интерфейса. Кроме того, пакеты могут фрагментироваться маршрутизаторами и шлюзами. То же самое справедливо для отношения числа отправленных пакетов к числу созданных фрагментов.
Фрагментация увеличивает нагрузку на процессор, поэтому важно определить ее причину. Учтите, что фрагментация неизбежна при работе некоторых приложений. Например, фрагментация происходит, если приложение отправляет данные небольшими порциями. Если же фрагментация выполняется несмотря на то, что приложение отправляет данные большими блоками, определите причину фрагментации. Возможно, указанный размер MTU интерфейса не совпадает с размером MTU удаленных систем.
Ниже приведен пример вывода команды для протокола udp: # netstat -p udp udp: 11623 дейтаграмм получено 0 неполных заголовков 0 полей неправильной длины 0 неправильных контрольных сумм 620 отброшено из-за отсутствия сокета 232850 дейтаграмм оповещения и многоцелевых дейтаграмм отброшено из-за отсутствия сокета 0 переполненных буферов сокетов 14 дейтаграмм доставлено 12 дейтаграмм отправлено
Ниже описаны поля, выделенные в выводе команды:
- Неправильных контрольных сумм
Неправильные контрольные суммы появляются в результате сбоя адаптера или повреждения кабеля.
- Отброшено из-за отсутствия сокета
Число полученных дейтаграмм UDP, целевой порт которых не был открыт. В этом случае возвращается сообщение Получатель ICMP недоступен - Порт недоступен. Для дейтаграмм оповещения UDP сообщения об ошибках ICMP не отправляются. Если число отброшенных дейтаграмм велико, то, скорее всего, возникают ошибки при работе с сокетами в приложении.
- Переполнений буфера сокета
Переполнения буфера сокета связаны с недостаточным количеством сокетов приема и передачи UDP, демонов nfsd или недостаточной величиной параметров nfs_socketsize , udp_recvspace и sb_max .
Если в выводе команды netstat -p udp число переполнений буфера сокета отлично от нуля, рекомендуется увеличить число демонов nfsd на сервере. Сначала проверьте, не перегружен ли процессор или подсистема ввода-вывода системы, а затем вызовите команду no -a и убедитесь, что для параметров протоколов других уровней установлены рекомендуемые значения. Если система перегружена, необходимо уменьшить нагрузку или увеличить объем ресурсов системы.
Ниже приведен пример вывода команды для протокола tcp: # netstat -p tcp tcp: 576 пакетов отправлено 512 пакетов данных (62323 байта) 0 пакетов данных (0 байт) передано повторно 55 пакетов уведомления (28 отложено) 0 срочных пакетов 0 пакетов проверки окна 0 пакетов обновления окна 9 управляющих пакетов 0 операций largesend 0 байт отправлено с помощью largesend 0 байт в максимальном пакете largesend 719 пакетов получено 504 пакетов уведомления (для 62334 байт) 19 повторных уведомлений 0 уведомлений о неотправленных данных 449 пакетов (4291 байт) получено в правильном порядке 8 полных копий пакетов (8 байт) 0 старых копий пакетов 0 пакетов с копиями данных (0 байт копий) 5 пакетов вне очереди (0 байт) 0 пакетов (0 байт) данных после окна 0 проверок окна 2 пакетов обновления окна 0 пакетов получено после закрытия 0 пакетов с неправильной аппаратной контрольной суммой 0 отброшено из-за неправильной контрольной суммы 0 отброшено из-за неправильных полей заголовка 0 отброшено из-за слишком малой длины 0 отброшено получателями 0 отброшено из-за переполнения очередей получателей 71 правильных прогнозов для заголовков пакетов уведомления 71 правильных прогнозов для заголовков пакетов данных 6 запросов на установление соединения 8 соединений разрешено установить 14 соединений установлено (включая разрешенные) 6 соединений закрыто (включая 0 отброшенных) 0 соединений с поддержкой ECN 0 ответов на ECN 0 начальных соединений отброшено 504 сегментов обновлено (505 попыток) 0 сегментов с уменьшенным числом разрядов окна нагрузки 0 сегментов с проверенным при нагрузке набором разрядов 0 повторных передач, связанных с вычислением MTU маршрута 0 операций поиска путей MTU прервано из-за повторной передачи 0 тайм-аутов повторной передачи 0 соединений отброшено из-за тайм-аута rexmit 0 быстрых операций повторной передачи 0 с окном загрузки, не превышающим 3 сегмента 0 новых операций повторной передачи 0 ошибочных операций быстрой повторной передачи предотвращено 0 постоянных тайм-аутов 0 соединений отброшено из-за постоянных тайм-аутов 16 тайм-аутов срока действия 16 тестов срока действия отправлено 0 соединений отброшено из-за срока действия 0 операций расширения массивов блоков SACK 0 операций расширения массивов промежутков SACK 0 пакетов отброшено из-за сбоев выделения памяти 0 соединений использовано повторно 0 отложенных уведомлений для SYN 0 отложенных уведомлений для FIN 0 операций отправки с отключением 0 сложных соединений 0 сложных соединений закрыто 0 сложных соединений сброшено 0 тайм-аутов сложных соединений 0 постоянных тайм-аутов сложных соединений 0 тайм-аутов срока действия сложных соединений
Ниже описаны поля, выделенные в выводе команды:
- Пакетов отправлено
- Пакетов данных
- Пакетов данных отправлено повторно
- Пакетов получено
- Повторных пакетов
- Тайм-аутов передачи
Сравните число отправленных пакетов с числом повторно отправленных пакетов. Если число повторно отправленных пакетов превышает 10-15 процентов от общего числа пакетов, возникают тайм-ауты TCP. Скорее всего, они связаны с тем, что сеть слишком загружена, поэтому уведомление не удается передать до наступления тайм-аута. Кроме того, повторные передачи пакетов TCP могут быть связаны с высокой загруженностью системы-получателя, либо с общей низкой производительностью сети. Повторные передачи увеличивают поток данных и приводят к дальнейшему повышению нагрузки на сеть.
Кроме того, сравните число полученных пакетов с числом повторных пакетов. Если после отправки пакета возникает тайм-аут ожидания подтверждения, пакет передается повторно. При этом целевая система может получить все переданные копии пакета. Если число повторных пакетов превышает 10-15 процентов, возможно, сеть или система-получатель перегружена. Повторные передачи пакетов также увеличивают поток данных в сети.
Тайм-аут повторной передачи возникает в том случае, если узел отправил пакет, но не получил подтверждение за заданное время. При этом пакет передается еще раз. Это значение увеличивается для каждой повторной передачи. Повторные передачи увеличивают нагрузку на процессор. Если подтверждение так и не будет получено, пакет будет отброшен.