Главное
- Настоящее различие между облачным и локальным браузером — в том, где выполняется сессия, а не в том, у кого больше функций.
- Исходящий IP, характеристики машины и сетевой путь размещённого браузера принадлежат инфраструктуре провайдера, а не оператору — это факт о границе доверия, а не обходной путь.
- Каждый переход между агентом и размещённым браузером добавляет задержку на обратный путь; локальный браузер устраняет этот переход полностью.
- Оператор размещённого браузера может видеть трафик между браузером и его центром управления; у локального браузера такой третьей стороны нет.
- Единственно «лучшего» варианта не существует — обе архитектуры отвечают на разные вопросы о том, кому что нужно видеть.
Где выполняется браузер и что это меняет
«Облачный браузер» и «локальный браузер» описывают два разных места выполнения одной и той же программы, и именно это место определяет всё остальное. Облачный браузер работает на инфраструктуре, которой управляет провайдер, — в дата-центре, в кластере контейнеров, в пуле безголовых инстансов, — а агент или скрипт обращается к нему по сети, обычно через CDP, предоставляемый как удалённая конечная точка WebSocket. Локальный браузер работает на собственной машине оператора, и любая поверхность автоматизации, которую он предоставляет, остаётся на этой же машине.
Именно это расположение определяет границу доверия. При использовании размещённого браузера инфраструктура провайдера находится между оператором и каждой страницей, которую загружает браузер: она терминирует соединение на себе, может логировать то, что через неё проходит, и является стороной сессии независимо от того, читает ли кто-то эти логи. При использовании локального браузера единственная инфраструктура в цепочке — собственное устройство оператора. Ни один из вариантов не является по своей природе более безопасным — грамотно управляемый размещённый кластер может быть профессионально изолирован, а плохо обслуживаемая локальная машина может оказаться самым слабым звеном, — но это не одна и та же граница, и считать их взаимозаменяемыми — то, с чего начинаются ошибки. Вопрос, который стоит задать до выбора, — не «что мощнее», а «кто, кроме оператора, в итоге получает видимость этой сессии».
Задержка и локальность для автоматизации
У локальности есть и второе, более механическое следствие: расстояние стоит времени. Локальный браузер получает команду и выполняет её на той же машине, без сетевого перехода между инструкцией и страницей. Размещённый браузер добавляет как минимум один обратный путь — а часто и несколько, когда скрипт выдаёт последовательность вызовов CDP, а не одиночный запрос, — между тем, где выполняется логика автоматизации, и тем, где физически находится инстанс браузера. Для нескольких действий эта задержка незаметна. Но для рабочего процесса, который выдаёт сотни мелких команд странице, ждёт селекторов и реагирует на найденное, эти обратные пути накапливаются, и разница между «на этой машине» и «где-то в сети провайдера» становится реальной частью общего времени выполнения процесса.
При масштабировании география только усугубляет это, а не сглаживает. Размещённый инстанс браузера разворачивается там, где у провайдера есть мощности, что не обязательно рядом с оператором или с сайтами, к которым нужно обращаться процессу. Локальность локального браузера фиксирована и известна заранее: она там же, где уже находится машина оператора, с тем сетевым путём к целевому сайту, который у этой машины уже есть. Предсказуемая локальность не всегда означает более высокую скорость — дата-центр с отличным пирингом может обойти домашнее подключение, — но она убирает ещё одну переменную, когда процесс работает медленно и никто не понимает почему.
Что видит размещённый браузер, а локальный — нет
Вопрос видимости из первого раздела приобретает конкретную форму, как только в дело вступает автоматизация. Провайдер размещённого браузера может наблюдать — как архитектурный факт, а не как политику конкретного поставщика — трафик между инстансом браузера и тем, что им управляет, куки и данные хранилища, накапливаемые за время сессии, и сетевую идентичность — исходящий IP, характеристики машины, — которую видит каждый сайт, посещаемый браузером. Для этого никому не нужно действовать недобросовестно; это попросту то, что на практике означает фраза «инфраструктура провайдера находится посередине». У локального браузера эквивалентной третьей стороны нет. Его куки и данные хранилища остаются на устройстве оператора, его сетевой выход — тот, что оператор уже настроил, а между браузером и посещаемыми сайтами нет инфраструктуры провайдера.
Именно здесь имеет значение и профиль — независимо от того, где выполняется браузер. Интерфейс автоматизации, управляющий локальным браузером, всё равно нуждается в собственной дисциплине относительно того, какой профиль принадлежит какой сессии: локальность меняет, кто ещё видит сессию, а не то, нужно ли самому процессу изолированное, чётко помеченное состояние для каждого агента. Локальный браузер без изоляции по профилям всё ещё может допустить утечку куки одного процесса в сессию другого; архитектура отвечает не на тот вопрос, на который отвечает модель изоляции, и одно не заменяет другое.
Это архитектурное различие, а не список функций
Соблазнительно разрешить вопрос «облачный браузер или локальный» сравнительной таблицей — строки для скорости, стоимости, усилий на настройку, — как это делает гид покупателя. Такая рамка недооценивает то, что на самом деле различается. Стоимость и усилия на настройку — это свойства конкретного продукта, его ценообразования и упаковки, и они меняются от поставщика к поставщику и от месяца к месяцу. То, где выполняется сессия и кто, кроме оператора, видит её, не меняется вместе с ценой — это фиксируется архитектурой в момент, когда браузер где-то развёрнут. Именно об этом стоит думать перед выбором: не у кого сейчас список функций лучше, а где на самом деле будут находиться состояние и трафик процесса и приемлем ли этот ответ для того, что этот процесс обрабатывает.
Ни одна из архитектур не является правильным выбором по умолчанию для любой задачи. У процесса, которому нужно работать непрерывно в масштабе, недостижимом для одной машины, и не зависеть от того, включено ли конкретное устройство оператора, есть реальные причины обратиться к размещённой инфраструктуре. У процесса, построенного вокруг аккаунтов и сессий, которые оператор хочет полностью держать вне инфраструктуры третьей стороны, есть не менее реальные причины оставить браузер локальным. Честный ответ на вопрос «облако или локально» состоит в том, что это зависит от того, кому нужно видеть сессию, — и на этот вопрос стоит отвечать осознанно, а не по умолчанию выбирая ту архитектуру, которую было проще всего развернуть первой.