J'ai lu des articles sur Conversations et TCP Streams, mais je ne sais toujours pas très bien comment ils se rapportent s'ils se trouvent sur le même calque.
Pour différentes couches, il est clair pour moi que, par exemple, une conversation IP peut être constituée de plusieurs flux TCP.
Une conversation TCP peut-elle consister en plusieurs flux TCP? Et à l'opposé, un flux TCP peut-il contenir plusieurs conversations TCP? Pourquoi?
Réponses:
Dans ce cas, une conversation a lieu au niveau TCP (transport) et est synonyme de connexion TCP entre deux ports.
Un "flux TCP" dans ce contexte est l'agrégation des messages de l'application qui ont été transmis dans une conversation. Par exemple, le flux de votre lien montre un hôte intérieur exécutant un programme compatible UPNP, demandant à un routeur de transférer le port 5000 pour celui-ci et à la réponse du routeur. Donc, ce que vous êtes en réalité, c'est le champ de données du segment TCP. Pour cette raison, je pense qu’il porte un mauvais nom. Toutes les informations TCP ont été supprimées, ne laissant que les messages que le logiciel des deux hôtes envoie et reçoit. Il peut s'agir de réponses HTTP GET et de réponses, de PUT FTP, de MAIL SMTP ou du langage de commande natif de toute autre application.
Personnellement, je ne suis pas sûr d'aimer la terminologie de Wireshark dans cette documentation, mais cela leur sert bien d'analyser le protocole. Une application voit une connexion Sockets entre deux points de terminaison sous la forme d'un flux d'E / S, quel que soit le protocole sous-jacent.
Sur une note de côté, je dirais que je ne suis pas d'accord sur l'IP ayant des "conversations". IP ne contient pas les données nécessaires au maintien d'un circuit virtuel et les laisse au-dessus d'une couche supérieure. TCP gère un circuit strict et UDP en gère un très lâche, laissant à son application l'ordre, la correction d'erreur et le contrôle de flux.
Les conversations TCP et les flux TCP doivent être au même niveau, mais, au moins dans certaines versions de Wireshark, ils utilisent un code différent pour identifier les paquets qui font partie de la conversation / du flux, afin de pouvoir donner des réponses différentes.
L’un d’eux peut, par exemple, traiter tout le trafic entre deux points de terminaison (paires adresse IP / port) comme faisant partie de la même conversation / du même flux, même si une connexion TCP entre ces deux points de terminaison est fermée et qu’une autre s’ouvre entre eux. les mêmes deux points de terminaison dans la même capture (peu probable, car les ports ne sont généralement pas réutilisés immédiatement, mais pas impossibles), tandis que l'autre peut reconnaître la fermeture de la connexion et l'afficher sous la forme de conversations / flux séparés.
S'ils n'utilisent pas le même code, c'est sans doute un bogue, mais il se peut que personne ne l'ait encore corrigé.
De toute évidence, les "conversations" IP , qui se situent entre deux points de terminaison IP (deux adresses IP), sont différentes des conversations / flux TCP; comme vous le constatez, il peut y avoir plusieurs conversations TCP, conversations UDP, etc. entre deux points de terminaison IP et donc plusieurs TCP / UDP / etc. conversations dans la même conversation IP.
En regardant simplement les exemples sur les pages que vous liez, il ne semble pas que les termes soient fonctionnellement différents. Les deux semblent être la longueur d'une seule connexion réseau.
La page de conversations ne résume pas plusieurs connexions, elle montre chacune d’elles, avec la durée et le nombre d’octets. La fenêtre de flux affiche simplement les détails des données réellement envoyées.