Utiliser les sockets sur android en 4g
Fermé
quent217
Messages postés
421
Date d'inscription
vendredi 25 septembre 2015
Statut
Membre
Dernière intervention
1 mars 2024
-
21 nov. 2017 à 15:00
ElementW Messages postés 4816 Date d'inscription dimanche 12 juin 2011 Statut Contributeur Dernière intervention 5 octobre 2021 - 23 nov. 2017 à 11:25
ElementW Messages postés 4816 Date d'inscription dimanche 12 juin 2011 Statut Contributeur Dernière intervention 5 octobre 2021 - 23 nov. 2017 à 11:25
A voir également:
- Ce partenaire n'accepte pas les connexions entrantes android
- Voir les connexions facebook - Guide
- Android recovery - Guide
- Jouer a pokemon sur android - Guide
- Mode sécurisé android - Guide
- Voir mot de passe wifi android - Guide
2 réponses
ElementW
Messages postés
4816
Date d'inscription
dimanche 12 juin 2011
Statut
Contributeur
Dernière intervention
5 octobre 2021
1 225
21 nov. 2017 à 15:40
21 nov. 2017 à 15:40
'lut,
sur un même réseau local 2 appareils peuvent se parler librement et sans restriction car ton trafic réseau reste chez toi, dans ton LAN. Dans ce LAN, un intervalle d'adresses IP est réservé pour les machines du réseau, et si un message part et veut arriver chez quelqu'un dans ce même intervalle, la box/le routeur relaye directement le trafic de la machine A vers la machine B, que les dites machines soient des PC, des smartphones ou des consoles de jeux, par exemple.
En revanche, quand tu passes en 4G, tes téléphones ne partagent plus de réseau direct en commun, tous deux sont livrés à l'immensité de l'internet. En principe ils pourraient très bien s'envoyer des messages directement pour peu que tu indique l'IP de l'autre à l'un d'entre eux, mais en pratique ce n'est pas possible, car il n'y a pas qu'un seul téléphone derrière une adresse IPv4, faute de place; on se retrouve avec la même situation que les box d'opérateurs qui font du NAT : cache plusieurs appareils derrière une même adresse externe. Ça a pour conséquence d'empêcher la création de serveurs qui écoutent sur un port particulier (et donc t'empêche d'utiliser les sockets qui reçoivent) car le NAT ne relaye pas de port fixe par défaut (uniquement ceux alloués dynamiquement quand on établit une connexion vers l'extérieur; et comme si c'était pas assez complexe le port vu de l'extérieur peut différer de celui vu de l'intérieur) sauf si on peut le configurer, mais les utilisateurs ne peuvent pas configurer les relais 4G.
En IPv6 la situation serait bien plus simple car pas de NAT, mais je crois qu'aucun opérateur ne propose d'IPv6 en 2/3/4G.
De base c'est donc impossible. Tu as toutefois 2 solutions:
sur un même réseau local 2 appareils peuvent se parler librement et sans restriction car ton trafic réseau reste chez toi, dans ton LAN. Dans ce LAN, un intervalle d'adresses IP est réservé pour les machines du réseau, et si un message part et veut arriver chez quelqu'un dans ce même intervalle, la box/le routeur relaye directement le trafic de la machine A vers la machine B, que les dites machines soient des PC, des smartphones ou des consoles de jeux, par exemple.
En revanche, quand tu passes en 4G, tes téléphones ne partagent plus de réseau direct en commun, tous deux sont livrés à l'immensité de l'internet. En principe ils pourraient très bien s'envoyer des messages directement pour peu que tu indique l'IP de l'autre à l'un d'entre eux, mais en pratique ce n'est pas possible, car il n'y a pas qu'un seul téléphone derrière une adresse IPv4, faute de place; on se retrouve avec la même situation que les box d'opérateurs qui font du NAT : cache plusieurs appareils derrière une même adresse externe. Ça a pour conséquence d'empêcher la création de serveurs qui écoutent sur un port particulier (et donc t'empêche d'utiliser les sockets qui reçoivent) car le NAT ne relaye pas de port fixe par défaut (uniquement ceux alloués dynamiquement quand on établit une connexion vers l'extérieur; et comme si c'était pas assez complexe le port vu de l'extérieur peut différer de celui vu de l'intérieur) sauf si on peut le configurer, mais les utilisateurs ne peuvent pas configurer les relais 4G.
En IPv6 la situation serait bien plus simple car pas de NAT, mais je crois qu'aucun opérateur ne propose d'IPv6 en 2/3/4G.
De base c'est donc impossible. Tu as toutefois 2 solutions:
- Utiliser un système de VPN, créant un LAN virtuel, les détails quant à la connexion étant laissés à sa charge
- Faire des trous dans le NAT avec ce qu'on appelle le TCP/UDP hole punching, qui consiste à se connecter à un serveur public pour établir une connexion entre 2 appareils. Il existe un protocole standardisé pour ça: STUN, qui de base ne marche qu'en UDP mais il existe des versions pour TCP. Tu peux facilement trouver des listes de serveurs STUN publics en cherchant "public turn server list" sur le net. Il y a des bibliothèques Python pour faire ça.
quent217
Messages postés
421
Date d'inscription
vendredi 25 septembre 2015
Statut
Membre
Dernière intervention
1 mars 2024
344
21 nov. 2017 à 19:20
21 nov. 2017 à 19:20
Merci pour ta réponse très rapide !
Je me pose cependant une question par rapport à ce que tu as dit :
Si 2 appareils peuvent être associer à une même adresse ip, comment les serveurs qui hébergent les sites web par exemple peuvent communiquer avec mon smartphone ? Ont ils des informations supplémentaires que l'adresse ip ?
--
Je me pose cependant une question par rapport à ce que tu as dit :
Si 2 appareils peuvent être associer à une même adresse ip, comment les serveurs qui hébergent les sites web par exemple peuvent communiquer avec mon smartphone ? Ont ils des informations supplémentaires que l'adresse ip ?
--
ElementW
Messages postés
4816
Date d'inscription
dimanche 12 juin 2011
Statut
Contributeur
Dernière intervention
5 octobre 2021
1 225
Modifié le 22 nov. 2017 à 13:59
Modifié le 22 nov. 2017 à 13:59
En prenant ton exemple en particulier, il y a deux niveaux:
le premier s'applique à toutes les box et routeurs qui font du NAT: il n'y a pas que l'adresse IP comme information. Une connexion s'identifie par un ensemble de 5 éléments: l'IP source, le port source, l'IP destination, le port destination, et le protocole (TCP/UDP/SCTP/autre). Quand plusieurs appareils sont cachés derrière un NAT = 1 IP visible, le routeur regarde son tableau de routage qui associe un port externe (par exemple 80 = HTTP; ce port externe correspond à l'info de "port destination") à une IP et un port à l'intérieur du réseau. Je peux faire tourner un serveur web sur ma machine 10.0.0.42 sur le port 8080, et configurer le NAT en lui disant d'associer le port 80 extérieur à 10.0.0.42:8080.
Le deuxième niveau s'applique pour HTTP(S) et permet d'avoir plusieurs sites derrière une même IP et un même port (80 ou 443, respectivement). La technique est simple: dans chaque requête au serveur, on transmet le nom de domaine qu'on veut dans l'en-tête HTTP
le premier s'applique à toutes les box et routeurs qui font du NAT: il n'y a pas que l'adresse IP comme information. Une connexion s'identifie par un ensemble de 5 éléments: l'IP source, le port source, l'IP destination, le port destination, et le protocole (TCP/UDP/SCTP/autre). Quand plusieurs appareils sont cachés derrière un NAT = 1 IP visible, le routeur regarde son tableau de routage qui associe un port externe (par exemple 80 = HTTP; ce port externe correspond à l'info de "port destination") à une IP et un port à l'intérieur du réseau. Je peux faire tourner un serveur web sur ma machine 10.0.0.42 sur le port 8080, et configurer le NAT en lui disant d'associer le port 80 extérieur à 10.0.0.42:8080.
Le deuxième niveau s'applique pour HTTP(S) et permet d'avoir plusieurs sites derrière une même IP et un même port (80 ou 443, respectivement). La technique est simple: dans chaque requête au serveur, on transmet le nom de domaine qu'on veut dans l'en-tête HTTP
Host. À partir de là le serveur web qui reçoit la demande agit comme configuré pour te donner le bon site web: un même serveur (ex. Apache) peut traiter à la fois les demandes de site1.com et site2.com tout en relayant le traffic de site3.com vers une autre machine (reverse proxy).
quent217
Messages postés
421
Date d'inscription
vendredi 25 septembre 2015
Statut
Membre
Dernière intervention
1 mars 2024
344
22 nov. 2017 à 22:43
22 nov. 2017 à 22:43
Bonjour,
est-il possible d'utiliser le même principe en python ? C'est à dire de spécifier le port du client en plus de l'adresse ip, l'autre méthode étant réservé à l'HTTPS ce qui n'est pas mon cas si j'ai bien compris.
En fait, ce que je me dis c'est que si un serveur est capable de faire quelque chose, il doit être possible de coder un serveur qui fais la même chose sur mon appareil sans avoir à passer par un VPN ou un serveur intermédiaire comme tu l'as dit dans ton premier message.
Peut être que je me trompe mais j'ai du mal à comprendre où est la différence entre un serveur qui héberge un site web et mon appareil sur lequel je code un serveur en python car il me semble qu'un serveur n'est rien de plus qu'une sorte d'ordinateur conçu pour fonctionner en continue.
Encore merci pour ton aide très précieuse :)
--
est-il possible d'utiliser le même principe en python ? C'est à dire de spécifier le port du client en plus de l'adresse ip, l'autre méthode étant réservé à l'HTTPS ce qui n'est pas mon cas si j'ai bien compris.
En fait, ce que je me dis c'est que si un serveur est capable de faire quelque chose, il doit être possible de coder un serveur qui fais la même chose sur mon appareil sans avoir à passer par un VPN ou un serveur intermédiaire comme tu l'as dit dans ton premier message.
Peut être que je me trompe mais j'ai du mal à comprendre où est la différence entre un serveur qui héberge un site web et mon appareil sur lequel je code un serveur en python car il me semble qu'un serveur n'est rien de plus qu'une sorte d'ordinateur conçu pour fonctionner en continue.
Encore merci pour ton aide très précieuse :)
--
ElementW
Messages postés
4816
Date d'inscription
dimanche 12 juin 2011
Statut
Contributeur
Dernière intervention
5 octobre 2021
1 225
>
quent217
Messages postés
421
Date d'inscription
vendredi 25 septembre 2015
Statut
Membre
Dernière intervention
1 mars 2024
23 nov. 2017 à 11:25
23 nov. 2017 à 11:25
Un serveur physique et un smartphone fonctionnent pareil pour faire tourner un serveur quelconque, et le réseau est géré pareil. Le problème se trouve un peu plus loin logiquement et physiquement, en voici une illustration:
