Alors que les textes informatiques diffèrent dans leur application du terme, Ubuntu utilise l'unité de transmission maximale TCP (MTU) pour désigner la plus grande taille qu'un paquet TCP qu'une machine peut transmettre via une connexion réseau TCP / IP. Bien que le calcul de cette valeur soit relativement simple et que les valeurs par défaut fonctionnent sur une majorité de machines, il peut être possible d'optimiser davantage votre système si les paquets se fragmentent en raison de paramètres inhabituels. L'envoi de grands paquets sortants uniques est plus efficace que l'envoi de plusieurs petits paquets sortants.
Le moyen le plus simple de trouver la valeur MTU correcte pour votre machine est d'ouvrir une fenêtre de terminal. Maintenez CTRL, ATL et T enfoncées ou peut-être démarrez-le à partir du tiret Unity. Si vous travaillez avec Ubuntu Server, vous utiliserez par défaut une interface CLI sans environnement graphique du tout. Une fois que vous êtes au terminal, tapez ping -s 1464 -c1 distrowatch.com et attendez la sortie. Si vous ne recevez rien, c'est que votre connexion réseau n'a pas été configurée correctement. En supposant que vous avez reçu une sortie correcte, recherchez une section qui lit 1464 (1492) octets de données, ce qui indique que vous envoyez le paquet avec 28 octets d'informations d'en-tête.
Méthode 1: examen de la sortie de ping pour la fragmentation des paquets
La commande ping vous permettra de savoir si le paquet a été envoyé sous forme de plusieurs fragments avec plusieurs données d'en-tête jointes. Examinez la sortie pour toute ligne qui avertit de quelque chose concernant «Frag nécessaire et DF set (mtu = 1492)» ou tout texte similaire. Selon la version de ping incluse avec votre version d'Ubuntu, l'avertissement peut être formulé différemment. Si ce texte n’est pas présent, il est fort probable que vous travailliez déjà avec une mesure MTU qui n’envoie pas de paquets fragmentés pour le moment.
Pour trouver le MTU le plus optimisé pour votre système, vous voudrez exécuter cette commande ping avec une petite taille de paquet, puis l'augmenter au fil du temps jusqu'à ce qu'elle commence à se fragmenter, après quoi vous considérez cela comme votre point de coupure. Gardez à l'esprit que MTU = payload + 28, car il doit y avoir de la place pour les données d'en-tête. Maintenant, si vous pouvez augmenter la taille à quelque chose de très grand sans aucun fragment, alors votre interface réseau pourrait être en mesure de gérer des paquets massifs sans avoir besoin de générer des fragments. Lorsque vous voyez enfin un avertissement Frag nécessaire, cela signifie que tout paquet envoyé avec une charge utile de la taille que vous avez exécutée ou supérieure sera envoyé sous forme de paquets multiples. Supposons que si vous essayez ping -s 2464 -c1 distrowatch.com sans aucun avertissement, mais que ping -s 2465 -c1 distrowatch.com envoie un avertissement, cela signifie que 2464 + 28 est le plus grand paramètre MTU que votre configuration TCP / IP puisse gérer avant d'envoyer plusieurs paquets fragmentés. Cela peut prendre quelques instants pour identifier une valeur exacte.
Une fois que vous avez une valeur à l'esprit en exécutant la commande ping plusieurs fois, vous devrez exécuter sudo ifconfig pour trouver une liste des interfaces réseau connues. Ubuntu et ses dérivés hachent le compte root, mais nous avons fonctionné à partir d'un shell créé par sudo bash pour nos exemples. Il est recommandé de faire précéder chaque commande de sudo individuellement.
Dès que vous connaissez le bon appareil, essayez:
sudo ifconfig interfaceName man ####
Remplacez interfaceName par le nom de la carte réseau avec laquelle vous travaillez, puis remplacez #### par la taille que vous avez trouvée, plus 28 pour les informations d'en-tête. Vous pouvez exécuter ifconfig pour voir quel était le MTU par défaut pour votre carte réseau et le réexécuter plusieurs fois pour voir si cette commande précédente le modifie. Certains adaptateurs d'interface réseau ne vous permettent tout simplement pas de le changer. Si tel est le cas, une optimisation supplémentaire sera malheureusement infructueuse. Si, cependant, cela a fonctionné, vous pouvez le rendre permanent. Essayez de courir ifconfig | grep MTU pour trouver toutes les valeurs si vous avez plusieurs connecteurs, puis vous pouvez faire correspondre les valeurs aux connecteurs avec lesquels vous travaillez.
Méthode 2: Faire coller les optimisations MTU
Jusqu'à présent, vous n'avez apporté aucune modification permanente à votre système. Si vous redémarrez, vous effacerez toutes les modifications, ce qui est bien si vous avez commis une erreur et constatez que vous ne pouvez plus vous connecter à Internet. En revanche, si vous avez trouvé une valeur précise pour votre MTU, vous devrez modifier le 
document. C'est probablement le bon moment pour en faire une copie au cas où quelque chose se produirait. Essayer 
ou quelque chose de similaire pour que vous ayez une copie au cas où. Si vous souhaitez le modifier graphiquement, saisissez 
et entrez votre mot de passe. Si vous utilisez Kubuntu, Xubuntu ou Lubuntu, vous devrez remplacer gedit par l'éditeur de texte graphique utilisé par votre respin Ubuntu. Xubuntu, par exemple, utilise mousepad au lieu de gedit. Si vous utilisez Ubuntu Server ou préférez simplement travailler avec la ligne de commande, saisissez à la place 
, en supposant que vous n'utilisez pas de shell racine.
Quelle que soit la méthode que vous avez utilisée pour l'éditer, recherchez le nom de l'interface ifconfig spit out avant. Supposons que vous regardiez le premier connecteur Wifi sur votre ordinateur, qui s'appellerait probablement wlan0 ou quelque chose de similaire. Dans ce cas, recherchez un extrait de code commençant par iface wlan0 inet static ou quelque chose de similaire. Votre kilométrage peut varier, mais la ligne suivante indiquera l'adresse suivie d'une adresse IP au format ###. ###. #. ##. Il peut être formaté différemment si vous utilisez une connexion IPv6 native. Vous aurez un masque de réseau et une ligne de passerelle, suivis de quelque chose qui répertorie un nom d'hôte ou quelque chose de similaire. En bas, vous aurez une autre ligne qui lit mtu et un nombre. Remplacez ce nombre par la valeur d'optimisation MTU, enregistrez le document, puis quittez l'éditeur de texte. Vous voudrez redémarrer le système pour vous assurer qu'il fonctionne.
Si tout va bien après plusieurs redémarrages, supprimez le fichier interfaces.bak dans votre répertoire ~ / Documents. Vous pouvez à la place utiliser sudo mv 
et alors
si quelque chose a mal tourné dans le processus.
Méthode 3: Modification des paramètres de la fenêtre de réception TCP (RWIN)
Ubuntu fait référence à la plus grande quantité de données qu'un hôte accepte avant de reconnaître l'expéditeur comme la valeur RWIN. Si vous téléchargez un fichier de 30 Mo, le serveur distant ne vous envoie pas immédiatement un bloc de données de 30 Mo. Votre hôte Ubuntu envoie un numéro RWIN spécifique lorsqu'il demande le fichier, puis le serveur commence à diffuser des données jusqu'à ce qu'il atteigne le nombre d'octets avant d'attendre une confirmation que votre système a obtenu les données. Une fois que le serveur reçoit cela, il commence à envoyer des blocs supplémentaires avant d'attendre un autre accusé de réception.
La latence est le temps nécessaire pour transmettre et recevoir des paquets d'un serveur distant. Les taux de connexion contribuent à cette valeur, tout comme de nombreux autres retards. La commande ping expliquera la latence en termes de temps d'aller-retour (RTT). Regardez la sortie de notre précédent ping de DistroWatch. Vous trouverez une ligne qui indique time = 134 ms, soit le temps qu'il a fallu aux paquets pour aller de notre machine Ubuntu à distrowatch.com et inversement. Nous envoyions un paquet de 1492 octets, donc à 134 ms, nous pourrions calculer une formule pour trouver la vitesse de transfert totale:
1 492 / 0,134 secondes = 11 134,328 octets / seconde, ce qui équivaut à environ 10,88 kilo-octets binaires par seconde. C'est plutôt lent dans l'ensemble, c'est pourquoi RWIN est en place pour vous éviter d'avoir à accuser réception de chaque paquet envoyé individuellement.
Les paramètres RWIN dans Ubuntu sont séparés des paramètres MTU. Calculez le produit de délai de bande passante (BDP) pour votre connexion Internet avec cette formule:
(Bande passante maximale totale que votre connexion Internet doit fournir en octets par seconde) (RTT en secondes) = BDP
La taille du paquet TCP n’influence pas RWIN, mais la taille du paquet elle-même est influencée par la valeur sélectionnée dans la méthode 1. Utilisez cette commande pour trouver les variables du noyau liées à RWIN:
Veuillez garder à l'esprit qu'il y a un espace après _mem, mais nulle part ailleurs dans le texte cité. Vous récupérerez plusieurs valeurs. Ceux dont nous avons besoin sont net.ipv4.tcp_rmem, net.ipv4.tcp_wmem et net.ipv4.tcp_mem . Les nombres après ces valeurs représentent les valeurs minimum, par défaut et maximum pour chacune. Ils représentent le vecteur mémoire de la fenêtre de réception, le vecteur d'envoi et le vecteur de pile TCP. Si vous utilisez Ubuntu Kylin, vous en avez peut-être une longue liste d’autres. Vous pouvez ignorer en toute sécurité l'une de ces valeurs supplémentaires. Certains utilisateurs de Kylin peuvent également voir certaines des valeurs définies dans d'autres scripts, mais une fois de plus, recherchez simplement ces lignes.
Ubuntu n’a pas de variable RWIN, mais net.ipv4.tcp_rmem est proche. Ces variables contrôlent l'utilisation de la mémoire et pas seulement la taille TCP. Ils incluent la mémoire consommée par les structures de socket de données et les paquets courts dans des tampons massifs. Si vous souhaitez optimiser ces valeurs, envoyez la taille maximale des paquets que vous avez définie dans la méthode 1 à un autre serveur distant. Utilisons à nouveau la valeur par défaut de 1 492 octets, en soustrayant 28 octets pour les informations d'en-tête, mais n'oubliez pas que vous pouvez avoir une valeur différente. Utilisez la commande ping -s 1464 -c5 distrowatch.com pour obtenir des données RTT supplémentaires.
Vous souhaiterez exécuter ce test plusieurs fois à différents moments du jour et de la nuit. Essayez également d'envoyer une requête ping à d'autres serveurs distants pour voir à quel point le RTT varie. Comme nous avons eu une moyenne d'un peu plus de 130 ms à chaque fois que nous l'avons essayé, nous pouvons utiliser la formule pour déterminer notre BDP. Supposons que vous ayez une connexion très générique de 6 Mbits / seconde. Le BDP serait:
(6 000 000 bits / s) (. 133 s) * (1 octet / 8 bits) = 99 750 octets
Cela signifie que la valeur par défaut de net.ipv4.tcp_rmem doit être d'environ 100 000. Vous pouvez le régler encore plus haut si vous craignez d’obtenir un RTT d’une demi-seconde. Toutes les valeurs trouvées dans net.ipv4.tcp_rmem et net.ipv4.tcp_wmem doivent être définies de la même manière, car la transmission et la réception des paquets s'effectuent via la même connexion Internet. Vous souhaiterez généralement définir net.ipv4.tcp_mem sur la même valeur que celle utilisée par net.ipv4.tcp_wmem et net.ipv4.tcp_rmem, car cette première variable est la plus grande taille totale de mémoire tampon définie pour les transactions TCP.
Émettez la commande 
et voyez si ces deux paramètres sont définis sur 0 ou 1, ce qui indique un état désactivé ou activé.
Définir net.ipv4.tcp_no_metrics_save sur 1 forcera le noyau Linux à optimiser la fenêtre de réception entre les valeurs net.ipv4.tcp_rmem et net.ipv4.tcp_wmem de manière dynamique. Lorsque net.ipv4.tcp_moderate_rcvbuf est activé, cela empêche la congestion d'influencer la connectivité ultérieure. Avant d'apporter des modifications permanentes, effectuez une vérification de la vitesse via http://www.speedtest.net ou http://www.bing.com/search?q=speed+test pour vous assurer que vous avez une idée de vos mesures.
Modifiez temporairement les variables avec vos valeurs calculées. Assurez-vous de remplacer les # par vos sommes calculées.
sudo sysctl -w net.ipv4.tcp_rmem = ”#### ##### ######” net.ipv4.tcp_wmem = ”#### ##### ######” net.ipv4.tcp_mem = ”#### ##### ######” net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1
Testez à nouveau votre connexion pour voir si la vitesse s'est améliorée, et si ce n'est pas le cas, ajustez à nouveau votre commande et réexécutez-la. N'oubliez pas que vous pouvez appuyer sur la touche haut de votre terminal pour répéter la dernière commande utilisée. Une fois que vous avez trouvé les valeurs appropriées, ouvrez 
avec le gksu ou sudo éditeur de texte de la méthode 1, et modifiez les lignes pour lire comme suit, en remplaçant une fois de plus les # par vos valeurs calculées. Vous souhaiterez bien sûr également sauvegarder le 
fichier de la même manière que vous l'avez fait dans la première partie au cas où vous feriez une erreur. Si vous en avez créé un, vous pouvez également restaurer de la même manière.
net.ipv4.tcp_rmem = #### ##### ######
net.ipv4.tcp_wmem = #### ##### ######
net.ipv4.tcp_mem = #### ##### ######
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
Enregistrez-le une fois que vous êtes sûr que tout va bien. Exécutez la commande suivante:
sudo sysctl -p
Cela forcera le noyau Linux à recharger les paramètres dans 
, et si tout s'est bien passé, cela devrait vous donner au moins une connexion réseau un peu plus rapide. En fonction de vos paramètres par défaut d'origine, la différence peut en fait être dramatique ou potentiellement pas du tout perceptible.
