Jouons un peu avec TCP : à l'époque où ce mot voulait encore dire « Transmission Control Program », on se souciait de pouvoir faire communiquer de manière fiable deux processus discutant à travers un réseau à commutation de paquet non fiable (on n'avait pas encore séparé IP de TCP, et la taille des adresses n'était pas encore définie : de 24 bits en 1974 à « variable » en 1978, par exemple), et en réassemblant et réordonnant ces paquets, avec une fenêtre d'envoi et de réception pour gérer tout ça et en bonus le contrôle du flux. L'idée fondamentale derrière tout ça était de trouver le « minimum » vital qui permettait d'obtenir ce résultat. Il en sorti qu'il fallait « simplement » établir un protocole qui permet de synchroniser des numéros de séquence et des tailles de fenêtre — si on fait abstraction de l'adressage, en se concentrant sur le flux.
Vous retrouverez ces concepts dans la très bonne lecture qu'est l'Internet Experiment Note 21, Specification of Internetwork Transmission Control Program (disponible seulement en PDF scanné), par Vint Cerf et Jon Postel, en 1978. Vous retrouvez également l'idée originale dans A Protocol for Packet Network Intercommunication, par Vint Cerf et Bob Kahn, en 1974, qu'on considère comme les inventeurs d'Internet.
Et donc en lisant le 4.2.2, où on retrouve la fameuse machine à état de TCP, on se rend compte que deux processus actifs (i.e. initiant une connexion) peuvent se synchroniser, car ce protocole a été bien fait. Démonstration ; dans un terminal, lancez un netcat ainsi :
Et dans un deuxième :
while true; do nc -p 5678 ::1 1234 ; done
Et magie ! Vous vous retrouvez avec deux sockets synchronisées, qui vous permettent ici de retrouvez ce que vous tapez dans un terminal dans l'autre (à la gestion de buffer prêt : il faut valider avec entrée pour que les buffers soient vidés).
while true; do nc -p 1234 ::1 5678 ; done
Je vous conseille donc grandement la lecture de ces documents historiques très intéressants.
# croiser avec stdin, stdout et tutti quanti ?
Posté par Thomas Douillard . Évalué à 2.
Du coup les numéro de port sont carrément analogues aux "file descriptor" unix. J'ai jamais vraiment utilisé netcat, mais du coup la séparation "net" et "cat" prend tout son sens.
On a vraiment l'équivalent des tricks de magie noire qu'on peut faire avec les redirection d'entrée sorties, mais par le réseau.
[^] # Re: croiser avec stdin, stdout et tutti quanti ?
Posté par benoar . Évalué à 2.
Mmmhh, je ne suis pas tout à fait d'accord avec cette analogie : un descripteur de fichier est valable dans un contexte particulier, qui est celui d'un processus.
Je ferais plutôt l'analogie avec le nom d'un fichier, qui n'est valable que dans le contexte d'une machine mais est au moins le même pour tous les processus. Ici, on l'étendrait à l'ensemble du réseau : l'ensemble d'un hôte (adressé par nom ou par adresse) et d'un port (dont il existe un forme textuelle dans la base correspondante de l'IANA) forme le « nom » d'un processus sur le réseau. On retrouve cette terminologie dans l'API des sockets avec
getsockname
etgetpeername
, qui retournent respectivement l'ensemble adresse + port de l'hôte local ou distant. Ces ensembles ont une signification globale et non particulière à un contexte : en tout point du réseau, ce « nom » de processus l'identifie clairement.J'insiste sur la signification globale de l'identifiant, car c'est le point central d'Internet : il n'y a pas d'état dans le réseau, et donc pas besoin de synchronisation au cœur du réseau, ce qui simplifie énormément le coût d'opération de celui-ci. L'intelligence est aux extrémités, qui gèrent leur synchronisation eux-même, en utilisant des identifiants globaux.
Bien sûr, ces principes sont cassés quand on n'utilise pas d'adresse globale, et la complexité de fonctionnement du réseau augmente exponentiellement, mais ça n'est pas nouveau. C'est juste que personne n'ose mesurer le coût de fonctionnement d'une telle architecture.
# Ou plutôt « SYNchroniser »
Posté par benoar . Évalué à 2.
Voilà quand on lit trop vite le document : ici, c'est plutôt à la forme infinitive qu'il faut voir la synchronisation, car il est écrit que SYN permet de « SYNchroniser ».
# RFC793
Posté par ®om (site web personnel) . Évalué à 3.
Coïncidence, j'étais justement en train de lire le RFC793 quand je suis tombé sur ce journal.
La section 3.3 explique pourquoi synchroniser les numéros de séquence:
La section 3.4 parle de la connexion simultanée (puis détaille un échange):
C'est rigolo, j'ai justement demandé par mail hier à Stéphane Bortzmeyer si ce cas de connexion simultanée existait en réalité. Je colle sa réponse (je pense qu'il ne m'en voudra pas, même si un mail est censé être privé), qui indique justement que ça peut se produire avec un port source fixe:
Et tu donnes dans ce billet un exemple concret. Merci, ça tombe très bien :)
blog.rom1v.com
[^] # Re: RFC793
Posté par benoar . Évalué à 3.
Merci pour la référence, c'est effectivement la « suite » des documents que je cite.
Oui, et en fait il faut se remettre en tête le contexte de l'époque : le réseau était beaucoup moins grand, moins dynamique, les processus aussi, et on mettait alors en place des « associations » entre processus sur des machines distantes en fixant statiquement certains paramètres. Ainsi, on pouvait éventuellement fixer complètement une association en y mettant les adresses locales et distantes, ainsi que les ports. Une association est alors ouverte (la commande OPEN de l'API de l'époque, décrit dans le 2.7 de ta RFC 793). Ce qui déclenche la synchronisation de numéro de séquence est l'activation de la socket, soit en l'indiquant explicitement, soit à l'époque également à l'envoi de données (c.f. 2.4.1 de l'IEN 21).
C'est une chose qui n'est pas tout à fait reflétée dans l'API des socket d'aujourd'hui : on ne peut pas (à ma connaissance) fixer d'adresse et le port d'une socket distante avec cette API en TCP sans l'activer immédiatement. En UDP, on peut tout à fait faire un ''connect'' (oui, ça peut sembler étrange pour un protocole « non-connecté ») pour les fixer à l'avance, si on n'accepte que les connexions d'un processus sur un nœud précis du réseau, et cela ne générera absolument aucun trafic.
Je ne connaissais par contre pas l'utilisation historique de ce genre de chose dans le DNS ou BGP : merci à Stéphane, donc.
Exemple concret mais d'une utitilée très limitée quand même… Il sert quand même à réfléchir aux principes qui sous-tendent TCP. De rien :-)
# Hole punching
Posté par palkeo (site web personnel) . Évalué à 2.
Merci pour ce journal, c'est super intéressant !
Ça m'a aussi fait découvrir que c'est cette technique de connexion simultanée qui est utilisée pour passer les NAT avec le « hole punching ».
[^] # Re: Hole punching
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Un exemple pour les curieux: https://samy.pl/pwnat/
[^] # Re: Hole punching
Posté par benoar . Évalué à 6.
Nan mais c'est pas possible que des mecs aient pu inventer ça… Détourner les réponses d'expiration de TTL pour passer en retour à un ping sur une fausse adresse, pour ensuite essayer en random des ports en UDP pour espérer passer à travers le bousin… (j'ai arrêté avant la fin) Sans déconner, comment peut-on vouloir faire marcher un réseau correctement avec ça ?!
Bordel, on s'emmerderait tellement moins si les gens passaient plus de temps à promouvoir des solutions pérennes comme IPv6, et sans les firewall de nazi au milieu.
[^] # Re: Hole punching
Posté par benoar . Évalué à 1.
Heu… en TCP ?! Autant le hole-punching en UDP, ça se comprend un peu, même si c'est crade, mais alors en TCP… je suis allé voir la page wikipédia sur le TCP hole punching, et ça a effectivement l'air d'exister, mais alors niveau crade de chez crade et pas fiable, je ne pense pas qu'on puisse faire mieux. Je ne connais personne qui fait ça en pratique, ni entendu que ça puisse marcher.
Franchement, au lieu d'inventer des nouveaux trucs pas fiables, il vaudrait mieux passer son temps à former les admin réseaux sur comment le pas pourrir Internet, ça serait plus productif.
[^] # Re: Hole punching
Posté par Larry Cow . Évalué à 2.
Tout le monde n'est pas formable (sans parler des cas où il n'y a plus personne à former, et juste un truc dans un coin qui "juste marche" depuis des lustres).
[^] # Re: Hole punching
Posté par benoar . Évalué à 2.
Ça c'est dommage, même si je peux comprendre certaines raisons. Mais déjà, leur apprendre à ne pas faire plus de mal au réseau que ce qu'il est actuellement, ça serait bien.
Je ne suis pas pour tout remplacer du jour au lendemain, surtout ce qui marche, bien sûr ! IPv4 et certains NAT resterons encore longtemps. Mais aujourd'hui, beaucoup de choses ne marchent simplement pas. Alors autant les remplacer. Et surtout ne pas reproduire les erreurs du passé : malheureusement, c'est ce qui est en train d'arriver avec les firewalls stateful IPv6 qui sont configurés comme des merdes. D'où le besoin de formation.
[^] # Re: Hole punching
Posté par foobarbazz . Évalué à 4.
Je pense que c'est bien que ce genre de choses existent. De la même manière que l'horreur des chimio thérapie permet de comprendre l'horreur du cancer. L'horreur de ces choses là permettent de comprendre l'horreur des NAT. Et donc, qu'il faut lutter contre le cancer de la même manière qu'il faut lutter contre les NAT, lui préférant le routage avec IPv6.
[^] # Re: Hole punching
Posté par PachaFonk . Évalué à 2.
Meilleur comparaison de tous les temps !
# Rien
Posté par Marotte ⛧ . Évalué à -2. Dernière modification le 07 février 2017 à 20:34.
[non rien vraiment]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.