Оптимизиране на Internet Explorer

1. MTU такъв, какъвто е

Обичам да държа под око червеното светещо око на моя Courier's RD. Сладката отрова на Интернет бързо изпълва мен и компютъра ми, когато тази шпионка свети постоянно и доста ярко при изтегляне на уеб страница или файл през FTP. Настроението обаче често се влошава, когато яркостта на окото забележимо спадне или то „мига“. Още по-лошо е, ако изгасне за дълго време: за секунда, две, пет. Или дори минават 10, 20, 30 секунди и той все още е мъртъв. Секунда, две, пет - все още е наред, спецификата на HTTP 1.0 е следната: изчакайте повторно свързване с вашия сайт. Но замразяването за 10, 20 или повече секунди е много подобно на "лошо храносмилане" (лошо храносмилане на канала) с вашия $40 или близък доставчик и можете да опитате да се справите с това, като си вземете 32 MB RAM и личен DNS сървър. Малко помага да привлечете поне няколко дузини други потребители към някой нов доставчик на "shareware": любител на безплатните продукти е мобилен като живак. Разбира се, би било по-радикално да ги избием всички, тези фенове на онлайн "Квак" и теглещи следващите 44 MB "Explorer" на една мила компания. Но, както се казва, Богородица не заповядва дори за добра кауза да облекчи непоносимите трудности на вашия доставчик от тази клиентска страна.

10-20% увеличение на пропускателната способност поради наистина работеща връзка като x2 или K56Flex все още ще трябва да почака (може изобщо да не изчакате), но изграждането на ваша собствена TCP / IP връзка, която добавя от 20 до 50% производителност, с известно търпение и желание за експериментиране, е доста реалистично в момента.

Във вавилонския хаос, какъвто е интернет днес, максималната производителност на TCP/IP връзка дори в една моментна сесия може да зависи откуп фактори. Но половин дузина от тях могат да се конфигурират от вашия клиент. Освен това такава настройка е просто необходима за платформите Windows 3.1x/95, OSR2, Memphis и отчасти Windows NT, тъй като настройките по подразбиране в техните регистри почти не съответстват на нищо полезно.

Трябва да започнете, като се снабдите с програма като Net.Medic за събиране на статистика и събирането на същите тези статистики внимателно и точно. След това ще трябва да го сравните с новите статистики за връзки със същите хостове, въведени с параметрите, преустроени съгласно метода по-долу. Няма оптимален набор от тези параметри, които да отговарят на всички и всичко, включително Kvaks, и перестройката може да се наложи да се повтори и повече от веднъж. Вярно е, че има програми, които ви позволяват по-удобно да зададете всички тези варианти, но фината настройка е твърде деликатен предмет, за да се надяваме да получите перфектния TCP / IP стек, без да разбирате нищо. Освен това с тяхна помощ можете да объркате до ступор системния регистър на Windows 95. Така че първо запазете оригиналните си USER.DAT и SYSTEM.DAT на специално място или под друго име, за да не боли мъчително.

Така че следните параметри подлежат на конфигуриране.

На MTU стойността се присвоява определена MSS стойност (максимален размер на сегмента, максималният размер на сегмента [на данни, пакетирани в MTU]). MSS стойността, която задавате, е най-големият сегмент от данни, който вашият стек може да приеме в един пакет при дадена връзка. Стойността на MSS трябва да е по-малка от MTU с поне 40 байта от заглавката и придружаващите данни.

Неотдавнашните препоръки за определяне на MSS като MTU-60 изглеждаха причинени от желанието да се прекали, но загубата на двадесет ценни „полезни“ байта на всеки пакет се оказа нищоне е оправдано. Като цяло резултатът в тази битка ще се поддържа до последния байт. Така че MSS=MTU-40.

Има и TTL (Time To Live, време за живот), както и (за Windows 95 / NT) Session Keep Alive (максималната продължителност на поддържане на връзката отворена). Освен това: опция PMTU (Path MTU, MTU стойност на пътя при автоматично търсене на маршрут с най-голям MTU от всички минимални маршрути), опция PMTU Black Hole Detect (откриване на "черна дупка" в PMTU). И накрая, NDI Cache (Network Driver Interface Cache), тоест размерът на кеша, използван за съхраняване на пътища за маршрутизиране от типа Token Ring. С промяна на всички тези параметри не трябва да очаквате особено резки подобрения, но си струва да опитате. Стойността на TTL може да се остави по подразбиране (32 s), но можете също да опитате препоръчителната (www.sns-access.com): 64 s. Не усетих голяма разлика и засега не виждам никакви шансове този препоръчан TTL да се прояви от най-добрата страна.

