Pourquoi les réseaux mobiles ont-ils des latences élevées? Comment peuvent-ils être réduits?

Je constate de plus en plus que les technologies de réseau mobile sont utilisées pour obtenir un accès à Internet dans des zones où il n’est pas disponible autrement.

Bien que le réseau mobile ne soit généralement pas encore viable en tant que connexion Internet principale, la technologie mobile semble être une bonne option en cas de repli d'urgence.

La bande passante n'est pas le problème: avec HDSPA, des vitesses de plusieurs Mbits sont possibles, ce qui fournit une liaison montante décente. Cependant, je sais par expérience que les liens Internet des réseaux mobiles (via GPRS, UMTS, etc.) ont des latences bien supérieures à celles du DSL classique (200 à 400 ms pour UMTS, voire plus pour GPRS). Bien entendu, cela les rend impropres à de nombreuses applications, telles que la VoIP et la téléconférence.

• D'où vient cette latence?
• Existe-t-il des technologies disponibles permettant d'atténuer ce problème afin de rendre l'UMTS viable pour les applications à faible temps de latence?

Je suppose qu'il doit y avoir une raison technique inhérente, mais de quoi s'agit-il? Cela a-t-il à voir avec la façon dont les données sont transmises par voie hertzienne? Et si c'est à cause de la transmission sans fil, pourquoi le WLAN a-t-il des latences beaucoup plus basses?

Le livre "High Performance Browser Networking" de Ilya Grigorik répond exactement à cela. Il existe un chapitre entier (7ème) consacré aux réseaux mobiles. Le livre indique que le problème des hautes performances est presque toujours lié à la latence. Nous avons généralement beaucoup de bande passante, mais les protocoles nous en empêchent. Qu'il s'agisse d' un démarrage lent TCP , du contrôleur de ressources radio (RRC) ou de configurations sous-optimales. Si votre latence est faible uniquement sur les réseaux mobiles, c'est leur conception.

Le livre contient un tableau sur les latences typiques:

Tableau 7-2. Débits de données et latence pour une connexion mobile active

Génération | Débit de données | Latence
2G | 100–400 Kbit / s | 300–1000 ms
3G | 0,5 à 5 Mbit / s | 100–500 ms
4G | 1–50 Mbit / s | <100 ms

Bien qu’elles soient très pertinentes pour la latence, la négociation tridimensionnelle caractéristique du protocole TCP ou le démarrage lent ne répondent pas vraiment à la question, car elles affectent également les connexions câblées. Ce qui affecte vraiment la latence dans les réseaux mobiles, c'est la couche sous IP. Si la couche sous IP a une latence d'une demi-seconde, une connexion TCP à un serveur prendra environ 1,5 seconde (0,5 s * 3), car les chiffres s'additionnent assez rapidement. Comme dit précédemment, cela suppose que le mobile n'est pas inactif. Si le combiné est inactif, il doit d'abord se "connecter" au réseau, ce qui nécessite de négocier une réserve de ressources avec la tour (simplifiée), et cela prend entre 50 et 100 ms en LTE, jusqu'à plusieurs secondes en 3G, et plus encore. dans les réseaux précédents.

Figure 7-12. Latences de flux de demandes LTE

1. Latence du plan de contrôle : Coût de latence unique, fixe, engagé pour la négociation RRC et les transitions d'état: <100 ms pour les périodes d'inactivité à actives et <50 ms pour les phases inactives à actives.
2. Latence du plan utilisateur : coût fixe pour chaque paquet d'application transféré entre le périphérique et la tour radio: <5 ms.
3. Temps de latence du réseau central: coût dépendant de l’opérateur pour le transport du paquet de la tour radio à la passerelle de paquets: en pratique, 30–100 ms.
4. Latence de routage Internet: coût de latence variable entre la passerelle de paquets de l’opérateur et l’adresse de destination sur l’Internet public.

