Taille maximale des paquets pour une connexion TCP


196

Quelle est la taille de paquet maximale pour une connexion TCP ou comment puis-je obtenir la taille de paquet maximale?


24
TCP est basé sur le flux. Y a-t-il une raison particulière pour laquelle vous vous inquiétez des paquets individuels?
Matti Virkkunen

27
Parce que les couches sous-jacentes sont basées sur des paquets ... ) - Utilise un service par paquets en dessous.

2
Il n'y a pas de «paquet TCP». Il existe des segments TCP , dont la longueur est décrite par un mot de 32 bits, et ils sont contenus dans ou entre des paquets IP , dont la longueur est décrite en 16 bits. Il existe également des trames Ethernet, qui contiennent toutes ces choses. Laquelle de ces choses demandez-vous? Dans tous les cas, si vous utilisez TCP, vous n'avez à vous soucier d'aucune d'entre elles: TCP et IP s'occupent de tout pour vous.
Marquis de Lorne

Réponses:


178

La limite absolue de la taille des paquets TCP est de 64 Ko (65 535 octets), mais en pratique, elle est bien plus grande que la taille de tout paquet que vous verrez, car les couches inférieures (par exemple, Ethernet) ont des tailles de paquets inférieures.

La MTU (Maximum Transmission Unit) pour Ethernet, par exemple, est de 1500 octets. Certains types de réseaux (comme Token Ring) ont de plus grandes MTU et certains types ont de plus petites MTU, mais les valeurs sont fixes pour chaque technologie physique.


15
"Mais les valeurs sont fixes pour chaque technologie physique" - ce n'est pas vrai. Ethernet avait auparavant un MTU maximum de 1500, mais vous pouvez en utiliser un plus bas. Avec l'avènement des trames jumbo, il n'y a pas de véritable maximum spécifié, et le maximum varie en fonction du matériel et du pilote.
WhirlWind

4
@Whirl: c'est vrai, ils sont configurables, mais généralement ils ne le sont pas; "configurable" est subjectif car il faudrait se plonger dans le noyau pour le faire. Ce n'est pas quelque chose que l'on peut bricoler au niveau de l'application, où l'OP semble être.
Ether

3
@HiroProtagonist: 1500 est un maximum, donc avoir 600 n'est pas surprenant.
Nicolas Raoul

28
pourquoi est-ce 64K (65535 octets) la limitation? Parce que l'attribut de taille de fenêtre dans l'en-tête TCP n'est que de 16 bits. Je voulais juste mentionner, pourrait aider quelqu'un à un moment donné ..... excellente réponse btw @Ether!
Cacho Santa

2
En outre, il est possible de l'augmenter en utilisant la mise à l'échelle de la fenêtre. Dans ce cas, le maximum est de 1 Gio
Martin Melka

86

C'est une excellente question et j'y rencontre beaucoup au travail en fait. Il y a beaucoup de réponses "techniquement correctes" comme 65k et 1500. J'ai fait beaucoup de travail pour écrire des interfaces réseau et utiliser 65k est idiot, et 1500 peut aussi vous causer de gros ennuis. Mon travail se déroule sur de nombreux matériels / plates-formes / routeurs différents, et pour être honnête, je commence par 1400 octets. Si vous avez besoin de plus de 1400, vous pouvez commencer à avancer progressivement, vous pouvez probablement aller à 1450 et parfois à 1480 pouces. Si vous avez besoin de plus que cela, vous devez bien sûr diviser en 2 paquets, dont il existe plusieurs façons évidentes de le faire.

Le problème est que vous parlez de créer un paquet de données et de l'écrire via TCP, mais bien sûr, les données d'en-tête sont clouées, etc. beaucoup de matériel a des limites inférieures.

Si vous "poussez", vous pouvez obtenir des choses vraiment étranges. Des données tronquées, évidemment, ou des données supprimées que j'ai rarement vues. Les données corrompues se produisent également rarement mais certainement.


Pourquoi les demandes GET font-elles en moyenne environ 600 octets?

10
Vous voulez dire 64K, pas 65K. Je ne sais pas ce que vous entendez par «l'endroit où je commence est 1400 octets». Vous n'avez pas à vous soucier de la taille des paquets dans l'API TCP. Il s'occupe de déterminer et d'observer le chemin MTU. Il n'y a aucune raison pour que vous ne puissiez pas écrire 2G en un send()si c'est pratique.
Marquis de Lorne le

