Кабель UTP — технические характеристики, описание, расшифровка, ГОСТ

Расшифровка кабеля UTP:

U — Unshielded (неэкранированная)
T — Twisted (витая)
P — Pair (пара)

Элементы конструкции кабеля UTP:

1. Жила — медная гибкая.
2. Изоляция – ПВХ пластикат.
3. Оболочка — ПВХ пластиката.

Назначение кабеля UTP:

Существует несколько категорий кабеля UTP, которые нумеруются от CAT1 до CAT7 и определяют эффективный пропускаемый частотный диапазон. Категории неэкранированной витой пары описываются в стандарте EIA/TIA 568 (Американский стандарт проводки в коммерческих зданиях).
• UTP кабель CAT1 — (полоса частот 0.1 МГц) телефонный кабель, всего одна пара, известный в России, как «лапша». Используется только для передачи голоса или данных при помощи модема.
• UTP кабель CAT2 — (полоса частот 1 МГц) старый тип кабеля, 2-е пары проводников, поддерживал передачу данных на скоростях до 4 Мбит/с, использовался в сетях token ring и ARCNet. Сейчас иногда встречается в телефонных сетях.
• UTP кабель CAT3 — (полоса частот 16 МГц) использовался при построении локальных сетей 10BASE-T и token ring, поддерживает скорость передачи данных только до 10 Мбит/с. В отличие от предыдущих двух, отвечает требованиям стандарта IEEE 802.3. Также до сих пор встречается в телефонных сетях.
• UTP кабель CAT4 — (полоса частот 20 МГц) использовался в сетях token ring, 10BASE-T, 10BASE-T4, скорость передачи данных не превышает 16 Мбит/с, сейчас не используется.
• UTP кабель САТ5 — (полоса частот 100 МГц) это и есть, то, что обычно называют кабель «витая пара», благодаря высокой скорости передачи, до 100 Мбит/с при использовании 2-х пар и до 1000Мбит/с, при использовании 4-х пар, является самым распространённым сетевым носителем, использующимся в компьютерных сетях до сих пор. При прокладке новых сетей пользуются несколько усовершенствованным кабелем CAT5e (полоса частот 125 МГц), который лучше пропускает высокочастотные сигналы.
• UTP кабель CAT6 — (полоса частот 250 МГц) применяется в сетях Fast Ethernet и Gigabit Ethernet, состоит из 4-х пар проводников и способен передавать данные на скорости до 10000Мбит/с. Существует категория CAT6е, в которой увеличена частота пропускаемого сигнала до 500МГц.
• UTP кабель CAT7 — Спецификация на данный тип кабеля пока не утверждена, скорость передачи данных до 10000Мбит/с, частота пропускаемого сигнала до 600—700 МГц. Кабель этой категории экранирован.

Условия эксплуатации и монтажа кабеля UTP:

При монтаже кабеля витой пары должен выдерживаться минимально допустимый радиус изгиба (8 внешних диаметров кабеля).
Больший изгиб может привести к увеличению внешних наводок на сигнал или привести к разрушению оболочки кабеля.
При монтаже экранированной витой пары необходимо следить за целостностью экрана по всей длине кабеля. Растяжение или изгиб кабеля приводит к разрушению экрана, что ведёт к снижению устойчивости к электромагнитным помехам.
Дренажный провод должен быть соединён с экраном разъёма.

UDP — Википедия

У этого термина существуют и другие значения, см. UDP (значения).

UDP
Название	User Datagram Protocol
Уровень (по модели OSI)	Транспортный
Семейство	TCP/IP (иногда называют UDP/IP)
Создан в	1980[1]
Порт/ID	17 (в IP)
Спецификация	RFC 768 / STD 6
Основные реализации (клиенты)	Ядра Windows, Linux, UNIX
Основные реализации (серверы)	Ядра Windows, Linux, UNIX
Расширяемость	нет

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из ключевых элементов набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определён в RFC 768.

UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.

Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.

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

IANA разбила номера портов на три группы.