En pratique, la latence de bout en bout de nombreux réseaux 4G déployés tend à se situer dans une plage allant de 30 à 100 ms lorsque le périphérique est dans un état connecté.

Donc, vous avez pour une requête (Figure 8-2. Composants d’une requête HTTP "simple"):

1. Négociation RRC 50-2500 ms
2. Recherche DNS 1 RTT
3. Poignée de main TCP 1 RTT (connexion préexistante) ou 3 RTT (nouvelle connexion)
4. Poignée de main TLS 1-2 RTT
5. Requête HTTP 1-n RTT

Et avec des données réelles:

Tableau 8-1. Surcoût de latence d'une requête HTTP unique

                       | 3G | 4G
Plan de contrôle | 200–2 500 ms | 50–100 ms
Recherche DNS | 200 ms | 100 ms
Poignée de main TCP | 200 ms | 100 ms
Poignée de main TLS | 200–400 ms | 100–200 ms
Requête HTTP | 200 ms | 100 ms
Surcharge totale de latence | 200–3500 ms | 100–600 ms

En outre, si vous avez une application interactive que vous souhaitez exécuter correctement dans un réseau mobile, vous pouvez essayer de désactiver l'algorithme de Nagle (le noyau attend que les données fusionnent en paquets plus gros au lieu d'envoyer plusieurs paquets plus petits), recherchez des moyens de le tester. dans https://stackoverflow.com/a/17843292/869019 .

Il est possible de lire gratuitement le livre entier gratuitement par tout le monde à l' adresse https://hpbn.co/ sponsorisée par Velocity Conference. Ce livre est vivement recommandé, non seulement aux personnes développant des sites Web, il est utile à tous ceux qui servent des octets sur un réseau à un client.

Je soupçonne qu’une grande partie de la latence que vous pouvez rencontrer lors de l’utilisation des technologies «à large bande cellulaire» est un problème complexe qui se pose à plusieurs égards.

Il y a de la distance, mais comme l'a mentionné Syneticon-dj, il ne s'agit en réalité que d'une très petite proportion du temps aller-retour.

Voici quelque chose à considérer ... Les retards que vous rencontrez en tant que client (en particulier en tant que client particulier ou particulier) sont probablement provoqués artificiellement, du moins dans une certaine mesure. Il existe une classe de communications 3G et GSM pour l'utilisation de M2M, pour SCADA, etc., qui peut parfois offrir une plus grande fiabilité et une transmission à faible temps de latence. En conséquence, ils sont généralement prohibitifs.

Donc, fondamentalement, vous êtes confronté à la formation de trafic. Soit le FAI / Telco le fait pour donner la priorité aux clients les mieux payés, soit la cellule à laquelle vous êtes connecté est un peu occupée, soit tout son réseau est un peu lent (essayez 00:00 GMT le 1/1/2012, par exemple). Exemple).

Mais il y a un moyen de contourner tout cela, c'est quand même un peu sournois. Vous aurez essentiellement besoin d'un proxy de connexion TCP avant que votre trafic ne passe par le réseau WWAN mobile. Ce proxy enverrait essentiellement un ACK usurpé à votre application, car le véritable ACK pourrait être retardé par la mise en forme du trafic du FAI.
C'est tout à fait douteux, mais un certain nombre de fournisseurs de satellites utilisent ce mécanisme pour donner l'impression que la latence est inférieure à la réalité.

Un peu tard dans le jeu, mais vous voudrez peut-être consulter l'article de mon calendrier de performances sur le sujet: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing-link/

tl; dr - une partie importante de la latence des mobiles est due à un routage non optimisé sur le trajet de retour.

Les technologies de modem de téléphonie cellulaire souffrent d'un temps de latence élevé en raison de la nature des communications en plein air: les distances de transmission WLAN étant généralement beaucoup plus courtes que celles des autres technologies que vous avez mentionnées, c'est l'une des raisons pour lesquelles le temps de latence est inférieur.