Utp протокол что это

Что такое uTP(что-то с торрентами свзанное) и как его включить, вродь как это ускоряет закачку.

Это протокол передачи данных. Он не включается пользователем, его использует специальная программа (например uTorrent). И он действительно ускоряет закачку

μTP — переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который реагирует раньше, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP первым замедляется и отдает канал другим приложениям. При использовании TCP канал распределялся равномерно по соединениям, а поскольку у P2P программ обычно на порядок больше соединений, чем у других, они просто забирали под себя весь канал, увеличивая пинг и делая работу других приложений медленной или вообще невозможной.
μTP предназначен для более быстрого скачивания, так как работает по протоколу UDP, в котором обмен данными происходит быстрее, чем через протокол TCP. Ускорение достигается за счёт того, что торрент-клиент берёт на себя выполнение нужных функций, отсутствующих в UDP, например, клиент перепроверяет целостность данных и, если блок неверен, скачивает его заново. Также, провайдерам намного сложнее блокировать передачу данных через μTP, благодаря отсутствию строгих, формализованных отличий UDP пакетов обычного трафика (формируемого, к примеру, сетевыми играми) от трафика формируемого протоколом μTP, в отличие от TCP пакетов, по содержанию полей которых можно делать вывод о их принадлежности к p2p трафику.

μTP — переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который реагирует раньше, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP первым замедляется и отдает канал другим приложениям. При использовании TCP канал распределялся равномерно по соединениям, а поскольку у P2P программ обычно на порядок больше соединений, чем у других, они просто забирали под себя весь канал, увеличивая пинг и делая работу других приложений медленной или вообще невозможной.

μTP предназначен для более быстрого скачивания, так как работает по протоколу UDP, в котором обмен данными происходит быстрее, чем через протокол TCP. Ускорение достигается за счёт того, что торрент-клиент берёт на себя выполнение нужных функций, отсутствующих в UDP, например, клиент перепроверяет целостность данных и, если блок неверен, скачивает его заново. Также, провайдерам намного сложнее блокировать передачу данных через μTP, благодаря отсутствию строгих, формализованных отличий UDP пакетов обычного трафика (формируемого, к примеру, сетевыми играми) от трафика формируемого протоколом μTP, в отличие от TCP пакетов, по содержанию полей которых можно делать вывод о их принадлежности к p2p трафику.

Источник

H Torrent/uTP — о протоколе и самодельных DPI в черновиках Recovery Mode

В 2009 году появился Micro Transport Protocol, сокращённо — uTP, можно ознакомится тут.
Суть задумки в том, чтобы не полагаться на TCP Congestion Control, которым под виндой рулить весьма проблематично, а самим управлять загрузкой канала.
uTP выявил много узких мест как у провайдеров так и у пользователей: ещё вчера прекрасно работающие роутеры превратились в тыкву. А некоторые пользователи обнаружили что торренты качаются на все 100 мегабит, не зависимо от тарифа.
Utp протокол что это. 89551cd561c9c05604e4684a7e1d9acd. Utp протокол что это фото. Utp протокол что это-89551cd561c9c05604e4684a7e1d9acd. картинка Utp протокол что это. картинка 89551cd561c9c05604e4684a7e1d9acd

Также провайдерам намного сложнее блокировать передачу данных через μTP благодаря отсутствию строгих, формализованных отличий UDP пакетов обычного трафика (формируемого, к примеру, сетевыми играми) от трафика, формируемого протоколом μTP, в отличие от TCP пакетов, по содержанию полей которых можно делать вывод об их принадлежности к p2p-трафику.

https://ru.wikipedia.org/wiki/ΜTorrent
Utp протокол что это. 77473989d97b4b77ae89d917348035d8. Utp протокол что это фото. Utp протокол что это-77473989d97b4b77ae89d917348035d8. картинка Utp протокол что это. картинка 77473989d97b4b77ae89d917348035d8

Как не правильно блокировать можно почитать тут: geektimes.ru/post/243305/
и немного ниже 🙂