• Порты с номерами от 0 до 1023 используются для обычных, хорошо известных служб. В Unix-подобных операционных системах для использования таких портов необходимо разрешение суперпользователя.
• Порты с номерами от 1024 до 49151 предназначены для зарегистрированных IANA служб.
• Порты с 49152 по 65535 могут быть использованы для любых целей, поскольку официально не разработаны для какой-то определённой службы. Они также используются как динамические (временные) порты, которые запущенное на хосте программное обеспечение может случайным образом выбрать для самоопределения. По сути, они используются как временные порты в основном клиентами при связи с серверами.

UDP — минимальный ориентированный на обработку сообщений протокол транспортного уровня, задокументированный в RFC 768.

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Биты	0 — 15																16 — 31
0-31	Порт отправителя (Source port)																Порт получателя (Destination port)
32-63	Длина датаграммы (Length)																Контрольная сумма (Checksum)
64-…	Данные (Data)

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя[править | править код]

В этом поле указывается номер порта отправителя. Предполагается, что это значение задаёт порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, динамическим. Если источником является сервер, то его порт будет одним из «хорошо известных».

Порт получателя[править | править код]

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

Длина датаграммы[править | править код]

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC 791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники IPv4, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт

[2].

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (2³² — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной, превышающей 1500 байт, нужно проверять возможность такой связи опытным путём на конкретном оборудовании

[3].

Контрольная сумма[править | править код]

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

Метод для вычисления контрольной суммы определён в RFC 1071^[4].

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

Для расчёта контрольной суммы псевдозаголовок и UDP-сообщение разбивается на двухбайтные слова. Затем рассчитывается сумма всех слов в арифметике обратного кода (то есть кода, в котором отрицательное число получается из положительного инверсией всех разрядов числа и существует два нуля: 0х0000 (обозначается +0) и 0xffff(обозначается −0)). Результат записывается в соответствующее поле в UDP-заголовке.

Значение контрольной суммы, равное 0х0000 (+0 в обратном коде), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение

0xffff(-0 в обратном коде).

При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится −0 (то есть 0xffff), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче, либо контрольная сумма неверно посчитана на передающей стороне), то решение о дальнейших действиях принимает принимающая сторона. Как правило, в большинстве современных устройств, работающих с UDP/IP-пакетами имеются настройки, позволяющие либо игнорировать такие пакеты, либо пропускать их на дальнейшую обработку, невзирая на неправильность контрольной суммы.

Пример расчёта контрольной суммы[править | править код]

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281.

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

0x398a + 0xf802 = 0x1318c → 0x318d (перенос в старший разряд)
0x318d + 0x14b2 = 0x0463f → 0x463f (число положительное)
0x463f + 0xc281 = 0x108c0 → 0x08c1

В конце выполняется инверсия всех битов получившегося числа

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e или, иначе — 0xffff − 0x08c1 = 0xf73e. Это и есть искомая контрольная сумма.

В документе RFC 1071^[4] приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

Псевдозаголовок для IPv4[править | править код]

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

Биты	0 — 7								8 — 15								16 — 23								24 — 31
0	Адрес источника
32	Адрес получателя
64	Нули								Протокол								Длина UDP
96	Порт источника																Порт получателя
128	Длина																Контрольная сумма
160+	Данные

Адреса источника и получателя берутся из IPv4-заголовка. Значения поля «Протокол» для UDP равно 17 (0x11). Поле «Длина UDP» соответствует длине заголовка и данных.

Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.

Псевдозаголовок для IPv6[править | править код]

При работе UDP над IPv6 контрольная сумма обязательна. Метод для её вычисления был опубликован в RFC 2460:

При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:

Биты	0 — 7								8 — 15								16 — 23								24 — 31
0	Адрес источника
32
64
96
128	Адрес получателя
160
192
224
256	Длина UDP
288	Нули																								Следующий заголовок
320	Порт источника																Порт получателя
352	Длина																Контрольная сумма
384+	Данные

Адрес источника такой же, как и в IPv6-заголовке. Адрес получателя — финальный получатель; если в IPv6-пакете не содержится заголовка маршрутизации (Routing), то это будет адрес получателя из IPv6-заголовка, в противном случае, на начальном узле, это будет адрес последнего элемента заголовка маршрутизации, а на узле-получателе — адрес получателя из IPv6-заголовка. Значение «Следующий заголовок» равно значению протокола — 17 для UDP. Длина UDP — длина UDP-заголовка и данных.

