Почему сети мобильной связи имеют высокие задержки? Как они могут быть уменьшены?
Я попытался бы переписать URL на лету с помощью URL, Переписывают Модуль для IIS.
Книга Ильи Григорика «Высокопроизводительные браузерные сети» отвечает именно на это. Мобильным сетям посвящена целая глава (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 или медленный старт, характерное для TCP, очень важно для задержки, на самом деле не отвечает на вопрос, поскольку они одинаково влияют на проводные соединения. Что действительно влияет на задержку в мобильных сетях, так это уровень IP. Если уровень под IP имеет задержку в полсекунды, TCP-соединение с сервером займет ~ 1,5 секунды (0,5 с * 3), как вы видите, числа складываются довольно быстро. Как было сказано ранее, это предполагает, что мобильный телефон не простаивает. Если телефон не используется, он сначала должен «подключиться» к сети, что требует согласования резерва ресурсов с вышкой (упрощенно), и это занимает от 50 до 100 мс в LTE, до нескольких секунд в 3G и т. Д. в более ранних сетях.
Рисунок 7-12. Задержки потока запросов LTE
- Задержка плоскости управления : Фиксированная, единовременная стоимость задержки, понесенная для согласования RRC и переходов между состояниями: <100 мс для бездействия в активное и <50 мс для бездействующего в активное.
- Согласование RRC 50–2500 мс
- Поиск DNS 1 RTT
- Подтверждение TCP 1 RTT (существующее соединение) или 3 RTT (новое соединение)
- Подтверждение связи TLS 1-2 RTT
- HTTP-запрос 1- n RTT
И с реальными данными:
Таблица 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. Это очень рекомендуемая книга не только людям, разрабатывающим веб-сайты,
Технологии модемов сотовых телефонов страдают от высокой задержки из-за характера открытой связи: расстояния передачи WLAN обычно намного короче, чем у других технологий, которые вы упомянули, поэтому это одна из причин, по которой задержка ниже.
Я подозреваю, что большая часть задержки, с которой вы можете столкнуться при использовании технологий «сотовой широкополосной связи», является сложной проблемой, связанной с рядом вещей.
Есть расстояние, но, как упоминал syneticon-dj, на самом деле это лишь очень небольшая часть времени туда и обратно.
Вот что нужно учитывать ... Задержки, которые вы испытываете как покупатель (особенно дома, или клиент из малого бизнеса), вероятно, искусственно вызваны, по крайней мере, в некоторой степени. Существует класс связи 3G и GSM для использования M2M, для SCADA и т.д., которые иногда могут обеспечить большую надежность и меньшую задержку передачи. В результате они обычно непомерно дороги.
В общем, вы выступаете против формирования трафика. Либо интернет-провайдер / телефонная компания делают это, чтобы определить приоритетность более высокооплачиваемых клиентов, либо ячейка, к которой вы подключены, немного занята, либо вся их сеть немного вялая (попробуйте 00:00 по Гринвичу 01.01.2012, для пример).
Но все это можно обойти, хотя и немного хитроумно. По сути, вам понадобится прокси-сервер TCP-соединения, прежде чем ваш трафик перейдет в мобильную WWAN. По сути, этот прокси-сервер отправит вашему приложению поддельный ACK, так как настоящий ACK может быть задержан из-за формирования трафика провайдером.
d в основном нужен прокси-сервер TCP-соединения, прежде чем ваш трафик перейдет в мобильную WWAN. По сути, этот прокси-сервер отправит вашему приложению поддельный ACK, так как настоящий ACK может быть задержан из-за формирования трафика провайдером.
d в основном нужен прокси-сервер TCP-соединения, прежде чем ваш трафик перейдет в мобильную WWAN. По сути, этот прокси-сервер отправит вашему приложению поддельный ACK, так как настоящий ACK может быть задержан из-за формирования трафика провайдером.
Это явно сомнительно, но ряд спутниковых провайдеров используют этот механизм, чтобы задержка казалась ниже, чем она есть на самом деле.
Немного поздно в игре, но вы можете проверить статью моего календаря производительности по этой теме: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/
tl; dr - большая часть задержки мобильной связи связана с неоптимизированной маршрутизацией на задней панели - ремонт.