Mens computertekster adskiller sig i deres anvendelse af udtrykket, bruger Ubuntu TCP Maximum Transmission Unit (MTU) til at henvise til den største størrelse af en TCP-pakke, som en maskine kan overføre en TCP / IP-netværksforbindelse. Mens beregning af denne værdi er relativt enkel, og standardværdier fungerer på et flertal af maskiner, er det muligvis muligt at optimere dit system yderligere, hvis pakker er fragmenterede på grund af usædvanlige indstillinger. At sende store enkeltudgående pakker er mere effektiv end at sende flere mindre udgående pakker.
Den nemmeste måde at finde ud af den korrekte MTU-værdi til din maskine er at åbne et terminalvindue. Hold CTRL, ATL og T nede, eller start det måske fra Unity-bindestreg. Hvis du arbejder med Ubuntu Server, vil du som standard have en CLI-grænseflade uden noget grafisk miljø overhovedet. Når du er ved terminalen, skal du skrive ping -s 1464 -c1 distrowatch.com og vente på output. Hvis du ikke modtager noget, er din netværksforbindelse ikke konfigureret korrekt. Forudsat at du har modtaget korrekt output, skal du kigge efter et afsnit, der læser 1464 (1492) bytes data, hvilket indikerer, at du sender pakken med 28 bytes headeroplysninger.
Metode 1: Undersøgelse af pingoutput for pakkefragmentering
Ping-kommandoen giver dig besked, hvis pakken blev sendt som mere end et fragment med flere headerdata vedhæftet. Undersøg output for enhver linje, der advarer om noget angående “Frag nødvendig og DF-sæt (mtu = 1492)” eller lignende tekst. Afhængigt af hvilken version af ping der blev inkluderet i din version af Ubuntu, kan advarslen være formuleret forskelligt. Hvis denne tekst ikke er til stede, arbejder du mere end sandsynligt allerede med nogle MTU-målinger, der ikke udsender fragmenterede pakker på nuværende tidspunkt.
For at finde den mest optimerede MTU til dit system, vil du køre denne ping-kommando med en lille pakke størrelse og derefter øge den over tid, indtil den begynder at fragmentere, hvorefter du betragter dette som dit afskæringspunkt. Husk, at MTU = nyttelast + 28, da der skal være plads til headerdataene. Hvis du nu kan øge størrelsen til noget meget stort uden nogen fragmenter, kan din netværksgrænseflade muligvis håndtere massive pakker uden behov for at generere fragmenter. Når du endelig ser en advarsel om Frag-behov, betyder det, at enhver pakke, der sendes med en nyttelast i den størrelse, du kørte eller højere, sendes som flere pakker. Antag, at hvis du prøver ping -s 2464 -c1 distrowatch.com uden nogen advarsel, men ping -s 2465 -c1 distrowatch.com sender en advarsel, betyder det, at 2.464 + 28 er den største MTU-indstilling, din TCP / IP-konfiguration kan håndtere inden du sender flere fragmenterede pakker. Det kan tage et øjeblik at bestemme en nøjagtig værdi.
Når du har en værdi i tankerne fra at køre ping-kommandoen flere gange, skal du køre sudo ifconfig for at finde en liste over kendte netværksgrænseflader. Ubuntu og dets derivater hash ud rodkontoen, men vi opererede fra en shell oprettet af sudo bash til vores eksempler. Det anbefales, at du hellere bare forordner hver kommando med sudo individuelt.
Så snart du kender den rigtige enhed, skal du prøve:
sudo ifconfig interfaceName mand ####
Udskift interfaceName med navnet på den netværksadapter, du arbejder med, og udskift derefter #### med den størrelse, du fandt plus 28 for headeroplysninger. Du kan køre ifconfig for at se, hvad standard MTU var for din NIC og køre den igen flere gange for at se, om denne forrige kommando ændrer den. Nogle netværksinterfaceadaptere lader dig simpelthen ikke ændre det. Hvis det er tilfældet, vil yderligere optimering desværre ikke være frugtbar. Hvis dette dog fungerede, kan du faktisk gøre det permanent. Prøv at løbe ifconfig | grep MTU for at finde alle værdierne, hvis du har flere stik, og derefter kan du matche værdierne til de stik, du arbejder med.
Metode 2: Oprettelse af MTU-optimeringer
Indtil videre har du ikke foretaget nogen permanent ændring af dit system. Hvis du genstarter, sletter du eventuelle ændringer, hvilket er godt, hvis du har lavet en slags fejl og finder ud af, at du ikke længere kan oprette forbindelse til internettet. På den anden side, hvis du har fundet en nøjagtig værdi til din MTU, skal du redigere 
dokument. Dette er sandsynligvis et godt tidspunkt at lave en kopi af det, hvis der sker noget. Prøve 
eller noget lignende, så du har en kopi i tilfælde af. Hvis du vil redigere det grafisk, skal du skrive 
og indtast din adgangskode. Hvis du bruger Kubuntu, Xubuntu eller Lubuntu, skal du erstatte gedit med den grafiske teksteditor, som din Ubuntu-respin bruger. Xubuntu bruger for eksempel mousepad i stedet for gedit. Hvis du bruger Ubuntu Server eller blot foretrækker at arbejde med kommandolinjen, skal du i stedet skrive 
forudsat at du ikke bruger en rodskal.
Uanset hvilken metode du brugte til at redigere det, skal du finde navnet på grænsefladen ifconfig spyttede ud før. Lad os antage, at du kiggede på det første Wifi-stik på din maskine, som sandsynligvis ville få navnet wlan0 eller noget lignende. I dette tilfælde skal du finde et kodestykke, der starter med iface wlan0 inet statisk eller noget lignende. Din kilometertal kan variere, men den næste linje læser adressen efterfulgt af en IP-adresse i ###. ###. #. ## format. Det kan være formateret anderledes, hvis du har en oprindelig IPv6-forbindelse. Du har en netmaske og gatewaylinje efterfulgt af noget, der viser et værtsnavn eller lignende. Nederst har du en anden linje, der læser mtu og et tal. Udskift dette nummer med optimerings MTU-værdien, gem dokumentet og afslut derefter teksteditoren. Du vil gerne genstarte systemet for at sikre, at det fungerede.
Skulle alt være i orden efter flere genstarter, skal du slette interfaces.bak-filen i din ~ / Documents-mappe. Du kan i stedet bruge sudo mv 
og så
hvis der gik noget galt i processen.
Metode 3: Redigering af TCP-modtagelsesvindue (RWIN) -indstillinger
Ubuntu henviser til den største mængde data, som en vært accepterer, før den anerkender afsenderen som RWIN-værdien. Hvis du downloader en 30 MB fil, sender fjernserveren dig ikke straks en 30 MB datablok. Din Ubuntu-vært sender et specifikt RWIN-nummer, når den anmoder om filen, og derefter begynder serveren at streame data, indtil den når antallet af byte, før den venter på en bekræftelse på, at dit system har modtaget dataene. Når serveren først modtager dette, begynder det at sende yderligere blokke, inden det venter på en anden bekræftelse.
Latency er den tid, det tager at sende og modtage pakker fra en ekstern server. Forbindelseshastigheder bidrager til denne værdi, men det gør også mange andre forsinkelser. Ping-kommandoen forklarer ventetid i form af RTT-numre. Se på output fra vores forrige ping af DistroWatch. Du finder en linje, der læser tid = 134 ms, hvilket er, hvor lang tid det tog for pakker at gå tur-retur fra vores Ubuntu-maskine til distrowatch.com og tilbage igen. Vi sendte en 1.492-byte-pakke, så ved 134 ms kunne vi beregne en formel for at finde den samlede overførselshastighed:
1.492 / .134 sekunder = 11.134.328 bytes / sekund, hvilket udgør cirka 10.88 binære kilobytes pr. Sekund. Det er ret langsomt generelt, hvorfor RWIN er på plads for at forhindre dig i at skulle anerkende hver pakke, der sendes individuelt.
RWIN-indstillinger i Ubuntu er adskilt fra MTU-indstillinger. Beregn båndbreddeforsinkelsesproduktet (BDP) for din internetforbindelse med denne formel:
(Total maksimal båndbredde, din internetforbindelse skal levere i Bytes per sekund) (RTT i sekunder) = BDP
TCP-pakkestørrelse påvirker ikke RWIN, men selve pakkestørrelsen påvirkes af den værdi, der er valgt i metode 1. Brug denne kommando til at finde kernevariablerne relateret til RWIN:
Husk, at der er et mellemrum efter _mem, men ingen andre steder i den citerede tekst. Du får flere værdier tilbage. De nødvendige er net.ipv4.tcp_rmem, net.ipv4.tcp_wmem og net.ipv4.tcp_mem . Tallene efter disse værdier repræsenterer minimums-, standard- og maksimumværdierne for hver. De repræsenterer modtagevinduets hukommelsesvektor, sendvektor og TCP stakvektor. Hvis du kører Ubuntu Kylin, har du muligvis en lang liste med yderligere. Du kan sikkert ignorere nogen af disse yderligere værdier. Nogle brugere af Kylin kan muligvis også se nogle af de værdier, der er afgrænset i andre scripts, men se endnu en gang blot efter disse linjer.
Ubuntu har ikke en RWIN-variabel, men net.ipv4.tcp_rmem er tæt på. Disse variabler styrer hukommelsesforbruget og ikke kun TCP-størrelsen. De inkluderer hukommelse, der er spist op af datatilslutningsstrukturer og korte pakker i massive buffere. Hvis du vil optimere disse værdier, skal du sende pakkerne med den maksimale størrelse, du indstiller i metode 1, til en anden fjernserver. Lad os bruge 1.492-byte-standard igen og trække 28 byte til headeroplysninger, men husk at du muligvis har en anden værdi. Brug kommandoen ping -s 1464 -c5 distrowatch.com for at få yderligere RTT-data.
Du vil gerne køre denne test mere end én gang på forskellige tidspunkter af dagen og natten. Prøv også at pinge nogle andre eksterne servere for at se, hvor meget RTT varierer. Da vi havde et gennemsnit på lidt over 130 ms hver gang vi prøvede det, kan vi bruge formlen til at finde ud af vores BDP. Lad os antage, at du har en meget generisk 6 Mbits / sekund-forbindelse. BDP ville være:
(6.000.000 bits / sek) (. 133 sek) * (1 byte / 8 bit) = 99.750 byte
Dette betyder, at standardværdien net.ipv4.tcp_rmem skal være et sted omkring 100.000. Du kan indstille det endnu højere, hvis du frygter, at du får en RTT så dårlig som et halvt sekund. Alle værdier, der findes i net.ipv4.tcp_rmem og net.ipv4.tcp_wmem, skal indstilles identisk, da transmission og modtagelse af pakker sker over den samme internetforbindelse. Du vil normalt indstille net.ipv4.tcp_mem til den samme værdi, der bruges af net.ipv4.tcp_wmem og net.ipv4.tcp_rmem, da denne første variabel er den samlede største bufferhukommelsesstørrelse, der er indstillet til TCP-transaktioner.
Udsted kommandoen 
og se om begge disse indstillinger er indstillet til 0 eller 1, hvilket indikerer en tilstand fra eller til.
Indstilling af net.ipv4.tcp_no_metrics_save til 1 vil tvinge Linux-kernen til at optimere modtagevinduet mellem net.ipv4.tcp_rmem og net.ipv4.tcp_wmem på en dynamisk måde. Når net.ipv4.tcp_moderate_rcvbuf er aktiveret, forhindrer det overbelastning i at påvirke efterfølgende forbindelse. Inden du foretager permanente ændringer, skal du foretage en hastighedskontrol gennem http://www.speedtest.net eller http://www.bing.com/search?q=speed+test for at sikre, at du har et greb om dine målinger.
Skift variablerne midlertidigt med dine beregnede værdier. Sørg for at udskifte #s med dine beregnede summer.
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
Test din forbindelse igen for at se, om hastigheden er forbedret, og hvis ikke finjuster din kommando igen og kør den igen. Husk at du kan trykke på op-tasten i din terminal for at gentage den sidst anvendte kommando. Når du har fundet de relevante værdier, skal du åbne 
med gksu eller sudo teksteditorkommando fra metode 1, og rediger linjerne, der skal læses som følger, og erstatt endnu en gang #'erne med dine beregnede værdier. Du vil selvfølgelig også gerne sikkerhedskopiere 
arkiver på samme måde som i del 1, bare hvis du laver en fejl. Hvis du har lavet en, kan du også gendanne på samme måde.
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
Gem det, når du er sikker på, at alt er okay. Udsted følgende kommando:
sudo sysctl -p
Dette vil tvinge Linux-kernen til at genindlæse indstillingerne i 
, og hvis alt gik godt, skulle det give dig mindst en noget hurtigere netværksforbindelse. Afhængig af dine oprindelige standarder, kan forskellen faktisk være dramatisk eller slet ikke mærkbar.
