Le Maximum Transmission Unit (MTU) est la plus grande taille de paquet qu'un lien réseau peut transporter sans fragmentation, et la valeur par défaut standard pour la plupart du trafic Internet est de 1 500 octets. En termes pratiques, le paramètre MTU détermine combien de données votre interface peut placer dans un seul paquet avant que le réseau ne doive le diviser ou le rejeter.
Vous pouvez avoir une connexion proxy saine, des IP tournantes et un tableau de bord d'automatisation réactif, mais voir quand même des pages individuelles échouer, des téléchargements se bloquer ou des sessions de connexion disparaître. La cause est souvent un désaccord sur la taille des paquets entre un centre de données ou un segment VPN à MTU élevé et un chemin mobile à MTU plus bas. Votre scraper n'est pas nécessairement lent. Il peut envoyer des paquets qu'un lien caché ne peut pas transporter.
Pourquoi votre scraper échoue même lorsque la connexion semble correcte
Un travail de scraping peut passer son contrôle de santé et échouer encore sur un travail réel. Le proxy s'authentifie, la cible répond et la première page se charge. Ensuite, une réponse plus grande, une soumission de formulaire ou une demande riche en médias se bloque pendant que d'autres destinations continuent de fonctionner.
Ce schéma induit en erreur les équipes car les indicateurs évidents semblent normaux. Le DNS fonctionne, le socket s'ouvre et la rotation des IP se comporte comme prévu. L'échec semble spécifique à la destination ou à la session, mais le problème sous-jacent peut être un paquet qui dépasse le plus petit MTU quelque part entre votre travailleur, le proxy, le réseau de transport et la cible.
Règle pratique : Si les petites requêtes fonctionnent mais que les transferts plus importants se bloquent, examinez la taille des paquets avant de blâmer la bande passante ou la rotation du proxy.
Le même proxy peut donc sembler fiable dans un test et instable en production. Un chemin de centre de données peut supporter des paquets plus grands localement, tandis qu'un tunnel VPN ou un itinéraire cellulaire impose une limite plus petite. Si l'expéditeur ne prend pas connaissance de cette limite, des paquets surdimensionnés peuvent être fragmentés, rejetés ou retransmis plusieurs fois.
La question pratique derrière ce qu'est un paramètre MTU n'est pas seulement "quel nombre devrais-je entrer ?" C'est de savoir si la taille du paquet reste sûre sur l'ensemble du chemin que votre automatisation utilise.
Définir le paramètre MTU et sa fonction principale
Un paramètre MTU est la taille maximale de paquet qu'une interface peut transmettre sur un lien sans fragmentation. Le paramètre appartient à une interface réseau, donc votre ordinateur portable, hôte proxy, adaptateur VPN, conteneur, routeur et passerelle cellulaire peuvent tous avoir des limites différentes.
Dans l'Ethernet standard, le MTU largement adopté est de 1 500 octets. Ce nombre décrit la charge utile transportée par la trame Ethernet, et non la trame complète sur le fil. Une trame Ethernet II standard totalise 1 518 octets, combinant la charge utile de 1 500 octets avec 14 octets d'en-tête et 4 octets de surcharge de séquence de contrôle de trame, comme documenté dans l'explication d'AWS sur le MTU réseau.
Que se passe-t-il lorsque les données atteignent la limite
Votre application crée des données. Les protocoles de transport tels que TCP ou UDP enveloppent ces données, IP ajoute son en-tête, et l'interface place le paquet résultant dans une trame. Le MTU fixe le plafond pour le paquet transporté sur ce lien.
Pour un chemin Ethernet standard, un MTU de 1 500 octets laisse 1 460 octets pour la charge utile TCP, après avoir pris en compte un en-tête IP de 20 octets et un en-tête TCP de 20 octets, selon les conseils de Cisco sur le MTU et le MSS TCP. Si un paquet est trop grand pour l'interface sortante, le réseau doit soit le fragmenter, soit le rejeter, selon le protocole et la configuration.
Cette distinction vous donne un vocabulaire utile pour le dépannage :
- MTU d'interface : Le plus grand paquet qu'une interface spécifique peut transporter sans fragmentation.
- MTU de chemin : Le plus grand paquet qui peut traverser l'ensemble du chemin en toute sécurité.
- Fragmentation : Diviser un paquet surdimensionné en morceaux plus petits.
- MSS : La limite de charge utile TCP négociée entre les points de terminaison.
La valeur par défaut survit car elle offre une large compatibilité à travers les réseaux d'accès Internet. Des trames plus grandes peuvent être efficaces sur un réseau interne contrôlé, mais elles deviennent risquées lorsqu'un tunnel, un lien de transport, un pare-feu ou un dispositif intermédiaire supporte moins.
Comment le MTU impacte la latence, le débit et la fragmentation
Le MTU affecte la performance par le nombre de paquets et la gestion des échecs. Des paquets plus grands transportent plus de charge utile par transmission, réduisant généralement la surcharge du protocole et le nombre de paquets que votre système doit traiter. Des paquets plus petits sont plus faciles à faire passer par des chemins contraints, mais ils utilisent la bande passante de manière moins efficace.
Un désaccord crée le pire résultat. Les conseils MTU d'Alibaba Cloud donnent un exemple clair : un paquet de 2 000 octets traversant un lien MTU de 1 500 octets est divisé en fragments de 1 500 octets et de 500 octets. Le récepteur doit réassembler ces morceaux, et un fragment perdu peut forcer la retransmission des données affectées.
Pourquoi la fragmentation nuit à l'automatisation
La fragmentation ajoute du travail à plusieurs points :
- L'expéditeur ou le routeur divise le paquet.
- Le réseau transporte plusieurs fragments au lieu d'un seul paquet.
- Le récepteur suit et réassemble les fragments.
- Un fragment manquant peut retarder la livraison ou déclencher une retransmission.
Ce traitement supplémentaire peut augmenter la latence et réduire le débit effectif. Il crée également plus d'opportunités pour qu'un pare-feu, un dispositif NAT ou une passerelle de transport gère mal le trafic. Un scraper peut toujours signaler une connexion ouverte pendant que l'application attend un fragment qui n'arrive jamais.
L'erreur opposée consiste à définir des paquets trop petits partout. Des petits paquets évitent de nombreux problèmes de limites de chemin, mais ils augmentent le nombre de paquets et réduisent l'efficacité de la charge utile. Cela peut consommer plus de CPU et créer une surcharge de protocole inutile, surtout pour des transferts soutenus.
Ajustez pour le chemin, pas pour l'interface la plus rapide
Une interface de centre de données à MTU élevé ne rend pas un itinéraire mobile à MTU élevé. Un VPN peut ajouter une surcharge d'encapsulation, et un opérateur cellulaire peut imposer une limite effective plus basse. L'objectif utile est la plus grande taille de paquet qui reste en dessous de chaque limite de lien pertinente.
Mesurez la latence en même temps que le comportement des paquets, et non à la place de cela. Un flux de travail pratique de mesure de latence peut montrer si un changement réduit le délai, mais un résultat de latence propre à lui seul ne prouve pas que des paquets plus grands traversent le chemin de manière fiable.
Pour l'automatisation, évitez de changer le MTU juste pour poursuivre un gain théorique de débit. Identifiez d'abord si les échecs sont corrélés avec des réponses plus grandes, des téléchargements ou un trafic tunnelé. Si c'est le cas, un MTU conservateur, testé de manière cohérente, bat généralement une valeur agressive qui ne fonctionne que sur le segment local.
Comprendre la découverte de MTU de chemin et les valeurs par défaut courantes
L'interface locale ne connaît que sa propre limite. La découverte de MTU de chemin, ou PMTUD, détermine le plus grand paquet qui peut voyager de l'expéditeur à une destination particulière sans fragmentation. Cette valeur peut changer lorsque le chemin change, donc ce n'est pas une propriété universelle de la machine ou du proxy.
La RFC 8201 décrit le PMTU comme étant lié à un chemin spécifique et indique que le PMTU initial est supposé être le MTU du lien de premier saut. La RFC 4821 explique que lorsque des retours ICMP utiles ne sont pas disponibles, les points de terminaison peuvent sonder avec des paquets de plus en plus grands pour découvrir une taille fonctionnelle.
MTU d'interface contre MTU de chemin
Considérez un hôte de travail avec une interface locale configurée pour 1 500 octets. Sa demande entre dans un VPN, traverse une passerelle proxy, voyage à travers un réseau de transport et atteint une destination. La taille de paquet sûre est régie par la plus petite limite effective le long de ce chemin.
La situation inverse est plus dangereuse pour les opérations proxy. Un hôte ou un segment de centre de données peut prendre en charge un paquet plus grand, mais un tunnel ou un chemin d'accès mobile peut ne pas le faire. Augmenter la valeur locale n'augmente pas la capacité du chemin distant. Cela peut plutôt produire une fragmentation ou une perte silencieuse lorsque le paquet atteint le saut contraint.
Les trames jumbo appartiennent à des environnements contrôlés où chaque appareil prend en charge la même taille de trame plus grande. Elles ne sont pas un choix par défaut sensé pour un chemin qui inclut des chemins Internet publics, des tunnels tiers ou une infrastructure cellulaire changeante.
Pourquoi le PMTUD peut sembler incohérent
Le PMTUD repose sur la communication entre les points de terminaison et les dispositifs réseau concernant les limites de paquet. Si le retour d'information est bloqué ou perdu, l'expéditeur peut continuer à utiliser une taille inappropriée. Le résultat est une connexion qui s'établit avec succès mais qui se bloque une fois que l'application envoie des charges utiles plus grandes.
Utilisez des tests séparés pour :
- Capacité de l'interface locale, qui confirme le MTU configuré.
- Capacité du chemin, qui teste les paquets le long du chemin réel.
- Comportement de l'application, qui confirme que le proxy et la cible gèrent des transferts plus importants.
Un petit ping fonctionnel ne libère pas le chemin. Il prouve seulement qu'un petit paquet a fait le trajet. Pour le scraping, le test pertinent est de savoir si les modèles de demande et de réponse utilisés par le travail restent en dessous de la limite effective du chemin.
Proxies Mobiles, CGNAT et Contraintes Réseau Uniques
Un scraper peut fonctionner de manière fiable via un proxy de centre de données, puis se bloquer sur une sortie mobile même lorsque les deux connexions semblent saines. La différence est souvent le MTU effectif du chemin, et non le temps de réponse du proxy.
Un proxy de centre de données utilise généralement une infrastructure avec des interfaces prévisibles et un réseau local contrôlé. Un proxy résidentiel sort par une connexion d'accès domestique ou fixe, donc le fournisseur d'accès et le routeur local façonnent le chemin. Un proxy mobile utilise une connexion cellulaire 4G ou 5G, avec un routage de transporteur et un NAT entre le dispositif proxy et l'Internet public.
Les proxies mobiles fonctionnent souvent derrière un NAT de niveau opérateur, ou CGNAT. De nombreux abonnés partagent un plus petit pool d'adresses IPv4 publiques. La conception partagée peut également introduire des couches de transfert supplémentaires et des variations de chemin, donc l'adresse publique seule ne décrit pas le chemin réseau.
Pourquoi le type de proxy change le problème du MTU
Un lien de centre de données ou VPN peut prendre en charge un MTU Ethernet familier. Un chemin mobile peut avoir une limite effective plus basse car le trafic traverse une infrastructure d'accès radio, des réseaux de transporteurs, un NAT, et parfois un tunnel avant d'atteindre la cible. L'encapsulation consomme de l'espace d'en-tête. Les paquets qui s'adaptent au lien d'origine peuvent donc dépasser la limite du chemin mobile.
L'échec peut être silencieux. Une connexion peut s'établir, de petites demandes peuvent réussir, et des réponses plus grandes peuvent se bloquer lorsque le retour d'information sur le MTU du chemin est bloqué ou qu'un paquet est rejeté. Testez le chemin complet plutôt que de copier une valeur d'interface de centre de données dans une configuration mobile ou VPN. Un chemin utilisant la connectivité LTE peut rester utilisable tout en nécessitant une taille de paquet sûre plus petite.
Choix de transport et de ciblage
Le choix de transport est important car une encapsulation supplémentaire réduit la charge utile disponible pour l'application. SOCKS5 peut transporter du trafic au-delà des demandes web ordinaires, donc son profil de trafic peut exposer des problèmes de MTU qu'une simple demande de navigateur ne fait pas. Tenez compte de la couche proxy, des frais généraux VPN et de tout autre tunnel lors du test de la taille des paquets.
Le ciblage peut changer le chemin. La sélection de pays, de ville ou d'ASN peut placer une demande sur un autre transporteur ou réseau d'accès. Un ASN, ou numéro de système autonome, identifie le domaine de routage d'un opérateur réseau. Deux cibles avec le même paramètre de pays peuvent toujours utiliser des chemins différents et montrer des comportements de MTU différents.
Gardez la rotation IP séparée des tests de paquets. La rotation change l'identité de sortie et peut changer le chemin, tandis qu'une session persistante maintient les demandes connexes sur une seule identité proxy pour un flux de travail défini. Pour la gestion des comptes, la vérification des annonces ou le QA dépendant de la géolocalisation, un routage cohérent compte souvent plus que le changement d'identité à chaque demande. Testez le comportement de session et la stabilité du chemin ensemble.
Comment Vérifier et Changer le MTU sur les Principaux Systèmes d'Exploitation
Commencez par vérifier l'interface qui transporte le trafic. Une valeur locale est une preuve concernant un lien, pas une preuve de la limite du chemin.
Windows
Ouvrez un terminal avec des privilèges administratifs et affichez les valeurs d'interface :
netsh interface ipv4 show subinterfaces
Vous pouvez également inspecter les détails de l'adaptateur avec :
ipconfig /all
Pour un ajustement temporaire, utilisez le nom de l'interface affiché par la première commande :
netsh interface ipv4 set subinterface "Nom de l'Interface" mtu=1500 store=active
Changez la valeur uniquement après avoir testé. Évitez les modifications du registre pour le travail de MTU de routine, car l'interface active et le chemin peuvent ne pas être celui que vous pensez.
macOS
Listez les interfaces et leurs paramètres actuels :
ifconfig
Pour un changement temporaire, remplacez en0 par l'interface transportant le chemin :
sudo ifconfig en0 mtu 1500
Le paramètre peut se réinitialiser après un changement de réseau ou un redémarrage, donc utilisez la configuration réseau du système d'exploitation si vous avez besoin de persistance.
Linux
Inspectez les interfaces avec :
ip link show
Testez une valeur temporaire :
sudo ip link set dev eth0 mtu 1500
Pour une configuration persistante, utilisez le gestionnaire de réseau de la distribution ou la configuration réseau déclarative. Ne changez pas seulement l'interface physique si un VPN, un pont de conteneur ou une interface virtuelle transporte le trafic d'automatisation.
Testez progressivement plutôt que de faire un grand saut. La valeur correcte est la limite effective minimale le long du chemin, et un MTU local plus élevé peut toujours échouer à un lien intermédiaire plus petit. Les directives de configuration MTU de Cisco soulignent cette distinction entre le MTU par interface et le MTU de chemin.
Dépannage des Symptômes et Meilleures Pratiques pour l'Automatisation
Les défauts de MTU ont tendance à être sélectifs. Une connexion peut s'authentifier, charger un petit document, puis échouer lorsque la réponse ou le téléchargement devient plus grand. Recherchez :
- Chargements de page partiels : HTML arrive, mais les scripts, images ou réponses API se bloquent.
- Chutes de session : Les flux de travail de connexion ou de téléchargement échouent après la négociation initiale.
- Erreurs spécifiques à la destination : Un site échoue tandis qu'un autre fonctionne via la même interface locale.
- Résultats de rotation incohérents : Certaines sorties proxy complètent un travail, tandis que d'autres expirent car leurs chemins diffèrent.
- Échecs uniquement VPN : Le trafic direct fonctionne, mais le trafic encapsulé se casse sous charge.
Un paquet plus grand que le MTU de sortie peut être rejeté même lorsque l'interface locale semble correctement configurée. La source peut être invitée à réduire son MTU de chemin, mais si ce retour d'information n'atteint pas l'expéditeur, l'application peut continuer à retransmettre une taille de paquet inappropriée, comme expliqué dans les directives de découverte de MTU de chemin.
Une liste de contrôle opérationnelle pratique
- Capturez l'itinéraire. Testez le travailleur, le tunnel, le type de proxy, la région cible et la destination ensemble.
- Comparez les catégories de proxy. Ne supposez pas qu'un résultat de centre de données prédit un comportement résidentiel ou mobile.
- Préservez les sessions si nécessaire. Utilisez des sessions persistantes pour les flux de travail en plusieurs étapes, puis testez la rotation séparément.
- Vérifiez le transport. Comparez le trafic HTTP/S avec SOCKS5 lorsque l'application prend en charge les deux.
- Testez des charges utiles plus importantes. De petites requêtes peuvent passer tandis que des réponses en masse échouent.
- Réduisez prudemment. Diminuez l'interface ou le MTU du tunnel par étapes contrôlées, puis retestez le travail exact.
- Surveillez la stabilité. Passez en revue les pratiques de stabilité du réseau ainsi que la latence, les délais d'attente, les retransmissions et les erreurs d'application.
- Gardez la conformité à l'esprit. Utilisez l'automatisation pour la recherche autorisée, la gestion des comptes, la vérification des annonces, la surveillance des prix, la protection de la marque et l'assurance qualité, et suivez les règles de chaque plateforme.
La meilleure configuration n'est pas le plus grand nombre sur une interface. C'est la plus grande valeur sûre qui fonctionne de manière cohérente sur l'ensemble de l'itinéraire dont dépend votre processus commercial.
Evoproxy fournit une connectivité proxy mobile 4G, LTE et 3G pour les équipes gérant des médias sociaux conformes, la vérification des annonces, la recherche de marché, l'assurance qualité géodépendante et les flux de travail de surveillance. Visitez Evoproxy pour tester un itinéraire mobile et évaluer comment son chemin de transport se comporte avec vos sessions, charges utiles et exigences MTU.
