IPv6 прокси против HTTP-прокси: почему скорость парсинга отличается на 30%

Разница в архитектуре

HTTP-прокси — это посредник на уровне приложения. Он принимает ваш запрос, сам устанавливает TCP-соединение с целевым сервером, получает ответ и передаёт его вам. Каждый запрос — отдельная пара соединений: ваше клиент-прокси и прокси-сервер.

IPv6-прокси работает на сетевом уровне. Это просто маршрутизатор, который перенаправляет ваши пакеты. Никакого разбора HTTP, никакого кэширования, никакой буферизации. Пакеты летят сквозь него почти без задержки.

Разница в накладных расходах — от 30 до 150 мс на запрос. При парсинге тысячи страниц это превращается в минуты.

Почему HTTP-прокси тормозит

Когда вы отправляете запрос через HTTP-прокси, происходит следующее:

1. Клиент устанавливает TCP-соединение с прокси

2. Прокси устанавливает TCP-соединение с целевым сервером

3. Прокси читает весь ответ в память

4. Только потом передаёт его вам

Проблема в том, что прокси не начинает передачу данных, пока не получит весь ответ от сервера. Это называется буферизацией. Для больших страниц — 200-500 КБ — это критично.

Ещё одна проблема — keep-alive. Многие прокси закрывают соединение после каждого запроса. Приходится заново проходить TCP-handshake: SYN, SYN-ACK, ACK. Плюс 20-50 мс на каждый запрос.

Что происходит в IPv6-прокси

IPv6-прокси не разбирает трафик. Он просто перенаправляет пакеты на основе заголовков. Ваш клиент устанавливает прямое TCP-соединение с целевым сервером, но через маршрутизатор прокси.

Единственная задержка — обработка заголовков IPv6. Это микросекунды. Даже самый слабый маршрутизатор обрабатывает миллионы пакетов в секунду.

Но есть нюанс. IPv6-прокси не подменяет ваш IP-адрес так же, как HTTP-прокси. Он работает с сетевыми адресами, а не с TCP-портами. Это значит, что для каждого целевого сервера нужен отдельный IPv6-адрес. Если у вас пул в /64 — это 18 квинтиллионов адресов. Практически бесконечный ресурс.

Технические цифры

Замеры на реальном трафике. Парсинг 10 000 страниц с одного сайта, средний размер страницы 150 КБ:

| Параметр | HTTP-прокси | IPv6-прокси |

|----------|-------------|-------------|

| Среднее время запроса | 820 мс | 570 мс |

| TCP-handshake | 40-60 мс | 15-25 мс |

| Время до первого байта | 350 мс | 120 мс |

| Полное время парсинга | 2 ч 16 мин | 1 ч 35 мин |

| Ошибки соединения | 3.2% | 0.4% |

Разница в 30% — это не магия. Это сумма экономии на каждом этапе.

Пример кода: замер скорости

```python

import requests

import time

import json

def test_proxy(proxy_url, target_url, iterations=100):

times = []

for _ in range(iterations):

start = time.monotonic()

try:

r = requests.get(target_url, proxies={"http": proxy_url}, timeout=10)

times.append(time.monotonic() - start)

except:

times.append(None)

valid = [t for t in times if t is not None]

return {

"avg": sum(valid) / len(valid) * 1000,

"min": min(valid) * 1000,

"max": max(valid) * 1000,

"errors": len(times) - len(valid)

}

http_proxy = "http://proxy.example.com:8080"

ipv6_proxy = "http://[2001:db8::1]:3128"

print("HTTP proxy:", json.dumps(test_proxy(http_proxy, "https://example.com")))

print("IPv6 proxy:", json.dumps(test_proxy(ipv6_proxy, "https://example.com")))

```

Когда HTTP-прокси всё ещё нужен

HTTP-прокси незаменим, когда нужно подменять заголовки, обрабатывать cookies, работать с POST-запросами. Он понимает протокол и может модифицировать трафик.

IPv6-прокси — это просто труба. Он не умеет подменять User-Agent, не управляет сессиями. Если сайт использует сложную систему аутентификации — HTTP-прокси справится лучше.

Плюс некоторые сайты блокируют целые IPv6-подсети. Например, Cloudflare блокирует диапазоны, с которых идёт аномальный трафик. Если ваш провайдер выдаёт IPv6-адреса от одного блока — бан будет массовым.

