P2 что это в компьютере
Обновлено: 06.07.2024
Подключение проводов блока питания при сборке ПК — одна из самых серьезных задач, с которой сталкиваются начинающие пользователи. Все слышали фразу «с электричеством шутки плохи», и нужно понимать, что в случае неправильного подключения проводов можно запросто повредить дорогие комплектующие. Чтобы этого не случилось, нужно знать распиновку разъемов БП, максимальную нагрузку на каждый разъем и положение ключей, которые не дают подключить провода неправильно. В этой статье вы найдете всю информацию на эту тему.
Стандарты блоков питания для ПК и их разъемов развиваются уже почти 40 лет — со времен выхода первых компьютеров IBM PC. За это время сменилось несколько стандартов AT и ATX. Казалось бы, все возможные разъемы уже придуманы и ничего нового не требуется, но осенью этого года ожидается выход видеокарт Nvidia GeForce RTX 3000-й серии, который принесет с собой новый, 12-контактный разъем питания. Производители уже стали добавлять в комплекты проводов новых БП коннектор 12-Pin Micro-Fit 3.0. Будет неудивительно, если этот разъем питания дополнит новые стандарты ATX.
Перед тем, как перейти к описанию и распиновке всех разъемов в современном БП, хотелось бы напомнить, что основные напряжения, которые нам встретятся, это +3.3 В, +5 В и +12 В. Сейчас основное напряжение, которое требуется и процессору, и видеокарте — это +12 В. В свою очередь, +5 В нужно накопителям, а +3.3 В используется все реже.
И если взглянуть на табличку, которая есть на боку каждого БП, мы увидим выдаваемые им напряжения, токи и мощность по каждому из каналов.
Разъем Molex
Начнем с самого древнего разъема, который почти без изменений дошел до наших времен, появившись у первых «персоналок». Это всем известный 4-контактный разъем, называемый Molex.
Сегодня сфера применения этого разъема сузилась до питания корпусных вентиляторов, передних панелей корпусов ПК, разветвителей и переходников питания видеокарт и накопителей. Например, переходников питания видеокарты «Molex — PCI-E 6 pin». Несмотря на то, что разъем выдает до 11 А на контакт, а значит, может дать видеокарте, в теории, 132 ватта мощности, использовать его стоит крайне осторожно.
Надо учитывать, что толщина проводов может не соответствовать такой мощности, а сами контакты могут быть разболтанными, с неплотной посадкой. В результате это чревато нагревом проводов, контактов и расплавлению изоляции.
Если вам обязательно требуется такой переходник, выбирайте модель с двумя разъемами Molex.
Обязательно проверяйте качество контактов переходника и вставляйте его надежно, до упора. Для защиты от неправильного подключения в разъеме предусмотрены два скоса.
Внимание! Несмотря на то, что скосы не дают воткнуть разъем другой стороной, при определенном усилии и разболтанных гнездах есть вероятность воткнуть разъем, развернутый на 180 градусов, что приведет к выходу из строя оборудования.
24-контактный разъем питания материнской платы
Этот разъем появился в спецификациях ATX12V 2.0 в 2004 году и заменил устаревший 20-контактный разъем. Он может обеспечить довольно серьезные мощности для питания процессора, видеокарты и материнской платы: по линии +3.3 В — 145.2 Вт, по линии +5 В — 275 Вт и 264 Вт по линии +12 В (при использовании контактов Molex Plus HCS).
Примечание. Контакты Molex сертифицированы на ток 6 А. Molex HCS — до 9 А. А Molex Plus HCS — до 11 А.
Разъемы питания процессора
Энергопотребление процессоров неуклонно росло последние 20 лет, что потребовало дополнительных разъемов питания для них. И в спецификациях ATX12V был введен дополнительный 4-контактный разъем питания процессора +12 В.
Сегодня даже на бюджетных материнских платах мы встречаем именно этот разъем, который теоретически может подать на питание процессора мощность до 576 Вт.
Разъем питания 3.5" дисководов
Еще один разъем, уже практически не встречающийся на новых БП. Ранее использовался для питания дисководов 3.5" и некоторых карт расширения.
Разъем питания SATA
Стандартный разъем для питания HDD, DVD и 2.5" SSD-приводов. Надежный и удобный разъем, воткнуть который другой стороной не получится из-за расположения специальных выступов. Ток, потребляемый HDD и SSD, довольно небольшой и беспокоиться о нагреве таких разъемов не стоит.
Разъемы дополнительного питания видеокарт
В начале нулевых годов резко выросло энергопотребление видеокарт, что потребовало для них специальных разъемов питания, принятых в спецификациях ATX12V 2.x.
Спецификация PCI Express x16 Graphics 150W-ATX Specification 1.0 была принята рабочей группой PCI-SIG в 2004 году. Она представила 6-контактный разъем, который может давать видеокарте 75 Вт мощности. И еще 75 Вт берутся со слота PCI-E x16. Получившиеся в сумме 150 ватт достаточны для питания видеокарт среднего уровня, например, GeForce GTX 1650 SUPER.
Производители видеокарт обычно стараются разгрузить питание по слоту PCI-E x16 и обеспечить запас питания для разгона, поэтому видеокарты с потреблением 120 ватт и выше, например, GeForce GTX 1660 SUPER, все чаще оснащаются восьмипиновым разъемом питания.
Вставить неправильно разъемы этого типа не получится: скосы на пинах расположены в строго определенном порядке. Но нужно подключать питание до упора — до защелкивания предохранительного язычка.
Выводы
Как вы могли заметить, все разъемы на современных БП разработаны так, чтобы исключить неправильное подключение. Также они обеспечивают избыточную надежность по нагрузке питания, что достигается увеличением числа контактов.
Но при сборке ПК не помешает помнить распиновки всех разъемов и максимальную силу тока, которую может выдержать разъем. Если пренебречь этими знаниями, можно рано или поздно повредить комплектующие. С подобным в период «крипто-лихорадки» 2017-2018 года столкнулись майнеры, у которых массово горели дешевые переходники питания видеокарт «Molex — PCI-E 6 pin».
Давайте отвлечемся от запретов в различных странах, давайте не будем думать, что P2P — механизм обхода блокировок.
Предлагаю вам альтернативное мнение на P2P — какие проблемы будущего и настоящего сможет решить данная архитектура информационных сетей.
Что такое настоящий P2P ?
Давайте введем понятие — настоящий P2P.
Настоящий P2P — это одноранговая сеть, в которой абсолютно все узлы сети выполняют одинаковые функции или автоматически могут изменять набор своих функций в зависимости от окружающих условий.
Изменение функций — это ничто иное как предоставление тех функций которые не могут работать у некоторых узлов одноранговой сети из-за ограничений:
1) За NAT'ом
2) Мобильные устройства
Оба класса устройств либо не могут иметь прямой доступ к сети (NAT) или могут, но строго не рекомендовано — (Мобильные устройства) из-за повышенного энергопотребления при огромном количестве подключений.
Для устранения данной проблемы используются такие технологии как TCP Relay (тк большинство P2P систем используют UDP, с огромным количеством одновременных подключений можно выбрать себе узел который будет выполнять функции получения запросов из сети по UDP и пересылки их на конечное устройство по TCP через одно и тоже соединение) Хочу напомнить, что подобный механизм уже был очень давно реализован в Skype, до его покупки компанией MS эти функции работали, позднее — понятие «супер ноды» в Skype ушло и их заменяют сервера MS.
Очень важно не путать P2P и Mesh сети. P2P — это одноранговое взаимодействие на уровне 3 и выше по модели OSI, Mesh — на 3 и ниже соответственно.
Какие проблемы решает P2P сети и какие технологии уйдут при повсеместном внедрении P2P?
Кэширование
В нынешнее время, некоторые провайдеры, а практически все операторы сотовой связи кэшируют трафик. Таким образом достигается экономия ресурсов и аплинков, что бы не гонять одинаковый трафик через магистрали.
Но зачем нужно кэширование, если контент попавший в сеть оператора при повторном запросе скорее всего будет запрошен из сети оператора?
При этом не надо строить никакой новой инфраструктуры вообще.
Система доставки контента используется в основном для доставки «тяжелого» контента, музыки, видео, игровых образом (steam), что бы снизить нагрузку на основной сервер и снизить время отклика — в разные страны и/или регионы ставиться CDN сервера, которые выполняют функцию балансировки нагрузки.
Данные сервера нужно обслуживать, затрачивая человека-часы их надо настраивать и они не смогут динамически увеличить свою пропускную способность или допустим:
В Нижнем Новгороде всегда был популярен сервис Giwi.get который позволяет в он-лайне смотреть легальный контент, CDN сервер в регионе может одновременно предоставить возможность просмотра фильмов и сериалов только 100 000 пользователей. Но внезапно на сервисе появляется новый контент (сериал) по прогнозам которые были сделаны на основе исследований, данный сериал не должен был заинтересовать людей из данного региона.
Нехватка каналов связи
Провайдеры последней мили готовы предоставить каналы в 1 Гигабит/с, и даже сеть внутри города сможет прокачать такую нагрузку, но вот незадача, от города идет магистральный канал, который не рассчитан на такую нагрузку, а расширение канала — это миллионы (подставьте валюту на выбор).
Естественно, данную проблемы опять же решают P2P сервисы, достаточно что бы в городе был хотя бы 1 источник контента (предварительно скачанный через магистраль) — все будут иметь доступ к контенту на максимальной скорости локальной сети (внутригородской)
Укрепление распределенности интернета
В нынешнем мире Аплинки — это всё, точки обмена трафика есть в городах, но провайдер скорее купит себе еще пару гигабит на магистрали, чем расширит каналы до точки обмена трафика или подключиться к соседним провайдерам.
Уменьшение нагрузки на аплинки
При использовании P2P — вполне логично, что провайдеру будет важнее иметь более широкие внутренние каналы, чем внешние, да и зачем платить за дорогостоящий аплинк, если с большой долей вероятности требуемый контент может быть найден в сети соседнего провайдера.
Провайдеры кстати тоже будут рады, даже сейчас провайдер предоставляет такие тарифы, что его аплинк не ровняется суммарному количеству всех пользователей.
Другими словами — если все пользователи начнут использовать на 100% свой тариф — аплинк у провайдера закончиться очень быстро.
Очевидно, что P2P решения дают возможность провайдеру сказать, что он предоставляет вам доступ к сети на скорости хоть 1 TB\c тк контент в сети очень редко бывает уникален, провайдер (который имеет пирсинг с соседями провайдерами из города) сможет с большой долей вероятности предоставить доступ к контенту на тарифной скорости.
Никаких лишних серверов в сети
Сейчас в сети провайдера обычно стоят такие сервера как: Google CDN (/Youtube), Yandex CDN/пиринг, DPI, + другие специфические сервера CDN/Кэширования которые используются в данном регионе.
Очевидно, что можно ликвидировать все CDN сервера и лишний пиринг (с сервисами, а не с провайдерами), DPI в такой ситуации тоже будет не нужен, тк в часы ЧНН не будет таких резких скачков нагрузку. Почему?
ЧНН — Забудьте эту аббревиатуру
ЧНН — Час наибольшей нагрузки, традиционно это утренние часы и вечерние часы, причем всегда заметны несколько пиков ЧНН в зависимости от рода занятости людей:
Пики вечернего ЧНН:
1) Возвращение школьников из школы
2) Возвращение студентов из вузов
3) Возвращение работников которые работают по графику 5/2
Данные пики вы сможете увидеть на любом оборудовании которое анализируют сетевую нагрузку на канал.
P2P Решает и эту проблему, тк велика вероятность, что контент который интересен школьникам может быть интересен как студентам так и работникам — соответственно он уже есть внутри сети провайдера — соответственно ЧНН на магистрали не будет.
Далёкое будущее
Мы отправляем свои аппараты на луну и на марс, уже давно есть интернет на МКС.
Очевидно, что в дальнейшем развитие технологий позволит осуществлять полёты в далёкий космос и длительное нахождение человека на других планетах.
Они тоже должны быть связаны в общую сеть, если мы рассматриваем классическую систему Клиент-Сервер, и сервера расположены на земле, а клиенты скажем на Марсе — Пинг убьет любе взаимодействие.
А если мы предполагаем, что на другой планете будет наша колония которая будет расти — то как и на земле они будут пользоваться интернетом, понятное что им нужны будут те же инструменты, что и нам:
1) Мессенджер
2) Соц-сети
И это минимально-необходимое количество сервисов которые позволяют обмениваться информацией.
Логично, что контент который будет генерироваться на Марсе будет интересен и популярен на марсе, а не на земле, как быть соц.-сетям?
Устанавливать свои сервера которые будут автономно работать и через некоторое время синхронизироваться с землёй?
P2P сети решать и эту проблему — на марсе у источника контента свои подписчики, на земле — свои, но соц.-сеть одна и та же, но если у Марсианского жителя будет подписчик с земли — нет проблем, при наличии канала контент прилетит и на другую планету.
Что важно отметить — не будет рассинхронизации, которая может случиться в традиционных сетях, не надо устанавливать никаких лишних серверов там и даже что-то настраивать. P2P система позаботиться сама о поддержке актуальности контента.
Разрыв каналов
Вернемся к нашему мысленному эксперименту — на марсе живут люди, на земле живут люди — все они обмениваются контентом, но в один прекрасный момент происходит катастрофа и связь между планетами пропадает.
При традиционных клиент-серверных системах мы можем получит полностью неработающую соц.-сеть или другую службу.
Помните, что у каждого сервиса есть центр авторизации. Кто будет заниматься авторизацией, когда канал нарушен?
А марсианские тинэйджеры тоже хотят постить фотографии своей марсианской еды в MarsaGram.
P2P Сети при разрыве канала с легкостью переходят в автономный режим — в котором она будет существовать полностью автономно и без какого-либо взаимодействия.
А как только связь появиться — все службы автоматически синхронизируется.
Но марс — это далеко, даже на земле могут быть проблемы с разрывом канала связи.
Вспомните последние громкие проекты Google/Facebook с покрытием новых территорий интернетом.
Некоторые уголки нашей планеты всё еще не подключены к сети. Подключение может быть слишком дорогим или экономически не оправданным.
Если же в таких регионах стоить свою сеть (интранет) с последующим подключением её к глобальной по средствам очень узкого канала — спутника, то P2P решения позволяет на начальном этапе пользоваться всеми функциями как и при глобальной связанности сетей. А в последствии — как мы уже говорили выше — позволяет прокачать весь нужный контент через узкий канал.
Выживаемость сети
Если мы полагаемся на централизованную инфраструктуру у нас вполне конкретное количество точек отказа, да, есть еще и резервные копии и резервные дата-центры, но надо понимать, что если основной ДЦ будет поврежден из-за стихии, доступ к контенту будет замедлен в разы, если вообще не прекратиться.
При P2P решении — выход из строя одного участника сети никак не сказывается на работе сети.
Я — не могу представить будущее в котором наши системы останутся клиент-серверными, это сгенерирует огромное количество ненужных костылей в инфраструктуре, усложнит поддержку, добавит точки отказа, не позволит произвести масштабирование когда оно понадобиться, потребуются огромные усилия, если мы захотим что бы наши клиент-серверные решения работали не только на нашей планете.
Так, что будущее — это определенно P2P, как изменил мир P2P можно наблюдать уже сейчас:
Skype — небольшая компания не тратила деньги на сервера смогла вырасти до огромного гиганта
Bittorrent — OpenSource проекты могут передавать файлы не нагружая свои сервера
Это только два ярких представителя информационной революции. На подходе множество других программ которые изменят мир.
Внимание! Не используйте для питания CPU разъёмы 6 pin или 6+2 pin. Они предназначены для видеокарт.
На текущий момент в блоках питания зачастую встречаются универсальные разъёмы 4+4 pin, хотя можно встретить и простой разъём 4 pin, и разъём 8 pin, который не разделяется на части. Безусловно, если говорить об универсальности, то разъём 4+4 pin предпочтительнее.
Разъёмы для питания видеокарт бывают двух видов: 6 pin и 8 pin. Очень часто производители блоков питания используют конфигурацию 6+2 pin.
Допустим, мы имеем дело с разъёмом 8 pin, который не разбивается на составные части. Как определить его предназначение? Во-первых, разъёмы блоков питания, как правило, подписываются. Надпись PCI-E означает, что данный коннектор должен подключаться к видеокарте. А надпись CPU говорит, что это разъём для питания процессора. Во-вторых, можно посмотреть распиновку. Это поможет, если коннекторы не подписаны. Обратите внимание на рисунок ниже.
Слева разъём для питания видеокарты, справа разъём для питания центрального процессора.
Разъём питания SATA имеет 15 pin, выглядят они по-другому, нежели в предыдущих разъёмах. В стороне от контактного ряда есть ключ, который и указывает, какой стороной нужно вставлять коннектор.
На текущий момент разъём SATA всё больше вытесняет разъём Molex, речь о котором пойдёт ниже. Поэтому лучше заранее посчитать количество устройств с данным разъёмом, которые придётся подключать, и иметь запас в один-два свободных разъёмов.
Кстати, именно фирме Molex мы обязаны за вид вилок и розеток, которые используются для питания материнских плат, процессоров и видеокарт.
Разъём своим появлением обязан компании Berg Electronics Corporation. Имеет четыре контакта и ключ, который подсказывает, как надо подключать коннектор.
Разъём для питания Floppy-дисководов (Floppy Drive Power Connector) был не единственным вкладом Berg Electronics Corporation в конструкцию персонального компьютера, но, конечно, до вклада компании Molex тут далеко. Кроме вышеописанного разъёма Berg Electronics Corporation также запомнилась внедрением в стандарты материнских плат своих разъёмов для подключения элементов лицевой панели системного блока.
Со стандартными разъёмами блоков питания на этом всё. Далее поговорим об экзотике.
Схема подключения разъёмов P8 и P9 на материнской плате.
Напоследок об использовании переходников. При отсутствии необходимого разъёма у блока питания соблазн использовать переходники довольно велик. Но слепо поддаваться этому соблазну не стоит.
Универсального решения для обнаружения работающего P2P приложения не существует. На сегодняшний день самые распространенные методы, проверка открытых портов и анализ трафика, не являются лучшими. Разрабатывайте собственные методы, и, может быть, некоторые из них значительно поднимут планку в эффективности обнаружения P2P трафика и идентификации P2P приложений.
С появлением в конце 1999 года Napster'a, P2P приложения быстро обрели популярность в интернет сообществе. Вместе с тем возросло потребление трафика такими приложениями и появилась необходимость в обнаружении пользователей P2P сетей в пределах сетевого трафика компании.
В этой статье автор предлагает новый способ обнаружения P2P пользователей, основанный на анализе поведения трафика, позволяющий определить даже тип используемого P2P приложения.
Стандартные методы
В настоящее время есть два основных способа идентификации пользователей P2P: наличие открытых портов и анализ трафика. Далее следует их краткий обзор.
Анализ открытых портов
Проверка на наличие открытых портов самый простой и распространенный из способов обнаружения использования P2P приложений. Он основывается на том, что большинство P2P приложений работают на заданных по умолчанию портах. Например:
Limewire 6346/6347 TCP/UDP
Morpheus 6346/6347 TCP/UDP
BearShare default 6346 TCP/UDP
Edonkey 4662/TCP
EMule 4662/TCP 4672/UDP
Bittorrent 6881-6889 TCP/UDP
WinMx 6699/TCP 6257/UDP
Для обнаружения P2P пользователей данным способом, нужно анализировать сетевой трафик на наличие соединений, использующих эти порты. Если соответствие обнаружено, это может быть индикатором P2P активности. Анализ открытых портов – практически единственный метод, доступный сетевым администраторам, ни имеющих специального ПО или аппаратных средств (таких как системы обнаружения вторжений) для мониторинга трафика.
Описанный способ очень прост в реализации, но его недостатки очевидны. Большинство P2P приложений позволяют изменять номера портов по умолчанию на любые. Кроме этого, многие современные приложения предпочитают использовать случайные номера портов. Также существует тенденция использования номеров портов известных приложений, таких как 80 порт. Все эти факты снижают эффективность данного способа.
Кроме проверки на наличие открытых портов у администраторов есть еще один метод обнаружения использования P2P приложений - анализ трафика протоколов прикладного уровня.
Суть этого способа в мониторинге трафика, проходящего через сеть, на предмет обнаружения определенных сигнатур, специфичных для P2P приложений, в полезной нагрузке пакетов. Многие современные коммерческие и свободно распространяемые решения для обнаружения P2P трафика основаны на этом методе. В их число входят L7-filter, Cisco's PDML, Juniper's netscreen-IDP, Alteon Application Switches, сигнатуры основных приложений Microsoft и NetScout. Каждое из этих приложений с помощью регулярных выражений анализирует данные, проходящие через прикладной уровень, пытаясь определить факт использования P2P приложения.
- P2P приложения постоянно развиваются и соответственно изменяются их сигнатуры. Чтобы анализ трафика был эффективен, требуется постоянное обновление базы сигнатур.
- С появлением программ для обнаружения P2P трафика, разработчики P2P приложений все чаще и чаще шифруют трафик, например, используя SSL, что сильно затрудняет анализ протокола.
- Поиск по сигнатуре требует анализа всего сетевого трафика, что может создать проблемы в работе крупных сетей. Такое ПО может создавать слишком большие нагрузки на сетевое оборудование или даже быть причиной ошибок в работе сети.
- Кроме того, поиск по сигнатуре на прикладном сетевом уровне очень ресурсоемкий. Чем больше пропускная способность сети, тем большую цену придется заплатить за проверку трафика.
Поведение трафика
Информация о сетевом трафике может быть легко получена из различных сетевых устройств без серьезного воздействия на производительность и доступность системы. В маленьких и средних сетях администраторы могут использовать логи сетевого оборудования. В больших сетях можно использовать функцию Netflow на маршрутизаторе для сохранения логов сетевого трафика.Несмотря на то, что полученные данные несколько “сыроваты”, в них все же есть полезная информация, которую можно проверить на соответствие определенным шаблонам. Хорошие результаты может принести анализ UDP сеансов.
Обнаружение P2P пользователей
Автор этой статьи обнаружил уникальные моменты в поведении трафика, характерные для P2P приложений. Данный факт может использоваться для обнаружения хостов, на которых работают P2P приложения. И все, что для этого нужно, это логи сетевого трафика.
Что подразумевается под анализом UDP сеансов и как это может нам помочь? Перед тем как ответить на этот вопрос, давайте рассмотри популярное P2P приложение Napster.
Централизованные, нецентрализованные и смешанные P2P сети
Napster, разработанный Шоном Фенингом, впервые появился в мае 1999 и представлял собой первое поколение P2P сетей. Сетевая структура Napster’а была централизована, что означает, что ее составными частями были два элемента: центральные индексные сервера и пользовательские компьютеры. Центральные сервера принадлежали Napster’у и использовались для обслуживания пользователей. Когда пользователь хотел загрузить музыкальный файл, он посылал запрос на центральный индексный сервер, который в соответствии с запросом производил поиск в своей базе данных и отсылал ответ, содержащий список других пользователей, имеющих желаемые музыкальные файлы. Затем, для загрузки файла, пользователь мог создать прямое соединения с пользователями из полученного списка.
Ахиллесова пята Napster’a – полная зависимость от центрального сервера. Если сервер прекратит работу – сеть разрушится. Это хорошо иллюстрируется действиями звукозаписывающих компаний, вынудивших Napster прекратить свою работу.
Случай с Napster’ом показал уязвимость централизованной структуры и сильно повлиял на дальнейшее развитие P2P приложений. По причинам законности, безопасности, масштабируемости, анонимности и др. все больше и больше современных P2P приложений работают в полностью или частично децентрализованной сетевой структуре или двигаются в этом направлении. Основные P2P сети и протоколы, такие как Edonkey2k, FastTrack, Gnutella, Gnutella2, Overnet, Kad, все использует данную концепцию.
Здесь нужно пояснить, Bittorrent не является универсальной P2P сетью, хотя это популярное P2P приложение. В то время как сетевая структура Bittorrent частично децентрализована, он все еще нуждается в ведомых серверах и методы, описанные в этой статье, не могут использоваться для идентификации пользователей этой программы.
Децентрализация означает сетевую структуру без центральных индексных серверов. Это основное направление эволюции P2P. Сегодня существует много сетей, имеющих полностью или частично децентрализованную структуру. Некоторым P2P приложениям, таким как EMule и Edonkey, поддерживающим полностью децентрализованные протоколы типа Kademlia, вообще не нужны никакие сервера. Но на данный момент самая популярная сетевая модель - частично децентрализованная, являющаяся гибридом децентрализованных сетей.
В частично децентрализованной сети все еще присутствуют центральные сервера, но они явно не конкретизированы и не статичны. Вместо этого, некоторые пользователи, обладающие значительными ресурсами (скорость процессора, дисковое пространство, высокоскоростная связь и процессорное время) автоматически принимают на себя функции центрального сервера. Каждый из них обслуживает группу обычных пользователей. Они связаны друг с другом и формируют основу частично децентрализованной сети. По мере появления в сети новых пользователей и ухода старых, компьютеры, исполняющие роль центральных серверов, меняются.
Чтобы подключиться к сети, пользователь должен найти способ подключиться к одному из действующих серверов. Список таких серверов может поставляться с программой или находиться на специальном сайте. Подключившись к сети, P2P приложение, кроме выполнения стандартной работы по загрузке файлов, должно взаимодействовать с P2P сетью, загружать информацию на сервер, проверять статус сервера, получать текущий список доступных серверов, сравнивать их характеристики и переключаться на наилучший, искать файлы, проверять статус компьютеров, на которых этих файлы находятся, сохранять список серверов для дальнейшего использования и т.д. Короче говоря, кроме стандартного трафика загрузки файлов, пользователю нужно отправлять большое количество управляющих пакетов на различные хосты, чтобы своевременно реагировать на изменяющуюся структуру сети. Это первый ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для взаимодействия с децентрализованной сетью пользователям периодически необходимо отсылать много управляющих пакетов .
Шаблоны UDP соединения
Большинство современных P2P приложений, использующих децентрализованную структуру, имеют встроенный модуль, выполняющий всю работу по взаимодействию с сервером. В качестве протокола взаимодействия часто используется UDP.
Почему UDP? Это простой, эффективный и низкозатратный протокол. Он не гарантирует доставку пакета, не требует установки и поддержки соединения. Все эти возможности делают UDP пригодным для быстрой доставки данных большому количеству получателей. Это все что нужно P2P приложениям. Внимательно изучив различные P2P программы, вы увидите, что для большинства современных приложений характерно определенное сетевое поведение. После запуска они начинают прослушивать один или несколько UDP портов и на протяжении всей работы активно взаимодействуют с внешними адресами через эти порты. Это второй ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для отправки управляющих пакетов пользователи используют один или несколько UDP портов .
Теперь давайте рассмотрим, как можно идентифицировать популярное P2P приложение Edonkey2000.
Пример UDP трафика Edonkey2000
Ниже показаны выборочные части логов исходящего UDP трафика Edonkey. Фактически, за две минуты мы получили 390 записей. В данном примере адрес отправителя заменен на x, а первая часть адреса получателя на y.
Как мы видим, весь трафик исходит из двух UDP портов: 2587 и 10810 (эти порты были выбраны Edonkey случайным образом и на другом хосте могут отличаться). Целевые адреса разнообразны. Фактически, Edonkey использует один порт для запроса статуса серверов Edonkey, а другой для создания соединений, поисковых запросов и другой работы.
Поиск по шаблону
Анализ работы других децентрализованных P2P приложений, таких как BearShare, Skpye, Kazaa, EMule, Limewire, Shareaza, Xolox, MLDonkey, Gnucleus, Sancho и Morpheus показал аналогичные результаты. Все эти приложения действуют одинаково: они используют один или несколько UDP портов для взаимодействия с внешними хостами. В терминах сетевого уровня этот шаблон может быть сформулирован следующим образом:
За период времени x, с одного IP и фиксированного UDP порта отправляются пакеты на y различных IP с фиксированным или случайным портом.
Опыт показывает, что при x равном 5, y равен 3, и на основе этого можно сделать выводы о наличии P2P трафика. Для получения более точного или грубого результата администраторы могут изменять значения x и y.
На практике мы можем сохранять логи сетевой активности соответствующих устройств и использовать базу данных и несложный скрипт для их обработки. Каждую минуту можно проверять, если какой-либо хост с фиксированного порта отправляет некоторое количество UDP пакетов на различные IP адреса, скорее всего это P2P хост.
Автор этой статьи провел тестирование в одном из крупнейших китайских интернет провайдеров. Логи сетевых соединений экспортировались как Netflow-данные и сохранялись в БД MySQL. С помощью небольшого скрипта, обрабатывающего данные, многие хосты были идентифицированы как P2P хосты, и что самое интересное, были обнаружены новые, широко не распространенные, P2P приложения.
Описанный способ кажется неплохим для обнаружения трафика, но что насчет ложных срабатываний? К счастью, такое поведение трафика редко встречается среди других сетевых приложений. Исключением являются игровые сервера и DNS сервера. Эти типы серверов также генерируют трафик, отсылая большое количество UDP пакетов на различные IP адреса. Но администраторы легко могут определить, является ли хост одним из вышеперечисленных серверов, так как в этом случае он не будет отсылать никаких пакетов с портов отличных от своего функционального порта, что в свою очередь не характерно для P2P приложений.
Значимость этого шаблона очевидна: такой подход не требует никакой информации о прикладном уровне, и в то же время весьма эффективен. Данный метод не зависит от базы сигнатур, поэтому с его помощью можно обнаруживать известные и неизвестные на данный момент P2P приложения. Вместе с тем для анализа информации сетевого уровня не требуется практически никакого дополнительно программного или аппаратного обеспечения, а нагрузка на существующее оборудование незначительна.
Минусы такого подхода
В описанном методе есть два минуса. Он может быть использован только для обнаружения P2P приложений, реализующих децентрализованную сетевую структуру (хотя большинство P2P приложений децентрализованы). Второй недостаток – если P2P приложение для взаимодействия с сетью использует протокол TCP, а не UDP, наши попытки его идентифицировать потерпят неудачу.
Идентификация P2P приложений
До этого момента мы пытались обнаружить P2P пользователей на основании логов сетевых соединений. Теперь продвинемся на шаг дальше, попробовав точно идентифицировать используемое хостом P2P приложение, не имея доступа к информации прикладного уровня.
Более тщательно анализируя UDP трафик различных P2P приложений можно обнаружить интересные закономерности. Выше было упомянуто, что P2P приложению с децентрализованной структурой необходимо периодически отправлять большое количество командных пакетов разного типа. Пакеты одного типа часто имеют одинаковый размер. Поэтому, анализируя UDP пакеты, даже при отсутствии информации прикладного уровня, можно точно определить, какое P2P приложение используется.
У большинства P2P приложений не документированы все детали реализации, некоторые поставляются с закрытыми исходными кодами, поэтому структура UDP пакетов большинства UDP приложений может быть нам точно не известна. Автор этой статьи выбрал семь популярных децентрализованных P2P приложений и провел такие наблюдения. Результаты подтвердили гипотезу о том, что все эти приложения для взаимодействия с внешним миром используют пакеты фиксированной длинны.
Edonkey2000
Edonkey2000 использует большое количество 6 байтовых UDP пакетов для запроса ‘server status request’. Этот тип пакетов можно наблюдать в основном во время запуска Edonkey. В дополнение, пакеты, содержащие запрос поиска, почти всегда имеют размер 25 байт.
BearShare
Во время запуска BearShare отсылает 28 байтовые UDP пакеты на несколько целевых адресов. Каждый раз, когда BearShare начинает загрузку файла, происходит отправка большого количества 23 байтовых UDP пакетов хостам-владельцам файла.
Limewire
При старте Limewire отправляет много UDP пакетов, размером в 23 и 35 байт. В начале операции загрузки файла этот P2P клиент отсылает большое количество 23 байтовых UDP пакетов.
Skype
При запуске Skype отправляет много 18 байтовых UDP пакетов.
Kazaa
С началом работы Kazaa отправляет 12 байтовые UDP пакеты на различные хосты.
EMule
Когда вы запустите EMule и начнете соединение с сервером, данное приложение оправит большое количество 6 байтовых UDP пакетов с запросами ‘server status request’ и ‘get server info’. Если вы захотите подключиться к сети Kad, Emule в процессе соединения будет отправлять UDP пакеты, размером 27 и 35 байт.
Shareaza
На протяжении всей работы Shareaza периодически отправляет 19 байтовые UDP пакеты.
Также присутствуют другие характеристики, по которым можно производить анализ поведения трафика, например тип переданных данных. Продолжительность соединения также может использоваться для обнаружения P2P трафика, но это добавит дополнительный уровень сложности.
Читайте также: