Докато компютърните текстове се различават в приложението на термина, Ubuntu използва TCP Maximum Transmission Unit (MTU), за да се позове на най-големия размер на TCP пакет, който машината може да предаде през TCP / IP мрежова връзка. Докато изчисляването на тази стойност е относително просто и по подразбиране работи на повечето машини, може да е възможно допълнително да оптимизирате вашата система, ако пакетите фрагментират поради необичайни настройки. Изпращането на големи единични изходящи пакети е по-ефективно от изпращането на множество по-малки изходящи пакети.
Най-лесният начин да разберете правилната стойност на MTU за вашата машина е да отворите терминален прозорец. Задръжте CTRL, ATL и T или може да го стартирате от тирето на Unity. Ако работите с Ubuntu Server, тогава по подразбиране ще използвате интерфейс CLI без никаква графична среда. След като стигнете до терминала, напишете ping -s 1464 -c1 distrowatch.com и изчакайте изхода. Ако не получавате нищо, мрежовата ви връзка не е конфигурирана правилно. Ако приемем, че сте получили правилен изход, тогава потърсете раздел, който чете 1464 (1492) байта данни, което показва, че изпращате пакета с 28 байта информация за заглавката.
Метод 1: Проверка на изхода на ping за фрагментация на пакети
Командата ping ще ви уведоми дали пакетът е изпратен като повече от един фрагмент с прикачени множество заглавни данни. Проверете изхода за всеки ред, който предупреждава за нещо относно „Frag needed and DF set (mtu = 1492)“ или друг подобен текст. В зависимост от това коя версия на ping е включена във вашата версия на Ubuntu, предупреждението може да бъде формулирано по различен начин. Ако този текст не присъства, тогава повече от вероятно вече работите с някакво измерване на MTU, което в момента не изпраща фрагментирани пакети.
За да намерите най-оптимизираната MTU за вашата система, бихте искали да изпълните тази команда за пинг с малък размер на пакета и след това да я увеличите с течение на времето, докато започне фрагментиране, след което смятате, че това е вашата точка на прекъсване. Имайте предвид, че MTU = полезен товар + 28, тъй като трябва да има място за данните в заглавката. Сега, ако можете да увеличите размера до нещо много голямо, без никакви фрагменти, тогава вашият мрежов интерфейс може да бъде в състояние да обработва масивни пакети, без да е необходимо да генерирате фрагменти. Когато накрая видите предупреждение, необходимо за Frag, това означава, че всеки пакет, изпратен с полезен товар с размера, който сте изпълнили или по-висок, ще изпрати като множество пакети. Да предположим, че ако опитате ping -s 2464 -c1 distrowatch.com без никакво предупреждение, но ping -s 2465 -c1 distrowatch.com изпраща предупреждение, това означава, че 2,464 + 28 е най-голямата MTU настройка, която вашата TCP / IP конфигурация може да обработи преди изпращане на множество фрагментирани пакети. Може да отнеме няколко минути, за да се определи точна стойност.
След като имате предвид стойност от многократно стартиране на командата ping, ще трябва да изпълните sudo ifconfig за да намерите списък с известни мрежови интерфейси. Ubuntu и неговите производни хешират основния акаунт, но ние работихме от черупка, създадена от sudo bash за нашите примери. Препоръчва се по-скоро просто да предговаряте всяка команда със sudo поотделно.
Щом познаете правилното устройство, опитайте:
sudo ifconfig interfaceName man ####
Заменете interfaceName с името на мрежовия адаптер, с който работите, и след това заменете #### с размера, който сте намерили плюс 28 за информация в заглавката. Можете да стартирате ifconfig, за да видите какъв е MTU по подразбиране за вашия NIC и да го стартирате отново няколко пъти, за да видите дали тази предишна команда го променя. Някои адаптери за мрежов интерфейс просто няма да ви позволят да го промените. Ако случаят е такъв, тогава по-нататъшната оптимизация ще бъде безрезултатна за съжаление. Ако обаче това е работило, тогава всъщност можете да го направите постоянен. Опитайте да бягате ifconfig | grep MTU за да намерите всички стойности, ако имате множество съединители, и след това можете да съпоставите стойностите с съединителите, с които работите.
Метод 2: Осъществяване на MTU оптимизации Stick
Досега не сте направили постоянна промяна в системата си. Ако рестартирате, ще изтриете всички промени, което е добре, ако сте допуснали някаква грешка и установите, че вече не можете да се свързвате с интернет. От друга страна, ако сте намерили точна стойност за вашия MTU, тогава ще трябва да редактирате 
документ. Вероятно е подходящ момент да направите копие от него, в случай че нещо се случи. Опитвам 
или нещо подобно, за да имате копие за всеки случай. Ако искате да го редактирате графично, въведете 
и въведете паролата си. Ако използвате Kubuntu, Xubuntu или Lubuntu, тогава ще трябва да замените gedit с графичния текстов редактор, който използва вашият Ubuntu respin. Xubuntu, например, използва подложка за мишка вместо gedit. Ако използвате Ubuntu Server или просто предпочитате да работите с командния ред, вместо това напишете 
, ако приемем, че не използвате коренна черупка.
Независимо кой метод сте използвали, за да го редактирате, намерете името на интерфейса ifconfig изплюва преди. Да предположим, че разглеждате първия Wifi конектор на вашата машина, който вероятно ще бъде наречен wlan0 или нещо подобно. В този случай намерете фрагмент от код, който започва с iface wlan0 inet static или нещо подобно. Вашият пробег може да варира, но следващият ред ще прочете адреса, последван от IP адрес във формат ###. ###. #. ##. Може да е форматиран по различен начин, ако сте на родна IPv6 връзка. Ще имате линия на мрежова маска и шлюз, последвана от нещо, което изброява име на хост или нещо подобно. В долната част ще имате още един ред, който чете mtu и число. Заменете този номер с оптимизираната стойност на MTU, запазете документа и след това излезте от текстовия редактор. Искате да рестартирате системата, за да сте сигурни, че работи.
Ако всичко е наред след няколко рестартирания, изтрийте файла interfaces.bak във вашата директория ~ / Documents. Вместо това можете да използвате sudo mv 
и тогава
ако нещо се обърка в процеса.
Метод 3: Редактиране на настройките на прозореца за получаване на TCP (RWIN)
Ubuntu се отнася до най-голямото количество данни, които хостът приема, преди да признае подателя като стойност RWIN. Ако изтеглите 30 MB файл, тогава отдалеченият сървър всъщност не ви изпраща незабавно 30 MB блок данни. Вашият хост на Ubuntu изпраща определен RWIN номер, когато поиска файла, и след това сървърът започва да предава поточни данни, докато достигне броя на байтовете, преди да изчака потвърждение, че вашата система е получила данните. След като сървърът получи това, той започва да изпраща допълнителни блокове, преди да изчака ново потвърждение.
Латентността е времето, необходимо за предаване и получаване на пакети от отдалечен сървър. Цените на връзките допринасят за тази стойност, но също така и много други забавяния. Командата ping ще обясни латентността по отношение на числата за време на връщане (RTT). Погледнете резултата от предишния ни пинг на DistroWatch. Ще намерите ред, който чете време = 134 ms, което е колко време е било необходимо на пакетите да се върнат от нашата машина на Ubuntu до distrowatch.com и обратно. Изпращахме 1 492-байтов пакет, така че при 134 ms можем да изчислим формула, за да намерим общата скорост на трансфер:
1,492 / .134 секунди = 11 134,328 байта / секунда, което достига до приблизително 10,88 двоични килобайта в секунда. Като цяло това е доста бавно, поради което RWIN е на място, за да ви предпази от необходимостта да потвърждавате всеки изпратен пакет поотделно.
Настройките на RWIN в Ubuntu са отделни от настройките на MTU. Изчислете продукта за забавяне на честотната лента (BDP) за вашата интернет връзка с тази формула:
(Общата максимална честотна лента, която вашата интернет връзка трябва да предоставя в байтове в секунда) (RTT в секунди) = BDP
Размерът на TCP пакета не влияе на RWIN, но самият размер на пакета се влияе от стойността, избрана в Метод 1. Използвайте тази команда, за да намерите променливите на ядрото, свързани с RWIN:
Моля, имайте предвид, че след _mem има интервал, но никъде другаде в цитирания текст. Ще получите няколко стойности обратно. Необходимите са net.ipv4.tcp_rmem, net.ipv4.tcp_wmem и net.ipv4.tcp_mem . Числата след тези стойности представляват минималните, стандартните и максималните стойности за всяка. Те представляват вектора на паметта на прозореца за получаване, вектора за изпращане и вектора на TCP стека. Ако използвате Ubuntu Kylin, може да имате дълъг списък с допълнителни. Можете спокойно да игнорирате някоя от тези допълнителни стойности. Някои потребители на Kylin може също да видят някои от стойностите, очертани в други скриптове, но още веднъж просто потърсете тези редове.
Ubuntu няма променлива RWIN, но net.ipv4.tcp_rmem е близо. Тези променливи контролират използването на паметта, а не само размера на TCP. Те включват памет, изядена от структури на сокета за данни и къси пакети в масивни буфери. Ако искате да оптимизирате тези стойности, изпратете пакетите с максимален размер, зададени от Метод 1, на друг отдалечен сървър. Нека използваме отново 1492 байта по подразбиране, като извадим 28 байта за заглавна информация, но не забравяйте, че може да имате различна стойност. Използвайте командата ping -s 1464 -c5 distrowatch.com, за да получите допълнителни RTT данни.
Ще искате да провеждате този тест повече от веднъж по различно време на денонощието. Опитайте да пингнете и някои други отдалечени сървъри, за да видите колко варира RTT. Тъй като имахме средно малко над 130 ms всеки път, когато го опитахме, можем да използваме формулата, за да разберем нашето BDP. Да предположим, че сте на много обща връзка от 6 Mbit / секунда. BDP ще бъде:
(6 000 000 бита / сек) (. 133 секунди) * (1 байт / 8 бита) = 99 750 байта
Това означава, че стойността по подразбиране net.ipv4.tcp_rmem трябва да бъде някъде около 100 000. Можете да го настроите дори по-високо, ако се страхувате, че ще получите RTT толкова лошо, колкото половин секунда. Всички стойности, намерени в net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, трябва да бъдат зададени еднакво, тъй като предаването и приемането на пакети се случват през една и съща интернет връзка. Обикновено ще искате да зададете net.ipv4.tcp_mem на същата стойност, използвана от net.ipv4.tcp_wmem и net.ipv4.tcp_rmem, тъй като тази първа променлива е общият най-голям размер на буферната памет, зададен за TCP транзакции.
Издайте командата 
и вижте дали и двете настройки са зададени на 0 или 1, които показват състояние на изключено или включено.
Задаването на net.ipv4.tcp_no_metrics_save на 1 ще принуди ядрото на Linux да оптимизира прозореца за получаване между стойностите net.ipv4.tcp_rmem и net.ipv4.tcp_wmem по динамичен начин. Когато net.ipv4.tcp_moderate_rcvbuf е активиран, той предотвратява претоварването да повлияе на последваща свързаност. Преди да направите каквито и да е постоянни промени, направете проверка на скоростта през http://www.speedtest.net или http://www.bing.com/search?q=speed+test, за да се уверите, че разполагате с вашите измервания.
Временно променете променливите с вашите изчислени стойности. Не забравяйте да замените #s с вашите изчислени суми.
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
Изпробвайте отново връзката си, за да видите дали скоростта се е подобрила и ако не, променете командата си отново и я повторете. Не забравяйте, че можете да натиснете бутона за нагоре в терминала си, за да повторите последната използвана команда. След като намерите подходящите стойности, отворете 
с gksu или судо команда за текстов редактор от Метод 1 и редактирайте редовете, за да се четат по следния начин, като още веднъж замените #s с изчислените стойности. Разбира се, ще искате да архивирате и 
подайте по същия начин, както го направихте в част първа, само в случай че сгрешите. Ако сте го направили, можете също да възстановите по същия начин.
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
Запазете го, след като сте сигурни, че всичко е наред. Издайте следната команда:
sudo sysctl -p
Това ще принуди ядрото на Linux да презареди настройките в 
и ако всичко е минало добре, то трябва да ви осигури поне малко по-бърза мрежова връзка. В зависимост от първоначалните ви настройки по подразбиране, разликата всъщност може да е драматична или изобщо да не се забелязва.