Също така се дава неясно разсъждение за 10 минути вместо 1 час по подразбиране в стойността на Session Keep Alive и отново не наблюдавах значителен ефект. Доста странна история е свързана с PMTU и PMTU Black Hole Detect. В Windows 95 опцията за автоматично откриване на MTU на пътя е активирана по подразбиране, което изглежда е причината да се намери плавен, нефрагментиращ маршрут с MTU=1500 също по подразбиране. Но номерът е, че Интернет, така да се каже, "в глобален мащаб" съдържа твърде много рутери с MTU=576, 512, 552, 556, 1024, 1152. Има дори машини с MTU=1524 някъде в Обединеното кралство. Така че ще има малък шанс да намерите магистрала с MTU = 1500 навсякъде до вашата дестинация и да се возите по нея, без да се смачквате със същите занаятчии, ако наберете от Урюпинск или Марина Роща, а не, да речем, от Сан Хосе(Калифорния). Да, и можете да отделите много време за такива търсения, достигайки до обект от Урюпинск, тъй като те имат топология с адаптивно настроен трафик там и само някои къси нишки достигат до нас от тази плетеница.

Ясно е, че ако започнете с MaxMTU в района на 500 копейки, тогава изглежда, че няма голяма разлика, нека търси нефрагментиращ път, когато вече е почти първият, който се среща. Все пак се препоръчва да експериментирате с деактивираната опция PMTU. Съответно в Windows 95 търсенето на черни дупки е деактивирано по подразбиране. Активирането на тази опция означава, че TCP заявката ще се опита да открие рутери с максимално MTU, които не изпращат ICMP съобщения за фрагментиране в отговор на PMTU търсения. Сега, в такава TCP заявка, ще бъдат изпратени сегменти с нулиране на байта DF (Don't Fragment) в случаите, когато повторното предаване на сегмента е останало незабелязано. Ако се видят такива пробни сегменти, стойността на MTU ще бъде намалена и битът DF ще бъде зададен за следващите пакети във връзката.

Сега можете да започнете да се заблуждавате, разглеждайки статистиката на миналия си живот за последен път. Редактирайте ръчно регистъра (след задължително записване някъде на оригиналните USER.DAT и SYSTEM.DAT), както следва:

MaxMTU = xxxx (512, 552, 576, 1006, 1024, 1152, 1500 или дори 1524.) под HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Class\NetTrans\00yy (Тук yy ще варира от 00 до 30, съответстващо на различни настройки. ) DefaultR cvWindow = yyyy (4*, 6*, 8* или 10*MSS; MSS=MTU-40.) под HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP PMTUDiscovery = 0 или 1 под HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\VxD\MSTCP PMTUBlackHoleDetect = 0 или 1 под HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP DefaultTTL = 32 или 64 под HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP по подразбиране = xx под HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\ VxD\NWLink\Ndi\params\cachesize (Това xx по подразбиране за Windows 95 е 0. По-добри резултати се отбелязват с xx=16)

За тези, които са твърде мързеливи, за да правят това ръчно всеки път, можем да препоръчаме изтегляне и използване на специални програми TweakDUN версия 1.2 или MTU-Speed (http://www.mjs.u-net.com/mtuspeed.htm)

Просто е добра идея всеки път да се уверявате, че програмите работят правилно, като проверявате тези ключове в системния регистър, след като настройките са направени. Е, това е всичко. Осмелявам се! Тези, които все още не са елиминирали нефатални грешки като CRC OVERRUN Error, бийте се. Може да има малко от тях при потоци до 28,8 kbps, но повече при 33,6K и повече при връзки с 56K. Вижте сами: три седмици работа с моя повече или по-малко възстановен стек даде подобрение на производителността от 30 или дори 50%. Числата 3.0, 3.1, 3.2 Kbps през FTP, от 1.5 до 2.5, дори с изблици до 4.5 Kbps при изтегляне на уеб страници, започнаха да се появяват все по-често в лентата на състоянието и да остават за дълго време. Така че сега мога да се мотая по-малко онлайн. Разбира се, Arena под Linux или новата ми играчка - мъничък Voyager под QNX, и "летят", и "летят", стековете им не са толкова "криви" като тези на добра компания. Но поне е ясно към какво да се стремим.