Оптимізація Internet Explorer
1. MTU як він є
Я люблю стежити за червоним вічком, що світиться, RD мого "Кур'єра". Солодка отрута Інтернету швидко наповнює мене і мій комп'ютер, коли це вічко світиться рівно і досить яскраво при завантаженні Web-сторінки або FTP-файлу. Однак настрій часто псується, коли яскравість вічка помітно падає або він "моргає". Ще гірша справа, якщо він гасне надовго: на секунду, дві, п'ять. Або навіть 10, 20, 30 секунд минає, а він усе мертвий. Секунда, дві, п'ять - це ще куди не йшло, специфіка HTTP 1.0 така: чекайте на реконнект з вашим сайтом. Але завмирання на 10, 20 і більше секунд - це дуже схоже на "несварення" (channel indigestion) у вашого 40-доларового або близького до того провайдера, і пробувати боротися з цим можна, завівши собі 32 Мбайт RAM і персональний DNS-сервер . Трохи допомагає зманити хоч пару дюжин інших користувачів до якогось нового "умовно-безкоштовного" провайдера: любитель халяви рухливий, як ртуть. Звичайно, радикальніше було б повбивати їх усіх, цих любителів онлайнового "Квака" та гойдалок чергових 44 Мбайт "Експлорера" однієї доброї фірми. Але, як кажуть, богородиця не велить навіть для доброї справи полегшити непосильний тягар вашого провайдера з цього клієнтського кінця.
10-20-відсоткового приросту пропускної спроможності за рахунок дійсно працюючого з'єднання типу х2 або K56Flex ще доведеться почекати (можна і зовсім не дочекатися), а ось відбудувати своє власне TCP/IP-з'єднання, що додає від 20 до 50% продуктивності, це при деякому терпіння та бажання поекспериментувати цілком реально вже зараз.
У тому вавилонському стовпотворі, який є Інтернетом сьогодні, максимальна продуктивність TCP/IP-з'єднання навіть в одному єдиному миттєвому сеансі може залежати віднеміряної купи факторів. Але з півдюжини їх піддаються налаштуванню на вашому клієнтському кінці. Більш того, подібне налаштування просто необхідне для платформ Windows 3.1x/95, OSR2, Memphis і частково Windows NT, оскільки параметри за замовчуванням в їх реєстрах мало путньому відповідають.
Почати треба з того, щоб запастися програмою типу Net.Medic для набору статистики і набрати цю статистику вдумливо і акуратно. Після доведеться порівнювати її з новою статистикою за коннектами з тими ж хостами, набраною з параметрами, що перебудовуються за наведеною нижче методикою. Оптимального набору цих параметрів, що влаштовують всіх і вся, включаючи "Кваков", немає, і перебудову, можливо, доведеться повторити, та неодноразово. Є, щоправда, програми, що дозволяють зручніше задати всі ці варіації, але тонка настройка - предмет дуже тонкий, щоб сподіватися отримати ідеальний TCP/IP-стек, зовсім нічого не розуміючи. До того ж з їх допомогою можна до ступору запсувати реєстр Windows 95. Так що попередньо збережіть в спеціальному місці або під іншим ім'ям ваші вихідні USER.DAT і SYSTEM.DAT, щоб не було боляче.
Отже, налаштування підлягають наступним параметрам.
Величині MTU ставиться у відповідність деяке значення MSS (Maximum Segment Size, максимальний розмір сегмента [даних, покладених у 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 с), але можна випробувати і рекомендовану (www.sns-access.com): 64 с. Особливої різниці я не відчув і поки що не бачу якихось шансів цьому рекомендованому 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, які у відповідь на пошуки PMTU не надсилають ICMP-повідомлень про необхідність фрагментації. Тепер у подібному 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 (Тут y0 , відповідаючи різним варіантам установок.) DefaultRcvWindow = 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\CurrentControl>default = xx у розділі HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ VxD\NWLink\Ndi\params\cachesize (Це умовчання хх для Windows 95 становить 0. Відзначаються більш якісні результати при хх=16)
Тим, кому ліньки це робити щоразу вручну, можна порадити завантажити і використовувати спеціальні програми TweakDUN версії 1.2 або MTU-Speed (http://www.mjs.u-net.com/mtuspeed.htm)
Тільки непогано щоразу переконуватися у правильності роботи програм, розглядаючи ці розділи реєстру після проведених налаштувань. Ну ось і все. Наважуйтеся! Ті, у кого ще не зжито нефатальних помилок типу CRC OVERRUN Error, боріться. Їх, можливо, і мало на потоках до 28,8 кбіт/с, але полізе більше за 33,6К і через край на коннектах з 56К. Дивіться самі: три тижні роботи з моїм більш-менш відбудованим стеком дали прирости продуктивності на 30, а то й під 50%. У рядку стану все частіше стали з'являтися і довго триматися цифри 3.0, 3.1, 3.2 Kbps по FTP, від 1.5 до 2.5, навіть із вихлестами до 4.5 Kbps у завантаженнях Web-сторінок. Так я, чого доброго, можу тепер і менше в онлайні стирчати. Зрозуміло, Arena під Linux, або моя нова іграшка - крихітчик Voyager під QNX, як "літали" так і "літають", у них стеки зродуючись не такі "криві", як у однієї доброї фірми. Але, принаймні, зрозуміло, чого слід прагнути.