19
Votre 1480'ishdevrait l'être 1460. L'en-tête IP et l'en-tête TCP occupent au moins 20 octets chacun (à moins que des champs d'en-tête facultatifs ne soient utilisés) et donc le maximum pour (trame non Jumbo) Ethernet est 1500 - 20 -20 = 1460.
Eugene Beresovsky

2
J'ai vu via Wireshark qu'un serveur envoie de gros paquets (plus de 1400 octets) et que le client le reçoit démonté en quelques paquets de 1400 octets maximum. qui est responsable du démontage du paquet? @NekData ...?
inbaly

2
@EugeneBeresovsky bien avec les en-têtes optionnels c'est + jusqu'à 40 octets de plus, mais c'est variable donc 1420 semble la limite. avec la suggestion de 1400, vous obtenez un peu de rembourrage. je vais aller avec 1408 car il est divisible par 128
Garet Claborn

22

Au niveau de l'application, l'application utilise TCP comme protocole orienté flux. TCP à son tour a des segments et résume les détails de l'utilisation des paquets IP non fiables.

TCP traite les segments plutôt que les paquets. Chaque segment TCP a un numéro de séquence qui est contenu dans un en-tête TCP. Les données réelles envoyées dans un segment TCP sont variables.

Il existe une valeur pour getsockopt prise en charge sur certains systèmes d'exploitation que vous pouvez utiliser, appelée TCP_MAXSEG, qui récupère la taille de segment TCP maximale (MSS). Il n'est cependant pas pris en charge sur tous les systèmes d'exploitation.

Je ne sais pas exactement ce que vous essayez de faire, mais si vous voulez réduire la taille de la mémoire tampon utilisée, vous pouvez également examiner: SO_SNDBUF et SO_RCVBUF.


Je me demande si vous pouvez utiliser TCP comme file d'attente de messages si vous pouvez ranger tous vos messages dans un grand paquet TCP?
CMCDragonkai


4

Il n'y a pas de paquets dans l'API TCP.

Il y a souvent des paquets dans les protocoles sous-jacents, comme lorsque TCP est fait sur IP, ce qui ne vous intéresse pas, car ils n'ont rien à voir avec l'utilisateur, sauf pour des optimisations de performances très délicates qui ne vous intéressent probablement pas (selon le formulation de la question).

Si vous demandez quel est le nombre maximal d'octets que vous pouvez send()dans un appel d'API, cela dépend de l'implémentation et des paramètres. Vous appelez généralement send () pour des segments pouvant aller jusqu'à plusieurs kilo-octets et vous êtes toujours prêt à ce que le système refuse de l'accepter totalement ou partiellement, auquel cas vous devrez gérer manuellement le fractionnement en morceaux plus petits pour alimenter vos données dans le fichier. API TCP send ().


8
TCP a des paquets, ainsi qu'un en-tête de paquet, dont une partie chevauche l'en-tête IP. Ce n'est pas parce que vous n'êtes pas censé le voir que cela n'existe pas. TCP se fait toujours sur IP. Vous ne pouvez pas le faire sans IP car les en-têtes se chevauchent.
WhirlWind

23
@WhirlWind TCP a des segments. IP a des paquets.
Marquis de Lorne le

1
TCP a des segments (ou appelez-les des paquets, c'est ok). L'API TCP n'a pas de paquets.
Pavel Radzivilovsky

13
@NathanLong Le mal est que vous causez une confusion inutile. TCP a des segments, UDP a des datagrammes, IP a des paquets, Ethernet a des trames, ...
Marquis de Lorne

1
@Chexxor Alors quel langage allez-vous utiliser pour décrire les segments TCP à l'intérieur des paquets IP à l'intérieur des trames Ethernet? Il n'est nullement nécessaire de confondre le problème en utilisant le même terme pour différentes choses, lorsque les auteurs de ces choses ont eu beaucoup de mal à utiliser des termes différents.
Marquis de Lorne

3

En général, cela dépend de l'interface que la connexion utilise. Vous pouvez probablement utiliser un ioctl () pour obtenir le MTU, et s'il s'agit d'Ethernet, vous pouvez généralement obtenir la taille de paquet maximale en soustrayant la taille de l'en-tête matériel de celle-ci, qui est 14 pour Ethernet sans VLAN.

Ce n'est le cas que si la MTU est au moins aussi grande sur le réseau. TCP peut utiliser la découverte de MTU de chemin pour réduire votre MTU efficace.

La question est, pourquoi vous en souciez-vous?


6
Cela ne vous donnera que la taille maximale des paquets sur le premier lien. Pour autant que je sache, tout autre noeud le long de la route est autorisé à ne pas aimer les gros paquets et il pourrait être divisé n'importe où le long du chemin.
Matti Virkkunen

Oui, c'est vrai ... donc votre question est bonne - pourquoi voudriez-vous cela?
WhirlWind

Je veux transmettre des vidéos / images via une connexion LAN
Alexa

1
Puisque TCP est orienté flux, pourquoi est-ce important?
WhirlWind

3

Si vous utilisez des machines Linux, "ifconfig eth0 mtu 9000 up" est la commande pour définir le MTU d'une interface. Cependant, je dois dire que le gros MTU a des inconvénients si la transmission réseau n'est pas aussi stable et qu'il peut utiliser plus de mémoires d'espace noyau.


3

Il semble que la plupart des sites Web sur Internet utilisent 1460 octets pour la valeur de MTU. Parfois, c'est 1452 et si vous êtes sur un VPN, cela baissera encore plus pour les en-têtes IPSec.

La taille de fenêtre par défaut varie considérablement jusqu'à un maximum de 65 535 octets. J'utilise http://tcpcheck.com pour consulter mes propres valeurs IP source et vérifier ce que les autres fournisseurs Internet utilisent.


2

Une solution peut être de définir l'option de socket TCP_MAXSEG ( http://linux.die.net/man/7/tcp ) sur une valeur qui est "sûre" avec le réseau sous-jacent (par exemple définie sur 1400 pour être sûre sur Ethernet), puis utiliser un grand tampon lors de l'envoi d'un appel système. De cette façon, il peut y avoir moins d'appels système coûteux. Le noyau divisera les données pour correspondre à MSS.

De cette façon, vous pouvez éviter les données tronquées et votre application n'a pas à se soucier des petits tampons.


2

La taille de paquet pour un paramètre TCP dans le protocole IP (Ip4). Pour ce champ (TL), 16 bits sont alloués, la taille maximale du paquet est donc de 65 535 octets: Détails du protocole IP

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.