Сравнение latency: прокси vs прямой трафик на мобильных сетях 4G/5G

Как мы меряли

Взяли три оператора — МТС, Билайн, Tele2. Город — Москва, время — будний день 14:00-16:00. Пять замеров на точку, отбрасывали выбросы. Сервер назначения — AWS Frankfurt, пинг через ICMP и TCP-соединение на 443 порт.

Прокси — IPv4 и IPv6, обычный HTTP CONNECT. Без TLS-туннелей, чтобы чистую задержку протокола поймать. Софт — mtr и скрипт на Python с time.perf_counter().

Результаты: прямой 4G — 45-55 мс, через прокси — 65-85 мс. Разница в 20-30 мс. На 5G картина другая — прямой 15-25 мс, прокси 35-50 мс. Прокси съедает больше половины преимущества 5G.

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

Три причины. Первая — дополнительный хоп. Пакет идёт не сразу к цели, а через прокси-сервер. Даже если прокси стоит рядом с вами, маршрутизация может быть кривой.

Вторая — обработка на прокси. HTTP CONNECT — это не просто forward. Нужно разобрать заголовки, установить туннель, держать состояние соединения. На дешёвых VPS это даёт 5-10 мс на каждый запрос.

Третья — MTU и фрагментация. Мобильные сети любят MTU 1400-1420. Прокси добавляет свои заголовки — пакет летит фрагментированным. Каждый фрагмент — дополнительная задержка и риск потери.

```bash

Проверка MTU на мобильном интерфейсе

ping -M do -s 1472 -c 5 8.8.8.8

Если не проходит — снижаем до 1400

ping -M do -s 1372 -c 5 8.8.8.8

```

4G vs 5G — разница в цифрах

| Параметр | 4G прямой | 4G прокси | 5G прямой | 5G прокси |

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

| Средняя latency | 48 мс | 72 мс | 19 мс | 42 мс |

| Jitter | 12 мс | 18 мс | 5 мс | 11 мс |

| Потери пакетов | 0.3% | 0.8% | 0.1% | 0.4% |

| TCP handshake | 96 мс | 144 мс | 38 мс | 84 мс |

На 5G прокси убивает почти всё преимущество новой сети. TCP handshake через прокси занимает 84 мс против 38 мс напрямую. Для веб-серфинга это не критично, для real-time приложений — смертельно.

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

TCP-соединение через прокси — это двойной handshake. Сначала клиент-прокси, потом прокси-сервер. Каждый handshake — RTT туда-обратно. На 4G с latency 48 мс это 96 мс только на установку соединения.

Плюс проблема с окном перегрузки. Прокси не знает реального состояния канала между клиентом и сервером. Он начинает передачу с минимального окна, потом адаптируется. Но адаптация идёт через два независимых TCP-стека — клиент-прокси и прокси-сервер. Это даёт дополнительную задержку на первые 5-10 пакетов.

```python

import socket

import time

def measure_tcp_handshake(host, port, proxy=None):

start = time.perf_counter()

if proxy:

Через прокси

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

sock.connect(proxy)

sock.send(b'CONNECT %s:%d HTTP/1.1\r\n\r\n' % (host.encode(), port))

sock.recv(1024) # Ждём 200 Connection established

else:

Прямое соединение

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

sock.connect((host, port))

end = time.perf_counter()

sock.close()

return (end - start) * 1000 # в миллисекундах

```

IPv6 и прокси — отдельная история

IPv6 на мобильных сетях работает быстрее IPv4. У Билайна разница в 5-7 мс в пользу IPv6. Tele2 даёт 10-12 мс. Причина — нет NAT, маршрутизация проще, меньше промежуточных устройств.

Прокси на IPv6 — ситуация сложнее. Если прокси поддерживает dual-stack, а клиент сидит на IPv6 — задержка минимальна. Если клиент на IPv4, а прокси на IPv6 — добавляется конвертация протоколов. Это ещё 5-10 мс.

Провайдеры вроде lexic.ml держат прокси на обоих стеках, но реальная маршрутизация зависит от оператора. У МТС IPv6-трафик идёт через их собственный NAT64 — это добавляет 15-20 мс даже до прокси.

Кейс: стриминг через прокси на 4G

Проблема: видео дёргается, буферизация каждые 10 секунд. Пользователь сидит на 4G Tele2, смотрит YouTube через корпоративный прокси.

Замерили: прямой доступ к YouTube — 52 мс, через прокси — 89 мс. Но дело не только в latency. Прокси резал TCP-окно до 64 КБ, хотя мобильный канал позволял 256 КБ. Видеоплеер запрашивал сегменты по 2 МБ, каждый сегмент — 8-10 RTT.

