WebRTC: жизненный цикл ICE-пула и время

Пул ICE-кандидатов влияет на время возможной работы, но не объединяет сбор, события страницы, локальное описание и последующий перезапуск в одно наблюдение. Тихий журнал не доказывает отсутствие прежней активности сервера. BotBrowser документирует адресные политики WebRTC, но не гарантирует настройку размера пула или отмену прежней активности.

Кратко

• Ненулевой iceCandidatePoolSize запрашивает предварительный сбор, но не подтверждает готовность пула.
• setLocalDescription() обозначает этап передачи кандидатов, а не время первого сетевого действия.
• Начальный пул применяется в первом обмене; restartIce() запрашивает новое согласование и не отменяет прошлую активность.

Посмотреть видео

Это видео на английском разбирает тот же вопрос, что и статья: в трассе WebRTC несколько часов, поэтому настроенный размер пула, событие кандидата в странице, локальное описание и серверный журнал нельзя заменить одним моментом «ICE начался». Показан контролируемый локальный стенд в Ubuntu Chrome: peer connection создаётся с ненулевым размером пула, а позднее изменение возвращает InvalidModificationError; второй зонд считает события кандидатов внутри заявленного окна и читает состояние сбора. Счёт остаётся наблюдением страницы, а не серверным журналом; видео не утверждает, что измерялся реальный сайт, и не заявляет, что BotBrowser управляет размером пула. Аудио на английском.

Содержание

• Посмотреть видео
• Как время меняет вопрос приватности
• Ограниченный жизненный цикл пула
• Разделяйте уровни наблюдения
• Разбор неполной хронологии
• Граница политики BotBrowser
• Практический вывод

BotBrowser документирует адресные политики WebRTC для управляемых сессий, но не гарантирует настройку размера пула или отмену прежней активности. Руководство по предотвращению утечек WebRTC описывает типы кандидатов и адресные политики, а руководство по mDNS-кандидатам объясняет представление host-кандидата. Здесь рассматривается время наблюдения отдельных этапов ICE.

Как время меняет вопрос приватности

В трассе WebRTC может быть несколько временных точек: создание peer connection, необязательный предварительный сбор кандидатов, вызов локального описания, передача событий кандидатов странице, обмен offer/answer и последующий перезапуск ICE. Если считать всё единым моментом «начала ICE», важные различия исчезают. Рекомендация WebRTC определяет iceCandidatePoolSize как размер заранее собираемого пула; значение по умолчанию равно нулю. Ненулевое значение запрашивает пул, но не является записью с отметками времени о том, что получила страница.

Граница API	Записать	Не делать вывод
RTCPeerConnection(configuration)	Запрошенный iceCandidatePoolSize и начало записи	Что предварительный сбор завершён
setLocalDescription()	Время вызова и переданные события	Что сеть заработала именно тогда
restartIce()	Запрос перезапуска и следующее согласование	Что начальный пул восстановлен

Событие страницы описывает видимую приложению точку передачи. Оно не задаёт время каждой DNS-, STUN- или TURN-операции, которая могла произойти раньше. Важен и обратный случай: отсутствие события кандидата в журнале приложения само по себе не доказывает отсутствия прежнего сбора или активности сервера. Запись могла начаться поздно, приложение могло отфильтровать собственный журнал, а наблюдение могло поступить с другого уровня. Это причины обозначить границы свидетельств, а не придумывать пропущенное событие.

При разрешённой проверке приватности или совместимости разделяйте четыре наблюдения:

• Настроенный размер пула и время фиксации этой конфигурации.
• Сетевую активность из отдельного разрешённого серверного журнала, если он есть.
• События кандидатов, переданные приложению, с указанным окном записи.
• Локальное описание и этап offer/answer, записанные приложением.

Эти записи отвечают на разные вопросы. Настройка показывает запрос приложения. Событие показывает передачу скрипту. Локальное описание показывает данные, переданные приложением API согласования. Серверный журнал показывает наблюдение конкретного сервера. Ни одна запись сама по себе не доказывает, что политика адресов применялась до всех значимых сетевых действий. Перед сравнением отметок времени укажите часы и точку наблюдения каждого источника.

Пул также не равен видимому странице числу кандидатов. Настроенный размер не доказывает, что реализация успела собрать столько пригодных кандидатов до следующего вызова. RFC 9429 прямо учитывает исчерпание пула, если нужны дополнительные компоненты ICE или времени на сбор не хватило; тогда остальные кандидаты собираются обычным способом. Поэтому значение настройки, число событий страницы и содержимое локального описания нельзя считать взаимозаменяемыми измерениями.

