Bonjour,

Ce n'est pas en comparaison de quoique ce soit, TCP est décrit comme un protocole connecté qui établit et synchronise les deux parties avant d'envoyer des données de manière fiable (c'est-à-dire sans pertes sauf en cas d'incidents réseaux majeurs).

Les autres protocoles de la couche 1 à 3 de la stack TCP/IP ne permettent pas ça.

Ok je vois merci pour les explications KoaTao, donc c'est cette synchronisation avant l'envoi sans perte qui est exclusive à TCP. Mais (je ne peux m'empêcher de le comparer au protocole UDP de la couche transport), du coup pour ces raisons il est plus lent que le protocole UDP nan ? Donc par exemple si on utilisait TCP sur les diffusion LIVE en direct sur youtube ou sur la voip ca serait décalé ou lent ?

Par contre les rediffusion ou videos sur youtube par exemple sont vues en TCP ?

Merci

-
Edité par DddDddds 22 janvier 2023 à 17:28:44

En effet, avec TCP, il y a la synchronisation (3-way handshake) qui implique dans la manière la plus classique l'échange de 3 segments sans données utiles avant d'échanger ces données utiles justement. Cependant, TCP implémente d'autres mécanismes qui lui permet d'atteindre un niveau de qualité de service permettant de le décrire comme un protocole fiable d'un point de vue réseau:

• Retransmission des données non-reçus (ou incorrectement reçues)
• Contrôle de flux
• Contrôle de congestion

Avec le 3-way handshake, ça fait 4 mécanismes déjà qui sont implémentés dans le protocole et qui forcément, influent sur la taille des données transmisses dans un segment et le débit de la communication en termes de données utiles. Ajouter à ça un header plus grand et donc, à la longue, plus de données non-utiles générées et transmises, ce qui réduit le débit des données utiles.

UDP, par contre, ne s'embête pas avec tout ça, il envoie des datagrammes au destinataire avec les données utiles. Charge au destinataire d'absorber le trafic reçu et charge à l'émetteur d'envoyer les datagrammes au débit nécessaire pour le bon fonctionnement de l'application qui repose sur UDP. Pas de synchronisation, de retransmission ou de contrôle, simplement un checksum pour assurer l'intégrité du datagramme. C'est plus ou moins du Fire & Forget: une fois le datagramme envoyé, ce n'est plus la responsabilité de l'émetteur.

Il faut bien comprendre que ces protocoles ont été conçus il y a maintenant quelques dizaines d'années. Un temps où les technologies de l'information et des communications étaient très loin d'offrir les mêmes performances qu'actuellement. Notamment, pas de 4G, 5G ou de fibre optique. D'où l'intérêt d'avoir un protocole aussi robuste que TCP, capable de faire abstraction des systèmes physiques de télécommunications et de leurs relatives fiabilités pour l'époque.

Dans un mode de streaming non live, on veut pouvoir avoir toutes les données (t'as pas envie de voir que la moitié de la vidéo), il est plus intéressant dans ce cas d'utiliser TCP pour assurer que toutes les données seront reçues et pouvoir aussi émettre et recevoir à un rythme qui satisfait l'émetteur et le récepteur tout en s'adaptant aux changements et perturbations sur le réseau. Sachant qu'ensuite, on peut rajouter d'autres mécanismes et systèmes de contrôles dans le protocole applicatif.

Dans le streaming live, en réalité, on a pas besoin d'avoir du temps réel, on peut simplement mettre un buffer et mettre un délai de quelques secondes à quelques minutes pour laisser le temps d'avoir un buffer assez conséquent pour avoir offrir à l'utilisateur une expérience satisfaisante. Là aussi, c'est un peu comme la streaming non live au final. Juste que si le débit est vraiment trop faible, il faut dégrader la qualité ou alors augmenter le buffer (ce qui se fait au détriment de l'expérience utilisateur). C'est un choix, on pourrait faire le choix d'UDP et laisser le protocole applicatif assurer les fonctions de contrôles nécessaires. Cependant, vu que TCP le fait très bien, pourquoi s'embêter?

Vient la question des applications en temps réel: VoIP, vidéoconférence, remote desktop, etc... Ces applications ont besoin d'une latence très faible, quand tu parles avec quelqu'un, tu ne peux pas avoir de buffer par exemple, ça doit sembler complètement interactif et similaire à la «vraie vie». De même, les paquets qui sont perdues n'ont pas besoin d'être retransmis dans ce cas, leurs données ne serviront à rien de toute manière (l'application ne va pas revenir en arrière dans la communication). De base, on utilise UDP pour ce type d'application, parce que c'est typiquement un cas d'usage d'UDP. Pour ce qui est du contrôle et de la qualité de service, la VoIP par exemple, implémente des protocoles au niveau applicatif.  Pour la vidéoconférence (type Zoom, Teams, etc...), c'est un peu le même principe que la VoIP sauf qu'on rajoute la vidéo en plus. Pareil de manière générale, c'est UDP qui est choisi. Cependant, certaines applications, comme celle de Shadow Cloud Computing qui offre un PC dans le cloud avec une connexion en remote desktop, permettent de choisir le protocol de transport: UDP ou TCP. Et pour avoir tester les deux en étant derrière une connexion internet par la fibre, je n'ai remarqué aucune différence notable.

En bref, si les performances réseaux de ta connexion sont suffisantes, UDP ou TCP, tu ne feras pas la différence.  Aujourd'hui, les technologies de télécommunications sont assez évoluées pour offrir des performances qui effacent partiellement voir même tout simplement complètement le désavantage  « lourdeur » de TCP comparé à UDP. De plus en plus d'applications préfèrent se reposer sur TCP pour simplifier l'architecture et l'implémentation de(s) protocole(s) applicatif(s).

-
Edité par KoaTao 23 janvier 2023 à 23:57:30

KoaTao a écrit:

En effet, avec TCP, il y a la synchronisation (3-way handshake) qui implique dans la manière la plus classique l'échange de 3 segments sans données utiles avant d'échanger ces données utiles justement. Cependant, TCP implémente d'autres mécanismes qui lui permet d'atteindre un niveau de qualité de service permettant de le décrire comme un protocole fiable d'un point de vue réseau:

• Retransmission des données non-reçus (ou incorrectement reçues)
• Contrôle de flux
• Contrôle de congestion

Avec le 3-way handshake, ça fait 4 mécanismes déjà qui sont implémentés dans le protocole et qui forcément, influent sur la taille des données transmisses dans un segment et le débit de la communication en termes de données utiles. Ajouter à ça un header plus grand et donc, à la longue, plus de données non-utiles générées et transmises, ce qui réduit le débit des données utiles.

UDP, par contre, ne s'embête pas avec tout ça, il envoie des datagrammes au destinataire avec les données utiles. Charge au destinataire d'absorber le trafic reçu et charge à l'émetteur d'envoyer les datagrammes au débit nécessaire pour le bon fonctionnement de l'application qui repose sur UDP. Pas de synchronisation, de retransmission ou de contrôle, simplement un checksum pour assurer l'intégrité du datagramme. C'est plus ou moins du Fire & Forget: une fois le datagramme envoyé, ce n'est plus la responsabilité de l'émetteur.

Il faut bien comprendre que ces protocoles ont été conçus il y a maintenant quelques dizaines d'années. Un temps où les technologies de l'information et des communications étaient très loin d'offrir les mêmes performances qu'actuellement. Notamment, pas de 4G, 5G ou de fibre optique. D'où l'intérêt d'avoir un protocole aussi robuste que TCP, capable de faire abstraction des systèmes physiques de télécommunications et de leurs relatives fiabilités pour l'époque.

Dans un mode de streaming non live, on veut pouvoir avoir toutes les données (t'as pas envie de voir que la moitié de la vidéo), il est plus intéressant dans ce cas d'utiliser TCP pour assurer que toutes les données seront reçues et pouvoir aussi émettre et recevoir à un rythme qui satisfait l'émetteur et le récepteur tout en s'adaptant aux changements et perturbations sur le réseau. Sachant qu'ensuite, on peut rajouter d'autres mécanismes et systèmes de contrôles dans le protocole applicatif.

Dans le streaming live, en réalité, on a pas besoin d'avoir du temps réel, on peut simplement mettre un buffer et mettre un délai de quelques secondes à quelques minutes pour laisser le temps d'avoir un buffer assez conséquent pour avoir offrir à l'utilisateur une expérience satisfaisante. Là aussi, c'est un peu comme la streaming non live au final. Juste que si le débit est vraiment trop faible, il faut dégrader la qualité ou alors augmenter le buffer (ce qui se fait au détriment de l'expérience utilisateur). C'est un choix, on pourrait faire le choix d'UDP et laisser le protocole applicatif assurer les fonctions de contrôles nécessaires. Cependant, vu que TCP le fait très bien, pourquoi s'embêter?

Vient la question des applications en temps réel: VoIP, vidéoconférence, remote desktop, etc... Ces applications ont besoin d'une latence très faible, quand tu parles avec quelqu'un, tu ne peux pas avoir de buffer par exemple, ça doit sembler complètement interactif et similaire à la «vraie vie». De même, les paquets qui sont perdues n'ont pas besoin d'être retransmis dans ce cas, leurs données ne serviront à rien de toute manière (l'application ne va pas revenir en arrière dans la communication). De base, on utilise UDP pour ce type d'application, parce que c'est typiquement un cas d'usage d'UDP. Pour ce qui est du contrôle et de la qualité de service, la VoIP par exemple, implémente des protocoles au niveau applicatif.  Pour la vidéoconférence (type Zoom, Teams, etc...), c'est un peu le même principe que la VoIP sauf qu'on rajoute la vidéo en plus. Pareil de manière générale, c'est UDP qui est choisi. Cependant, certaines applications, comme celle de Shadow Cloud Computing qui offre un PC dans le cloud avec une connexion en remote desktop, permettent de choisir le protocol de transport: UDP ou TCP. Et pour avoir tester les deux en étant derrière une connexion internet par la fibre, je n'ai remarqué aucune différence notable.

En bref, si les performances réseaux de ta connexion sont suffisantes, UDP ou TCP, tu ne feras pas la différence.  Aujourd'hui, les technologies de télécommunications sont assez évoluées pour offrir des performances qui effacent partiellement voir même tout simplement complètement le désavantage  « lourdeur » de TCP comparé à UDP. De plus en plus d'applications préfèrent se reposer sur TCP pour simplifier l'architecture et l'implémentation de(s) protocole(s) applicatif(s).

-
Edité par KoaTao il y a environ 12 heures

Il y a beaucoup de choses à dire sur TCP, la doc du protocole est très longue et de nombreuses études ont été réalisées dessus. Il faudrait passer des heures et des heures à l'étudier pour en faire le tour.

Je ne parlerais pas d'obsolescence d'UDP encore. Dans certaines situations, UDP reste très utile. Par exemple, pour les VPN, on souhaite souvent éviter l'encapsulation de TCP dans TCP car ça peut rapidement dégrader les performances. UDP ne sera jamais obsolete je pense car c'est vraiment la façon la plus basique et simple de concevoir un protocole de transport.

Enfin, je dirais que je ne parle que dans le contexte de l'utilisation de la pile TCP/IP. Certaines applications justement utilisent d'autres protocoles réseaux pour avoir de meilleures performances notamment en termes de latence (c'est le cas pour certains équipements IoT qui ont besoin d'avoir des temps de latences très très faibles).