Я все чаще наблюдаю, как мобильные сетевые технологии используются для доступа в Интернет там, где он иначе недоступен.
Хотя мобильная сеть обычно еще не является жизнеспособным в качестве основного подключения к Интернету, мобильные технологии выглядят как хороший вариант на случай чрезвычайной ситуации.
Проблема не в полосе пропускания: с HDSPA возможны скорости в несколько мегабит, что обеспечивает приличный восходящий канал. Тем не менее, я знаю из личного опыта, что интернет-ссылки в мобильных сетях (через GPRS, UMTS и т. Д.) Имеют гораздо более высокие задержки, чем обычный DSL (200-400 мс для UMTS, даже больше для GPRS). Это, конечно, делает их непригодными для многих приложений, таких как VoIP и телеконференции.
Я предполагаю, что должна быть какая-то внутренняя техническая причина, но что это? Связано ли это с тем, как данные передаются по воздуху? И если это из-за беспроводной передачи, почему WLAN имеет намного меньшие задержки?
Книга Ильи Григорика "High Performance Browser Networking" отвечает именно на это. Мобильным сетям посвящена целая глава (7-я). В книге говорится, что проблема с высокой производительностью почти всегда связана с задержкой, у нас обычно много полосы пропускания, но протоколы мешают. Будь то TCP медленный старт, то Контроллер радиоресурсов (RRC) или неоптимальные конфигурации. Если у вас низкая задержка только в мобильных сетях, это так, как они устроены.
В книге есть таблица с типичными задержками:
Таблица 7-2. Скорость передачи данных и задержка для активного мобильного соединения
Generation | Data rate | Latency 2G | 100–400 Kbit/s | 300–1000 ms 3G | 0.5–5 Mbit/s | 100–500 ms 4G | 1–50 Mbit/s | < 100 ms
Хотя трехэтапное рукопожатие или медленный старт протокола TCP очень важно для задержки, они не дают ответа на этот вопрос, поскольку они одинаково влияют на проводные соединения. Что действительно влияет на задержку в мобильных сетях, так это уровень IP. Если уровень под IP имеет задержку в полсекунды, TCP-соединение с сервером займет ~ 1,5 секунды (0,5 с * 3), как вы видите, числа складываются довольно быстро. Как было сказано ранее, это предполагает, что мобильный телефон не простаивает. Если телефон не используется, он сначала должен «подключиться» к сети, что требует согласования резерва ресурсов с вышкой (упрощенно), и это занимает от 50 до 100 мс в LTE, до нескольких секунд в 3G и т. Д. в более ранних сетях.
Рисунок 7-12. Задержки потока запросов LTE
На практике сквозная задержка во многих развернутых сетях 4G обычно находится в диапазоне 30–100 мс, когда устройство находится в подключенном состоянии.
Итак, у вас есть для одного запроса (Рисунок 8-2. Компоненты «простого» HTTP-запроса):
И с реальными данными:
Таблица 8-1. Накладные расходы на задержку одного HTTP-запроса
| 3G | 4G Control plane | 200–2,500 ms | 50–100 ms DNS lookup | 200 ms | 100 ms TCP handshake | 200 ms | 100 ms TLS handshake | 200–400 ms | 100–200 ms HTTP request | 200 ms | 100 ms Total latency overhead | 200–3500 ms | 100–600 ms
Кроме того, если у вас есть интерактивное приложение, которое вы хотите нормально работать в мобильной сети, вы можете поэкспериментировать, отключив алгоритм Нэгла (ядро ожидает объединения данных в более крупные пакеты вместо отправки нескольких меньших пакетов), ищите способы его тестирования в https://stackoverflow.com/a/17843292/869019.
Все желающие могут бесплатно прочитать всю книгу на сайте https://hpbn.co/ спонсируется Velocity Conference. Это очень рекомендуемая книга не только для людей, разрабатывающих веб-сайты, она полезна всем, кто действительно передает байты по какой-либо сети клиенту.
Я подозреваю, что большая часть задержки, с которой вы можете столкнуться при использовании технологий «сотовой широкополосной связи», является сложной проблемой, связанной с рядом вещей.
Есть расстояние, но, как упоминалось в syneticon-dj, на самом деле это лишь очень небольшая часть времени прохождения туда и обратно.
Вот что нужно учитывать ... Задержки, которые вы испытываете как покупатель (особенно как домашний клиент или покупатель из малого бизнеса), вероятно, искусственно вызваны, по крайней мере, в некоторой степени. Существует класс связи 3G и GSM для использования M2M, для SCADA и т.д., которые иногда могут обеспечить большую надежность и меньшую задержку передачи. В результате они обычно непомерно дороги.
Таким образом, вы боретесь с формированием трафика. Либо интернет-провайдер / телефонная компания делают это для определения приоритетов более высокооплачиваемых клиентов, либо ячейка, к которой вы подключены, немного занята, либо вся их сеть немного вялая (попробуйте 00:00 по Гринвичу 01.01.2012, для пример).
Но есть способ обойти все это, хотя это немного хитроумно. По сути, вам понадобится прокси-сервер TCP-соединения, прежде чем ваш трафик перейдет в мобильную WWAN. Этот прокси-сервер, по сути, отправит вашему приложению поддельный ACK, так как настоящий ACK может быть задержан из-за формирования трафика провайдером.
Это явно сомнительно, но ряд спутниковых провайдеров используют этот механизм, чтобы задержка казалась ниже, чем она есть на самом деле.
Немного поздно для игры, но вы можете проверить статью моего календаря производительности по этой теме: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/
tl; dr - большая часть задержки мобильной связи происходит из-за неоптимизированной маршрутизации на обратном пути.
Технологии модемов сотовых телефонов страдают от высокой задержки из-за природы открытой связи: расстояния передачи WLAN обычно намного короче, чем у других технологий, которые вы упомянули, поэтому это одна из причин, по которой задержка ниже.