Оптимізація з’єднання з Інтернет, Локальні мережі, статті

Кріс Касперски

Погодинна оплата з’єднання з Інтернет гаряче любима всіма недбайливими провайдерами, криві руки яких не можуть як слід відбудувати своє господарство і забезпечити належну швидкість обміну. Клієнт отримує меншу кількість інформації за той же час і, в результаті, довше стирчить в Мережі. А час – гроші. В самому, що ні на є, прямому сенсі цього слова. От якщо б оплата йшла за кожен скачаними мегабайт … будьте cпокойни – все б літало як реактивний бомбардувальник з ракетою класу “Буш – Саддам Хусейн”, але багато Чи провайдери підтримують такий тарифний план?

Гаразд би, всі пригоди обмежувалися однією швидкістю (В сенсі повним отсутствуем такої). Так ні ж – з’єднання може бути нестабільним, часто обриватися, а то і не працювати зовсім – деякі сайти можуть не грузиться, лаючись на загадкову помилку “TTL
Bug
“, Закачування по ftp може взагалі не” фетепіть “… та хіба ж перерахуєш всі пригоди, що терзали інтернетчика!

Звичайно, радикальніше за все – змінити провайдера, але це не завжди можливо. У великих містах рахунок провайдерів йде на десятки, а в провінціях він, монополіст окаянний, нерідко буває в одиничному примірнику, що удвічі гірше: монополісту немає чого турбуватися про своїх клієнтів – все одно вони нікуди не втечуть, яким би поганим якість обслуговування не було. Та й куди бігти-то?

Втім, в клінічних випадках варто задуматися про пошук провайдера в сусідньому місті. Як не парадоксально, але навіть з урахуванням міжміського оплати за телефон, іноді це виходить у декілька разів
дешевше. Правда-правда! Саме так і доводиться надходити автору цієї статті.

Менш радикальний захід – налаштувати параметри TCP / IP-з’єднання на максимальну продуктивність, що дає приріст швидкості обміну від 30% до 200% і позбавляє від більшої частини розривів. Залишаються лише фатальні збої і зависання самого провайдера, побороти які з клієнтської сторони принципово неможливо.

Існує безліч програм, наприклад, MTUSpeed, Як раз і призначених для цієї мети. Одна біда – жодна з них не працює в повністю автоматичному режимі – всі вони всього лише оболонки над системним реєстром Windows – так би мовити, комфортний інструмент внесення до нього змін. Але легко сказати “вносити”! А як? Безліч малозрозумілих і нічого не говорять параметрів, часом, взагалі без будь-яких пояснень. Спроби ж розібратися у всьому “методом тику” скоріше ще більше знизять швидкість, ніж її збільшать. Тут без хорошого керівництва не обійтися!

Перше, чим ми займемося – спробуємо усунути розриви TCP-з’єднань (не плутати з розривами модемних з’єднань!). Вони досить численні й різноманітні, а причиною їх виникнення може бути і провайдер, і один з маршрутизаторів в довгому ланцюжку передачі пакетів, і сам віддалений сервер, з яким, власне, і встановлено з’єднання, і … та хіба мало ще що!

Почнемо з провайдера. Отже, уявімо собі таку картину (маслом по дереву): модем не кидає трубку, але всі встановлені з’єднання раптом обриваються і після цього ні до одного сервера підключитися не вдається. Положення рятує лише реконнект – відключення від Інтернету і повторний вхід знову. Мало того, що це повільно, до того ж є ризик нарватися на глуху “бізю”, якщо звільнився телефонний номер миттєво займе інший клієнт (особливо якщо у провайдера гострий недолік вхідних номерів). Такі розриви можуть відбуватися і епізодично, і по кілька раз на годину, а то й на хвилину, являючи собою справжні тортури.

Причина їх виникнення, швидше за все, в тому, що у провайдера неправильно налаштований DHCP-сервер. Той самий, що видає користувачам IP-адреси. Як і будь-який власник, він видає їх не назовсім, а на якийсь, часом дуже нетривалий час. Якщо клієнт (точніше його операційна система) з якихось там причин (мережа зупинила, дах поїхала, пакет хтось прибив) не встигне продовжити термін оренди, його IP-адреса буде безжально віднятий. А коли ж, нарешті, клієнт “Прокинеться” і пошле петицію DHCP-серверу, той змилостивиться і відпустить з панського плеча ще одна IP-адреса, типу: ну, користуйся на здоров’я! І начебто б все нічого, та от не розуміє “народна” Windows 95 \ 98 таких збочень! Вона очікує отримання 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 NT \ 2000 і HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \
Services \ VxD \ MSTCP \ DefaultTTL
для Windows 9x, – вона-то і управляє терміном життя пакетів. За замовчуванням він дорівнює 32 вузлів, але, як показує практика, в деяких випадках цього явно недостатньо і варто збільшити його, принаймні, удвічі. (Можна і більше – але від цього краще не стане, хоча й гірше – теж). Після внесення змін до реєстру слід перезавантажитися, заново увійти в мережу і перевірити, набуло Чи це якась дія.

Здобуло? Так … З’єднання з 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 95 \ 98 і HKEY_LOCAL_MACHINE \ System \
CurrentControlSet \ Services \ Tcpip \ Parameters
для Windows NT \ 2000. Знайдіть або при необхідності створіть двійковий параметр
PMTUBlackHoleDetect для Windows 95 \ 98 і EnablePMTUBHDetect
для Windows NT \ 2000. Тепер надайте йому значення “1” і перезавантажитеся.

