Auteur Sujet: Pourquoi choix TCP pour mesurer bande passante disponible à un instant T  (Lu 1413 fois)

0 Membres et 1 Invité sur ce sujet

wire

  • Client Orange Fibre
  • *
  • Messages: 19
J'essaye de formaliser une explication sur le fait que c'est le protocole TCP qui est utilisé surtout pour mesurer une bande passante max disponible à
un instant t entre un client et un serveur Iperf.
Je comprends que c'est surtout par rapport à son fonctionnement que la mesure est possible avec ce protocole c'est à dire
que le protocole va aller jusqu'à la perte de paquets et va réguler son débit en deçà de la perte pour obtenir une mesure ?

Qu'en pensez vous ?

merci.

vivien

  • Administrateur
  • *
  • Messages: 29 703
    • Twitter LaFibre.info
Pourquoi choix TCP pour mesurer bande passante disponible à un instant T
« Réponse #1 le: 15 novembre 2017 à 21:41:51 »
TCP est un protocole qui va s'adapter au débit disponible.
C'est pour ca que TCP est utilisé pour tous les téléchargements et les sites web.

UDP est incapable de s'adapter au débit disponible. Il va donc envoyer de paquets au débit indiqué et le reste sera perdu.
UDP n'est utilisable que quand il n'y a pas d'adaptation de débit nécessaire : Par exemple une requête DNS ou un flux TV priorisé d'un opérateur (le débit est fixe).

Les paquets que tu reçois par UDP ne permettent pas d'obtenir le débit utile que tu aura en TCP car de nombreux facteurs peuvent faire influer le débit comme les pertes de paquets ou la gigue.

wire

  • Client Orange Fibre
  • *
  • Messages: 19
Pourquoi choix TCP pour mesurer bande passante disponible à un instant T
« Réponse #2 le: 15 novembre 2017 à 22:18:23 »
merci c'est plus clair que mon explication.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 562
  • FTTH 1Gb/s sur Paris (75)
Pourquoi choix TCP pour mesurer bande passante disponible à un instant T
« Réponse #3 le: 16 novembre 2017 à 12:13:55 »
Je comprends que c'est surtout par rapport à son fonctionnement que la mesure est possible avec ce protocole c'est à dire
que le protocole va aller jusqu'à la perte de paquets et va réguler son débit en deçà de la perte pour obtenir une mesure ?

c'est tout a fait cela.

TCP est plus utilisé simplement parce que c'est le système d'exploitation qui gère le contrôle de débit et la retransmission ce qui simplifie grandement la tache des développeurs d'applications.

Mais rien n’empêche d'utiliser UDP pour faire du transfert ou de la mesure de débit, c'est juste plus compliqué à faire car le programme doit gerer les pertes de paquets, les retransmissions et adapter le débit d’émission en conséquence.
Chrome par exemple fait ceci quand il communique avec les serveurs Web de Google (Search, Docs, Youtube, etc). Il utilise UDP et au dessus le protocol QUIC qui ressemble a TCP mais sans ses défauts.

Ca implique qu'IPerf pourrai avoir un mode "UDP" plus intelligent , capable de trouver le débit max possible tout seul. C'est juste qu'ils n'ont pas pris la peine de l'implèmenter.

On peut donc bien utiliser UDP pour trouver le débit max / utile c'est juste moins simple à faire avec les logiciels actuels.

vivien

  • Administrateur
  • *
  • Messages: 29 703
    • Twitter LaFibre.info
Pourquoi choix TCP pour mesurer bande passante disponible à un instant T
« Réponse #4 le: 16 novembre 2017 à 15:29:43 »
Attention : quand QUIC sera normalisé, il sera normalisé comme une évolution de TCP. (c'est ce que j'ai compris, comme SPDY de Google qui a été normalisé HTTP/2)

Aujourd'hui il utilise UDP au niveau du système d'exploitation, car c'est le seul moyen de faire rentrer un TCP expérimental, mais fondamentalement, QUIC est une grosse évolution de TCP.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 562
  • FTTH 1Gb/s sur Paris (75)
Pourquoi choix TCP pour mesurer bande passante disponible à un instant T
« Réponse #5 le: 16 novembre 2017 à 22:48:25 »
Attention : quand QUIC sera normalisé, il sera normalisé comme une évolution de TCP. (c'est ce que j'ai compris, comme SPDY de Google qui a été normalisé HTTP/2)

Aujourd'hui il utilise UDP au niveau du système d'exploitation, car c'est le seul moyen de faire rentrer un TCP expérimental, mais fondamentalement, QUIC est une grosse évolution de TCP.

c'est pas au meme niveau. QUIC est au dessus d'UDP. TCP est au même niveau qu'UDP (du moins vu des routeurs).
Tu ne peux pas 'remplacer' TCP par un "QUIC sans UDP" sans tout casser niveau compatibilité (et fonctionnement des NAT intermédiaires par exemple). En pratique, l'Internet IPv4 ne sait pas faire autre chose que TCP ou UDP.

Je n'ai pas vu  de 'normalisation' pour QUIC pour le moment. Ce n'est pas la meme chose que ce qui s'est produit avec SPDY et HTTP/2.
Ce qui peut éventuellement arriver ce sont l'intégration de "library" QUIC sur UDP pour les OS (Windows, Linux, Mac,etc) de façon a permettre l’utilisation de QUIC par n'importe quel application.

Idéalement il faudrait s'affranchir d'UDP et utiliser un nouveau 'protocol number' propre a QUIC mais tant qu'on aura IPv4 et son NAT omini-présent ca ne servira a rien.

sur de 'l'IPv6 only' c'est une autre histoire. La on verra peut-etre des choses arriver mais pas pour tout de suite.

 

Mobile View