Pourquoi les réseaux mobiles ont-ils des latences élevées? Comment les réduire?
Je constate de plus en plus que les technologies de réseautage mobile sont utilisées pour accéder à Internet dans des zones où il n'est pas disponible autrement.
Bien que la mise en 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 pour une solution de secours.
La bande passante n'est pas le problème: avec HDSPA, des vitesses de plusieurs MBit sont possibles, ce qui fournit une liaison montante décente. Cependant, je sais par expérience personnelle que les liens Internet des réseaux mobiles (via GPRS, UMTS, etc.) ont des latences beaucoup plus élevées que le DSL normal (200-400 ms pour UMTS, encore plus pour GPRS). Bien sûr, cela les rend inadaptés à de nombreuses applications, telles que la VoIP et les téléconférences.
- D'où vient cette latence?
- Y a-t-il des technologies disponibles qui peuvent atténuer ce problème, pour rendre UMTS viable pour les applications à faible latence?
Je suppose qu'il doit y avoir une raison technique inhérente, mais qu'est-ce que c'est? Cela a-t-il à voir avec la façon dont les données sont transmises par voie aérienne? Et si c'est à cause de la transmission sans fil, pourquoi le WLAN a-t-il des latences beaucoup plus faibles?
Le livre "High Performance Browser Networking" d'Ilya Grigorik répond exactement à cela. Il y a tout un chapitre (7ème) dédié 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 gênent. Que ce soit TCP démarrage lent , les configurations Radio Resource Controller (RRC) ou sous-optimales. Si vous rencontrez une latence faible uniquement dans les réseaux mobiles c'est la façon dont ils sont conçus.
Il y a un tableau dans le livre 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–1 000 ms 3G | 0,5 à 5 Mbit/s | 100–500 ms 4G | 1 à 50 Mbit/s | <100 ms
Bien que très pertinente pour la latence, la négociation TCP caractéristique à trois voies ou le démarrage lent ne répondent pas vraiment à la question, car elles affectent également les connexions câblées. Qu'est-ce qui affecte réellement la latence dans les réseaux mobiles 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), comme vous le voyez les chiffres s'additionnent assez rapidement. Comme indiqué 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 dans les réseaux antérieurs.
Figure 7-12. LTE latences de flux de demande
- Plan de contrôle latence: coût de latence fixe unique encouru pour la négociation RRC et les transitions d'état: <100 ms pour inactif à actif et <50 ms pour dormant à actif.
- Plan utilisateur latence: coût fixe pour chaque paquet d'application transféré entre l'appareil et la tour radio: <5 ms.
- Latence du cœur de réseau: 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.
- Latence de routage Internet: coût de latence variable entre la passerelle de paquets de l'opérateur et l'adresse de destination sur Internet public.
Dans la pratique, la latence de bout en bout de nombreux réseaux 4G déployés a tendance à se situer entre 30 et 100 ms une fois que l'appareil est connecté.
Donc, vous avez pour une seule requête (Figure 8-2. Composants d'une requête HTTP "simple"):
- Négociation RRC 50-2500 ms
- Recherche DNS 1 RTT
- Protocole TCP 1 RTT (connexion préexistante) ou 3 RTT (nouvelle connexion)
- Prise de contact TLS 1-2 RTT
- Requêtes HTTP 1-n RTT
Et avec des données réelles:
Tableau 8-1. Surcharge de latence d'une seule requête HTTP
| 3G | 4G Avion de contrôle | 200–2 500 ms | 50 à 100 ms Recherche DNS | 200 ms | 100 ms Négociation TCP | 200 ms | 100 ms Prise de contact TLS | 200–400 ms | 100 à 200 ms Requête HTTP | 200 ms | 100 ms Temps de latence total | 200–3500 ms | 100 à 600 ms
De plus, si vous avez une application interactive que vous souhaitez exécuter modérément bien dans un réseau mobile, vous pouvez expérimenter la désactivation de l'algorithme Nagle (le noyau attend que les données se 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 y a la possibilité de lire l'intégralité du livre gratuitement par tout le monde à https://hpbn.co/ parrainé par Velocity Conference. C'est un livre très fortement recommandé, non seulement aux personnes qui développent 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 de "large bande cellulaire" est un problème composé d'un certain nombre de choses.
Il y a de la distance, mais comme l'a mentionné Syneticon-dj, ce n'est en réalité qu'une très petite proportion du temps d'aller-retour.
Voici quelque chose à considérer ... Les retards que vous rencontrez en tant que client (en particulier en tant que client résidentiel ou de petite entreprise) sont probablement induits artificiellement, au moins dans une certaine mesure. Il existe une classe de communications 3G et GSM pour l'utilisation M2M, pour SCADA et ainsi de suite, qui peuvent parfois fournir une plus grande fiabilité et une transmission à latence plus faible. En conséquence, ils sont généralement d'un coût prohibitif.
Donc, fondamentalement, vous êtes confronté à la mise en forme du trafic. Soit l'ISP/Telco le fait pour prioriser les clients les mieux rémunérés, soit la cellule à laquelle vous êtes connecté est un peu occupée, soit leur réseau est un peu lent (essayez 00:00 GMT le 1/1/2012, pour exemple).
Mais il y a un moyen de contourner tout cela, c'est un peu sournois cependant. Vous auriez essentiellement besoin d'un proxy de connexion TCP avant que votre trafic ne passe par le WWAN mobile. Ce proxy enverrait essentiellement un ACK usurpé à votre application, car le véritable ACK pourrait être retardé par les FAI). mise en forme du trafic.
C'est clairement douteux, mais un certain nombre de fournisseurs de satellites utilisent ce mécanisme pour rendre la latence plus faible qu'elle ne l'est réellement.
Un peu tard pour le jeu, mais vous voudrez peut-être consulter l'article de mon calendrier des performances sur le sujet: http://calendar.perfplanet.com/2012/latency-in-mobile-networks-the-missing- lien /
tl; dr - une grande partie de la latence mobile est due au routage non optimisé sur le back-haul.
Les technologies de modem de téléphone portable souffrent d'une latence élevée en raison de la nature des communications en plein air: les distances de transmission WLAN sont généralement beaucoup plus courtes que celles des autres technologies que vous avez mentionnées, c'est donc une des raisons pour lesquelles la latence est plus faible.