Почему сетевая задержка убивает ваше приложение

Задержка (latency) — это скрытый убийца распределенных систем и API. Незначительная задержка на транспортном уровне вызывает огромные проблемы на прикладном уровне. Это портит пользовательский опыт в веб-инструментах реального времени и при потоковой передаче ИИ.

Вы не можете игнорировать физику интернета.

Ограничение скоростью света

Данные передаются по оптоволоконным кабелям на дне океана. Свет в стекле движется медленнее, чем в вакууме. Скорость света в оптоволокне составляет около 204 500 км/с.

Если вы отправляете данные из Токио в Сан-Франциско, расстояние составляет примерно 9 000 км. Физика диктует минимальное время кругового обхода (RTT) около 88 мс. Этот предел преодолеть невозможно. Любая ошибка маршрутизации или перегрузка только увеличивают задержку.

Маршрутизация Anycast против Unicast

В сети Unicast у каждого сервера есть один уникальный IP-адрес. Если пользователь из Лондона обращается к серверу в Нью-Йорке, данные проходят через множество непредсказуемых узлов (hops). Это вызывает скачки задержки.

Anycast меняет ситуацию. Вы назначаете один и тот же IP-адрес нескольким периферийным (edge) дата-центрам по всему миру.

• Маршрутизаторы находят кратчайший путь через BGP. • Пакеты направляются к ближайшему физическому периферийному узлу (edge node). • Установка соединения происходит на периферии, а не через океаны.

Это приближает периметр вашей сети к пользователям.

Опасность потери пакетов

Многие инженеры считают, что потеря 1% пакетов — это нормально. Это не так.

Стандартные алгоритмы TCP, такие как Cubic, при потере одного пакета впадают в панику. Они сокращают окно перегрузки (congestion window) на 30%. Если потери продолжаются, ваш оптоволоконный канал 1 Гбит/с будет работать как старое dial-up соединение.

Если пакеты теряются слишком часто, система достигает тайм-аута повторной передачи (Retransmission Timeout). Каждый тайм-аут удваивает время ожидания. Небольшой сетевой сбой может заморозить приложение на несколько секунд.

Два способа это исправить

Современные команды используют эти два метода для поддержания скорости:

  • Google BBR: Этот алгоритм измеряет фактическую пропускную способность вместо того, чтобы реагировать на каждый потерянный пакет. Он поддерживает стабильную пропускную способность даже при незначительных перегрузках.
  • Протокол QUIC: Он работает поверх UDP, чтобы предотвратить блокировку начала очереди (head-of-line blocking). Если один пакет теряется, другие потоки данных продолжают движение. Это предотвращает остановку всей сессии из-за одной потери.

Перестаньте относиться к интернету как к «магическому облаку». Понимайте физическую реальность ваших данных.

Источник: https://dev.to/taohuawu/demystifying-global-network-latency-the-mechanics-of-anycast-routing-cross-border-fiber-optics-1bpa

Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi