Коли протокол Transmission Control Protocol було стандартизовано в RFC 793 у вересні 1981 року, лінії мережі ARPANET функціонували через мідні канали зі швидкістю 56 кбіт/с, а затримки передачі вимірювалися мілісекундами. У ту обчислювальну добу виділення 16-бітного цілого числа під поле вікна прийому (rcv_wnd) вважалося цілком достатнім. Це 16-бітне поле обмежувало максимальний обсяг непідтверджених даних у транзиті величиною $2^{16} - 1 = 65 535$ байтів (64 КБ).

Через десятиліття глобальна цифрова інфраструктура кардинально трансформувалася. Корпоративні магістралі, високошвидкісні оптичні лінії та захищені оверлейні мережі VPN з'єднують континенти з круговою затримкою (RTT), що перевищує 100 мілісекунд. За таких умов фіксований ліміт у 64 КБ перетворюється на штучне вузьке місце, що обмежує реальну швидкість передачі до крихітної частки від фізичної ємності каналу.

Специфікація RFC 7323 (яка замінила RFC 1323) представила опцію масштабування вікна TCP Window Scale разом із технологією PAWS (Protection Against Wrapped Sequence Numbers). Розширюючи ефективний розмір вікна прийому до 1 гігабайта та застосовуючи мікросекундні часові позначки для захисту швидкісних потоків, RFC 7323 дозволяє мережевим тунелям та інфраструктурі VPN демонструвати максимальну продуктивність на глобальних відстанях.

Бар'єр 64 КБ: класичний механізм вікна TCP та виклик LFN

У класичному TCP керування потоком ґрунтується на концепції ковзного вікна. Отримувач постійно повідомляє відправнику розмір вільного буфера через 16-бітне поле Window у заголовку сегмента:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Порт джерела         |        Порт призначення       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Номер послідовності                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Номер підтвердження (ACK)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Зсув  |           |U|A|P|R|S|F|                               |
|даних  | Резерв    |R|C|S|S|Y|I|          Вікно прийому        |
|       |           |G|K|H|T|N|N|           (16 бітів)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Оскільки поле вікна обмежене лише 16 бітами, відправник може надіслати щонайбільше 65 535 байтів, після чого змушений зупинити передачу в очікуванні підтвердження (ACK) від іншої сторони.

У швидкісних мережах із відчутною затримкою — визначених у стандарті як Long Fat Networks (LFN) — час на передачу пакета й повернення підтвердження жорстко лімітує продуктивність. Якщо лінія має затримку RTT у 100 мс, відправник витрачає 100 мс на очікування підтвердження кожної порції у 64 КБ. Гранична швидкість знижується до:

$$\text{Швидкість}_{\max} = \frac{\text{Розмір вікна}}{\text{RTT}} = \frac{65 535 \text{ байтів}}{0,100 \text{ с}} \approx 5,24 \text{ Мбіт/с}$$

Навіть на виділеному оптичному каналі 10 Гбіт/с сесія TCP без масштабування вікна не здатна передавати швидше ніж 5,24 Мбіт/с за затримки 100 мс. Понад 99,9% фізичної смуги пропускання простоює.

Добуток пропускної здатності на затримку (BDP): фізика даних у каналі

Щоб повноцінно завантажити швидкісну магістраль, відправник має безперервно генерувати обсяг непідтверджених даних, достатній для заповнення фізичної ємності каналу між вузлами. Цей показник має назву добуток пропускної здатності на затримку (Bandwidth-Delay Product, BDP):

$$\text{BDP} = \text{Пропускна здатність (біт/с)} \times \text{Кругова затримка RTT (с)}$$

Порівняємо типові варіанти інфраструктури:

