Quelle est la taille minimale d'un paquet TCP

9

Un post ici:

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

indique que "Le plus petit téléchargement que les navigateurs peuvent faire est de 1 Ko".

Est-ce dû à la taille minimale d'un paquet sur le réseau? Si non, quelle en est la raison (si c'est vrai)?

— Andy Hume
source

2

Tenez-vous-en aux termes standard si vous voulez éviter toute confusion. "Paquet" est un terme de niveau IP. Vous dites "paquet IP", ni "paquet TCP", ni "paquet Ethernet".

— vtest

La phrase que vous citez ("Le plus petit téléchargement que les navigateurs peuvent faire est de 1 Ko") n'est certainement pas vraie - il n'y a pas de taille minimale de téléchargement; et tandis que là est une taille de paquet TCP / IP minimale (comme expliqué par @ DMA57361), ce n'est certainement pas 1 Ko.

— Piskvor

20

Paquet Le terme est ambigu ici car il est parfois mal utilisé de faire référence à différents éléments pour votre transmission. Permet de voir en quoi vos données sont condensées et vous verrez ce que je veux dire et espérons obtenir la réponse souhaitée:

Supposons que vous envoyez 1 octet de données ¹ sur internet, sur le Modèle TCP / IP .

le Les données commence au niveau de l'application et doit être inséré dans les en-têtes des niveaux inférieurs afin de pouvoir le faire circuler.

Premièrement, les données sont emballées dans un Segment TCP , qui ajoute un en-tête de 20 octets (taille minimale maintenant de 21 octets).
Cela nous met sur le niveau de transport.

Ceci est ensuite emballé dans un Paquet IP , qui ajoute un autre en-tête de 20 octets (taille minimale maintenant de 41 octets).
Maintenant nous sommes au niveau internet.
Notez que cette modification est modifiée à chaque fois qu'un nouveau routeur transfère vos données vers un nouveau sous-réseau.

Ceci est enveloppé dans un lien Cadre de type - dont la taille de l'en-tête et du pied de page varie en fonction du type de trame utilisé, lequel dépend du type de lien utilisé.
C'est au niveau des liens.
Ce bouclage est modifié chaque fois que l'unité est transmise entre deux entités.

Enfin, la transmission physique (par exemple, les signaux électriques sur un câble, les ondes radio, etc.).

Voici quelques images informatives disponibles sur Wikipedia Modèle TCP / IP page qui aide à expliquer visuellement ce qui se passe:

Data encapsulation using UDP/IP

Connection via layers in the TCP/IP model

^{1. Je suppose que vous pourrez peut-être envoyer 0 octet ... mais vous n'avez pas vérifié cela. En fait, je n'ai pas vérifié si 1 octet est autorisé non plus, mais hé.}

— DMA57361
source

4

C'est inexact, il n'y a pas de taille minimale pour un téléchargement. Vous pouvez le vérifier en créant un fichier minuscule sur votre serveur Web et en utilisant Wireshark pour surveiller le trafic réseau lorsque vous téléchargez ce fichier.

La taille minimale d'un paquet Ethernet standard est de 64 octets.

— shapr
source

3

À première vue, le blog que vous citez est incorrect. Il n'y a pas de "taille minimale de téléchargement" pour HTTP. (Et votre théorie sur la taille minimale des paquets est également incorrecte.)

Cependant, il y a un grain de vérité à cela. Et c’est-à-dire que si la taille du fichier que vous téléchargez est suffisamment petite, le message de réponse HTTP (composé du fichier et des en-têtes de réponse HTTP) s’intégrera dans un seul paquet réseau. Si cela se produit, le navigateur obtiendra probablement le fichier plus rapidement que s'il lui fallait deux paquets ou plus pour envoyer la réponse.

(Avec un paquet dans la réponse, il y a moins de chance qu'un paquet soit abandonné et doive être renvoyé, et plus probable que la fenêtre de contrôle de flux TCP / IP n'augmente pas les délais d'aller-retour supplémentaires pour l'accusé de réception. )

La taille maximale typique d'un paquet envoyé / reçu (la MTU) est de 1500 octets pour Ethernet. Lorsque vous prenez en compte les frais généraux IP et TCP, ainsi que la taille d'un en-tête de réponse HTTP typique, vous risquez de vous laisser environ 1 Ko pour les données de fichier dans le premier paquet d'une réponse. D'où le grain de vérité dans le commentaire du blogueur.

— Stephen C
source

Ce serait correct - si vous ne téléchargiez qu'une seule image, et non, par exemple, une page Web et ses ressources associées (images, JS, CSS) -, dans ce cas, vous utilisez keepalives et pipelining pour plusieurs ressources de toute façon, alors TCP les frais généraux et la taille des paquets sont beaucoup moins pertinents. Vous ont raison dans ce cas particulier (téléchargement d'une seule image), mais à quelle fréquence cela se produit-il? Il semble que le blogueur soit bloqué en 1999, chaque requête HTTP nécessitant sa propre connexion TCP.

— Piskvor

1

C'est pire que tu ne le penses.

Le chargement lent de la page est dû au fait que le navigateur rencontre des problèmes pour rendre le 1x1 pixel 800 000 fois (par exemple, pour une fenêtre de navigateur définie sur 1000x800). Il y a de nombreuses années, peut-être même en 1999, j'ai lu un article quelque part qui prescrivait 16x16 comme étant le «plus rapide» x le plus petit pour le pavage. Bien sûr, le rendu peut être différent maintenant.

Si vous lisez l'article du blog, la plainte porte sur le chargement lent des pages. Le téléchargement n'est pas lent. Cela n'a rien à voir avec les paquets bien que sa discussion ait été intéressante.

Alors peut-être que la question devrait être reformulée.

— mockman
source

Dans ce cas, j’ai peut-être mal compris l’article du blog - j’ai pensé que le cœur de cette phrase est le suivant: "Le plus petit téléchargement que les navigateurs peuvent faire est de 1 Ko [et donc, ajustez la taille de votre image à 1 Ko]" J'ai lu comme "... parce que vous transmettez quand même 1K octets, peu importe que votre image ne soit que 50 octets" (ce qui est un non-sens évident). Le problème ici peut utiliser " size "les deux pour les dimensions en pixels et pour le nombre d'octets, et les confondre. Votre explication a un sens, mais n’est pas pertinente pour compter le nombre d’octets d’image (contrairement à ce que dit le blog).

— Piskvor

Après avoir relu le billet du blog, il semble dévier du fait que le troisième paragraphe est incohérent.

— mockman

Après avoir relu votre commentaire ... Son objectif est de résoudre le problème soulevé dans le paragraphe d'introduction. Cependant, il attribue par erreur ce problème à la taille des paquets et y consacre le reste de la publication. Ma réponse expliquait la raison du lent chargement de la page. Comme d'autres l'ont souligné, les caractéristiques des paquets ne sont pas la cause.

— mockman