Такое разделение предотвращает два чрезмерных вывода. Фраза «до локального описания событие кандидата не записано» описывает конкретный журнал и его покрытие. Фраза «до локального описания сетевой активности не было» шире и требует свидетельств из соответствующей точки сетевого наблюдения. Ненулевое значение разрешает предварительный сбор, но не доказывает, что определённый сервер был связан в определённое время. Записывайте то, что показывает каждый источник; остальное оставляйте неизвестным.

Ограниченный жизненный цикл пула

У пула определённая роль в согласовании; это не кеш, повторно используемый при каждом следующем обмене. В разделе 3.5.4 RFC 9429 описана последовательность: когда setLocalDescription начинает сбор для первого обмена offer/answer, реализация должна сначала проверить наличие кандидатов в пуле. Доступные кандидаты следует передать приложению через события кандидатов. Если пул исчерпан, потому что нужно больше компонентов или времени на сбор не хватило, остальные кандидаты собираются обычным образом. RFC указывает, что такое применение пула относится к первому обмену offer/answer; после него пул очищается и больше не используется.

RFC использует «SHOULD» для передачи доступных кандидатов. Сохраняйте эту модальность: это нормативная рекомендация, а не доказательство, что конкретный пул завершил сбор к определённому времени. В том же разделе сказано, что поддержание предварительно собранных кандидатов может расходовать ресурсы настроенных STUN- или TURN-серверов. Это ресурсное последствие, указанное RFC, а не измеренный объём трафика или обещанная длительность хранения в конкретной сборке браузера.

Момент настройки тоже ограничен. Алгоритм WebRTC отвергает изменение iceCandidatePoolSize, если setLocalDescription уже вызывался. Для этого ограничения метод сообщает InvalidModificationError, но имя исключения само не устанавливает причину: его могут вызвать и другие изменения. В полезной записи инцидента нужны прежняя и запрошенная конфигурации, порядок вызовов и контекст исключения. Без этого приписывать ошибку размеру пула означает делать предположение.

Этап	Интерпретация пула	Видимое приложению свидетельство	Чего запись установить не может
Создание с размером 0	Эта настройка не запрашивала предсбор	Начальный снимок конфигурации	Что дальнейшего сбора не будет
Создание с ненулевым размером	Предварительный сбор разрешён при подготовке	Запрошенный размер; отдельное наблюдение сервера, если есть	Что пул заполнен или событие страницы уже произошло
До локального описания	Размер можно выбрать или изменить по правилам API	Снимки конфигурации и порядок вызовов	Что запрошенный пул уже готов
Сбор первого локального описания	Доступные кандидаты следует передать; недостающие собираются обычно	События и жизненный цикл локального описания	Полную раннюю сетевую хронологию только по событиям страницы
После первого обмена	Начальный пул пуст и больше не применяется	История согласования	Что поздний перезапуск восстановит пул
Поздний ICE restart	Через согласование запрашивается новое поколение ICE	Вызов перезапуска и следующая сигнализация	Что прежняя активность стёрта

Эта матрица помогает читать записи собственной тестовой системы; это не рецепт детектирования. Фиксируйте названия этапов и примерный порядок, а не содержимое кандидатов. Различайте запрошенную настройку и завершённую операцию. Если независимого сетевого наблюдения нет, так и укажите; не превращайте последовательность событий страницы в замену активности сервера.

ICE restart является последующим действием согласования, а не кнопкой возврата. restartIce() запрашивает перезапуск для следующего согласования. Он не удаляет прежнее событие задним числом, не стирает серверный журнал и не восстанавливает начальный пул после его расходования при первом обмене offer/answer. Если отчёт охватывает несколько поколений, помечайте этап каждой записи. Иначе кандидата после перезапуска можно ошибочно связать со свидетельствами начального обмена.

Разделяйте уровни наблюдения

Набор свидетельств должен указывать, какой уровень породил каждое наблюдение, и какой интервал времени оно охватывает. Снимок конфигурации фиксирует запрошенные приложением значения. Событие страницы фиксирует передачу скрипту. Локальное описание фиксирует данные на границе этого API. Серверный журнал, если владелец системы вправе его просматривать, фиксирует наблюдения конкретного сервера. Часы, сроки хранения и покрытие могут различаться. Сравнение без этих сведений может выглядеть убедительнее, чем исходные записи.

Наблюдение	Поддерживает вывод	Само по себе не поддерживает
iceCandidatePoolSize: 0 до согласования	Эта настройка не запрашивала предсбор	Что кандидаты никогда не будут собираться
Ненулевой настроенный пул	Предсбор был запрошен	Что сбор завершён или пул всё ещё доступен
Время события кандидата	Страница получила событие в записанный момент	Что первая сетевая активность была именно тогда
Вызов setLocalDescription	Приложение вошло в этап локального описания	Что все кандидаты уже собраны
Вызов restartIce()	Приложение запросило перезапуск для дальнейшего согласования	Что начальный пул восстановлен или история стёрта
Нет события в частичной трассе	В записи этого события нет	Что вне окна записи не было активности

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

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