Надёжность и решения проблемы перегрузок[править | править код]

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (Erasure code^ru_en).

Более серьёзной потенциальной проблемой является то, что в отличие от TCP, основанные на UDP приложения не обязательно имеют хорошие механизмы контроля и избегания перегрузок. Чувствительные к перегрузкам UDP-приложения, которые потребляют значительную часть доступной пропускной способности, могут поставить под угрозу стабильность в Интернете.

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Многочисленные ключевые Интернет-приложения используют UDP, в их числе — DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

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

• Надёжность — TCP управляет подтверждением, повторной передачей и тайм-аутом сообщений. Производятся многочисленные попытки доставить сообщение. Если оно потеряется на пути, сервер вновь запросит потерянную часть. В TCP нет ни пропавших данных, ни (в случае многочисленных тайм-аутов) разорванных соединений.

• Упорядоченность — если два сообщения последовательно отправлены, первое сообщение достигнет приложения-получателя первым. Если участки данных прибывают в неверном порядке, TCP отправляет неупорядоченные данные в буфер до тех пор, пока все данные не могут быть упорядочены и переданы приложению.

• Тяжеловесность — TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надёжностью и перегрузками.

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

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

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

• Неупорядоченность — если два сообщения отправлены одному получателю, то порядок их достижения цели не может быть предугадан.

• Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.

• Датаграммы — пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.

• Нет контроля перегрузок — UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.

• RFC 768 — Протокол Пользовательских Датаграмм
• RFC 2460 — Интернет протокол, спецификация версии 6 (IPv6)
• RFC 2675 — IPv6 Jumbograms
• RFC 4113 — Management Information Base for the UDP
• RFC 5405 — Unicast UDP Usage Guidelines for Application Designers

• Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
• Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
• [email protected]. «UDP Protocol Overview». Ipv6.com. Retrieved 17 August 2011.
• Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
• RFC 2675
• Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
• Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
• «The impact of UDP on Data Applications». Networkperformancedaily.com. Retrieved 17 August 2011.
• IANA Port Assignments
• Семенов Ю. А. Протокол UDP

Кабели UTP/FTP для внутренней прокладки

Кабели для структурированных кабельных систем (UTP, FTP) категории 5е для внутренней прокладки КСВ 5е, КСВЭ 5е

(ТУ 3574-005-12154334-2005)

Назначение

Кабели витая пара предназначены для применения в структурированных кабельных системах категории 5е по стандарту ИСО/МЭК 11801 в частотном диапазоне до 100 МГц. Кабели соответствуют требованиям ГОСТ Р 54429-2011 и стандарта ANSI/TIA-568-С.2. Возможно их применения в качестве кабелей «последней мили» в сетях широкополосного абонентского доступа (ШПД), Fast Ethernet и Gigabit Ethernet, в системах цифрового телевидения, IP-системах, охраны и контроля доступа.

Пример записи обозначения кабеля:

КСВ 5е 4х2х0,52 ТУ 3574-005-12154334-2005

Пример маркировки кабельного изделия:

КСВ 5е 4х2х0,52 U/UTP Cat. 5e 4PR 24AWG PVC

Возможно изготовление кабеля с маркировкой заказчика, другим цветом оболочки (по умолчанию цвет оболочки — серый), а так же в коробке заказчика.

Материалы, применяемые для изготовления кабеля:

• композиция полиэтиленов для изоляции жил – ГОСТ 16336-2013;
• пластикат поливинилхлоридный для оболочек – ГОСТ 5960-72;
• проволока медная марки ММ – ТУ 16-705.492-2005;
• проволока медная лужёная – ТУ 16-505.850-75;
• материал фольгированный композиционный гибкий (алюмофлекс) – ТУ 2358-017-50157149-2004.

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

Конструктивные размеры

Марка кабеля	КСВ 5е	КСВ 5е	КСВЭ 5е		КСВ 5е	КСВЭ 5е
Число пар	1	2			4
Диаметр токопроводящих жил, мм	0,52мм
Диаметр изолированной жилы, не более, мм	1,22
Наружный диаметр кабеля, мм	3,6	3,6х5,2			6,5
Расчетная масса 1 км кабеля, кг*	11,3	18		23,3	31,4		46,6