Жизнь с uTP

В адрес авторов uTP звучала масса упрёков в изобретении TCP с нуля и хождении по всем граблям, в том что они не взяли уже готовые протоколы, и в том что теперь придётся обновляться и расширятся.
С точки зрения разработчиков — выбора особо не было: TCP все провайдеры шейпят и душат, для управления всеми аспектами работы tcp протокола в винде нужны права администратора и скорее всего свой драйвер, многие другие протоколы которые ходят поверх IP (tcp/udp/gre/udplite/. ) вообще провайдерами фильтруются и в винде их так просто не реализовать.
Потому просто взяли и сделали поверх UDP.

Это решение подкосило многие домашние мыльницы и некоторых провайдеров.
Количество трансляций в NAT роутеров стало очень быстро расти.
Для TCP — NAT знает когда соединение установлено и когда оно завершено, а для UDP понятие соединений отсутствует в принципе, поэтому обычно применяются таймеры для удаления старых сессий.

Другим побочным эффектом явилось то, что uTorrent запрашивал больше трафика чем позволял тарифный план провайдера, и от этого страдали даже те провайдеры у которых шейпер был настроен правильно: на хомячка из интернета прилетало ощутимо больше его тарифного плана и этот излишек дропался шейпером. Провайдеры несли финансовые потери от такого DDoS хомяка на самого себя.
Авторы uTorrent позже всё таки научились правильно подстраиваться под канал, но их эксперименты стоили нервов и денег.

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

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

Протокол uTP

Версия 0

Начиная с uTorrent 1.8

Версия 1

Начиная с uTorrent 2.0

Типы пакетов

flags из версии 0 превратился в type в версии 1, типы пакетов перечислены выше.
Сначала отправляется SYN на него приходит ответ STATE или RESET.
Завершается соединение на FIN или RESET.
DATA и STATE используются при передаче данных.

connid — идентификатор соединения. В TCP его роль выполняет номер порта (вернее их пара). Номер соединения у двух хостов всегда различается на единицу.
Вообще довольно запутанная и странная схема установления соединения:
>> SYN: connid=34 — запрос на установление соединения
> DATA: connid=35 — передача данных
И эти люди продают мне интернет.

— возникает у меня периодически к голове, когда я читаю провайдерский форум. 🙂

Провайдеры искали способ как быстро нормализовать работу сети и решили фильтровать uTP по сигнатурам пакетов, добавляя их то в ACL коммутаторов то в фаервол BSD/Linux роутера.
«Странность» ситуации в том, что сигнатуры искали анализируя пакеты.
Притом, что код libuTP был открыт 16 мая 2010 года — через 4 месяца после выхода uTorrent 2.0 где uTP был включён.

Спустя пару месяцев «живительные» сигнатуры путём нечеловеческих усилий по анализу пакетов были получены.
Ещё через некоторое время авторы поменяли пару незначительных для протокола начальных значений в SYN пакете и что то рандомизировали (connid, seq_nr — больше не смогли) 🙂

После того как ng_utp был написан стало понятно что проверять корректность работы с помощью tcpdump без правильных сигнатур мягко говоря не удобно — слишком много лишнего приходилось пробегать глазами.
Я ещё раз пробежался по коду libuTP и получились такие сигнатуры, сейчас может быть они уже устарели.

Версия 0

‘udp[17] = 2 and udp[18] = 4 and udp[21:2] = 0 and udp[23] = 0 and udp[24] = 8 and udp[25:4] = 0 and udp[29:4] = 0’

41 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 41 and udp[25:2] = 0x0204 and udp[29:4] = 0x00000008 and udp[33:4] = 0 and udp[37:4] = 0)’

— последнее это то что можно скармливать в tcpdump, отличается от первой смещениями и тем что константы объединены чтобы сравнений было меньше. Первая больше для самообразования.

RESET

‘udp[17] = 0 and udp[18] = 3’

31 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 31 and udp[25:2] = 0x0003)’

