Главное
Все это время у FourA была одна точка входа: вы отправляете нам URL, мы возвращаем страницу. На этой неделе мы открыли вторую: обычный proxy endpoint, который можно вставить в любой HTTP-клиент, с учетными данными из Dashboard. Proxy Finder также научился использовать платные выходные узлы для ресурсов, которые блокируют все остальное, а режим Auto стал лучше запоминать рабочие выходы.
Что нового
Подключение любого HTTP-клиента
Новый раздел в Dashboard: ACCESS, затем Proxy. Создайте proxy-пользователя, и страница сгенерирует готовую строку подключения с примерами для curl, Python и Node. Выберите тип выхода, страну и необходимость сохранять один узел между запросами, строка обновится автоматически.
Зачем это нужно, если API уже работает? Некоторые задачи не укладываются в схему запрос-ответ. Туннель передает байты по мере поступления: без JSON-обертки и без буферизации. Это необходимо для больших файлов и видеопотоков, чего наш API делать не умел.
Для платных узлов доступен более точный таргетинг: регион, город, сеть по имени провайдера (ISP) и время удержания узла. Наш собственный пул намеренно ограничен выбором страны. Город в стране со слабым покрытием дает всего несколько адресов, а фильтр, который регулярно дает сбой, хуже его отсутствия.
Прямой компромисс. Через обычный туннель соединение с сайтом устанавливает ваш клиент, а не мы. Поэтому логика API в этом сценарии недоступна: флаг unblocker, рендеринг через браузер, правила validate, воспроизведение сессий. Туннель дает наши узлы и пропускную способность. API дает нашу внутреннюю логику обработки. Выбирайте инструмент под конкретную задачу.
Премиум-узлы и информация об источнике в ответе
/api/proxy теперь принимает exitClass со значениями standard или premium. Опция Premium направляет трафик через платный выход для ресурсов, которые блокируют наш собственный пул.
Если параметр не передан, действует автовыбор: сначала опрашивается общий пул, а платный узел подключается только при проблемах с доступом. Если класс указан явно, мы строго следуем настройке. standard никогда не переключается на платный пул сам по себе, ради этого он и задается.
В ответе передается заголовок exitClass, поэтому вы всегда видите, какой узел обработал запрос. Если на premium-запрос ответил наш собственный пул, возвращается standard, это успешное выполнение, а не понижение качества. Если в вашем тарифе нет premium-доступа, запрос сразу отклоняется, а не обслуживается молча через другой пул.
Премиум-трафик отображается как часть общей квоты: отдельная строка в Quota, колонка в Metrics, отметка в строке Activity и блок в Overview. В Playground появился соответствующий переключатель, и пустое значение имеет значение: если оно не выбрано, поле не отправляется вовсе, так как «не запрашивать» и «запретить переключение» являются разными запросами.
Auto запоминает успешные узлы
Лестница Auto всегда фиксировала неудачные выходы. Теперь она записывает и успешные, причем с каждой ступени, а не только с браузерных, и только после того, как контент проходит ту же проверку, которая определяет, отдадим ли мы страницу клиенту. Выход не может быть помечен как рабочий для страницы, которую мы бы вам не вернули.
Блокировки также сбрасываются по собственному таймеру. Раньше срок действия списка исключений хоста продлевался каждый раз при добавлении новой блокировки; теперь каждая блокировка истекает строго по назначенному ей расписанию.
Когда выполнение упирается в лимит браузеров вашего тарифа, лестница больше не останавливается. Вместо этого она переходит на ступень proxy, а затем кэширует победивший выход, чтобы последующие вызовы могли недорого воспроизвести его через Single.
Auto по-прежнему остается инструментом поиска маршрута, а не рабочим маршрутом для продакшена. Позвольте ему определить выигравшую ступень и вернуть session, а затем направляйте основной трафик на /api/single или /api/browser напрямую с этой session. Этот принцип был озвучен еще при запуске Auto, и текущие изменения его не меняют.
Страница, которую вы не запрашивали
Некоторые выходы находятся внутри фильтруемых корпоративных сетей, где вместо целевого сайта отвечает шлюз. Ответ приходит с кодом 200, телом ответа и проходит все наши проверки. Теперь все иначе: такая страница считается доказательством непригодности выхода, а не ответом сайта, поэтому request идет дальше, а данный выход теряет приоритет.
Каждый паттерн страницы, по которому мы сопоставляем ответы, содержит ограничение по размеру, поэтому реальный документ, в котором случайно встретились эти слова, не будет заблокирован. Размер является предохранителем, а не сигналом. Мы подробно разбирали эту тему две недели назад в статье о том, что делать, когда блокировка выглядит как полезные данные.
Под капотом
Rate limits теперь проверяются относительно лимита вашей учетной записи до того, как запрос задействует общие ресурсы. Всплеск нагрузки внутри одного аккаунта отклоняется по его собственному лимиту мгновенно, не занимая слот, который ждет другой пользователь.
Количество активных запросов на вашей панели управления поступает из динамического счетчика, который каждый инстанс обновляет каждую секунду, а не из накопительного счетчика, способного бесконечно расти. Интерфейс и лимитер теперь считывают одно и то же значение.
Цифры
В наших тестах открытие туннеля к хосту, для которого выходы уже были найдены, занимало от 63 до 672 мс на выборке из дюжины замеров, причем большинство укладывалось в 260 мс. Первое обращение к новому хосту происходит медленнее: оно занимает секунды, иногда десятки секунд, пока в пуле идет поиск подходящих выходов. Это происходит один раз на хост, а не на каждый request. Небольшая выборка, наши собственные замеры.
Наличие двух путей ставит вопрос, которого не было на прошлой неделе: задача заключается в передаче объема данных или в прохождении защиты? Для передачи большого файла туннель является самым дешевым решением. Для всех более сложных задач по-прежнему предназначен API.