* Расчетная масса кабеля приведена в качестве справочного материала

Токопроводящие жилы попарно скручены и имеют различную расцветку.

Электрические параметры

Эл. сопротивление жил, Ом/100м не более	Волновое сопротивление на частоте 100МГц, Ом	Рабочая емкость пары, нФ/100м	Коэффициент затухания, дБ/100 м, не более				Затухание отражения (RL), дБ, не менее				Переходное затухание на ближнем конце (NEXT), дБ, не менее				Защищенность на дальнем конце (EL FEXT), дБ, не менее
			Частота, МГц				Частота, МГц				Частота, МГц				Частота, МГц
			4	10	62,5	100	4	10	62,5	100	4	10	62,5	100	4	10	62,5	100
9,1	100±15	≤5,6	4,1	6,5	17,0	22	23	25	21,5	20,1	56,3	50,3	38,4	35,3	52,0	44,0	28,0	24,0

Эксплуатационные характеристики

Монтаж кабеля должен производиться при температуре не ниже минус 10°С.

Минимальный радиус изгиба кабеля при прокладке и монтаже – 40 мм.

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

Гарантия производителя:

Срок службы – не менее 15 лет, при соблюдении условий хранения и эксплуатации.

Гарантийный срок эксплуатации кабелей – 3 года с момента ввода в эксплуатацию.

Декларация о соответствии КСВ Декларация о соответствии КСВп Декларация о соответствии КСВЭ Сертификат
ТР ТС Пожарный сертификат Добровольный сертификат

Шпаргалка по типам и стандартам Ethernet 802.3 / Habr

Когда я изучал CCNA больше всего меня напрягали стандарты IEEE из-за своего количества, типов и названий. И приходилось каждый раз искать и смотреть какому стандарту соответствует такой-то тип интерфейса. После многих часов работы я смог слепить до кучи таблицы по каждому типу Ethernet интерфейсов, которая включает год выпуска стандарта, тип интерфейса, скорость передачи данных соответствующего типа интерфейса, максимальную длину сегмента и тип используемого кабеля. Рад поделиться с читателями.

Первые версии Ethernet

10 Мбит/с Ethernet (Thick ethernet)	Стандарт	Год выхода стандарта	Тип	Скорость передачи (Мbps)	Максимальная длина сегмента в метрах	Тип кабеля
	IEEE 802.3	1983	10Base5	10	500 м	коаксиальный
	IEEE 802.3а	1985	10Base2	10	185 м
	IEEE 802.3b	1985	10Broad36	10	3600 м
	IEEE 802.3e	1987	1Base5	1	250 м	UTP
	IEEE 802.3e	1987	StarLan 10	10	250 м	UTP
	IEEE 802.3d	1987	FOIRL	10	1000	оптоволоконный
	IEEE 802.3i	1990	10Base-Т	10	100 м	UTP cat 3,5
	IEEE 802.3j	1993	10Base-F	10	2км	оптоволоконный

Fast Ethernet — общее название для набора стандартов передачи данных в компьютерных сетях по технологии Ethernet со скоростью до 100 Мбит/с, в отличие от исходных 10 Мбит/с.

100 Мбит/с Ethernet (Fast Ethernet)	Стандарт	Год выхода стандарта	Тип	Скорость передачи (Мbps)	Максимальная длина сегмента в метрах	Тип кабеля
	IEEE 802.3u	1995	100Base-FX	100	Одномод — 2 км Многомод — 400 м	оптоволоконный
			100Base-Т	100	100 м	UTP/STP cat 5
			100Base-Т4	100	100 м	UTP/STP cat >= 3
			100Base-ТХ	100	100 м	UTP/STP cat 5
	IEEE 802.12	1995	100Base‑VG	100	100 м	UTP cat 3,5
	IEEE 802.3y	1998	100Base-Т2	100	100 м	UTP cat 3,5
	TIA/EIA-785	2001	100Base-SX	100	300 м	оптоволоконный
	IEEE 802.3ah	2004	100Base-LX10	100	10 км
	IEEE 802.3ah	2004	100Base-BX10	100	10 км

