Мені потрібно кілька дуплексних каналів між двома хостами. Існує ряд переваг для встановлення лише одного TCP-з'єднання. Але я сумніваюся, що мультиплексування спричинить неминучі проблеми. Чи це завдасть шкоди продуктивності або збільшить затримку? А як щодо використання пам'яті та використання процесора? Чи є якась пропозиція чи застереження, які ви хочете дати?
Відповіді:
TLDR: Основний недолік, який ви можете помітити, коли мультиплексування декількох каналів у верхній частині TCP (якщо ви зробите це правильно), - це збільшена затримка через блокування прямих ліній між каналами.
Висновок: Якщо ви не піклуєтесь про затримку, вам слід добре.
З іншого боку, використання єдиного TCP-з'єднання "означає меншу конкуренцію з іншими потоками та триваліші зв'язки, що, в свою чергу, призводить до кращого використання наявної ємності мережі" .
Якщо ви мультиплексуєте кілька каналів поверх одного і того ж потоку TCP, канали можуть зазнати блокування прямого рядка :
Блокування прямих рядків (HOL) може статися, коли протоколи транспорту пропонують замовлену або частково замовлену послугу: Якщо сегменти втрачаються, наступні повідомлення повинні чекати успішної повторної передачі в черзі приймача, і таким чином затримуються.
Коли ви мультиплексуєте кілька потоків поверх TCP, ви отримуєте HOL між каналами .
Якщо канал A заповнив буфер відправлення TCP, вам доведеться почекати, перш ніж всі ці дані будуть отримані, перш ніж будь-які нові дані каналу В можуть ефективно передатись на віддалений рівень програми.
Див. "Мультиплексування зверху TCP" для отримання більш детальної інформації про мультиплексування каналів поверх TCP та обговорення на hackernews .
Типовим прикладом цього є SSH. SSH може мультиплексировать кілька каналів (див ControlMaster, ControlPathі ControlPersistв OpenSSH). Використання цього зменшує витрати на ініціалізацію нового сеансу SSH (початкова затримка), але велика передача на одному каналі зазвичай збільшує затримку / інтерактивність інших (що не відбувається, якщо ви використовуєте кілька потоків TCP): якщо ви використовуєте інтерактивний сеансів і почати тригерувати велику передачу файлів на одному каналі, ваш сеанс почне отримувати набагато менш інтерактивний.
HTTP / 2 використовує мультиплексування запитів / відповідей через TCP, щоб виправити блокування HOL. Ця функція рекламується у багатьох статтях та працях про HTTP / 2. У HTTP / 2 RFC претензії:
HTTP / 1.1 додав запит на конвеєрний запит, але це лише частково адресований запит одночасно і все ще страждає від блокування прямого рядка.
[...]
Отриманий протокол є більш сприятливим для мережі, оскільки в порівнянні з HTTP / 1.x можна використовувати менше з'єднань TCP. Це означає меншу конкуренцію з іншими потоками та триваліші зв’язки, що, в свою чергу, призводить до кращого використання наявної ємності мережі.
Однак не обговорюється те, що блокування HOL не вирішено повністю. HTTP / 2 через TCP все ще страждає ) від блокування HOL на рівні TCP .
Про це йдеться в цій статті LWN про QUIC:
HTTP / 2 був розроблений для вирішення цієї проблеми за допомогою декількох "потоків", вбудованих в єдине з'єднання . [...] це створює нову проблему: втрата одного пакету зупинить передачу всіх потоків одразу, створюючи нові проблеми затримки. Цей варіант проблеми з блокуванням прямої лінії вбудований у сам TCP і його неможливо виправити за допомогою більшої кількості настроїв на рівні HTTP.
Це одна з відмінних особливостей SCTP (багатопотокової передачі), ви можете мати кілька незалежних потоків в одній і тій же асоціації SCTP, і кожен потік не блокує інші.
Див. Розділ SSH через SCTP - оптимізація багатоканального протоколу шляхом адаптації його до SCTP для ефекту використання SCTP, щоб уникнути міжканального блокування HOL у SSH:
SCTP зберігає лише порядок повідомлень у межах одного потоку для зменшення ефекту, відомого як блокування прямого рядка. Якщо повідомлення втрачено, наступні повідомлення потрібно відкладати, поки втрачене не буде повторно передано для збереження замовлення. Оскільки лише повідомлення одного потоку мають бути відкладені, кількість постраждалих повідомлень після втрати зменшується.
[...]
Шляхом відображення каналів SSH на потоки SCTP, перевагу багатопотокового передавання надається SSH, що є пом’якшенням блокування прямого каналу .
Розгортання SCTP не обов'язково просте (через доступність ОС, взаємодію із середнім ящиком тощо). Можливість полягає в його реалізації через UDP в просторі користувачів .
Іншим прикладом є експериментальний протокол QUIC, який використовується для мультиплексування HTTP через UDP (оскільки мультиплексування декількох потоків поверх TCP, оскільки HTTP / 2 страждає від блокування HOL ):
QUIC - це новий транспорт, який зменшує затримку в порівнянні з TCP. На поверхні, QUIC дуже схожий на TCP + TLS + HTTP / 2, реалізований на UDP.
[...]
Мультиплексування без блокування заголовка лінії
Протокол QUIC від Google: переміщення Інтернету від TCP до UDP представляє хороший огляд блокування QUIC та HOL при мультиплексування каналів поверх TCP.
Нещодавня презентація стверджує, що HTTP над QUIC покращує затримку, але поліпшення блокування HOL є "меншою перевагою":
0-RTT, Понад 50% поліпшення затримки
[…]
Менша кількість повторних передач на основі таймауту покращує затримку хвоста […]
Інші, менші переваги, наприклад, блокування головних ліній
Зауважте, що хоча QUIC описується як "дуже схожий на TCP + TLS + HTTP / 2, реалізований на UDP", насправді транспорт загального призначення, який можна використовувати незалежно від HTTP / 2 і може відповідати вашим потребам.
Примітка: HTTP / QUIC буде стандартизована як HTTP / 3 .
Я б сказав, що вам потрібно прочитати посібник із ZeroMQ , тому що його моделі мають причини та недоліки.
Але в іншому випадку немає проблеми з відключенням мережевого каналу від доставки даних додатків. Вам доведеться взяти на себе вимкнення та демонізування надісланих пакетів даних (і я би рекомендував тут архітектуру на основі пакетів, не потоку даних у безперервному потоці) та буферизацію їх на кожному кінці.
В іншому випадку це має бути незначним впливом, можливо, вам буде потрібно більше пам'яті, але лише трохи - для буферизації даних та трохи більше процесора, коли ви обробляєте більше коду для блокування та розбору пакетів, але нічого значущого. (якщо ви не пишете щось спеціаліста, що вимагає великої пропускної спроможності, а продуктивність є критичною).
Так, я створив систему баз даних клієнт-сервер, використовуючи саме цей принцип.
Канали, мультиплексовані на одне TCP-з'єднання, кожен надсилає пакети даних, які потім розбиваються на відповідних одержувачів на іншому кінці.
Перемикання з'єднання одним неприємним каналом здійснює відправник з'єднання TCP, здійснюючи круговий вибір, який пакет передавати з-поміж каналів, які мають дані, готові відправити.
Для обробки випадку одного каналу, який вирішив надіслати пакет 1 Гб і заблокувати всіх інших, відправник може вирішити розділити пакет на шматки і надіслати лише один фрагмент, перш ніж він подасть черговий канал. На кінці отримання повторне збирання шматочків в пакет робиться до того, як одержувач побачить пакет.