Для повторяемого сравнения определяйте наблюдения одинаково в обоих запусках. Если один записывает вызовы API с момента создания соединения, а другой начинает с первого callback кандидата, видимые хронологии не выровнены. До сравнения составьте небольшую таблицу: определение события, источник часов, граница начала и правило обработки пропусков. Это метод проверки собственных тестовых систем; он не требует раскрывать кандидаты или обращаться к сторонним endpoint.

Разбор неполной хронологии

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

Симптом	Сначала проверить	Не делать вывод
Нет события до локального описания	Запрашивался ли сбор и охватывает ли запись раннюю активность	Что не было предсбора или обращения к серверу
Событий после описания меньше ожидаемого	Хватило ли пулу времени или ёмкости; обычный сбор может продолжаться	Что соединение сорвалось только из-за малого пула
InvalidModificationError при настройке	Какое поле изменилось и вызывался ли setLocalDescription	Что причиной обязательно был размер пула
События после restartIce()	Вызов, порядок согласования и полнота записи	Что прежнее поколение или активность исчезли
Серверный и страничный журналы расходятся	Часы, границы, фильтрацию и точку наблюдения	Что одна запись описывает другой уровень

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

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

При сравнении запусков различия могут быть связаны с охватом записи, временем сетевого ответа, порядком вызовов приложения или границами серверного журнала, а не только с размером пула. Записывайте эти условия рядом со сравнением. Не утверждайте, что изменение размера вызвало разницу, если свидетельства не изолируют этот фактор, а источник не подтверждает предложенный механизм. Цитируемые стандарты описывают поведение API и жизненный цикл, но не дают измерений для неисполнявшейся конфигурации браузера.

Тот же подход применим к отклонённому изменению настроек. Сохраните старую и новую конфигурации без секретов, отметьте, вызывалось ли локальное описание, и запишите точный тип исключения и фазу. InvalidModificationError сообщает, что изменение не принято по правилам API; без окружающей записи исключение не определяет ответственное поле.

Граница политики BotBrowser

Документация BotBrowser по WebRTC описывает выбор и настройку политик адресов для управляемых сессий. Это источник о продуктовых средствах управления. Значение пула по умолчанию, его жизненный цикл в первом обмене и обработка локального описания описаны WebRTC и JSEP. Публичная документация продукта не обещает отдельную настройку размера пула, предварительный сбор каждого кандидата или удаление прежней активности сервера после поздней смены политики.

В контролируемом сравнении фиксируйте выбранную политику отдельно от свидетельств фаз API и указывайте источник каждого утверждения. Не считайте справку по настройке доказательством состояния сети. Отсутствие события страницы не доказывает, что узел никогда не связывался с настроенной службой. Руководство по предотвращению утечек WebRTC остаётся инструкцией по настройке адресных политик; приведённые здесь таблицы добавляют интерпретацию времени и границ свидетельств. Результаты для неисполнявшейся сборки, сети или развёртывания не заявляются.

FAQ

Гарантирует ли ненулевой пул готовность кандидатов до согласования?

Нет. Он запрашивает предварительный сбор, но RFC 9429 описывает исчерпание пула или нехватку времени на сбор. Доступные кандидаты должны передаваться при начале сбора; настройка не подтверждает завершение.

Исправит ли изменение размера после локального описания прежнюю запись?

Нет. Алгоритм set-configuration W3C ограничивает это изменение после вызова setLocalDescription(). Поздняя настройка не переписывает предыдущий журнал или серверное наблюдение.

Восстанавливает ли restartIce() начальный пул?

Нет. Он запрашивает перезапуск для следующего согласования. У него отдельное окно свидетельств, и он не стирает прежнюю сетевую активность.

Источники

• Рекомендация W3C WebRTC: RTCConfiguration и алгоритм конфигурации
• RFC 9429, раздел 3.5.4: ICE Candidate Pool
• MDN: RTCPeerConnection.setConfiguration()
• MDN: RTCPeerConnection.restartIce()
• BotBrowser: предотвращение утечек WebRTC

Практический вывод

Храните конфигурацию, события страницы и наблюдения сервера как отдельные свидетельства. Записывайте окно сбора и порядок вызовов; если чего-либо не хватает, отмечайте хронологию как неполную, а не делайте вывод об отсутствии прежней сетевой активности.