La distance physique affecte-t-elle la vitesse de téléchargement?

22

Je viens de me disputer avec un de mes collègues et j'ai pensé que j'allais simplement contacter les experts à ce sujet. Voici le scénario. Nous utilisions un site Web qui mesure la vitesse de votre connexion. Nous avons testé en utilisant un serveur qui est loin de nous (nous sommes en Malaisie et le serveur était aux USA). C'était environ 2 Mbps. Ensuite, nous avons essayé avec un serveur à Singapour et c'était beaucoup plus rapide (environ 15 Mbps). Mon collègue pensait que c'était à cause de la distance physique alors que je ne pense pas que cela soit important. Ma compréhension est qu'une fois que vous avez fait la poignée de main initiale et que le flux de données a commencé, peu importe où se trouve le serveur et le résultat devrait être presque le même. Est-ce que j'ai râté quelque chose? Comment ça marche vraiment?

Navid
la source
2
Vous pouvez le confirmer vous-même trivialement. Envoyez une requête ping au serveur pour acquérir la latence. Puis 2Mbps * Latence == Fenêtre. Vous pouvez confirmer la taille réelle de la fenêtre avec Wireshark. Mais supposons que vous n'ayez pas de mise à l'échelle de la fenêtre, alors c'est 64 Ko / 2 Mbps = 256 ms, donc je prédis que votre serveur sera à 256 ms.
ytti
2
@ytti décrit indirectement le BDP (produit à retard de bande passante) qui se traduit grosso modo en réseaux longs (retard), gros (bande passante) étant plus difficiles à maintenir pleins et rien de moins mange loin de votre débit potentiel. Voir en.wikipedia.org/wiki/Bandwidth-delay_product .
generalnetworkerror
2
@ytti, Windows Vista et versions ultérieures ont la mise à l'échelle de la fenêtre par défaut ... nous devons savoir quel OS Navid utilise pour le test
Mike Pennington
Selon ce support, la mise à l'échelle (facteur 8) de microsoft.com/kb/934430 est par défaut dans Vista, mais uniquement pour les non-HTTP. Je ne suis pas moi-même un utilisateur de Windows, je ne peux donc pas le vérifier.
ytti
2
@ytti, je ne suis pas sûr que ce soit pertinent. J'exécute Vista, et je regarde un reniflement de ma connexion HTTP à cette page de support, et le TCP SYN dit: "Échelle de fenêtre: 2 (multipliez par un facteur 4)"
Mike Pennington

Réponses:

23

Mon collègue pensait que c'était à cause de la distance physique alors que je ne pense pas que cela soit important. Ma compréhension est qu'une fois que vous avez fait la poignée de main initiale et que le flux de données a commencé, peu importe où se trouve le serveur et le résultat devrait être presque le même. Est-ce que j'ai râté quelque chose? Comment ça marche vraiment?

Vous avez tous deux eu raison à un moment donné de l'histoire, mais votre compréhension est généralement correcte ... aujourd'hui :). Il y a quelques facteurs qui ont changé entre l'ancienne réponse de votre ami et les capacités que nous avons aujourd'hui.

  • Mise à l'échelle de la fenêtre TCP
  • Réglage du tampon d'hôte

La différence dans les résultats que vous avez pu voir pourrait avoir été affectée par:

  • Perte de paquets
  • Transferts TCP parallèles

Mise à l'échelle de la fenêtre TCP: l'effet de retard de la bande passante

Comme votre ami l'a mentionné, les anciennes implémentations de TCP souffraient des limites imposées par la taille de la fenêtre de réception 16 bits d'origine dans l'en-tête TCP (réf RFC 793: section 3.1 ); RWIN contrôle combien de données non acquittées peuvent attendre dans un seul socket TCP. RWIN 16 bits valorise les chemins Internet limités avec des produits à retard de bande passante élevé (et la plupart des connexions Internet à large bande passante d'aujourd'hui seraient limitées par une valeur 16 bits).

Pour les valeurs RTT élevées, il est utile d'avoir un RWIN très grand. Par exemple, si votre chemin RTT de la Malaisie aux États-Unis est d'environ 200 ms, le TCP RWIN d'origine vous limiterait à 2,6 Mbps.

Débit max = Rcv_Win / RTT

* Débit max = 65535 * 8 / 0,200 *

Débit max = 2,6 Mbps

La RFC 1323 a défini certaines "options TCP" pour surmonter ces limitations; l'une de ces options TCP est la "mise à l'échelle des fenêtres". Il introduit un facteur d'échelle, qui multiplie la valeur RWIN d'origine, afin d'obtenir la valeur complète de la fenêtre de réception; l'utilisation des options de mise à l'échelle de la fenêtre autorise un RWIN maximal de 1073725440 octets. Appliquer les mêmes calculs:

Débit max = Rcv_Win / RTT

* Débit max = 1073725440 * 8 / 0,200 *

Débit max = 42,96 Gbps

Gardez à l'esprit que TCP augmente RWIN progressivement pendant la durée d'un transfert, tant que la perte de paquets n'est pas un problème. Pour voir des taux de transfert vraiment importants sur une connexion à retard élevé, vous devez transférer un fichier volumineux (afin que TCP ait le temps d'augmenter la fenêtre) et la perte de paquets ne peut pas être un problème pour la connexion.

Perte de paquets

Les circuits Internet à travers l'océan Pacifique sont parfois assez encombrés. Certains membres de ma famille vivent à Taïwan, et nous rencontrons régulièrement des problèmes lorsque nous utilisons Google Talk avec eux. Je constate souvent une perte de paquets supérieure à 0,5% lorsque je envoie une requête ping à leur ligne DSL depuis les États-Unis; si vous voyez quelque chose comme une perte de 0,5% sur le serveur "plus lent", cela limiterait très facilement le débit sur un seul socket TCP.

