Comment fonctionnent les sockets sur les connexions sans fil?

Je n'ai travaillé que sur des applications côté client (spécifiquement mobiles) utilisant Android, où tout le réseau est géré au niveau de la couche HTTP à l'aide de composants fournis par le framework comme HttpUrlConnection.

Mais les systèmes de messagerie push comme Websockets / XMPP, etc., maintiennent tous une connexion persistante au serveur. Même le GCM de Google, intégré aux appareils pris en charge par Google Play, maintient une connexion persistante aux serveurs.

Ma question est, comment cela fonctionne sans décharger la batterie? Si nous faisons des requêtes HTTP continues de manière séquentielle, la décharge de la batterie est importante. Comment ces connexions persistantes sont-elles maintenues sans rencontrer le même problème?

Une connexion TCP ouverte est un état logique. Cela n'implique pas que ces données soient toujours envoyées dans les deux sens. Après la prise de contact à trois voies initiale, vous êtes entré dans l'état "connecté". Vous êtes dans cet état jusqu'à ce qu'une déconnexion à 3 voies se produise ou qu'un maintien en vie échoue.

Pendant la durée de la connexion, des ressources provenant du support "physique" sous-jacent peuvent être établies pour effectuer des transferts de données pour cette connexion. Dans le cas d'une connexion filaire, il s'agit de transférer des trames Ethernet. Dans le cas d'une connexion sans fil 3G / 4G, cela se fait en établissant des connexions avec les protocoles de niveau inférieur selon les besoins.

Donc, pendant la durée de la connexion, il n'y a pas de connexion de données sous-jacente physique qui existe. Au lieu de cela, il reste dormant en attendant que l'un des pairs de la connexion TCP ait besoin d'envoyer des données.

Un autre problème est que TCP est basé sur un accusé de réception . Les pairs TCP peuvent se tenir mutuellement assez efficacement informés de ce qui a été définitivement reçu. En cas d'échec, TCP retransmet. Cela fonctionne très bien pour des liens physiques assez fiables, mais a tendance à s'effondrer dans les liens très bruyants / cassés, comme vos connexions sans fil. Comme vous pouvez l'imaginer, des accusés de réception / retransmissions se produiraient très fréquemment dans ces environnements.

Donc, généralement, le protocole sans fil sous-jacent fait tout ce qu'il peut pour réduire le besoin de retransmissions TCP. Par exemple, de nombreuses vérifications d'erreurs sont intégrées à la couche sans fil. Les pairs du domaine sans fil (la station de base / téléphone) utilisent également un protocole basé sur nak pour dire à l'autre côté quand ils n'ont pas reçu quelque chose. Être basé sur nak réduit les frais généraux liés à la recherche d'erreurs (nous supposons que tout va bien, sauf si l'autre côté dit le contraire). Il aide également à corriger les erreurs avantils bouillonnent jusqu'à la couche TCP - évitant ainsi beaucoup de thrash TCP essayant de retransmettre. De plus, cela réduit la portée de toutes les retransmissions aux homologues sans fil - le téléphone n'a plus besoin de demander le paquet au serveur quelque part sur Internet, juste la station de base via la liaison sans fil.