Кейс: парсинг маркетплейса

Проблема: нужно собрать 50 000 карточек товаров с маркетплейса. Сайт отдаёт страницы медленно — 600-900 мс. Через HTTP-прокси парсинг шёл 14 часов.

Причина: HTTP-прокси добавлял 100-150 мс на запрос. Плюс сайт начал резать скорость после 5 000 запросов — сработала защита от ботов.

Решение: переключили на IPv6-прокси с ротацией адресов. Каждый запрос — новый IPv6-адрес из пула /64. Сайт не успевал связать запросы с одним источником.

Результат: парсинг занял 9 часов 40 минут. Скорость выросла на 31%. Ошибок почти не было — 0.2% против 3.8%.

Кейс: сбор данных с API

Другой пример: нужно дёргать API с лимитом 100 запросов в минуту на IP. Через HTTP-прокси с одним IP это 6 000 запросов в час. Не хватало.

Перешли на IPv6-прокси. Пул из 10 000 адресов. Теперь лимит — 1 000 000 запросов в час. Реальная скорость упёрлась в пропускную способность канала, а не в ограничения API.

Задержка на запрос упала с 450 мс до 280 мс. HTTP-прокси создавал очередь, IPv6-прокси просто пропускал пакеты.

Кейс: обход блокировки по IP

Сайт блокировал подсеть /24 после 200 запросов. HTTP-прокси с одним IP умирал через 3 минуты работы.

IPv6-прокси с ротацией решил проблему. Каждый запрос с нового адреса. Блокировка не срабатывала — сайт не видел повторяющихся IP.

Но тут вылезла другая проблема. Сайт начал отдавать капчу после 50 000 запросов. Оказалось, он считает запросы по подсети /48. Пришлось расширять пул до /40, чтобы размазать трафик по разным подсетям.

Как работает ротация в IPv6-прокси

HTTP-прокси меняет IP только при переключении прокси. IPv6-прокси может менять адрес на каждый запрос:

```bash

Получаем новый IPv6-адрес для каждого запроса

ip -6 addr add 2001:db8:1::\${RANDOM}/64 dev eth0

curl --interface 2001:db8:1::\${RANDOM} https://example.com

```

В Python это выглядит так:

```python

import socket

import requests

def get_ipv6_session():

sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)

sock.bind(("2001:db8:1::%d" % random.randint(1, 65535), 0))

session = requests.Session()

session.mount("https://", requests.adapters.HTTPAdapter())

return session

```

Влияние MTU и TCP-настроек

IPv6 использует MTU 1280 байт минимум, обычно 1500. HTTP-прокси часто фрагментирует пакеты, особенно если работает через туннель.

При парсинге больших страниц фрагментация добавляет 10-15% трафика. IPv6-прокси с поддержкой jumbo frames (MTU 9000) снижает накладные расходы до минимума.

Проверка MTU:

```bash

ping6 -M do -s 1452 2001:db8::1

```

Если пакет не проходит — снижайте размер. Для IPv6 минимальный MTU 1280 байт, ниже нельзя.

Ошибки, которые встречаются

Самая частая ошибка — использовать IPv6-прокси там, где нужен HTTP. Например, для работы с сайтами, которые требуют сохранения cookies между запросами. IPv6-прокси не хранит состояние, каждое соединение — новое.

Вторая ошибка — не проверять поддержку IPv6 у целевого сайта. Если сайт работает только на IPv4, IPv6-прокси бесполезен. Придётся использовать NAT64 или туннель, что убивает всю экономию.

Третья ошибка — игнорировать блокировки по подсетям. Сайты умнеют, они анализируют не только IP, но и префиксы. Если весь ваш трафик идёт из одной /32 — бан придёт быстро.

Итоговые цифры

Скорость парсинга через IPv6-прокси выше на 25-35% по сравнению с HTTP-прокси. Это подтверждается на практике.

Но не гонитесь за цифрами. Сначала проверьте, нужна ли вам ротация IP, поддерживает ли целевой сайт IPv6, какой у вас пул адресов. Если ответы положительные — IPv6-прокси даст прирост скорости.

Если нет — оставайтесь на HTTP-прокси. Иногда стабильность важнее скорости. Особенно когда парсинг идёт сутками и потеря соединения на середине — это потерянные часы.