Flux TCP parallèles

Pour info, certains sites Web de test de vitesse utilisent des flux TCP parallèles pour augmenter le débit ; cela peut affecter les résultats que vous voyez, car les flux TCP parallèles augmentent considérablement le débit au cas où vous auriez une perte de paquets sur le chemin. J'ai vu quatre flux TCP parallèles saturer complètement un modem câble de 5 Mbps qui souffrait d'une perte de paquets constante de 1%. Normalement, une perte de 1% réduirait le débit d'un seul flux TCP.

Matériel bonus: réglage du tampon hôte

De nombreuses implémentations de systèmes d'exploitation plus anciennes avaient des sockets avec des tampons limités; avec les anciens systèmes d'exploitation (comme Windows 2000), peu importait que TCP autorise le vol de grandes quantités de données ... leurs tampons de socket n'étaient pas réglés pour tirer parti du grand RWIN. De nombreuses recherches ont été effectuées pour permettre des performances élevées sur les transferts TCP . Les systèmes d'exploitation modernes (pour cette réponse, nous pouvons appeler Windows Vista et plus tard "moderne") incluent de meilleurs mécanismes d'allocation de tampon dans leurs implémentations de tampon de socket.

Mike Pennington
la source
4
En guise de remarque: il existe de nombreux routeurs à l'ancienne qui ralentiront la mise à l'échelle des fenêtres (il y en a moins chaque jour, mais il y en a encore beaucoup) et la réinitialiser à zéro, ce qui réduit considérablement votre bande passante. La probabilité de toucher l'un de ces routeurs cassés augmente avec le nombre de sauts vers la destination, bien que la plupart des fournisseurs d'infrastructure réseau ne devraient pas avoir ce problème de nos jours.
Chris Down
Les routeurs sont des périphériques L3. La mise à l'échelle de la fenêtre TCP est un processus L4. Le routeur transmet le paquet ou non et, à l'exception de l'utilisation des mécanismes de QoS, il n'y a pas de différenciation entre TCP, UDP ou tout autre protocole. Les routeurs ont certainement un effet sur la négociation MSS initiale (..ou le font s'ils abandonnent ICMP inaccessibles) mais l'algorithme de fenêtre coulissante est purement une fonction des piles sur les systèmes d'extrémité.
rnxrx
2
@rnxrx Je suis d'accord, ce serait surtout le FW de pointe qui se mettrait en colère contre les options TCP. Je n'ai pas entendu parler de l'option de mise à l'échelle de la fenêtre TCP du routeur, mais je ne serais pas très surpris si quelqu'un proposait un fournisseur / modèle qui l'avait fait, étant donné qu'il n'est pas rare que les routeurs de périphérie gèrent l'option TCP MSS en transit , ce n'est pas si grand que d'imaginer quelqu'un fscking cela.
ytti
3

Réponse courte: Oui, la distance a un effet sur la bande passante d'un seul flux.

Internet a évolué pour limiter cet effet ... ACK retardé, mise à l'échelle des fenêtres, autres protocoles :-) Mais la physique finit toujours par gagner. Dans ce cas, il est beaucoup plus probable qu'il y ait une congestion générale du réseau sur autant de sauts - il suffit d'un seul paquet abandonné pour tuer un flux TCP.

Ricky Beam
la source
1

Bien qu'il existe déjà d'excellentes réponses à cela, je voudrais ajouter: non, la vitesse n'est pas nécessairement affectée par la distance et oui, très souvent, la vitesse est affectée par la distance sont les deux vraies.

Pourquoi donc?

Fortement simplifié, plus la distance est longue, plus il y a de "sauts" sur le chemin via Internet. La bande passante maximale est déterminée par le saut le plus lent et le trafic simultané. Avec une distance croissante et une distribution quelque peu aléatoire des vitesses de saut, la probabilité d'obtenir des vitesses globales plus lentes augmente. De plus, la physique fait obstacle et l'augmentation de la latence peut également ralentir la liaison.

Mais cela ne doit pas être pris pour acquis. La technologie nous permet de construire une connexion englobant la planète de presque n'importe quelle bande passante souhaitée. Cependant, la bande passante et la distance sont des ennemis et les deux augmentent considérablement le coût de la connexion, ce qui la rend encore moins susceptible d'exister uniquement pour la connexion dont vous pourriez avoir besoin en ce moment.

Bien sûr, c'est trop simplifié, mais en réalité, cette situation est ce que vous trouvez très souvent. Et là encore, vous ne le faites pas quand il y a une connexion étonnamment rapide ou un proxy de distribution juste au coin de la rue - mais quand tout est instantané, nous pensons rarement à la vitesse d'Internet ...

Zac67
la source
-1

Selon Andrew Martin, la réponse est oui

Graphiques

Jonathan
la source
Les réponses avec lien uniquement sont déconseillées. Veuillez fournir des détails qui rendent cette réponse utile sans dépendre de la page Web liée.
Teun Vink
Mec, ce n'est pas seulement un lien de réponse, c'est une image avec des statistiques
Jonathan
Je ne suis pas ton mec. De plus, cette image n'a aucun sens sans explication sur ce qui se trouve sur l'axe Y et comment elle a été mesurée. Et même alors, vous devez expliquer en quoi cette image est une réponse à la question.
Teun Vink
Je ne sais pas pourquoi c'est difficile pour vous, mais les axes X et Y sont étiquetés. "Vitesse de téléchargement moyenne en Mbps"
Jonathan