Версия 1

‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40 and udp[1] = 2 and udp[18:2] = 0 and udp[20] = 0 and udp[21] = 8 and udp[22:4] = 0 and udp[26:4] = 0’

(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x40) => udp[0] = 0x41

38 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 38 and udp[8:2] = 0x4102 and udp[26:4] = 0x00000008 and udp[30:4] = 0 and udp[34:4] = 0)’

RESET

rst — 4 bytes
‘udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30 and udp[1] = 0’
(udp[0] & 0x0f = 1 and udp[0] & 0xf0 = 0x30) => udp[0] = 0x31)
28 = udp hdr len (8) + upd pkt data len

upd header included:
‘(udp[4:2] = 28 and udp[8:2] = 0x3100)’

Обнаружение фильтрации

Проще всего, используя описание протокола, реализовать простенький клиент, который будет устанавливать соединение и пытаться отправлять данные.
По сути нужно симулировать установление соединения, и дальше пытаться слать DATA и STATE пакеты в ответ с ext типа ACK.
Дальше один клиент запускается в интернете, другой у себя и смотрим теряются ли пакеты в 100% случаев или может RESET приходят.
Сходным образом при использовании yota некоторые пакеты из l2tp на завершающем этапе согласования пропадают в 100% случаев. Так было ещё в сентябре.

Заключение

1. То что написано в вики на русском — полнейший бред: uTP имеет достаточно чёткие сигнатуры и легко ловится DPI.
Более того, ловить сигнатуры в TCP ощутимо сложнее, поскольку для гарантированного обнаружения нужно уметь собирать несколько пакетов вместе и уже потом проверять содержимое: клиент может передавать данные по одному байту.
Авторы uTP либо не ставили себе цель сделать протокол без сигнатур либо даже не приблизись к цели.
(На мой взгляд в начале не ставили, а потом было уже поздно и рандомизация отдельных полей не помогает).
Вики на английском более адекватна.

2. Производители различных DPI уже давно добавили сигнатуры для uTP, вряд ли им это было трудно сделать.

4. Для IPv6 код не писал, на всякий случай 😉

5. uTP не лучше TCP для передачи данных, вся проблема в том, что TCP можно хоть как то управлять из приложения только на BSD/Linux — setsockopt(. IPPROTO_TCP, TCP_CONGESTION. ) — основное что требуется, хотя и там более тонкие параметры congestion control для отдельных сокетов не настраиваются.
Говорить про оверхэд в 23/20 байт сейчас уже не актуально, HTTP/2.0 не сильно лучше.
Возможно с приходом кучи готовых либ для HTTP/2.0 торренты пустят и через него, скорее всего это вопрос времени.

Источник

Про µTP в новых версиях µTorrent: что это, как, зачем?

Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.

Пара слов про TCP и UDP. Первый расшифровывается как Transmission Control Protocol, или протокол управления потоком. Он удобен тем, что даёт использующей его программе гарантию, что данные дойдут до адресата целыми, полностью и в том порядке, в котором были отправлены. Его использование требует предварительной установки соединения и его закрытия в конце. Этакое создание «трубы» через которую будет идти обмен данными. UDP же не предоставляет никаких гарантий что данные дойдут, или что дойдут в правильном порядке. Он только позволяет переслать небольшой блок данных (датаграмму) от одного адреса другому. Вся работа по проверке доставки, и при необходимости — повторной посылке, ложится на саму программу.

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

При этом, если посылающий сидит на широком канале, а принимающий — на модеме, то первый сразу отправляет большой блок данных, который может быстро дойти до провайдера второго, и потихоньку просачиваться в модем. В это время первый, не получив подтверждения о получении, перешлёт часть кусков заново. Ещё раз, и ещё, в результате магистраль провайдера оказывается забита этой ненужной перепосылкой. Одна из основных целей uTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.