Решение: настроили TCP-буферизацию на прокси, увеличили окно до 256 КБ. Latency не изменилась, но количество RTT на сегмент упало до 3-4. Буферизация исчезла.

```bash

Настройка TCP буферизации на Linux-прокси

sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'

sysctl -w net.ipv4.tcp_wmem='4096 65536 6291456'

sysctl -w net.core.rmem_max=6291456

sysctl -w net.core.wmem_max=6291456

```

Кейс: онлайн-игра через прокси на 5G

Проблема: пинги скачут от 30 до 150 мс. Игрок на 5G МТС, игра через прокси для обхода блокировок.

Замерили: прямой пинг до игрового сервера — 18 мс стабильно. Через прокси — 45 мс, но с выбросами до 200 мс каждые 30-40 секунд. Поймали tcpdump — выбросы совпадали с перезагрузкой TCP-соединения на прокси из-за таймаута keepalive.

Оказалось, прокси держал keepalive 60 секунд, а игра отправляла пакеты раз в 5 секунд. Прокси сбрасывал соединение, думая, что оно мёртвое. Игра переподключалась — отсюда скачки.

Решение: увеличили keepalive до 300 секунд, отключили агрессивное закрытие idle-соединений. Пинги стабилизировались на 45-50 мс.

Кейс: API-запросы через прокси на 4G

Проблема: мобильное приложение отправляет 50 параллельных запросов к API. Через прокси — таймауты на 30% запросов. Прямой доступ — 0% таймаутов.

Замерили: прокси на VPS с 1 ядром и 1 ГБ RAM. 50 параллельных соединений — это 100 TCP-сокетов (50 туда, 50 оттуда). VPS тупо не успевал обрабатывать. Добавили ещё одно ядро — таймауты упали до 5%.

Но осталась проблема с очередями. Прокси ставил все запросы в одну очередь — последние ждали по 2-3 секунды. Переключили на epoll с многопоточностью — latency выровнялась.

```python

Пример epoll-сервера для прокси

import select

import socket

epoll = select.epoll()

connections = {}

while True:

events = epoll.poll(timeout=1)

for fd, event in events:

if event & select.EPOLLIN:

data = connections[fd].recv(4096)

if data:

forward data

pass

```

Что делать с latency

Первое — выбирать прокси ближе к себе. Не к серверу, а к вам. Если вы в Москве, а сервер в США — ставьте прокси в Москве или Европе. Разница в 50-100 мс.

Второе — отключать шифрование на прокси, если не нужно. TLS-туннель через прокси — это двойное шифрование. Клиент-прокси и прокси-сервер. Каждая операция шифрования — 1-3 мс.

Третье — мониторить MTU. Мобильные сети любят MTU 1400. Если прокси шлёт пакеты по 1500 — будет фрагментация и потери. Настройте прокси на MTU 1400 или 1420.

Четвёртое — использовать multiplexing. Одно TCP-соединение между клиентом и прокси, много запросов через него. HTTP/2 multiplexing на прокси даёт выигрыш 20-30% по сравнению с HTTP/1.1.

Когда прокси не выход

Real-time приложения — голос, видео, игры — не терпят дополнительной задержки. 20-30 мс для голоса — это разница между "нормально" и "ты меня слышишь?". Для игр 50 мс — уже плохо, 80 мс — неиграбельно.

Если вам нужно 10-15 мс до сервера — ставьте прокси на том же операторе, что и клиент. Или вообще не используйте прокси. Иногда прямой доступ через IPv6 даёт меньше latency, чем IPv4 через прокси.

Прокси — это компромисс. Вы получаете обход блокировок, скрытие IP, балансировку. Платите latency и джиттером. Для веба и API это терпимо. Для real-time — хреново.

Цифры для тех, кто любит точность

Провели 500 замеров на каждом операторе. Статистика по 4G:

- МТС: прямой 47±8 мс, прокси 71±14 мс

- Билайн: прямой 52±10 мс, прокси 78±16 мс

- Tele2: прямой 44±7 мс, прокси 68±12 мс

По 5G:

- МТС: прямой 18±4 мс, прокси 41±9 мс

- Билайн: прямой 22±5 мс, прокси 45±11 мс

- Tele2: прямой 16±3 мс, прокси 38±8 мс

Разница между прокси и прямым доступом на 5G — 20-25 мс. На 4G — 24-30 мс. Прокси съедает больше половины преимущества 5G.

Вывод простой: если вам критична latency — не используйте прокси. Если обход блокировок важнее скорости — готовьтесь к 20-30 мс дополнительной задержки. И проверяйте TCP-настройки — они часто дают больше, чем сам прокси.