Тип з'єднання Смуга Затримка RTT Розрахований BDP Потрібен Window Scale?
Міська лінія Metro 1 Гбіт/с 2 мс 250 КБ Так ($> 64\text{ КБ}$)
Трансатлантичний VPN 1 Гбіт/с 80 мс 10 МБ Так (Обов'язково)
Міжконтинентальна хмара 10 Гбіт/с 160 мс 200 МБ Так (Обов'язково)

Коли обчислений показник BDP перевищує 65 535 байтів, класичний протокол TCP не спроможний наситити магістраль. Без масштабування вікна швидкісна мережа нагадує порожню багатосмугову автомагістраль, на яку випустили єдиний повільний автомобіль.

+-----------------------------------------------------------------------------+
|                МОДЕЛЬ НАСИЧЕННЯ КАНАЛУ ДАНИМИ ЗА ПОКАЗНИКОМ BDP             |
+-----------------------------------------------------------------------------+
Відправник ======[ Пакети в польоті (мають відповідати BDP) ]=====> Отримувач
           <=====[ Безперервний потік зворотних пакетів ACK ]=======

Архітектура TCP Window Scale: механізми протоколу RFC 7323

Стандарт RFC 7323 долає обмеження 16-бітного поля за допомогою використання поля опцій TCP (TCP Options), зберігаючи базовий 20-байтний заголовок без будь-яких змін.

Узгодження при тристоронньому рукостисканні та кодування Shift Count

Опція TCP Window Scale міститься виключно у пакетах із встановленим прапорцем SYN на початковому етапі встановлення з'єднання:

+----------------------------------------------------+
|  Kind = 3 (1 октет)  | Довжина Length = 3 (1 октет)|
+----------------------------------------------------+
|  Коефіцієнт зсуву Shift Count: S (Діапазон: 0-14)  |
+----------------------------------------------------+

Поле Shift Count $S$ розміром в 1 октет визначає коефіцієнт двійкового зсуву. Для всіх наступних сегментів без прапорця SYN дійсний розмір вікна прийому обчислюється шляхом бітового зсуву 16-бітного значення заголовка ліворуч на $S$ позицій:

$$\text{Ефективне вікно} = \text{Значення в заголовку} \times 2^S$$

Оскільки стандарт встановлює максимальний зсув на рівні $S = 14$, початкове 16-бітне вікно трансформується у 30-бітний еквівалент:

$$\text{Вікно}_{\max} = 65 535 \times 2^{14} = 1 073 725 440 \text{ байтів } (\approx 1,07 \text{ ГБ})$$

Такого вікна обсягом понад 1 ГБ достатньо для ефективної роботи каналів 100 Гбіт/с на трансокеанських дистанціях.

Асиметричне масштабування та ризики спотворення вікна проміжними вузлами

Узгодження опції масштабування є двостороннім та асиметричним. Хост A може оголосити значення $S = 7$ з огляду на обсяг своєї пам'яті, тоді як хост B пропонує $S = 9$. Кожен бік підтримує власний масштабний множник для вхідного трафіку.

Однак якщо застарілий фаєрвол чи некоректний транслятор NAT вирізає опцію Window Scale із пакетів SYN, з'єднання автоматично повертається до 16-бітного формату. Якщо ж посередницький шлюз спотворює поле вікна без перерахунку узгодженого коефіцієнта зсуву, зв'язок зазнає раптового падіння швидкості або обриву.

Захист від переповнення номерів послідовності PAWS та вимірювання RTTM

Збільшення розміру вікна понад 64 КБ породжує ризик швидкого вичерпання простору порядкових номерів пакетів.

Порядкові номери TCP кодуються 32-бітним числом, забезпечуючи діапазон у $2^{32} = 4 294 967 296$ байтів (~4,29 ГБ). На високих швидкостях цей простір проходить повний цикл обертання за лічені секунди:

  • За швидкості 1 Гбіт/с: Простір номерів обертається за 34,3 секунди.
  • За швидкості 10 Гбіт/с: Час обертання становить 3,4 секунди.
  • За швидкості 40 Гбіт/с: Повний оборот триває лише 0,86 секунди.

За стандартними правилами TCP старий пакет, що затримався в буферах провайдерів, може надійти під час наступного циклу обертання з валідним номером, що призведе до непомітного спотворення структури файлу.

Затриманий старий пакет (Seq: 10 000) --------------------\
                                                          \
Поточний потік (Обернений Seq: 10 000) ===> Буфер прийому ---> [ СПОТВОРЕННЯ ДАНИХ! ]

Механізми опції часових позначок та швидкісний цикл переповнення номерів

RFC 7323 усуває цю проблему за допомогою механізму PAWS (Protection Against Wrapped Sequence Numbers) через опцію часових позначок (Kind=8, Length=10):

+----------------------------------------------------+
|  Kind = 8 (1 октет)  | Довжина Length = 10 (1 октет|
+----------------------------------------------------+
|  Значення часової позначки: TSval (4 октети)       |
+----------------------------------------------------+
|  Ехо-відповідь позначки: TSecr (4 октети)          |
+----------------------------------------------------+

Алгоритм PAWS сприймає 32-бітне поле TSval як монотонний лічильник часу. Коли пакет потрапляє в активне вікно, отримувач перевіряє, чи його часова позначка не менша за позначку останнього прийнятого пакета:

$$\text{TSval} \ge \text{TS.Recent}$$

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

Автоматичне налаштування буферів сокетів у ядрі Linux та пам'ять

Підтримка стандарту RFC 7323 не принесе результату, якщо стек операційної системи обмежує пам'ять сокетів. Ядро Linux використовує механізм автоматичного динамічного виділення буферів (autotuning), масштабуючи пам'ять відповідно до обсягу трафіку.

Конфігурація параметрів tcp_rmem, tcp_wmem та лімітів SO_RCVBUF

Стек Linux контролює буфери надсилання та прийому через масиви з трьох величин [мінімум, за замовчуванням, максимум]:

# Перевірка поточних параметрів мережі TCP
sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Для вузлів із високошвидкісними магістральними лініями слід задати відповідні верхні ліміти:

# Увімкнення розширень стандарту RFC 7323
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_timestamps=1

# Збільшення граничного буфера сокетів до 64 МБ
sysctl -w net.ipv4.tcp_rmem="4096 131072 67108864"
sysctl -w net.ipv4.tcp_wmem="4096 65536 67108864"

# Підняття глобальних лімітів системної пам'яті
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864

Слід уникати викликів setsockopt(..., SO_RCVBUF, ...) зі статичними величинами в застосунках, оскільки це вимикає автоналаштування ядра та обмежує потік малим фіксованим вікном.

Інкапсуляція у VPN-тунелях та колізії ковзного вікна TCP

Під час транспортування пакетів TCP через шифрований тунель VPN (WireGuard або IPsec) виникають певні особливості:

  1. Накладні витрати заголовків: Додавання зовнішніх заголовків IP/UDP та блоків авторизації зменшує MTU (наприклад, з 1500 до 1420 байтів). За відсутності налаштованого фіксування MSS пакети фрагментуються, що призводить до падіння вікна.
  2. Bufferbloat та коливання затримки: Якщо маршрутизатор накопичує пакети в глибоких чергах, RTT нестабільно коливається. Стек TCP вважає це перевантаженням і невиправдано звужує вікно (cwnd).
  3. Ефект збою TCP-у-TCP: Загортання трафіку TCP у тунель, побудований на протоколі TCP, спричиняє лавину повторних передач у разі втрати пакетів, паралізуючи зв'язок.

Сучасні тунелі покладаються на транспорт UDP у поєднанні з оптимізацією буферів під реальний показник BDP.

Практичне тестування: пропускна здатність на трансокеанських магістралях

Переваги активації розширення TCP Window Scale наочно ілюструють результати бенчмарків:

Профіль з'єднання Затримка RTT Класичний TCP (без опції) TCP із масштабуванням Коефіцієнт зростання
Міська лінія (1 Гбіт/с) 25 мс 20,9 Мбіт/с 940 Мбіт/с У 45 разів швидше
Трансатлантика (1 Гбіт/с) 85 мс 6,1 Мбіт/с 920 Мбіт/с У 150 разів швидше
Транстихоокеанський канал (1 Гбіт/с) 160 мс 3,2 Мбіт/с 890 Мбіт/с У 278 разів швидше
Міжконтинентальна хмара (10 Гбіт/с) 120 мс 4,3 Мбіт/с 8 750 Мбіт/с У 2 034 рази швидше

Без розширення RFC 7323 орендування багатогігабітних магістралей не забезпечує зростання швидкості для окремих сесій передачі даних.

Як RiceGuard оптимізує буфери сокетів та масштабування вікна на повній швидкості

Глобальна мережа Anycast сервісу VPNRice налічує понад 40 вузлів у ключових точках світу. Користувачі можуть оцінити маршрут підключення та пінг за допомогою інструмента перевірки IP VPNRice.

Для гарантування швидкісної передачі трафіку через транскордонні відстані в протоколі RiceGuard реалізовано комплекс оптимізацій:

  1. Кільцеві буфери нульового копіювання: Архітектура безблокувальних черг у просторі користувача обробляє масиви BDP у десятки мегабайтів без витрат ресурсів ядра на копіювання.
  2. Динамічне фіксування MSS: Граничні шлюзи Anycast аналізують внутрішні пакети TCP SYN і виставляють оптимальний розмір MSS відповідно до MTU тунелю, запобігаючи фрагментації.
  3. Захист заголовків: RiceGuard нормалізує опції TCP на магістральних стиках, унеможливлюючи вирізання полів Window Scale та часових позначок.
  4. Співпраця з Anycast: Інтеграція налаштованих буферів із маршрутизацією BGP ADD-PATH та моніторингом ліній BFD забезпечує стабільний трафік без зайвого джитера.

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

+-----------------------------------------------------------------------------+
|             АРХІТЕКТУРА ШВИДКІСНОЇ ПЕРЕДАЧІ ДАНИХ RICEGUARD                 |
+-----------------------------------------------------------------------------+
[ Пристрій користувача ]
       | (Буфер сокета, оптимізований під BDP)
       v
[ Тунель RiceGuard (Інкапсуляція WireGuard UDP) ]
       |
       +---> Внутрішній TCP: Масштабування RFC 7323 (Зсув S=7)
       +---> Внутрішній TCP: Активний PAWS (Часові позначки)
       +---> Шлюз: Автоматичне фіксування MSS (Без фрагментації)
       v
[ Віддалений корпоративний сервер / Хмара ] (Повне заповнення каналу BDP)

Поєднання оптимізацій транспортного рівня з контролем сесій—як-от управління станом TCP TIME-WAIT—створює надійний канал зв'язку на будь-яких відстанях.

Чек-лист оптимізації високошвидкісного TCP та тунелів VPN у продакшені

Для досягнення максимальної пропускної здатності на каналах із помітною затримкою рекомендується дотримуватися наступного плану дій:

  • Перевірка опції масштабування: Виконайте sysctl net.ipv4.tcp_window_scaling та переконайтеся, що значення становить 1.
  • Активація часових позначок: Перевірте статус net.ipv4.tcp_timestamps (1) для підтримки роботи механізму PAWS.
  • Розрахунок величини BDP: Помножте бажану пропускну здатність на час RTT для визначення необхідного обсягу буфера в байтах.
  • Підняття стелі буферів: Збільште граничні параметри net.ipv4.tcp_rmem та net.ipv4.tcp_wmem вище від розрахованого BDP.
  • Аудит проміжних мережевих пристроїв: За допомогою tcpdump переконайтеся у наявності опції Window Scale в обох пакетах SYN та SYN-ACK.
  • Налаштування фіксування MSS: Впровадьте правила автоматичного підлаштування MSS під розмір MTU на шлюзах доступу VPN.
  • Моніторинг повторних передач: Аналізуйте лічильники повторних пакетів для розрізнення фізичного перевантаження лінії та дефіциту сокетних буферів.