Латентно uTP появился в µTorrent версии 1.8, но умел принимать только входящие uTP-соединения, инициировать их сам — не умел. Впервые это научилась альфа-версия 1.9, потом стало возможным включить это и в новых версиях 1.8 ключиком bt.transp_disposition. Его значение от версии к версии менялось, но сейчас устаканилось на следующих битовых флагах:

1 — разрешить инициировать исходящие TCP-соединения,
2 — разрешить инициировать исходящие uTP-соединения,
4 — разрешить принимать входящие TCP-соединения,
8 — разрешить принимать входящие uTP-соединения

Таким образом, 13 (1+4+8), значение по умолчанию в последних версиях 1.8, означает возможность принимать все виды соединений, но самостоятельно устанавливать только TCP. 15 (значение по умолчанию в 2.0) разрешает все виды как исходящих так и входящих соединений. Чтобы запретить uTP вообще (если он вызывает какие-либо проблемы) надо поставить 5 (1+4). Стоит ли ставить 15 в 1.8 — вопрос спорный, на официальном форуме пишут что поддержка uTP в версии 2.0 намного лучше, поэтому скорость в 1.8 может быть хуже, чем по TCP.

В версии 2.0 также появилась поддержка UDP-трекеров. Для трекера вообще TCP очень излишний и требует много лишних ресурсов пакетами установки/закрытия соединения, поэтому для открытых трекеров UDP — благо. Например, последнее время трекер anirena очень глючит по TCP и далеко не с первого раза отвечает, DHT там часто запрещён, а UDP-трекер работает прекрасно. Но для закрытых трекеров он не подходит, т.к. не позволяет послать пасскей, чтобы идентифицировать таким образом качающего.

Ещё в 2.0 появится метод обхода некоторых NAT (STUN), что поможет соединяться большему числу NAT-страдальцев, хотя будет работать не во всех случаях.

Лично меня из всех новшеств 2.0 больше всего порадовал TCP Rate Control. Он позволяет подстраивать скорость и TCP-соединений так, чтобы они не мешали другим приложениям и минимизировать лишнюю перепосылку пакетов, о которой написано выше. Раньше это достигалось установкой cFos-драйвера, в котором можно было поставить низкий приоритет торренту, высокий — браузеру, а с версией 2.0 этого больше не требуется. Управляется это опцией bt.tcp_rate_control, если вам важнее чтобы торрент не мешает другим интернет-приложениям — его стоит включить, если важна максимальная скорость торрента — есть смысл отключить, на официальном форуме пишут что это иногда скорость увеличивает.

Замечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.

За счёт этого, пока канал свободен — он используется на полную. как только например другое приложение (броузер) начинает грузить канал — в µTorrent’е начинает возрастать время отклика, и он автоматически освобождает канал для броузера. Как только пинг вернулся обратно (канал снова освободился) — µTorrent увеличивает загрузку канала. При этом лишних перепосылок пакетов гораздо меньше, чем если бы это происходило на TCP-уровне

Впрочем, тут есть интересный момент, что с ней или по uTP исходящий канал может забиваться на 95%, а без неё только с TCP — на 100%, но эта разница в 5% может оказаться той самой излишней перепосылкой одних и тех же пакетов, что канал забивает, а реальной пользы не приносит, так что imho не всегда когда канал чуть недозабивается это значит что новая версия хуже.

Ещё в обсуждениях часто мелькает ключ net.calc_overhead. Если он включен, то при настройке скорости учитывается и служебный трафик — запросы блоков, подтверждения, уведомления какие блоки у кого есть и т.п. Если отключен — считаются только сами блоки данных. Поэтому раньше советовали ограничивать исходящий канал в торренте до 80-90% от реального, иначе он весь забивался отправляемыми блоками, и уведомления о получении блоков и запросы новых не успевали проходить, поэтому серьёзно страдала скорость скачивания. Опять же, на широких каналах некоторые пишут что при выключении этой опции скорость чуть выше, но может это глюк бета-версии и в релизе всё будет нормально.

