Connexion P2P sur NAT?
J'ai commencé à explorer la possibilité de se connecter avec d'autres en utilisant une connexion p2p, j'ai donc codé un programme de socket simple dans Java pour Android appareils dans lesquels les utilisateurs peuvent partager des messages simples p2p (je n'avais aucune idée de NAT alors). J'ai appris à connaître NAT, donc je dois maintenant établir un TCP connexion avec un autre utilisateur qui utilise un serveur pour la découverte mais la charge utile est transférée p2p. J'ai également regardé XMPP (une très bonne et détaillée explication du fonctionnement du protocole est ici ) et UPnP mais je ne sais pas comment pour les mettre en œuvre.
Une autre question intéressante qui se pose est celle de BitTorrent car ils peuvent fonctionner sur n'importe quel appareil et même derrière un NAT. Je ne peux pas obtenir d'explication sur le fonctionnement de BitTorrent.
J'ai beaucoup recherché mais je suis coincé.
Mes questions sont:
- Une explication détaillée de BitTorrent (comme ici , pas comment fonctionnent les torrents) et comment est-il capable de contourner NAT?
- Existe-t-il un moyen de créer une entrée NAT par programme?
- La programmation des sockets est-elle suffisante pour p2p?
- Est-il difficile de créer votre propre protocole et comment puis-je en créer un?
- Si deux appareils D1 et D2 veulent communiquer p2p et se connaissent IP l'un de l'autre. D1 envoie une demande à D2 et cela ne peut pas passer par le NAT du D2, mais il devrait y avoir une entrée créée dans le NAT de D1. Ainsi, lorsque D2 essaie d'envoyer quelque chose de D1 NAT devrait découvrir une entrée avec l'IP de D2. Alors pourquoi le paquet n'est-il pas autorisé par lui?
Une autre question intéressante qui se pose est celle de BitTorrent car ils peuvent fonctionner sur n'importe quel appareil et même derrière un NAT. Je ne peux pas obtenir d'explication sur le fonctionnement de BitTorrent.
Cette déclaration semble supposer que bittorrent a besoin d'une connectivité complète pour fonctionner.
C'est incorrect.
Derrière un appareil NAT vous pourrez toujours établir les connexions sortantes TCP . Ce qui est généralement suffisant pour bittorrent tant qu'il y a d'autres clients non NAT (ou NAT mais correctement port-forwarded ) dans le réseau qui peuvent accepter entrant connexions.
Le NAT n'a aucun impact sur la direction du flux des données car les connexions sont bidirectionnelles une fois qu'elles sont établies. C'est seulement problématique pour la configuration de connexion initiale.
Cela fonctionne parfaitement pour bittorrent car bittorent ne se soucie pas du nœud spécifique auquel vous obtenez vos données. Bien qu'une meilleure connectivité améliore généralement les performances.
Si l'identité du nœud est importante ou que les transferts individuels sont un cas d'utilisation important, alors d'autres protocoles p2p tentent généralement NAT traversal d'abord et si cela échoue, comptez sur des nœuds tiers relayant le trafic entre ces nœuds qui ne peuvent pas se connecter directement.
De plus, la prise en charge IPv6 deviendra essentielle à l'avenir pour maintenir la connectivité de bout en bout, car de plus en plus de FAI commencent à se déployer NAT de classe opérateur pour IPv4 tandis qu'IPv6 restera non NAT.
Une chose doit être claire, c'est que 100% P2P entre tous les types de NAT est impossible en ce moment. Il n'y a aucun moyen pratique d'établir une connectivité P2P entre ** Symmetric et Symmetric/PRC NAT. Dans cette connexion de scénario est établie via un serveur relais appelé TURN.
Je réponds à votre 2ème question car je ne connais pas grand-chose à la première.
2) Oui. Vous pouvez envoyer un paquet via votre NAT et il y aura un mappage entre votre IP interne: Port à l'IP externe de votre NAT: Port. Vous pouvez connaître ces IP externe: Port en envoyant une demande d'étourdissement Notez que cette technique ne fonctionne pas pour le NAT symétrique.
3) Oui la programmation des sockets est suffisante pour p2p.
4) Pourquoi avez-vous besoin d'un protocole alors qu'il en existe déjà plusieurs. Le protocole ICE est le meilleur aujourd'hui pour NAT traversal et je ne pense pas que ce soit facile à créer. UPnP et NAT-PMP sont vraiment vulnérables en termes de sécurité.
5) Je pense que ce qui se passe est généralement NAT bloque les paquets inconnus qui y arrivent. Ainsi, lorsque D1 envoie un paquet à D2, son NAT bloque tous les paquets provenant de IP D1: port. C'est pourquoi l'établissement de la connexion échoue. Vous devez utiliser la technique de perforation pour D1 et D2 pour établir avec succès la connectivité P2P.
** Par symétrique NAT je veux dire symétrique NAT avec allocation de port aléatoire.
Il existe un article sur " Peer-to-Peer Communication Across Network Address Translators " qui décrit la méthode DP hole poinçonnage et l'étend pour être utilisée sur TCP également.
Bien sûr, vous aurez toujours besoin d'un serveur relais pour les cas où la perforation n'est pas prise en charge.
Les versions récentes de BitTorrent utilisent µTP , qui est superposé à UDP, pas TCP. µTorrent utilise une extension privée (
ut_holepunch) qui effectue la perforation UDP, la plupart des autres implémentations ne dérangent pas (à l'exception notable de Tixati).Certains NAT routeurs acceptent les demandes de redirection de port en utilisant le protocole PNP ou PMP . Que ce soit cela est pris en charge dépend de la marque particulière du routeur et de sa configuration.
Oui, la programmation des sockets est suffisante pour le P2P.
Difficile de répondre. Je vous suggère de lire la spécification BitTorrent wikifiée et annotée pour commencer.
Oui, c'est le principe derrière perforation UDP .