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?
La distance physique affecte-t-elle la vitesse de téléchargement?
Réponses:
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.
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.
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 ...
Selon Andrew Martin, la réponse est oui