Тут ещё есть такой момент, в котором я не уверен на 100%, но кажется что служебного трафика в uTP больше. Ибо в каждой маленькой датаграмме надо передавать что это за блок, от какого торрента, а по TCP можно посылать большие блоки, не подписывая каждый кусочек. Впрочем, тут будет служебный трафик самого TCP, так что не факт что он сильно «экономичнее».

Ещё нельзя не упомянуть такое явление, как «шейпинг» или «резание» P2P-трафика некоторыми провайдерами. Для России это (пока?) не актуально, а на открытых трекерах, где много пиров со всего мира, скорость по uTP значительно выше.

С другой стороны, не всё сетевое железо — модемы, марштуризаторы — и не весь софт рассчитывался на такое количество UDP-трафика, поэтому у некоторых пользователей с ним возникают глюки. Например со скоростью — когда периодически она вдруг падает до нуля, потом снова восстанавливается, или плавает от нуля до максимума. Видимо где-то в сетевом окружении переполняется некий связанный с UDP буфер, чёрт знает. Опять же, на официальном форуме можно поискать про совместимость с разным софтом и железом в случае проблем.

Другие «продвинутые» опции, на которые можно обратить внимание:
bt.connect_speed — сколько максимум новых соединений можно устанавливать в секунду (стоит увеличить, у меня стоит 80),
net.max_halfopen — про это много писалось, и менять стоит вместе с патчем tcpip.sys, хотя с протоколом uTP это уже не важно.
net.utp_target_delay — это некий целевой «пинг» при подстройке соединений, в некоторых случаях при его увеличении где-то до 400-500 скорость становится лучше.
peer.disconnect_inactive_interval — через сколько секунд закрывается соединение с пиром, с которым нет обмена данными, актуально больше для открытых трекеров где больше народу и «плохих» пиров, либо на случай сетевых глюков — чтобы быстрее определять разрыв соединения и переустанавливать его. в некоторых случаях имеет смысл понизить до 90-120.

Версия 2.0 хотя и бета — вполне стабильная, скачать можно тут: forum.utorrent.com/viewtopic.php?id=60602

По личным ощущениям, в старых альфах 1.9 при скачивании с открытых трекеров если до этого входящий канал загружался где-то на 1/3, с uTP стал грузиться где-то на 2/3. При скачивании с закрытых трекеров раньше канал загружался так, что броузер начинал подтормаживать, а в 2.0 всё летает.

Источник

Витая пара в современных сетях

Utp протокол что это. 38b6b6c0d79ad1963a4c42ba02ac1853. Utp протокол что это фото. Utp протокол что это-38b6b6c0d79ad1963a4c42ba02ac1853. картинка Utp протокол что это. картинка 38b6b6c0d79ad1963a4c42ba02ac1853

Мы, специалисты «Мальтима Телеком», продолжаем публиковать справочные материалы по телеком-оборудованию и комплектующим в помощь специалистам. На этот раз речь пойдёт о витой паре, поставками которой мы в том числе занимаемся. Этот товар проходит входной контроль в России: часть партии тестируется тремя разными сертифицирующими тестерами, которые показывают всю картину по кабелю. Если хотя бы один тестер выявляет несоответствие, кабель в продажу не запускается.

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

Для удобства использования отдельные витые пары объединяют в кабели, содержащие 2, 4, 8 и более пар. Самыми распространенными в настоящее время являются кабели, состоящие из 4 витых пар. Несмотря на общий принцип устройства, такие кабели обладают различными свойствами, основным среди которых является полоса пропускаемых частот, которая напрямую зависит от устойчивости к внешним и взаимных помехам. Именно по этому параметру кабели с витыми парами принято разделять на категории в соответствии с международным стандартом ISO 11801. Рассмотрим эти категории подробнее.

К категориям 1 и 2 принято относить устаревшие кабели с одной или двумя парами проводов, пригодные для голосовой и модемной связи, а также передачи цифрового сигнала с пропускной способностью до 4 Мбит/с.

