Medan datortexter skiljer sig åt i deras tillämpning av termen använder Ubuntu TCP Maximum Transmission Unit (MTU) för att hänvisa till den största storleken på ett TCP-paket som en maskin kan skicka över en TCP / IP-nätverksanslutning. Medan beräkning av detta värde är relativt enkelt och standardarbetet fungerar på en majoritet av maskinerna, kan det vara möjligt att ytterligare optimera ditt system om paket är fragmenterade på grund av ovanliga inställningar. Att skicka stora enstaka utgående paket är effektivare än att skicka flera mindre utgående paket.
Det enklaste sättet att ta reda på rätt MTU-värde för din maskin är att öppna ett terminalfönster. Håll CTRL, ATL och T intryckt eller starta det kanske från enhetsstrecket. Om du arbetar med Ubuntu Server kommer du som standard att ha ett CLI-gränssnitt utan någon grafisk miljö alls. När du är vid terminalen skriver du in ping -s 1464 -c1 distrowatch.com och väntar på utdata. Om du inte får något har din nätverksanslutning inte konfigurerats korrekt. Förutsatt att du fick korrekt utdata letar du sedan efter ett avsnitt som läser 1464 (1492) byte data, vilket indikerar att du skickar paketet med 28 byte rubrikinformation.
Metod 1: Granska ping-utdata för paketfragmentering
Ping-kommandot kommer att meddela dig om paketet skickades som mer än ett fragment med flera rubrikdata bifogade. Undersök utdata för varje rad som varnar för något angående “Frag behövs och DF-set (mtu = 1492)” eller liknande text. Beroende på vilken version av ping som inkluderades i din version av Ubuntu kan varningen formuleras annorlunda. Om den här texten inte finns, är det mer än troligt att du redan arbetar med någon MTU-mätning som inte skickar ut fragmenterade paket just nu.
För att hitta den mest optimerade MTU för ditt system, skulle du vilja köra detta ping-kommando med en liten paketstorlek, och sedan öka den över tiden tills den börjar fragmentera varefter du anser att detta är din avgränsningspunkt. Tänk på att MTU = nyttolast + 28, eftersom det måste finnas lite utrymme för rubrikdata. Om du nu kan öka storleken till något mycket stort utan några fragment, kan ditt nätverksgränssnitt kanske hantera massiva paket utan att behöva generera fragment. När du äntligen ser en varning som behövs för Frag betyder det att alla paket som skickas med en nyttolast i den storlek du körde eller högre kommer att skickas som flera paket. Antag att om du försöker ping -s 2464 -c1 distrowatch.com utan någon varning, men ping -s 2465 -c1 distrowatch.com skickar en varning, betyder det att 2464 + 28 är den största MTU-inställningen som din TCP / IP-konfiguration klarar innan du skickar flera fragmenterade paket. Det kan ta några ögonblick att hitta ett exakt värde.
När du har ett värde i åtanke från att köra ping-kommandot flera gånger måste du köra sudo ifconfig för att hitta en lista över kända nätverksgränssnitt. Ubuntu och dess derivat hash ut rotkontot, men vi drivs från ett skal skapat av sudo bash för våra exempel. Det rekommenderas att du bara förordnar varje kommando med sudo individuellt.
Så snart du vet rätt enhet, försök:
sudo ifconfig interfaceName man ####
Byt gränssnittsnamn med namnet på nätverksadaptern du arbetar med och ersätt sedan #### med den storlek du hittade plus 28 för rubrikinformation. Du kan köra ifconfig för att se vilken standard MTU som var för ditt NIC och köra den igen flera gånger för att se om det här kommandot ändrar det. Vissa nätverksgränssnittsadaptrar låter dig helt enkelt inte ändra det. Om så är fallet kommer ytterligare optimering tyvärr att vara fruktlöst. Om detta dock fungerade kan du faktiskt göra det permanent. Försök springa ifconfig | grep MTU för att hitta alla värden om du har flera kontakter och sedan kan du matcha värdena till de kontakter du arbetar med.
Metod 2: Att göra MTU-optimeringar Stick
Hittills har du inte gjort någon permanent ändring av ditt system. Om du startar om kommer du att rensa bort alla ändringar, vilket är bra om du har gjort något slags misstag och upptäcker att du inte längre kan ansluta till Internet. Å andra sidan, om du har hittat ett exakt värde för din MTU, måste du redigera 
dokumentera. Det här är förmodligen en bra tid att göra en kopia av den om något händer. Prova 
eller något liknande så att du har en kopia för alla fall. Om du vill redigera den grafiskt skriver du 
och ange ditt lösenord. Om du använder Kubuntu, Xubuntu eller Lubuntu måste du ersätta gedit med den grafiska textredigeraren som din Ubuntu-respin använder. Xubuntu använder till exempel musmatta istället för gedit. Om du använder Ubuntu Server eller helt enkelt föredrar att arbeta med kommandoraden skriver du istället 
förutsatt att du inte använder ett rotskal.
Oavsett vilken metod du använde för att redigera den, hitta namnet på gränssnittet ifconfig spottade ut tidigare. Låt oss anta att du tittade på den första Wifi-kontakten på din maskin, som antagligen skulle heta wlan0 eller något liknande. I det här fallet hittar du ett kodavsnitt som börjar med iface wlan0 inet statisk eller något liknande. Din körsträcka kan variera, men nästa rad läser adressen följt av en IP-adress i formatet ###. ###. #. ##. Det kan formateras annorlunda om du har en inbyggd IPv6-anslutning. Du får en nätmask och en gateway-linje, följt av något som listar ett värdnamn eller något liknande. Längst ner har du en ny rad som läser mtu och ett nummer. Ersätt det numret med optimera MTU-värdet, spara dokumentet och avsluta sedan textredigeraren. Du vill starta om systemet för att säkerställa att det fungerar.
Om allt går bra efter flera omstart, ta bort filen interfaces.bak i katalogen ~ / Documents. Du kan istället använda sudo mv 
och då
om något gick fel i processen.
Metod 3: Redigera inställningar för TCP-mottagningsfönster (RWIN)
Ubuntu hänvisar till den största mängden data som en värd accepterar innan den erkänner avsändaren som RWIN-värdet. Om du laddar ner en 30 MB-fil skickar fjärrservern inte direkt ett 30 MB datablock. Din Ubuntu-värd skickar ett specifikt RWIN-nummer när den begär filen, och sedan börjar servern strömma data tills den har nått antalet byte innan den väntar på en bekräftelse på att ditt system har fått data. När servern tar emot detta börjar den skicka ytterligare block innan den väntar på ytterligare en bekräftelse.
Latency är den tid det tar att sända och ta emot paket från en fjärrserver. Anslutningshastigheter bidrar till detta värde, men det gör också många andra förseningar. Ping-kommandot kommer att förklara latens i termer av RTT-nummer. Titta på resultatet från vår tidigare ping av DistroWatch. Du hittar en rad som läser tid = 134 ms, vilket är hur lång tid det tog för paket att gå tur och retur från vår Ubuntu-maskin till distrowatch.com och tillbaka igen. Vi skickade ett 1 492 byte paket, så vid 134 ms kunde vi beräkna en formel för att hitta den totala överföringshastigheten:
1,492 / .134 sekunder = 11,134,328 byte / sekund, vilket är ungefär 10,88 binära kilobyte per sekund. Det är ganska långsamt totalt sett, varför RWIN är på plats för att hindra dig från att behöva erkänna varje paket som skickas individuellt.
RWIN-inställningar i Ubuntu är separata från MTU-inställningar. Beräkna BDP (Bandwidth Delay Product) för din Internetanslutning med denna formel:
(Total maximal bandbredd som din internetanslutning ska leverera i byte per sekund) (RTT i sekunder) = BDP
TCP-paketstorlek påverkar inte RWIN, men själva paketstorleken påverkas av det värde som valts i metod 1. Använd det här kommandot för att hitta kärnvariablerna relaterade till RWIN:
Kom ihåg att det finns ett mellanslag efter _mem, men ingen annanstans i den citerade texten. Du får tillbaka flera värden. De som behövs är net.ipv4.tcp_rmem, net.ipv4.tcp_wmem och net.ipv4.tcp_mem . Siffrorna efter dessa värden representerar minimi-, standard- och maxvärdena för varje. De representerar mottagningsfönstrets minnesvektor, skicka vektor och TCP-stackvektor. Om du kör Ubuntu Kylin kan du ha en lång lista med ytterligare. Du kan säkert ignorera något av dessa ytterligare värden. Vissa användare av Kylin kan också se några av de värden som avgränsas i andra skript, men leta enkelt igenom dessa rader.
Ubuntu har ingen RWIN-variabel, men net.ipv4.tcp_rmem är nära. Dessa variabler styr minnesanvändningen och inte bara TCP-storleken. De inkluderar minne som har ätit upp av datakontaktstrukturer och korta paket i massiva buffertar. Om du vill optimera dessa värden skickar du de paket med maximal storlek som du ställer in i metod 1 till en annan fjärrserver. Låt oss använda 1 492-byte-standard igen, subtrahera 28 byte för rubrikinformation, men kom ihåg att du kan ha ett annat värde. Använd kommandot ping -s 1464 -c5 distrowatch.com för att få ytterligare RTT-data.
Du vill köra testet mer än en gång vid olika tider på dygnet. Försök också pinga några andra fjärrservrar för att se hur mycket RTT varierar. Eftersom vi hade i genomsnitt drygt 130 ms varje gång vi försökte det kan vi använda formeln för att räkna ut vår BDP. Låt oss anta att du har en mycket generisk 6 Mbits / sekund-anslutning. BDP skulle vara:
(6.000.000 bitar / sek) (. 133 sek) * (1 byte / 8 bitar) = 99.750 byte
Det betyder att standardvärdet net.ipv4.tcp_rmem bör ligga någonstans runt 100.000. Du kan ställa in det ännu högre om du fruktar att du får en RTT så dålig som en halv sekund. Alla värden som finns i net.ipv4.tcp_rmem och net.ipv4.tcp_wmem måste ställas in identiskt, eftersom överföring och mottagning av paket sker över samma internetanslutning. Du vill vanligtvis ställa in net.ipv4.tcp_mem till samma värde som används av net.ipv4.tcp_wmem och net.ipv4.tcp_rmem eftersom den här första variabeln är den totala största buffertminnesstorleken för TCP-transaktioner.
Utfärda kommandot 
och se om båda dessa inställningar är inställda på 0 eller 1, vilket indikerar ett tillstånd av av eller på.
Att ställa in net.ipv4.tcp_no_metrics_save till 1 tvingar Linux-kärnan att optimera mottagningsfönstret mellan net.ipv4.tcp_rmem och net.ipv4.tcp_wmem på ett dynamiskt sätt. När net.ipv4.tcp_moderate_rcvbuf är aktiverat förhindrar det att trängsel påverkar efterföljande anslutning. Innan du gör några permanenta ändringar ska du genomföra en hastighetskontroll genom http://www.speedtest.net eller http://www.bing.com/search?q=speed+test för att se till att du har ett grepp om dina mätningar.
Ändra tillfälligt variablerna med dina beräknade värden. Se till att ersätta #s med dina beräknade summor.
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
Testa om din anslutning för att se om hastigheten har förbättrats, och om inte justera ditt kommando igen och kör om det. Kom ihåg att du kan trycka på uppåtknappen i din terminal för att upprepa det senast använda kommandot. När du har hittat lämpliga värden öppnar du 
med gksu eller sudo textredigerarkommandot från metod 1, och redigera raderna så att de läses som följer, och ersätt ännu en gång #s med dina beräknade värden. Du vill naturligtvis också säkerhetskopiera 
arkivera på samma sätt som du gjorde i del ett bara om du gjorde ett misstag. Om du har skapat en kan du också återställa på samma sätt.
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
Spara det när du är säker på att allt är okej. Utfärda följande kommando:
sudo sysctl -p
Detta tvingar Linux-kärnan att ladda om inställningarna igen 
, och om allt gick bra bör det ge dig åtminstone en något snabbare nätverksanslutning. Beroende på dina ursprungliga standardvärden kan skillnaden faktiskt vara dramatisk eller kanske inte märkbar alls.