Gigabit Ethernet (GbE) — термин, описывающий набор технологий для передачи пакетов Ethernet со скоростью 1 Гбит / с. Он определен в документе IEEE 802.3-2005.

1000 Мбит/с (Gigabit Ethernet)	Стандарт	Год выхода стандарта	Тип	Скорость передачи (Мbps)	Максимальная длина сегмента в метрах	Тип кабеля
	IEEE 802.3z	1998	1000Base-CX	1000	25 м	UTP/STP cat 5,5e,6
			1000Base-LX	1000	Одномод — 5 км Многомод — 550 м	оптоволоконный
			1000Base-SX	1000	550 м
	IEEE 802.3ab	1999	1000Base-T	1000	100 м	UTP/STP cat 5,5е,6,7
	TIA 854	2001	1000BASE‑TX	1000	100 м	UTP/STP cat 6,7
	IEEE 802.3ah	2004	1000BASE‑LX10	1000	10 км	оптоволоконный
	IEEE 802.3ah	2004	1000BASE‑BX10	1000	10 км
	IEEE 802.3ap	2007	1000BASE‑KX	1000	1 м	для объединительной платы
	non-standard	?	1000BASE‑EX	1000	40 км	оптоволоконный
	non-standard	?	1000BASE‑ZX	1000	70 км

10 Gigabit Ethernet или 10GbE являлся новейшим (на 2006 год) и самым быстрым из существующих стандартов Ethernet. Он определяет версию Ethernet с номинальной скоростью передачи данных 10 Гбит/с, что в 10 раз быстрее Gigabit Ethernet. Стандарт для оптоволокна специфицирован в IEEE 802.3-2005, а для витой пары в IEEE 802.3an-2006.

10 Гбит/с Ethernet (10 GbE)	Стандарт	Год выхода стандарта	Тип	Скорость передачи (Gbps)	Максимальная длина сегмента в метрах	Тип кабеля
	IEEE 802.3ае	2003	10GBASE-SR	10	26-300 м	оптоволоконный
		2003	10GBASE-LX4	10	Одномод — 10 км Многомод — 300 м
		2003	10GBASE-LR	10	10 км
		2003	10GBASE-ER	10	40 км
		2003	10GBASE-SW	10	26 м — 40 км
		2003	10GBASE-LW	10
		2003	10GBASE-EW	10
	IEEE 802.3аk	2004	10GBASE-CX4	10	15м	медный кабель СХ4
	IEEE 802.3an	2006	10GBASE-T	10	100 м	UTP/STP cat 6,6a,7
	IEEE 802.3aq	2006	10GBASE-LRM	10	220 м	оптоволоконный
	IEEE 802.3ap	2007	10GBASE-KX4	10	1 м	для объединительной платы
	IEEE 802.3ap	2007	10GBASE-KR	10	1 м
	IEEE 802.3av	2009	10GBASE-PR	10	20 км	оптоволоконный

40-гигабитный Ethernet (или 40GbE) и 100-гигабитный Ethernet (или 100GbE) — стандарты Ethernet, разработанные группой IEEE P802.3ba Ethernet Task Force в период с 2007 по 2011 год. Эти стандарты являются следующим этапом развития группы стандартов Ethernet, имевших до 2010 года наибольшую скорость в 10 гигабит/с. В новых стандартах обеспечивается скорость передачи данных в 40 и 100 гигабит в секунду.

40 и 100 Гбит/с Ethernet (40GbE или 100GbE)	Стандарт	Год выхода стандарта	Тип	Скорость передачи (Gbps)	Максимальная длина сегмента в метрах	Тип кабеля
	IEEE 802.3ba	2010	40GBase-KR4 100GBase-KP4	40 100	1 м	для объединительной платы
			100GBase-KR4	100	1 м	для улучшенной объединительной платы
			40GBase-CR4 100GBase-CR10	40 100	7 м	медный биаксиальный кабель
			40GBase-T	40	30 м	UTP cat 8
			40GBase-SR4 100GBase-SR10	40 100	100 м 125 м	оптоволоконный
			40GBase-LR4 100GBase-LR4	40 100	10 км
			100GBase-ER4	100	40 км
	IEEE 802.3bg	2011	40GBase-FR	40	2 км

