Почему мобильные сети имеют большие задержки? Как их можно уменьшить?

Я все чаще вижу, как мобильные сетевые технологии используются для получения доступа к Интернету в тех областях, где в противном случае он недоступен.

В то время как мобильные сети обычно еще не являются жизнеспособными в качестве основного интернет-соединения, мобильные технологии выглядят хорошим вариантом для аварийного восстановления.

Полоса пропускания не является проблемой: с HDSPA возможны скорости в несколько Мбит, что обеспечивает приличный восходящий канал. Однако из личного опыта я знаю, что интернет-каналы мобильных сетей (через GPRS, UMTS и т. Д.) Имеют гораздо более высокие задержки, чем обычные DSL (200–400 мс для UMTS, даже больше для GPRS). Это, конечно, делает их непригодными для многих приложений, таких как VoIP и телеконференции.

• Откуда эта задержка?
• Существуют ли какие-либо технологии, которые могут смягчить эту проблему, чтобы сделать UMTS жизнеспособным для приложений с малой задержкой?

Я предполагаю, что должна быть какая-то внутренняя техническая причина, но что это? Это связано с тем, как данные передаются по воздуху? И если это из-за беспроводной передачи, почему у WLAN гораздо меньшие задержки?

Книга «Высокопроизводительные браузерные сети» от Ильи Григорика отвечает именно на это. Целая глава (7) посвящена мобильным сетям. В книге говорится, что проблема с высокой производительностью почти всегда связана с задержкой, у нас обычно много пропускной способности, но протоколы мешают. Будь то медленный запуск TCP , контроллер радиоресурсов (RRC) или неоптимальные конфигурации. Если вы испытываете низкую задержку только в мобильных сетях, то так, как они спроектированы.

В книге есть таблица типичных задержек:

Таблица 7-2. Скорость передачи данных и задержка для активного мобильного соединения

Поколение | Скорость передачи данных | Задержка
2G | 100–400 кбит / с | 300–1000 мс
3G | 0,5–5 Мбит / с | 100–500 мс
4G | 1–50 Мбит / с | <100 мс

Хотя характерные для латентности задержки характерно трехстороннее рукопожатие TCP или медленный запуск, на самом деле это не отвечает, так как они одинаково влияют на проводные соединения. Что действительно влияет на задержку в мобильных сетях, так это уровень IP. Если у слоя под IP задержка составляет полсекунды, TCP-соединение с сервером займет ~ 1,5 сек (0,5 с * 3), как вы видите, цифры быстро складываются. Как уже было сказано, предполагается, что мобильный не простаивает. Если трубка находится в режиме ожидания, она сначала должна «подключиться» к сети, что требует согласования запаса ресурсов с вышкой (упрощенно), что занимает от 50 до 100 мс в LTE, до нескольких секунд в 3G и т. Д. в более ранних сетях.

Рисунок 7-12. Задержки потока запросов LTE

1. Задержка плоскости управления : фиксированная стоимость единовременной задержки, понесенная для согласования RRC и переходов между состояниями: <100 мс для режима ожидания и активного состояния и <50 мс для режима ожидания в нерабочем состоянии.
2. Задержка плоскости пользователя : фиксированная стоимость для каждого пакета приложения, передаваемого между устройством и радиомачтой: <5 мс.
3. Задержка базовой сети: зависящая от оператора стоимость транспортировки пакета от радиомачты к шлюзу пакетов: на практике, 30–100 мс.
4. Задержка маршрутизации Интернет: переменная стоимость задержки между пакетным шлюзом оператора связи и адресом назначения в общедоступном Интернете.

На практике сквозная задержка многих развернутых сетей 4G имеет тенденцию находиться в диапазоне 30–100 мс, когда устройство находится в подключенном состоянии.

Итак, у вас есть для одного запроса (рисунок 8-2. Компоненты «простого» HTTP-запроса):

1. Переговоры RRC 50-2500 мс
2. DNS lookup 1 RTT
3. TCP рукопожатие 1 RTT (существующее соединение) или 3 RTT (новое соединение)
4. TLS рукопожатие 1-2 РТЦ
5. HTTP-запрос 1-н RTT

И с реальными данными:

Таблица 8-1. Издержки задержки одного HTTP-запроса

                       | 3G | 4G
Плоскость управления | 200–2500 мс | 50–100 мс
Поиск DNS | 200 мс | 100 мс
TCP рукопожатие | 200 мс | 100 мс
TLS рукопожатие | 200–400 мс | 100–200 мс
HTTP-запрос | 200 мс | 100 мс
Общая задержка накладных расходов | 200–3500 мс | 100–600 мс

Кроме того, если у вас есть интерактивное приложение, которое вы хотите выполнять умеренно хорошо в мобильной сети, вы можете поэкспериментировать с отключением алгоритма Nagle (ядро ожидает объединения данных в большие пакеты вместо отправки нескольких меньших пакетов), ищите способы его тестирования. в https://stackoverflow.com/a/17843292/869019 .

Существует возможность бесплатно прочитать всю книгу по адресу https://hpbn.co/, спонсируемой Velocity Conference. Это очень рекомендуемая книга, не только для людей, разрабатывающих веб-сайты, она полезна для всех, кто передает клиенту байты по некоторой сети.

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

Есть расстояние, но, как уже упоминалось в syneticon-dj, это реально очень малая доля времени в оба конца.

Вот кое-что, чтобы рассмотреть ... Задержки, с которыми вы сталкиваетесь как клиент (особенно как дома, или клиент малого бизнеса), вероятно, вызваны искусственно, по крайней мере, до некоторой степени. Существует класс связи 3G и GSM для использования M2M, для SCADA и т. Д., Который иногда может обеспечить большую надежность и меньшую задержку передачи. В результате они обычно непомерно дороги.

Так что, в принципе, вы против трафика. Либо Интернет-провайдер / Telco делает это, чтобы расставить приоритеты у более высокооплачиваемых клиентов, либо сотовая сеть, к которой вы подключены, немного занята, или вся их сеть немного вялая (попробуйте 00:00 по Гринвичу 01.01.2012, для пример).

Но есть способ обойти все это, хотя это немного подлый. В основном вам нужен прокси-сервер TCP-подключения, прежде чем ваш трафик направится через мобильный WWAN. Этот прокси-сервер по сути отправляет поддельное подтверждение ACK вашему приложению, поскольку настоящее подтверждение ACK может быть задержано из-за формирования трафика интернет-провайдером.
Это явно сомнительно, но ряд спутниковых провайдеров используют этот механизм, чтобы задержка выглядела ниже, чем на самом деле.

Как-то поздно в игре, но вы можете проверить статью моего календаря производительности по этой теме: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/

tl; dr - большая часть задержек мобильной связи обусловлена ​​неоптимизированной маршрутизацией на обратном рейсе.

Модемы сотовых телефонов страдают высокой задержкой из-за характера связи на открытом воздухе: расстояния передачи WLAN обычно намного короче, чем у других технологий, которые вы упомянули, поэтому это одна из причин, почему задержка ниже.