Як оцінити пропускну здатність TCP між серверами

Як оцінити пропускну здатність TCP між серверами
Хостинг
19 Jun 2019

Отже, ви тільки що отримали сервер з гарантованим виділеним каналом на 1Гбіт/с (або більше) і були неприємно здивовані, виявивши відносно повільний трансфер файлів. Перш ніж писати в техпідтримку та шукати проблеми в мережі, оцініть реальну пропускну здатність TCP від ​​одного хоста до іншого.

Слід виділити два найважливіші фактори для успішної передачі даних за протоколом TCP:

  • розмір TCP-вікна — кількість байт, яку одна із сторін готова прийняти без підтвердження;
  • кругова затримка (латентність) передачі-приймання — час, витрачений на відправку пакета та підтвердження його доставки.

Якщо ви знаєте обидва ці показники, то легко розрахуєте максимально можливу пропускну здатність між двома хостами незалежно від ширини смуги пропускання.

Формула розрахунку пропускної спроможності TCP

Пропускна здатність TCP (біт/с) = Розмір TCP-вікна (біт) / Кругова латентність (с)

Розберемо на простому прикладі. Є гігабітний Ethernet-канал між серверами із круговою затримкою 30 мс. Необхідно надіслати великий файл із одного сервера на інший сервер за протоколом FTP. На яку реальну пропускну здатність можна розраховувати?

Спершу необхідно перевести розмір TCP-вікна з байтів у біти. В даному випадку буде задіяно стандартне TCP-вікно Windows-машини розміром 64 КБ = 65536 Б = 65536 * 8 = 524288 біт.

Потім необхідно взяти розмір TCP-вікна в бітах і розділити його на кругову латентність каналу, виражену в секундах. Для цілей даних розрахунків 30 мс перетворюється на 0.030 с.

Максимальна пропускна спроможність TCP = 524 288 біт / 0.030 с = 17 476 266 біт/с = 17.4 Мбіт/с

Таким чином, незважаючи на те, що між двома серверами є гігабітний Ethernet-зв'язок, при передачі файлів не можна розраховувати більш ніж на 17 Мбіт/с.

Як можна зробити мережу швидше? Відповідь очевидна: збільшити розмір TCP-вікна та/або скоротити затримку сигналу.

Для того, щоб узгодити більший розмір TCP-вікна, потрібне індивідуальне ручне налаштування кожного сервера. Це, у свою чергу, призводить до такого питання: який розмір TCP-вікна можна вважати оптимальним? Щоб з'ясувати це, необхідно провести обчислення, спираючись на ширину смуги пропускання.

Формула для розрахунку оптимального розміру TCP-вікна

Розмір TCP-вікна (байт) = Розмір TCP-вікна (біт) / 8 = Пропускна здатність (біт/с) * Кругова латентність (с) / 8

У наведеному вище прикладі для гігабітного Ethernet-маршруту між серверами з круговою затримкою 30 мс, виходить таке значення:

1 000 000 000 біт/с * 0.030 с = 30 000 000 біт/8 = 3 750 000 байтів.

Іншими словами, якщо налаштувати обидва сервери на TCP-вікно в 3750 КБ, FTP-з'єднання повністю заповнить смугу пропускання і досягне пропускної здатності в 1 Гбіт/с.

Слід знати, що збільшення розміру TCP-вікна має свої недоліки.

По-перше, це вимагатиме більше пам'яті для буферизації серверів, яка потрібна для зберігання непідтверджених даних на випадок їх повторного відправлення.

По-друге, збільшений розмір TCP-вікна може спричинити більшу кількість втрачених пакетів, які, у свою чергу, вимагають повторної передачі всього вікна. Це може негативно позначитися на продуктивності. Для вирішення цієї проблеми у стеку TCP/IP сервера може бути активована опція «вибіркові підтвердження», яка за замовчуванням вимкнена.

Один із варіантів вирішення проблеми - розміщення WAN-акселераторів - прискорювачів глобальної мережі на кожному кінці лінії. Вони:

  • відкривають збільшене вікно TCP;
  • надають можливість тонкої оптимізації протоколу TCP (наприклад, вибіркові підтвердження лише між акселераторами);
  • не вимагають спеціальної установки серверів або додаткової буферної пам'яті;
  • можуть використовувати особливі функції прикладного рівня моделі OSI (Layer 7 — доступ до мережевих служб) для скорочення затримки.

Латентність

Зменшити затримку сигналу? Чи це можливо в принципі? Ми не можемо подолати швидкість світла, а отже, ніяк не можемо вплинути на час проходження сигналом заданої відстані.

Оптимальний спосіб оптимізації, знову ж таки, полягає в установці WAN-прискорювача на кожному кінці лінії, який передає отримані TCP-пакети локальному серверу, тим самим обманюючи його на предмет реальної швидкості трансферу даних. Локальний сервер приймає моментальні підтвердження прискорювача замість того, щоб чекати загальмований відгук віддаленого сервера. Це позбавляє нас необхідності коригування розміру TCP-вікна на самих серверах.

Пара WAAS-пристроїв використовують збільшений розмір TCP-вікна та вибіркові підтвердження на всій ділянці лінії між ними.

Крім того, WAAS ефективно очищають TCP-потік від надлишкових резервних даних, забезпечуючи надзвичайно високий рівень компресії (стиснення). Кожен акселератор запам'ятовує раніше переглянуті дані. Якщо дублюючий фрагмент виникає повторно, він видаляється і замінюється крихітною 2-байтовою міткою. Ця мініатюрна мітка розпізнається віддаленим прискорювачем, який замість неї вставляє оригінальний фрагмент даних перед відправкою трафіку на локальний сервер.

Підтверджений на практиці результат оптимізації — більш висока пропускна спроможність лінії між серверами без спеціального TCP-налаштування локальних серверів.

Формула для розрахунку максимальної допустимої затримки для заданої пропускної спроможності

Приклад. На ділянці між двома віддаленими серверами необхідно гарантувати пропускну здатність FTP 10 Гбіт/с, використовуючи стандартний розмір TCP-вікна (64 КБ). Яка максимальна затримка сигналу допустима?

Кругова латентність (мс) = Розмір TCP-вікна (біт) / Необхідна пропускна здатність (біт/с)

524 288 біт / 10 000 000 000 біт/с = 52.4 мікросекунди

Що робити?

В принципі, ви можете не збільшувати TCP-вікно і не встановлювати WAN-прискорювачі. Просто використовуйте багатопоточність і ви зможете використовувати канал на 100% його пропускної спроможності!