Оптимізація з'єднання з Інтернетом
Кріс Касперски
Почасова
оплата з'єднання з Інтернетом гаряче любима всіма недбайливими провайдерами,
криві руки яких не можуть як слід відбудувати своє господарство і забезпечити
належну швидкість обміну. Клієнт отримує меншу кількість інформації за те
же час і, в результаті, довше стирчить в Мережі. А час - гроші. У самому, що
там не є, прямому значенні цього слова. От якщо б оплата йшла за кожен скачаними
мегабайт ... будьте Cпокойное - все б літало як реактивний бомбардувальник з
ракетою класу "Буш - Саддам Хусейн", але чи багато хто провайдери
підтримують такий тарифний план?
Гаразд
б, всі пригоди обмежувалися однією швидкістю (в сенсі повним відсутній
такої). Так ні ж - з'єднання може бути нестабільним, часто обриватися, а
то і не працювати зовсім - деякі сайти можуть не грузиться, лаючись на
загадкову помилку "TTL Bug", закачування по ftp може взагалі не
"фетепіть" ... та хіба ж перелічиш всі пригоди, що терзали
інтернетчика!
Звичайно,
радикальніше за все - змінити провайдера, але це не завжди можливо. У великих
містах рахунок провайдерів йде на десятки, а в провінціях він, монополіст
окаянний, нерідко буває в одиничному екземплярі, що удвічі гірше: монополісту
не треба піклуватися про своїх клієнтів - все одно вони нікуди не втечуть, яким би
кепським якість обслуговування не було. Та й куди бігти-то?
Втім,
в клінічних випадках варто задуматися про пошук провайдера в сусідньому місті.
Як не парадоксально, але навіть з урахуванням міжміського оплати за телефон, іноді
це виходить в декілька разів дешевше. Правда-правда! Саме так і доводиться
надходити автору цієї статті.
Менш
радикальна міра - налаштувати параметри TCP/IP-з'єднання на максимальну продуктивність,
що дає приріст швидкості обміну від 30% до 200% і позбавляє від більшої частини
розривів. Залишаються лише фатальні збої і зависання самого провайдера, побороти
які з клієнтської сторони принципово неможливо.
Існує
безліч програм, наприклад, MTUSpeed, як раз і призначених для цієї
мети. Одна біда - жодна з них не працює в повністю автоматичному режимі
- Всі вони всього лише оболонки над системним реєстром Windows - так би мовити,
комфортний інструмент внесення до нього змін. Але легко сказати
"вносити"! А як? Безліч малозрозумілих і нічого не говорять
параметрів, часом, взагалі без будь-яких пояснень. Спроби ж розібратися у
всім "методом тику" скоріше ще більше знизять швидкість, ніж її
збільшать. Тут без хорошого керівництва не обійтися!
Перше,
чим ми займаємося - спробуємо усунути розриви TCP-з'єднань (не плутати з
розривами модемних з'єднань!). Вони досить численні й різноманітні, а
причиною їх виникнення може бути і провайдер, і один з маршрутизаторів в
довгому ланцюжку передачі пакетів, і сам віддалений сервер, з яким,
власне, і встановлено з'єднання, і ... та чи мало ще що!
Почнемо
з провайдера. Отже, уявімо собі таку картину (маслом по дереву): модем
не кидає слухавку, але будь-яких з'єднання раптом обриваються і після
цього ні до одного сервера підключитися не вдається. Положення рятує лише
реконнект - відключення від Інтернет і повторний вхід знову. Мало того, що це
повільно, до того ж є ризик нарватися на глуху "бізю", якщо звільнився
телефонний номер миттєво займе інший клієнт (особливо якщо у провайдера
гострий недолік вхідних номерів). Такі розриви можуть відбуватися і
епізодично, і по кілька разів на годину, а то й за хвилину, являючи собою
справжні тортури.
Причина
їх виникнення, швидше за все, в тому, що у провайдера неправильно налаштований
DHCP-сервер. Той самий, що видає користувачам IP-адреси. Як і будь-який
власник, він видає їх не назовсім, а на якийсь, часом дуже
нетривалий час. Якщо клієнт (точніше його операційна система) по
якихось там причин (мережа загальмував, дах поїхав, пакет хтось прибив) не
встигне продовжити термін оренди, його IP-адреса буде безжально віднятий. А коли ж,
нарешті, клієнт "прокинеться" і пошле петицію DHCP-сервера, той
змилостивиться і відпустить з панського плеча ще одна IP-адреса, типу: ну,
користуйся на здоров'я! І начебто все гаразд, та от не розуміє
"народна" Windows 9598 таких збочень! Вона чекає отримання
IP-адреси всього лише один раз - на стадії підключення до провайдера.
Вірніше,
отримати щось IP-адреса вона отримує, але от включити його в таблицю маршрутизації
"забуває", і ні один відправляється пакет не може піти далі свого
комп'ютера. Доводиться, взяв ініціативу у свої руки, виправляти становище
самостійно.
Перш
необхідно в сеансі MS-DOS запустити утиліту ipconfig (входить в штатну
постачання Windows) і подивитися який у нас IP-адресу. Якщо він виглядає як
"0.0.0.0" - значить, DHCP-сервер фліртує з операційною системою (в
сенсі - висить глухо). Якщо ж IP дорівнює "127.0.0.1" - мережі геть
немає і тут щось серйозне. А от будь-яке інше значення вказує на вірний
IP-адресу, яку необхідно додати в голову таблиці маршрутизації, передавши
його утиліті route з штатної постачання Windows таким чином:
"route.exe ADD 0.0.0.0 MASK 0.0.0.0 Ваш IP METRIC 1". Спробуйте
встановити з'єднання з яким-небудь сервером, - тепер все має запрацювати.
Працює?
От і славненько! Однак відновити з'єднання без реконнекта - це тільки
півсправи. Добре було б усунути і причину цих розривів - адже не всі ж сервера
підтримують докачку, а часті розриви створюють великі проблеми.
В
ідеальному випадку слід було б взяти провайдера за вухо і з допомогу дядька прокурора
ткнути носом у DCHP-сервер, пояснюючи йому, що клієнт не повинен оплачувати
некомпетентність інженерного персоналу постачальника мережевих послуг за свій рахунок.
Та тільки в нашій країні такий прийом навряд чи вплине ... Доводиться
викручуватися самостійно, але на стороні клієнта дуже мало, що можна зробити,
та й то, тільки програмістам. Єдине доступне "простим
смертним "рішення - перейти на Windows 2000 - з цією проблемою вона
справляється на раз!
Другий
за рахунком джерело неприємностей - ця горезвісна помилка "TTL bug",
що призводить до неможливості встановлення з'єднання. Справа в тому, що для уникнення
засмічення мережі "Летючого Голландця", тобто, простіше кажучи,
зацикленим пакетами, кожен з них має обмежений термін існування,
вказаний в заголовку і вимірюється кількістю проміжних вузлів, які
може відвідати пакет. Якщо пакет не буде доставлений за цей час, він
"прибивається" черговим маршрутизатором c посилкою відправникові
відповідного "похоронного" повідомлення.
Чим
більше транзитних вузлів розташоване між відправником і одержувачем, тим
довше пакети добираються з одного кінця в інший. На щастя, час життя
пакета (абревіатура TTL так і розшифровується Time To Live - час життя)
дуже легко змінити, почніть Редактор Реєстру, попередньо зарезервувавши
сам реєстр, і відкрийте гілку HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet
Services Tcpip Parameters DefaultTTL для ОС Windows NT2000 і
HKEY_LOCAL_MACHINE System CurrentControlSet Services VxD MSTCP
DefaultTTL для Windows 9x, - вона-то й управляє терміном життя пакетів. За
замовчуванням він дорівнює 32 вузлів, але, як показує практика, в деяких випадках
цього явно недостатньо і варто збільшити його, принаймні, удвічі. (Можна і
більше - але від цього краще не стане, хоча і гірше - теж). Після внесення змін
до реєстру слід перезавантажитися, ввійти в мережу і перевірити, чи набуло
це якусь дію.
набуло?
Так ... Cоедіненіе з ftp-сервером встановити вдається, але от при завантаженні
працює, хоч убий: скільки не чекай, а індикатор прогресу знущально
залишається на нулі відсотків. Абыдно, понімашь! Що ж, будемо лікувати! Спробуйте
для початку включити опцію з інтригуючою назвою Розпізнавання Чорної діри --
"Black Hole Detect".
Навіщо
вона потрібна? А ось навіщо - хитра Windows, прагнучи збільшити швидкість передачі
даних, намагається обчислити максимальний розмір пакету, який би обробляється
надсилають його маршрутизаторами без розрізання. Розрізування (або, говорячи
професійною мовою, фрагментація) відчутно знижує швидкість з'єднання,
особливо якщо пакет дробиться на дві нерівні половини. Наприклад, нехай
комп'ютер клієнта намагається передати пакет розміром в 576 байт, але один з
маршрутизаторів в ланцюжку "вміє рахувати" тільки до 512, і розрізає
пакет на два, причому в другій потрапляє "хвостик" з 64 байт, плюс ...
заголовок, що займає від 40 і більше байт. У результаті - ККД другого пакету складе
всього лише 50%, що дуже недобре!
Якщо
Windows бачить, що уникнути фрагментації не вдасться, вона зменшує розмір
пакету так, щоб він без проблем пройшов крізь усі маршрутизатори одним шматком.
Але чи не простіше було б одразу встановити мінімальний розмір? Ні, і ось чому: чим
менший пакет, тим вище накладні витрати на його пересилання (заголовок теж
займає місце) і тим більше пакетів потрібно переслати для передачі того ж
обсягу інформації.
Уміння
Windows підбирати максимальний розмір нефрагментіруемого пакету всім добре
відомо, так от лихо - не завжди це працює. Деякі, не дуже
демократичні маршрутизатори, отримавши занадто довгий (на їхню думку) пакет з
позначкою "не фрагментувати", прибивають його на місці без всяких
повідомлень! Windows ж, не підозрюючи, що посланий нею пакет загинув, чекає
відгуку від сервера. Довго чекає ... А потім, так і не дочекавшись, знову посилає
той же самий пакет. І все повторюється! Так оцей-то недемократичний
маршрутизатор і називається "Чорною дірою"!
Включення
опції "Black Hole Detect" активує хитромудрий алгоритм розпізнання
"Чорних Дір" для обходу їх стороною. Але за все доводиться платити, і
таке детектування трохи знижує загальну продуктивність. Несильно - але
все ж таки! Тому вдаватися до нього слід тільки в крайніх випадках, коли
дійсно щось не працює: з'єднання є, а трансфер (передача даних)
на нулі.
Запустіть
"Редактор Реєстру" і відкрийте гілку HKEY_LOCAL_MACHINE System
CurrentControlSet Services VxD MSTCP для Windows 9598 і
HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters
для Windows NT2000. Знайдіть або при необхідності створіть двійковий параметр PMTUBlackHoleDetect
для Windows 9598 і EnablePMTUBHDetect для Windows NT2000. Тепер надайте
йому значення "1" і перезавантажити.
Що?
Все одно не працює? Хм ... Боги, боги, навіщо ви так несправедливі?! Нічого не
залишається, як розпрощатися з надією пересилання пакетів максимального розміру і
перейти на розмір, обов'язковий (ну, формально обов'язковий) для всіх
маршрутизаторів - 576 байт. Щоб цього в тій же самій гілці реєстру знайдіть
(створіть) двійковий параметр PMTUDiscovery для Windows 9598, а для Windows
NT2000 - EnablePMTUDiscovery, і дайте йому значення "0".
Перезавантажити. Ну, має ж це, нарешті, заробити!
До речі,
з типом двох цих ключів діється щось незрозуміле. Документація від Microsoft
стверджує, що він (тип, в сенсі) повинен представляти собою подвійне слово, то
пак, по-англійськи DWORD. Проте у автора під Windows 2000 закачування по ftp
починає працювати тільки після створення зазначених ключів типу одиночного слова
(WORD), а DWORD-ключі операційна система вперто ігнорує. Містика якась ...
Тепер
поговоримо про оптимізацію з'єднання. Оптимізація - справа непроста. Це не те
що: працює система чи ні. Працювати-то вона працює, от тільки як?
Тривіальним вимірюванням швидкості викачуваного файлу нічого з'ясувати не вдасться.
Графік швидкості тільки у виняткових випадках (і на хороших каналах)
представляється прямою лінією. Набагато частіше він нагадує трасу Урюпінськ --
Ханти-Мансійськ: суцільні горби, вибоїни, ями ... словом, украй поцяткована
місцевість. Говорити про середній швидкості можна тільки в переносному сенсі, тим
паче, що вона може сильно варіюватися залежно від часу доби,
сервера, з яким встановлено з'єднання, кількості опадів, що випали в
Африці, та чи мало ще від чого!
До
початку експериментів буде потрібно зібрати статистику роботи мережі за деякий
час, скажімо, за тиждень. У цьому допоможе програма Net Medic
(http://download.ru/) або будь-яка інша, аналогічна їй. Потім, після внесення
змін в налаштування системи, збирається інша статистика, знову-таки на
протягом семи-десяти днів, і порівнюється з попередньою: чи змінилося і
якщо так, то в який бік?
Справа
це, звичайно, повільне, але іншого способу тонкої настройки немає. Необхідно
переконатися в збільшенні швидкості обміну з усіма серверами і у всі часи доби,
тобто, знайти компромісний оптимум. Не все, що добре для одного випадку, так
само добре підходить для іншого. Взяти ту ж фрагментацію, які наведені
вище. Автоматичне визначення відповідного розміру пакета не завжди
збільшує швидкість з'єднання, нерідко воно її зменшує, часом дуже
значно, - автоматичне визначення займає якийсь час, збільшуючи
накладні витрати і знижуючи ККД. Має сенс спробувати знайти оптимальне
значення вручну.
Першим
Передусім необхідно вказати Windows, що потрібно використовувати не максимально
можливий, а заздалегідь обумовлений розмір пакета. Для цього встановіть значення
ключа PMTUDiscovery (EnablePMTUDiscovery) в нуль. Потім задайте бажаний розмір
пакету. За замовчуванням він дорівнює 576 байтам - це значення за стандартом повинні
підтримувати всі маршрутизатори, - та тільки хто ці стандарти дотримується? От і
зустрічаються вузли, що обробляють пакети розміром не більше 512, 522, 556, ... байт.
У принципі, можна поставити 500 і не мучитися проблемою вибору, але так нецікаво.
Хіба не заманливо методичним підбором байтів оптимізувати підключення до
кінця?
Розмір
пакетів для Windows 9598 задається ключем MaxMTU, що знаходяться в тій же самій
гілці реєстру, що і попередні ключі. З Windows NT2000 складніше: щоб
з'ясувати місце розташування ключа MTU необхідно визначити ідентифікатор
використовуваного адаптера. Перелік всіх адаптерів комп'ютера міститься в ключі
Adapters гілки HKEY_LOCAL_MACHINE System CurrentControlSet Services
Tcpip Parameters. Як правило, більшість персональних комп'ютерів обходяться
лише одним адаптером - контролером віддаленого доступу (ні, це не плата
розширення, це драйвер такий) і буриданова проблеми вибору потрібного
ідентифікатора не варто. Ідентифікатор ж, - це таке довге малозрозуміле
число, наприклад: 20692835-7194-467A-A2DC-0FAE23F0A70D.
Запам'ятовуємо
(записуємо) його і відкриваємо гілку HKEY_LOCAL_MACHINE SYSTEM
CurrentControlSet Services ІдентіфікаторАдаптера Parameters Tcpip (В
Windows 2000 - HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services
Parameters Tcpip Interfaces ІдентіфікаторАдаптера)
Серед
іншого непотребу тут повинен знаходитися тільки що запомненний ідентифікатор
адаптера, а в ньому - ключ MTU, що містить в собі максимальний розмір пакету в
байтах. Якщо такого ключа немає, його необхідно створити. Тип ключа MTU в обох
випадках відповідає подвійному слову (DWORD).
Другий
бастіон оптимізації - розмір TCP-вікна. Чим "ширше" вікно, тим вище
продуктивність, але, в той же час, більше витрати на повторні пересилання:
якби якийсь збій, - не до кінця заповнений вікно очиститься і доведеться його
"набивати" з самого початку. До того ж, пустощі з непомірковано
широкими вікнами часто призводить до утворення заторів у мережі: проміжні вузли
не встигають обробляти сиплються на них потік пакетів і починають моторошно
гальмувати. Причому, не тільки у винуватця нещастя, але і в інших ні в чому не
винних користувачів.
Ширина
TCP-вікна повинна бути кратна розміру пакета за вирахуванням довжини заголовка і
перевершувати його принаймні в чотири-шість разів. У деяких випадках
найвища продуктивність досягається при ширині вікна в 10х-12х
(де х - розмір пакета без заголовка, що називається так само "Квік"), а
то й більше. Деякі відчайдухи пробують навіть б