Кто заметит ошибки — пишите, исправлюсь. Спасибо.

 

Чем отличается протокол TCP от UDP

Чем отличается протокол TCP от UDP

Всем привет сегодня расскажу чем отличается протокол TCP от UDP. Протоколы транспортного уровня, следующие в иерархии за IP, используются для передачи данных между прикладными процессами, реализующимися в сетевых узлах. Пакет данных, поступивший от одного компьютера другому через Интернет, должен быть передан процессу-обработчику, и именно по конкретному назначению. Транспортный уровень принимает на себя ответственность за это. На этом уровне два основных протокола – TCP и UDP.

Что означают TCP и UDP

TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью.

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

Напоминаю, что оба протокола работают на транспортном уровне модели OSI или TCP/IP, и понимание того чем они отличаются очень важно.

Разница между протоколами TCP и UDP

Разница между протоколами TCP и UDP – в так называемой “гарантии доставки”. TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Также протокол TCP считается надежным, тогда как UDP получил даже именование “протокол ненадежных датаграмм. TCP исключает потери данных, дублирование и перемешивание пакетов, задержки. UDP все это допускает, и соединение для работы ему не требуется. Процессы, которым данные передаются по UDP, должны обходиться полученным, даже и с потерями. TCP контролирует загруженность соединения, UDP не контролирует ничего, кроме целостности полученных датаграмм.

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

Tcp Udp отличия

Давайте рассмотрим основные отличия tcp от udp.

1. TCP гарантирует доставку пакетов данных в неизменных виде, последовательности и без потерь, UDP ничего не гарантирует.
2. TCP нумерует пакеты при передаче, а UDP нет
3. TCP работает в дуплексном режиме, в одном пакете можно отправлять информацию и подтверждать получение предыдущего пакета.
4. TCP требует заранее установленного соединения, UDP соединения не требует, у него это просто поток данных.
5. UDP обеспечивает более высокую скорость передачи данных.
6. TCP надежнее и осуществляет контроль над процессом обмена данными.
7. UDP предпочтительнее для программ, воспроизводящих потоковое видео, видеофонии и телефонии, сетевых игр.
8. UPD не содержит функций восстановления данных

Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность. Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия.

Заголовки TCP и UDP

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

Заголовок UDP

• 16 битный порт источника > Указание порта источника для UDP необязательно. Если это поле используется, получатель может отправить ответ этому порту.
• 16 битный порт назначения > Номер порта назначения
• 16 битная длина UDP > Длина сообщения, включая заголовок и данные.
• 16 битная контрольная сумма > Контрольная сумма заголовка и данных для проверки

Заголовок TCP

• 16 битный порт источника > Номер порта источника
• 16 битный порт назначения > Номер порта назначения
• 32 битный последовательный номер > Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
• 32 битный номер подтверждения > Если установлен бит АСК поля «Управление», в данном поле содержит следующий ожидаемый последовательный номер.
• 4 бита длина заголовка > Информация о начале пакета данных.
• резерв > Резервируются для будущего использования.
• 16 битная контрольная сумма > Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
• 16 битный указатель срочности > В этом поле целевое устройство получает информацию о срочности данных.
• Параметры > Необязательные значения, которые указываются при необходимости.

Размер окна позволяет экономить трафик, рассмотрим когда его значение равно 1, тут на каждый отправленный ответ, отправитель ждет подтверждения, не совсем рационально.

При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.

Надеюсь у вас теперь есть представления об отличиях tcp udp протоколов.

Материал сайта pyatilistnik.org

Что такое протокол UDP? | Сеть без проблем

Протокол пользовательских дейтаграмм (UDP) — это самый простой коммуникационный протокол Transport Layer, доступный из набора протоколов TCP/IP. Это связано с минимальным механизмом связи. UDP считается ненадежным транспортным протоколом, но он использует IP-услуги, которые обеспечивают лучший механизм доставки усилий.

В UDP приемник не генерирует подтверждение принятого пакета и, в свою очередь, отправитель не ожидает подтверждения подтверждения отправленного пакета. Этот недостаток делает этот протокол ненадежным, а также проще при обработке.