Що? Все одно не працює? Хм … Боги, боги, навіщо ви так несправедливі?! Нічого не залишається, як розлучитися з надією пересилання пакетів максимального розміру і перейти на розмір, обов’язковий (ну, формально обов’язковий) для всіх маршрутизаторів – 576 байт. Для цього в тій же самій гілці реєстру знайдіть (створіть) двійковий параметр
PMTUDiscovery для Windows 95 \ 98, а для
Windows NT\2000 – EnablePMTUDiscovery , І надайте йому значення “0”. Перезавантажитеся. Ну, має ж це, нарешті, заробити!

До речі, з типом двох цих ключів діється щось незрозуміле. Документація від Microsoft стверджує, що він (тип, в сенсі) повинен являти собою подвійне слово, то пак, по-англійськи DWORD. Проте у автора під Windows 2000 закачування по ftp починає працювати тільки після створення зазначених ключів типу одиночного слова (WORD), а DWORD-ключі операційна система вперто ігнорує. Містика якась …

Тепер поговоримо про оптимізацію з’єднання. Оптимізація – справа непроста. Це не те що: працює система або немає. Працювати-то вона працює, от тільки як? Тривіальним вимірюванням швидкості викачуваного файлу нічого з’ясувати не вдасться. Графік швидкості тільки у виняткових випадках (і на хороших каналах) представляється прямою лінією. Набагато частіше він нагадує трасу Урюпінськ – Ханти-Мансійськ: суцільні горби, вибоїни, ями … словом, украй поцяткована місцевість. Говорити про середній швидкості можна тільки в переносному сенсі, тим паче, що вона може сильно варіюватися в Залежно від часу доби, сервера, з яким встановлено з’єднання, кількості опадів, що випали в Африці, та хіба мало ще від чого!

До початку експериментів буде потрібно зібрати статистику роботи мережі за деякий час, скажімо, за тиждень. У цьому допоможе програма Net Medic (download.ru/) Або будь-яка інша, аналогічна їй. Потім, після внесення змін в налаштування системи, збирається інша статистика, знову-таки протягом семи-десяти днів, і порівнюється з попередньої: чи змінилося що і якщо так, то в який бік?

Справа це, звичайно, повільне, але іншого способу тонкої налаштування немає. Необхідно переконатися в збільшенні швидкості обміну з усіма серверами і у всі часи доби, тобто, знайти компромісний оптимум. Чи не все, що добре для одного випадку, так само добре підходить для іншого. Взяти ту ж фрагментацію вже розглянуту вище. Автоматичне визначення відповідного розміру пакета не завжди збільшує швидкість з’єднання, нерідко воно її зменшує, часом досить значно, – автоматичне визначення займає якийсь час, збільшуючи накладні витрати і знижуючи ККД. Має сенс спробувати знайти оптимальне значення вручну.

Передусім необхідно вказати Windows, що потрібно використовувати не максимально можливий, а заздалегідь обумовлений розмір пакета. Для цього встановіть значення ключа PMTUDiscovery
(EnablePMTUDiscovery) В нуль. Потім задайте бажаний розмір пакета. За замовчуванням він дорівнює 576 байтам – це значення за стандартом повинні підтримувати всі маршрутизатори, – та тільки хто ці стандарти дотримується? Ось і зустрічаються вузли, що обробляють пакети розміром не більше 512, 522, 556, … байт. В принципі, можна поставити 500 і не мучитися проблемою вибору, але так нецікаво. Хіба не заманливо методичним підбором байтів оптимізувати з’єднання до кінця?

Розмір пакетів для Windows 95 \ 98 задається ключем
MaxMTU, Що знаходиться в тій же самій гілці реєстру, що і попередні ключі. З Windows NT \ 2000 складніше: щоб з’ясувати місце розташування ключа 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х (Де х – розмір пакета без заголовка, званий також “Квіком»), А то й більше. Деякі відчайдухи пробують навіть більші значення і стверджують, що все працює “на ура!”, але у автора такі значення не показують чудес продуктивності, тому підтвердити сказане він не береться. Розмір заголовка непостійний і варіюється від 40 до 60 байт, – не забувайте про це при пошуку оптимальної ширини вікна!

Для зміни розмірів вікна відкрийте гілку реєстру
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \
MSTCP
для Windows 95 \ 98 і HKEY_LOCAL_MACHINE \ System \
CurrentControlSet \ Services \ Tcpip \ Parameters
для Windows NT \ 2000. Знайдіть або при необхідності створіть двійковий параметр (подвійне слово,
DWORD) DefaultRcvWindow для Windows 95 \ 98 і
TcpWindowSize для Windows NT \ 2000. Дайте йому бажане значення (наприклад “3680”, якщо розмір пакета, заданий ключем MTU, дорівнює 500 байт: (500 – 40) * 8 = 3/600) і перезавантажити.

Оцініть, як змінилася швидкість з’єднання. Якщо вона зросла, збільшіть ширину вікна ще на один квік (не байт!), якщо зменшилася, – звузьте вікно, а якщо залишилася без змін, – розширте вікно на пару квік. Так, в кінці кінців, буде знайдено оптимальне значення. Інтернет-гуру стверджують, що оптимум ширини вікна залежить від завантаженості провайдера і сильно коливається протягом доби. При максимальній завантаженості в “годину пік” вікно краще прикривати, залишаючи лише вузьку щілину (3х-4х), А вночі, коли всі нормальні юзери давно спатоньки, і канал повністю вільний – широко розорювати обидві стулки (10x і вище). Ніяких добових варіацій у своїх провайдерів автор не помічав, але готовий повірити, що в деяких випадках вони можуть мати місце, і гуру не брешуть.

Крім вищезгаданих опцій реєстр Windows містить безліч інших значень, що відносяться до TCP / IP, але розповідати про кожного з них було б занадто утомливо, та й недоцільно, – для цього довелося б написати окрему книгу, сторінок так на п’ятсот.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*