Téléchargement lent sur Mac par rapport à Windows sur Mac en réseau

Le service de capture de paquets le plus proche de nous est probablement CloudShark.

Les réinitialisations sont intéressantes, et peuvent être une cause de votre lenteur perçue sur les machines OS X. Pour expliquer pourquoi, nous devons entrer dans un peu de détails sur la façon dont les vitesses sont sélectionnées. Ceci est basé sur Fenêtres coulissantes TCP avec un accompagnement de produit de retard de la bande passante .

Le débit absolu d'une connexion réseau donnée est déterminé par quelques facteurs :

• La vitesse à laquelle les paquets peuvent être transmis.
• Le temps que mettent les paquets pour arriver à destination.
• La quantité de données que l'expéditeur est prêt à laisser en suspens (sans accusé de réception).

Une connexion 1GbE traversant les États-Unis présente une latence unidirectionnelle d'environ 80 ms. Puisque les accusés de réception sont un facteur ici, nous devons compter leur temps de retour. On parle donc d'un temps de retour de 160 ms. Une connexion 1GbE peut avoir 20 Mo de données "en circulation" pendant ces 160 ms (1024 Go x 0,16 seconde) si elle transmet à pleine vitesse.

Lorsqu'une connexion TCP est négociée, l'un des paramètres sur lesquels les deux parties s'accordent est la taille de la fenêtre TCP. Il s'agit du troisième point : la quantité de données que la partie émettrice est disposée à laisser en suspens par rapport à la taille du tampon de la partie réceptrice pour recevoir les données. À mesure que les données sont transmises, les deux parties émettent des mises à jour sur la taille de la fenêtre qu'elles sont prêtes à tolérer. Pour les réseaux rapides et propres, cette fenêtre peut être assez grande.

Mais, si la connexion est rétablie pour une raison quelconque, le processus recommence avec les tailles de fenêtre initiales. Si la fenêtre est pleine, le côté émetteur cessera d'envoyer jusqu'à ce que les ACK lui parviennent. Vous commencez à comprendre pourquoi les réinitialisations de connexion peuvent causer des problèmes de performance.

Il y a un autre aspect que je veux mentionner, car je l'ai déjà vu causer ce genre de problème auparavant. Vous n'avez pas dit que vous l'aviez vu, mais si vous regardez, vous pouvez les voir. Retransmissions.

L'un des ajouts à TCP par rapport à la spécification initiale est que Remerciements sélectifs . Ceci entre en jeu s'il y a des pertes de paquets, pas des réinitialisations de connexion. Sans les SACKs, si cette connexion de 1Gb, 160ms RTT dont j'ai parlé plus haut a une chute de paquet, la partie réceptrice restera là et laissera tomber 20MB de données sur le sol avant que la partie émettrice ne renvoie tout ce qui se trouve dans le paquet tombé. Ce type de comportement convenait au type de réseaux que nous avions en 1989, mais nos réseaux actuels sont beaucoup plus rapides et plus gros. Les SACKs permettent à la partie réceptrice de dire "J'ai vu jusqu'à l'horodatage 123, et 125-137", ce qui permet à la partie expéditrice de ne retransmettre que le segment 124 manquant et de continuer avec le reste.

J'ai définitivement Nous avons vu des cas où l'absence de support SACK sur une connexion entraîne des débits tout simplement terribles. Une fois qu'ils ont été activés des deux côtés, les performances ont atteint leur maximum théorique.

L'indice de ce problème se trouve dans la poignée de main initiale à trois voies du TCP. Vous devriez voir SACK dans l'en-tête des options des deux côtés. Si les machines OSX ne l'émettent pas, mais que Windows le fait, vous avez un indice important de votre problème.