Методы и способы определения человека в Zoom
Как найти человека в зум, местонахождение, айди в зуме или ещё какую либо инфу о человеке?Если есть только запись и его ник?
06 Nov 2020 в 11:11 #2
LockMyClock сказал(а):↑
Как найти человека в зум, местонахождение, айди в зуме или ещё какую либо инфу о человеке?Если есть только запись и его ник?
Нажмите, чтобы раскрыть.
Маньяк или опер?
06 Nov 2020 в 11:14 #3
Brewsmaster сказал(а):↑
Маньяк или опер?
Нажмите, чтобы раскрыть.
Борец за справедливость, там чел какой то на лекцию зашёл лет 12, хотел бы вычислить.Для общего так сказать показательного урока, для всех.
06 Nov 2020 в 11:16 #4
LockMyClock сказал(а):↑
Борец за справедливость, там чел какой то на лекцию зашёл лет 12, хотел бы вычислить.Для общего так сказать показательного урока, для всех.
Нажмите, чтобы раскрыть.
удачи сломать сервак зума
06 Nov 2020 в 11:58 #5
Шизик, не трогай ребёнка
06 Nov 2020 в 12:08 #6
Тебя потом следователь посадит на
для показательно урока
06 Nov 2020 в 12:15 #7
LockMyClock сказал(а):↑
Как найти человека в зум, местонахождение, айди в зуме или ещё какую либо инфу о человеке?Если есть только запись и его ник?
Нажмите, чтобы раскрыть.
Вроде можно, но без знания как, не сделаешь никогда. Всего то выяснить откуда идёт поток данных от пользователя через все многочисленные узлы связи, а сделать это в домашних условиях почти нереально.
Узнать внешний ip-адрес своего компьютера
Уточните в вопросе, что вы имеете в виду под IP-адрес своего компьютера? Это локальный адрес (127.0.0.1), адрес во внутренней сети (192.168.*.* или 10.*.*.*), либо внешний (публичный) адрес? Какие вас интересуют?
27 дек 2016 в 18:02
String host = System.Net.Dns.GetHostName() Ну-ну. вот вернёт он тебе vasya-pupkin.xxx.local — и чё дальше?
27 дек 2016 в 18:57
@Akina Visual Studio считает его устаревшим)
27 дек 2016 в 20:08
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Я пару раз пользовался вот таким образам:
string pubIp = new System.Net.WebClient().DownloadString("https://api.ipify.org"); Отслеживать
ответ дан 27 дек 2016 в 21:36
Лазиз Эргашев Лазиз Эргашев
195 6 6 бронзовых знаков
Полагаю, что тривиальное решение с обращением к внешнему сервису не требуется?
Выполните трассировку на любой доступный публичный адрес. Первый не-приватный адрес в цепи — это почти наверняка адрес дефолтного шлюза внешнего маршрутизатора. Для определения его (самого маршрутизатора) адреса нужно оттрассировать все адреса подсети найденного дефолтного шлюза — при трассировке до внешнего адреса получите на 1 хоп меньше, чем до остальных адресов подсети.
PS1. Поскольку гарантированного способа определить маску подсети дефолтного шлюза имхо нет, придётся делать какие-то допущения. Впрочем, провайдеры редко выделяют под вывод клиентов широкий пул.
PS2. Провайдер запросто может учинить бяку и перекосячить трассировку (узлы могут не отвечать или нештатно менять TTL). А если у него OSPF с несколькими равноценными маршрутами, трасссировка может вообще превратиться в ходячий цирк.
PS3. Провайдер может иметь несколько внешних каналов, и твой внешний адрес будет зависеть от чего угодно — начиная с адреса узла назначения и кончая ценой на рис в Антарктиде.
PS4. И это ещё только для случая, когда выход в мир — прямой. А не приведи господи у тебя прокся какая-нибудь.
Что такое WebRTC?
WebRTC (Web Real Time Communications) — это стандарт, который описывает передачу потоковых аудиоданных, видеоданных и контента между браузерами (без установки плагинов или иных расширений) или другими поддерживающими его приложениями в режиме реального времени. Данная технология позволяет превратить браузер в оконечный терминал видеоконференцсвязи. Чтобы начать общение, достаточно просто открыть веб-страницу конференции.
В этой статье мы раскроем некоторые особенности применения WebRTC, а также рассмотрим преимущества и недостатки данной технологии.
Как работает WebRTC
Рассмотрим работу технологии на примере звонка между двумя абонентами через браузер:
- Пользователь открывает страницу, содержащую WebRTC контент.
- Браузер запрашивает доступ к веб-камере и микрофону, если это необходимо. Пока пользователь не разрешит доступ к устройству, оно не будет использоваться. В случаях, когда это необязательно (например, при просмотре трансляций), никаких дополнительных разрешений не требуется.
- В браузере, инициирующем соединение, формируется SDP-пакет. По сути это текстовый файл, содержащий всю необходимую информацию о параметрах соединения. Например, что будет передаваться (звук, видео, данные), с помощью каких кодеков, какие параметры поддерживаются браузером и т. д.
- В зависимости от реализации технологии, инициатор соединения передаёт этот пакет другим участникам. Зачастую для этого используется сигнальный сервер и WebSocket протокол.
- На принимающей стороне браузер получает SDP-пакет, а затем генерирует подобный, но с учетом информации из первого. Второй пакет отправляется назад, к инициирующей стороне. Теперь оба клиента уже имеют минимальное представление друг о друге.
- В зависимости от реализации, параллельно с предыдущими шагами происходит анализ состояния подключения к сети. Клиентам передаётся адрес STUN-сервера, который используется, чтобы узнать внешний IP-адрес устройства. Он сравнивается с внутренним IP-адресом для того, чтобы определить используется ли NAT в данном подключении и, если да, то как маршрутизируются UDP-пакеты. В более сложных случаях (например, когда используется двойной NAT), применяются TURN-сервера. Они, по сути, являются ретрансляторами, превращая соединение клиент-клиент (P2P) в клиент-сервер-клиент.
- Если все шаги пройдены успешно, то соединение устанавливается. Периодически вызывается событие onicecandidate, которое передаёт информацию об IP-адресах, настройках NAT, попытках подключения между клиентами.
Преимущества стандарта
- Не требуется установка ПО.
- Высокое качество связи благодаря:
- использованию современных видео- и аудиокодеков;
- автоматическому подстраиванию качества потока под условия соединения;
- встроенной системе эхо- и шумоподавления;
- автоматической регулировке уровня чувствительности микрофонов участников (АРУ).
Недостатки стандарта
- Все WebRTC решения несовместимы между собой, т. к. стандарт описывает лишь способы передачи видео и звука, оставляя реализацию способов адресации абонентов, отслеживания их доступности, обмена сообщениями и файлами, планирования и прочего за разработчиком. Другими словами, вы не сможете позвонить из одного WebRTC приложения в другое.
- Для пользователей, которые беспокоятся о своей приватности, неприятным открытием станет то, что WebRTC определяет их реальные IP-адреса. При этом сохранить анонимность не поможет ни прокси, ни использование сети Tor. Скрыть IP-адрес можно с помощью различных VPN сервисов, а также при использовании TURN-сервера. При необходимости использование WebRTC можно отключить.
- WebRTC не поддерживает удалённое управление рабочим столом. Да, транслировать происходящее на экране устройства можно, но это будет такой же односторонний видеопоток, как и изображение, передающееся с камеры и способа взаимодействия с источником потока нет. Сделано это из соображений безопасности: код Javascript не может управлять чем-либо за пределами текущего окна браузера. Больше возможностей, включая удалённое управление рабочим столом, можно получить при использовании специально разработанных клиентских приложений вендоров ВКС.
Особенности работы WebRTC на мобильных устройствах
Кодеки в WebRTC
Кодеки WebRTC можно разделить на обязательные (браузеры, реализующие данную технологию должны их поддерживать) и дополнительные (не включённые в стандарт, но добавленные некоторыми браузерами).
Аудиокодеки
Для сжатия аудиотрафика в WebRTC используются обязательные кодеки (Opus и G.711) и дополнительные (G.722, iLBC, iSAC).
Opus
Opus — это аудиокодек с низкой задержкой кодирования (от 2.5 мс до 60 мс), поддержкой переменного битрейта и высоким уровнем сжатия, что идеально подходит для передачи потокового аудиосигнала в сетях с переменной пропускной способностью. Является основным аудиокодеком для WebRTC. Opus — гибридное решение, сочетающее в себе лучшие характеристики кодеков SILK (компрессия голоса, устранение искажений человеческой речи) и CELT (кодирование аудиоданных). Кодек находится в свободном доступе, разработчикам, которые его используют, не нужно платить отчисления правообладателям. По сравнению с другими аудиокодеками, Opus, несомненно, выигрывает по множеству показателей. По ряду параметров он превосходит довольно популярные кодеки с низким битрейтом, такие, как MP3, Vorbis, AAC LC. Opus восстанавливает наиболее приближенную к оригиналу “картину” звука, чем AMR-WB и Speex.
G.711
G.711 — устаревший голосовой кодек с высоким битрейтом (64 kbps), который чаще всего применяется в системах традиционной телефонии. Основным достоинством является минимальная вычислительная нагрузка из-за использования лёгких алгоритмов сжатия. Кодек отличается низким уровнем компрессии голосовых сигналов и не вносит дополнительной задержки звука во время общения между пользователями.
G.711 поддерживается большим количеством устройств. Системы, в которых используется этот кодек, более легкие в применении, чем те, которые основаны на других аудиокодеках (G.723, G.726, G.728 и т.д.). По качеству G.711 получил оценку 4.2 в тестировании MOS (оценка в пределах 4-5 является самой высокой и означает хорошее качество, аналогичное качеству передачи голосового трафика в ISDN и даже выше).
G.722
G.722 — является стандартом ITU-T, принят в 1988 году, в настоящее время является бесплатным. Может работать со скоростью 48, 56 и 64 кбит/с, обеспечивая качество звука на уровне G.711. И аналогично G.711 является устаревшим. Поддерживается в Chrome, Safari и Firefox.
iLBC
iLBC (internet Low Bitrate Codec) — узкополосный речевой кодек с открытым исходным кодом. Доступен в Chrome и Safari. Из-за высокого сжатия потока при использовании данного кодека возрастает нагрузка на процессор.
iSAC
iSAC (internet Speech Audio Codec) — широкополосный речевой аудиокодек, ранее проприетарный, который в настоящее время является частью проекта WebRTC, тем не менее не обязателен для использования. Поддерживается в Chrome и Safari. В реализации для WebRTC используется адаптивный битрейт от 10 до 52 кбит/с с частотой дискретизации 32 kHz.
Видеокодеки
Вопросы выбора видеокодека для WebRTC заняли у разработчиков несколько лет, в итоге в стандарт вошли VP8 и H.264. Также существуют реализации необязательных видеокодеков (H.265, VP9, AV1).
VP8
VP8 — свободный видеокодек с открытой лицензией, отличается высокой скоростью декодирования видеопотока и повышенной устойчивостью к потере кадров. Кодек универсален, его легко внедрить в аппаратные платформы, поэтому очень часто разработчики систем видеоконференцсвязи используют его в своих продуктах. Совместим с браузерами Chrome, Edge, Firefox и Safari (12.1+).
Платный видеокодек H.264 стал известен намного раньше своего собрата. Это кодек с высокой степенью сжатия видеопотока при сохранении высокого качества видео. Широкая распространенность этого кодека среди аппаратных систем видеоконференцсвязи предполагает его использование в стандарте WebRTC. Совместим с браузерами Chrome (52+), Edge, Firefox (в версиях 68+ для Android поддержка была прекращена) и Safari.
VP9
VP9 — открытый и бесплатный стандарт сжатия видео, разработанный в 2012 году компанией Google. Является развитием идей, заложенных в VP8 и в последующем был расширен в рамках AV1. Совместим с браузерами Chrome (48+) и Firefox.
H.265
H.265 — платный видеокодек, являющийся преемником H.264, обеспечивающий такое же визуальное качество при вдвое меньшем битрейте. Это достигается с помощью более эффективных алгоритмов сжатия. В настоящее время этот кодек конкурирует с бесплатным AV1.
AV1
AV1 — открытый кодек для сжатия видео, разработанный специально для передачи видео по сети Интернет. Поддерживается в Chrome (70+) и Firefox (67+).
При указании совместимости кодека с браузером Chrome подразумевается совместимостьсо всеми Chromium-based браузерами соответствующих версий.
Тонкости работы с технологией WebRTC
Подключение по WebRTC
В зависимости от конкретной реализации WebRTC возможны отличия в версиях совместимых браузеров. Подробный список поддерживаемых десктопных и мобильных браузеров для TrueConf доступен на странице системных требований.
Если вам интересно узнать, как будет развиваться технология WebRTC, то рекомендуем посетить официальный сайт разработки, а также страницы стандарта проекта и репозитория.
WebRTC для рынка ВКС
Популярность технологии
На сегодняшний день WebRTC второй по популярности после проприетарного протокола Zoom протокол видеосвязи и опережает все остальные стандартные (H.323 и SIP) и проприетарные (Microsoft Teams и Cisco Webex) протоколы.
Увеличение числа ВКС-терминалов
Технология WebRTC оказала сильное влияние на развитие рынка ВКС. После выхода в свет первых браузеров с поддержкой WebRTC в 2013 году потенциальное количество терминалов видеоконференцсвязи по всему миру сразу увеличилось на 1 млрд. устройств. По сути, каждый браузер стал ВКС терминалом, обладающим базовыми возможностями для участия в видеоконференциях.
Использование в специализированных решениях
Использование различных JavaScript библиотек и API облачных сервисов с поддержкой WebRTC позволяет легко добавить поддержку видеосвязи в любые веб-проекты. Ранее для передачи данных в реальном времени разработчикам приходилось изучать принципы работы протоколов и использовать наработки других компаний, которые чаще всего требовали дополнительного лицензирования, что увеличивало расходы. Уже сейчас WebRTC активно используется для организации видео-контакт-центров, проведения вебинаров и т. п.
Конкуренция с Flash
WebRTC и HTML5 стали смертельным ударом для технологии Flash, которая и так переживала свои далеко не лучшие годы. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология окончательно исчезла с рынка.
Примеры сервисов, использующих WebRTC
TrueConf Server — отечественная ВКС платформа, основанная на современной масштабируемой архитектуре SVC, работает как в локальных сетях, так и через Интернет. Сервер вебинаров разворачивается на оборудовании вашей компании, что гарантирует защиту персональных данных от доступа третьих лиц. Благодаря высокому разрешению видео (до 4К) и инструментам для совместной работы прекрасно подходит для трансляций онлайн-мероприятий, дистанционного образования и удаленной работы.
Google Meet
Google Meet — сервис мгновенного обмена сообщениями, а также проведения видео- и аудиозвонков, выпущенный в 2017 году компанией Google. В браузерах, основанных на Chromium (Google Chrome и др.) используется много скрытых возможностей WebRTC, которые не описаны в документации и периодически появляются первыми в его решениях для Meet (как и в его предшественнике Hangouts). Так было с захватом экрана, размытием фона, поддержкой аппаратного кодирования на некоторых платформах.
Jitsi Meet
Jitsi Meet — приложение с открытым исходным кодом, выпущенное компанией 8×8. Технология Jitsi основана на архитектуре Simulcast, что означает нестабильную работу на слабых каналах связи и высокие требования к скорости подключения на стороне сервера. Позволяет проводить веб-конференции только в браузере и не имеет полноценных клиентских приложений для совместной работы, поддержаны конференции с количеством участников не более 75 (до 35 с высоким качеством связи). Для полноценного использования Jitsi в корпоративной среде необходима самостоятельная разработка и установка дополнительного ПО.
BigBlueButton
BigBlueButton – это свободное программное обеспечение для видеоконференцсвязи. Особый акцент разработчики делают на дистанционном образовании (присутствуют такие функции как интерактивная доска, показ контента, поддержка опросов и т. п.). Поддерживает веб-конференции до 100 участников.
А что насчёт Zoom
Вопреки расхожему мнению в Zoom технология WebRTC не используется для передачи и декодирования медиа-данных. Сделано это для экономии серверных ресурсов. На стороне браузера задействованы другие web технологии — низкоуровневый WebAssembly и WebSocket. При использовании подобных нестандартных подходов передачи видеопотока могут возникать проблемы с качеством картинки у некоторых участников.