Востребованность UDP

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

Возможности User Datagram Protocol

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

Заголовок UDP

UDP-заголовок так же прост, как и его функция.

Заголовок UDP содержит четыре основных параметра:

• Source Port — эта 16-разрядная информация используется для идентификации исходного порта пакета.
• Destination Port — эта 16-разрядная информация используется для определения службы уровня приложения на машине назначения.
• Lenght — Длина определяет всю длину UDP-пакета (включая заголовок). Это 16-битовое поле, а минимальное значение — 8-байтовое, то есть размер самого UDP-заголовка.
• Checksum. В этом поле хранится значение контрольной суммы, сгенерированное отправителем перед отправкой. IPv4 имеет это поле как необязательное, поэтому, когда поле контрольной суммы не содержит никакого значения, оно выполнено 0, а все его биты установлены на ноль.

Где используется UDP?

Вот несколько приложений, в которых UDP используется для передачи данных:

• Услуги доменных имен
• Простой протокол сетевого управления
• Тривиальный протокол передачи файлов
• Протокол маршрутной информации
• Kerberos

UDP протокол — что это такое и как он работает

Обмен данными в интернете происходит по своим правилам, и контролируется специальными протоколами, одним из них является UDP. Если вы часто пользуетесь интернетом, то наверняка могли слышать о нем.

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

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

UDP протокол — что это

UDP — это транспортный протокол пользовательских датаграмм из набора правил TCP/IP. Позволяет отправлять информацию (датаграммы) по IP-сети без предварительного установления соединения и создания специального виртуального канала или путей данных. Официально был разработан в 1 980 году человеком по имени Дэвид П. Рид. Полностью расшифровывается как — User Datagram Protocol.

Интересно! Любой протокол, который не устанавливает предварительное соединение — называется датаграммным.

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

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

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

Также, для расширения кругозора рекомендую прочитать статью — как проверить скорость интернета.

Плюсы UDP протокола — кому он полезен?

Доставка пакетов происходит гораздо быстрее, т.к. он просто не тратит время на все те проверки, установку соединения и т.д., как это делает TCP.

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

Отличие UDP от TCP — сравнение

Как вы уже знаете, есть два основных протокола в стеке TCP/IP — это TCP и UDP. Многие задаются в чем между ними разница, а разница по большому счету в «гарантии доставки» данных. Так, TCP требует от получателя подтверждения того, что он получил пакеты данных, а для этого необходимо изначально установленное соединение между узлами. Также, он исключает потерю данных, задержки, использует логическое соединение и т.д. А вот ЮДП этого не делает, поэтому его еще часто называют — «протокол ненадежных датаграмм».

Недостатки:

1. Ненадежный протокол. Не контролирует передачу и соответственно целостность данных, а просто передает их, так данные могут прийти битыми или с дубликатом, или потеряться.
2. Отправляет данные не упорядоченно. Если отправить данные нескольким адресатам, то неизвестно кому первому они придут. В тисипи все это контролируется и нумеруется по порядку.
3. Без проверки доставки, в отличие от своего собрата тисипи.
4. Проверка целостности пакета осуществляется только если он был доставлен и проверяет ее получатель, а в отправитель даже не будет знать доставлен ли пакет.
5. Плохая безопасность. Многие файрволы просто блокируют UDP пакеты, т.к. злоумышленники могут воспользоваться его портами, не устанавливая явных соединений.

Преимущества:

1. Легковесный — быстрая передача. Не нужно предварительно соединение, никаких проверок доставки, упорядочивания, отслеживания соединения. А в TCP все это есть — поэтому он тяжеловесный, еще ему нужно аж три пакета для установления сокет-соединения.
2. Разные соединения. Может быть связь — «один с одним», а может и «один со многими». А вот TCP позволяет только первый вариант.
3. Нагрузка и расходы. Т.к. ЮДП требует куда меньше ресурсов — система грузится куда меньше и покупать более дорогое оборудование нет смысла.
4. Размер заголовка. У UDP заголовок весит всего 8 байтов, а в TCP — 20 байтов, что означает что ему нужна меньшая пропускная способность.

В заключение

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