Кабели категории 3 имеют полосу пропускаемых частот 16 МГц и пригодны для построения локальных сетей с пропускной способностью до 100 Мбит/с по спецификации 100BASE-T4. В настоящее время кабели этой категории применяются в основном для организации голосовой телефонной связи.

Полоса пропускаемых частот кабелей 4 категории составляет 20 МГц. Они также применялись для построения сетей 100BASE-T4, но в настоящее время практически не используются.

О кабелях 5 (5e) категории слышали, наверное, все. Пригодные для организации телефонной связи и передачи видеосигнала, они все же получили наибольшее распространение как основа для создания локальных компьютерных сетей 10BASE-T, 100BASE-TX и 1000BASE-T благодаря полосе пропускаемых частот равной 100 МГц.

Более современными является кабель 6 категории. Его полоса пропускаемых частот составляет 250 МГц, что позволяет организовать передачу данных со скоростью 10 Гбит/с на расстояние до 55 м. Впрочем, ориентироваться на последний параметр не стоит. Специалисты-практики отмечают, что достижение устойчивой работоспособности канала на дистанции свыше 50 метров труднодостижимо. Гораздо более реалистичным является показатель 30-35 м.

Существует также подкатегория данного кабеля, известная как 6А. В целях борьбы с помехами и увеличения полосы пропускаемых частот до 500 МГц эти кабели оснащены либо общим экраном из фольги (F/UTP), либо экранами вокруг каждой из четырех витых пар (U/FTP). Благодаря повышенной до 500 МГц полосе пропускаемых частот, передачу данных со скоростью 10 Гбит/с можно осуществлять на расстояние до 100 м (предельное теоретическое значение).

Самой «молодой» утвержденной Международной организацией по стандартизации (ISO) категорией кабелей является седьмая. Предназначенные для наиболее требовательных к физической среде передачи сигнала СКС, кабели этой категории обеспечивают полосу пропускаемых частот 600 МГц (1000 МГц для категории 7А), а скорость передачи данных — до 40 Гбит/с (для категории 7А). От кабелей шестой категории их отличает наличие как экрана вокруг каждой витой пары, так и общего экрана для всех 4 пар (F/FTP или S/FTP в зависимости от технологии изготовления внешнего экрана — оплетка или фольга соответственно).

Экранирование витых пар используется как для снижения внешних электромагнитных помех (общий экран), так и для минимизации взаимных наводок между витыми парами (индивидуальные экраны). Судить о конструкции конкретного кабеля можно по его маркировке. Так буква F означает наличие экрана из сплошного полотна фольги, а буква S — наличие экранирующей оплетки. Буква U говорит об отсутствии экрана. При этом первая часть маркировки содержит информацию об общем экране, а вторая — об индивидуальных. Таким образом, например, маркировка SF/FTP означает, что в данном кабеле каждая пара экранирована фольгой, а также имеется двойной внешний экран из фольги и оплетки. В свою очередь маркировка UTP свидетельствует об отсутствии какой-либо защиты от наводок помимо самого скручивания проводов в пары с переменным шагом.

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

Многообразие номенклатуры кабелей с витыми парами объясняется широтой сфер применения. В связи с этим, конкретные модели могут включать в себя дополнительные функциональные элементы. Так уличные кабели, предназначенные для подвески на опорах, снабжены внешним стальным тросом, препятствующим деформации изделия под собственным весом. Силовые элементы, придающие кабелю большую прочность, могут размещаться и внутри, вблизи центральной оси. Для кабелей, предназначенных для внутренних работ, характерно наличие специального шнура из капронового волокна — рипкорда. Потянув за него, можно разрезать внешнюю оболочку кабеля, не повредив изоляцию витых пар. Некоторые модели с общим экраном помимо витых пар содержат в себе неизолированный дренажный провод, задачей которого является сохранение электрического контакта между частями экрана в случае его повреждения при слишком сильном сгибании. Этот список можно продолжать, но закончить стоит на том, что, какая бы задача не стояла перед проектировщиком СКС, всегда найдется именно та витая пара, которая подойдет наилучшим образом.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *