Jump to content

Многопутевой TCP

Многопутевой TCP (MPTCP)
Протокол связи
Цель Общего назначения
Разработчик(и) IETF
Введение 2009 год ; 15 лет назад ( 2009 )
На основе IP , обычно на уровне TCP
Уровень OSI Транспортный уровень
RFC(ы) RFC   8684

Multipath TCP ( MPTCP ) — это постоянная работа рабочей группы Multipath TCP Инженерной группы Интернета (IETF), цель которой — разрешить соединению по протоколу управления передачей (TCP) использовать несколько путей для максимизации пропускной способности и увеличения избыточности. [1]

В январе 2013 года IETF опубликовал спецификацию Multipath в качестве экспериментального стандарта. RFC   6824 . В марте 2020 года он был заменен спецификацией Multipath TCP v1 в РФК 8684 .

Преимущества

[ редактировать ]

Избыточность, предлагаемая Multipath TCP, обеспечивает обратное мультиплексирование ресурсов и, таким образом, увеличивает пропускную способность TCP до суммы всех доступных каналов канального уровня вместо использования одного, как того требует стандарт TCP. Многопутевой TCP обратно совместим со стандартным TCP.

Многопутевой TCP особенно полезен в контексте беспроводных сетей; [2] является использование как Wi-Fi , так и мобильной сети Типичным вариантом использования . [3] Помимо увеличения пропускной способности за счет обратного мультиплексирования, каналы можно добавлять или удалять по мере того, как пользователь входит в зону покрытия или выходит из нее, не нарушая сквозного TCP-соединения. [4]

Таким образом, проблема передачи обслуживания решается посредством абстракции на транспортном уровне без использования каких-либо специальных механизмов на сетевом или канальном уровнях . Функциональность хэндовера затем может быть реализована на конечных точках без необходимости использования специальных функций в подсетях Интернета — в соответствии с принципом сквозной передачи данных .

Multipath TCP также обеспечивает повышение производительности в средах центров обработки данных . [5] В отличие от Ethernet объединения каналов с использованием агрегации каналов 802.3ad , Multipath TCP может балансировать одно TCP-соединение между несколькими интерфейсами и достигать очень высокой пропускной способности. [6]

Многопутевой TCP вызывает ряд новых проблем. С точки зрения сетевой безопасности многопутевая маршрутизация приводит к фрагментации данных по перекрестным путям, в результате чего брандмауэры и сканеры вредоносных программ становятся неэффективными, когда они видят трафик только по одному пути. Кроме того, расшифровка SSL станет неэффективной из-за протоколов сквозного шифрования. [7]

Пользовательский интерфейс

[ редактировать ]

Чтобы облегчить развертывание, Multipath TCP предоставляет тот же интерфейс сокетов, что и TCP. Это означает, что любое стандартное TCP-приложение может использоваться поверх Multipath TCP, фактически распределяя данные по нескольким подпотокам. [8]

Многопутевой TCP в стеке протоколов

Некоторым приложениям может быть полезен расширенный API для управления базовым стеком Multipath TCP. Было предложено два разных API для предоставления приложениям некоторых функций стека Multipath TCP: API, который расширяет Netlink в Linux. [9] и улучшенный API сокетов. [10]

Реализации

[ редактировать ]

В июле 2013 года рабочая группа MPTCP сообщила о пяти независимых реализациях Multipath TCP: [11] включая первоначальную эталонную реализацию [8] в ядре Linux. [12] [13]

Доступные на данный момент реализации :

реализация для Solaris В июле 2014 года Oracle сообщила, что разрабатывается . В июне 2015 года работы продолжаются. [22] Также продолжаются попытки внедрить новую реализацию Multipath TCP в основное ядро ​​Linux. [23]

Во время заседания рабочей группы MPTCP на конференции IETF 93 Сон Хун Со объявил, что KT с середины июня развернула коммерческую услугу, которая позволяет пользователям смартфонов достигать скорости 1 Гбит/с с использованием прокси-службы MPTCP. [24] Tessares использует реализацию ядра Linux для развертывания сетей гибридного доступа .

Варианты использования

[ редактировать ]

Multipath TCP был разработан с учетом обратной совместимости с обычным TCP. Таким образом, он может поддерживать любое приложение. Однако некоторые конкретные развертывания [25] использовать возможность одновременного использования разных путей.

Apple использует Multipath TCP для поддержки приложения Siri на iPhone . Siri отправляет образцы голоса через сеанс HTTPS на серверы Apple. Эти серверы отвечают информацией, запрошенной пользователями. По мнению инженеров Apple, основные преимущества [26] Multipath TCP с этим приложением:

  • Обратная связь с пользователем (время до первого слова) на 20 % быстрее в 95-м процентиле
  • Пятикратное сокращение сетевых сбоев

В других развертываниях используется Multipath TCP для объединения пропускной способности различных сетей. Например, некоторые типы смартфонов, особенно в Корее, используют Multipath TCP для соединения Wi-Fi и 4G через прокси-серверы SOCKS. [27] Другим примером являются сети гибридного доступа , которые развертываются сетевыми операторами, желающими объединить сети xDSL и LTE . В этом развертывании Multipath TCP используется для эффективной балансировки трафика в сетях xDSL и LTE. [28]

При стандартизации конвергентных сетей фиксированной и мобильной связи 3GPP и BBF взаимодействуют, обеспечивая функцию ATSSS (выбор, коммутация, разделение трафика доступа) для поддержки многопутевых сеансов, например, путем применения многопутевого TCP как в пользовательском оборудовании (UE), так и в пользовательском оборудовании (UE), или Резидентный шлюз (RG) и на стороне сети. [29]

Параметры многопутевого TCP

[ редактировать ]

Multipath TCP использует параметры, подробно описанные в разделе РФК 8684 . Все параметры Multipath TCP кодируются как параметры TCP с типом параметра 30, зарезервированные IANA. [30]

Параметр Multipath TCP состоит из стандартных значений Option-Kind (в данном случае 30) и длины, за которыми следует 4-битное поле подтипа, для которого IANA поддерживает подреестр под названием «Подтипы параметров MPTCP» в разделе «Управление передачей». Реестр параметров протокола (TCP). Это поле подтипа указывает тип заголовка MPTCP, а его значения определяются следующим образом:

Ценить Символ Имя
0x0 MP_CAPABLE Возможность многолучевого распространения
0x1 MP_JOIN Присоединиться к соединению
0x2 ДСС Сигнал последовательности данных (подтверждение данных и отображение последовательности данных)
0x3 АДД_АДДР Добавить адрес
0x4 REMOVE_ADDR Удалить адрес
0x5 MP_PRIO Изменить приоритет подпотока
0x6 MP_FAIL Отступать
0x7 MP_FASTCLOSE Быстрое закрытие
0x8 MP_TCPRST Сброс подпотока
0xf MP_ЭКСПЕРИМЕНТАЛЬНЫЙ Зарезервировано для частного использования

Значения от 0x9 до 0xe в настоящее время не назначены.

Протокол работы

[ редактировать ]

Упрощенное описание

[ редактировать ]
Разница между TCP и MPTCP

Основная идея многопутевого TCP заключается в определении способа построения соединения между двумя хостами, а не между двумя интерфейсами (как это делает стандартный TCP).

Например, у Алисы есть смартфон с интерфейсами 3G и WiFi (с IP-адресами 10.11.12.13 и 10.11.12.14), а у Боба — компьютер с интерфейсом Ethernet (с IP-адресом 20.21.22.23).

В стандартном TCP соединение должно быть установлено между двумя IP-адресами. Каждое TCP-соединение идентифицируется четырьмя кортежами (адресами и портами источника и назначения). Учитывая это ограничение, приложение может создать только одно TCP-соединение по одному каналу. Multipath TCP позволяет соединению использовать несколько путей одновременно. Для этого Multipath TCP создает одно TCP-соединение, называемое подпотоком, по каждому пути, который необходимо использовать.

Целью различных операций протокола (определенных в RFC 6824) является:

  • для обработки того, когда и как добавлять/удалять пути (например, если потеряно соединение или какой-то контроль перегрузки)
  • быть совместимым с устаревшим оборудованием TCP (например, с некоторыми межсетевыми экранами, которые могут автоматически отклонять TCP-соединения, если порядковый номер не является последовательным)
  • определить справедливую стратегию управления перегрузкой между различными каналами и разными хостами (особенно с теми, которые не поддерживают MPTCP)
Пример полной сессии MPTCP

Multipath TCP добавляет новые механизмы к TCP-передачам:

  • Система подпотоков, используемая для сбора нескольких стандартных TCP-соединений (путей от одного хоста к другому). Подпотоки идентифицируются во время трехэтапного подтверждения TCP. После подтверждения приложение может добавить или удалить некоторые подпотоки (подтипы 0x3 и 0x4).
  • Опция MPTCP DSS содержит порядковый номер данных и номер подтверждения. Они позволяют получать данные из нескольких подпотоков в исходном порядке без каких-либо повреждений (подтип сообщения 0x2).
  • Модифицированный протокол повторной передачи обеспечивает контроль перегрузки и надежность.

Подробная спецификация

[ редактировать ]

Подробная спецификация протокола представлена ​​в RFC 8684. В нескольких обзорных статьях представлено введение в протокол. [31] [32]

Контроль перегрузок

[ редактировать ]

Для Multipath TCP было определено несколько механизмов контроля перегрузки. Их главное отличие от классических схем управления перегрузкой TCP заключается в том, что им необходимо реагировать на перегрузку на разных путях, не допуская несправедливости по отношению к источникам TCP с одним путем, которые могут конкурировать с ними на одном из путей. [3] Реализация Multipath TCP в ядре Linux в настоящее время поддерживает четыре схемы управления перегрузкой Multipath TCP.

  • Алгоритм связанного увеличения, определенный в RFC 6356.
  • Алгоритм оппортунистического связанного увеличения [33]
  • Алгоритм контроля перегрузки на основе задержки wVegas
  • Алгоритм сбалансированного связанного увеличения [34]

Альтернативы

[ редактировать ]

Протокол передачи управления потоком

[ редактировать ]

Протокол передачи управления потоком (SCTP) — это надежный транспортный протокол упорядоченного потока дейтаграмм, первоначально предназначенный для передачи телекоммуникационных сигналов. Он поддерживает одновременное использование нескольких каналов доступа и позволяет приложению влиять на выбор интерфейса доступа на основе потока дейтаграмм. Он также поддерживает мобильность посредством повторного согласования доступа. Следовательно, SCTP также является решением транспортного уровня. Он предлагает степень детализации потока типа 3 с параллелизмом, но с большим контролем планирования потока, чем Multipath TCP. Он также полностью поддерживает мобильность, аналогично Multipath TCP. [35]

В архитектуре IP Multimedia Subsystem (IMS) протокол инициирования сеанса (SIP) может поддерживать одновременное использование нескольких контактных IP-адресов для регистрации одного или нескольких пользовательских агентов IMS. Это позволяет создавать несколько путей сигнализации IMS. По этим путям сигнализации сигнальные сообщения содержат сообщения протокола описания сеанса (SDP) для согласования медиапотоков. SDP позволяет (повторно) согласовывать потоки одного медиасеанса по нескольким путям. В свою очередь, это обеспечивает многопутевую транспортировку на уровне приложений. Таким образом, с этой точки зрения IMS может предложить поддержку многопутевого доступа на прикладном уровне с детализацией потока и одновременным доступом. многопутевое расширение транспортного протокола реального времени (RTP). В IETF обсуждается [36] Многопутевой RTP может обеспечивать гранулярность потока с одновременным доступом и мобильностью (через IMS, сигнализацию SDP или протокол управления RTP). [35] Совсем недавно, кроме того, в IETF в TSVWG (Рабочая группа по транспортной области) обсуждается предложение о расширении DCCP (Протокол управления перегрузкой дейтаграмм) функцией многопутевого распространения. [37] получивший название MP-DCCP .

Многопутевой QUIC

[ редактировать ]

IETF протоколам в настоящее время разрабатывает протокол QUIC , который объединяет функции, традиционно присущие TCP , TLS и HTTP . Его можно расширить для поддержки тех же вариантов использования, что и Multipath TCP. Была предложена первая конструкция Multipath QUIC. [38] реализовано и оценено. [39]

Другие протоколы и эксперименты

[ редактировать ]

На сеансовом уровне в 2003 году проект Mobile Access Router экспериментировал с агрегированием нескольких беспроводных устройств доступа с использованием разнородных технологий, прозрачно балансируя трафик между ними в зависимости от воспринимаемой производительности каждого из них. [40]

Схемы параллельного доступа [35] используемые для ускорения передачи за счет использования запросов диапазона HTTP для инициирования соединений с несколькими серверами реплицируемого контента, не эквивалентны Multipath TCP, поскольку они задействуют уровень приложения и ограничиваются контентом известного размера.

  • RFC 6181 — Анализ угроз для расширений TCP для многопутевой работы с несколькими адресами
  • RFC 6182 — Архитектурные рекомендации для разработки многопутевого TCP
  • RFC 6356 — Совмещенное управление перегрузкой для многопутевых транспортных протоколов
  • RFC 6824 — расширения TCP для многопутевой работы с несколькими адресами (v0; заменено RFC 8684)
  • RFC 6897 - Особенности интерфейса приложения многопутевого TCP (MPTCP)
  • RFC 7430 — Анализ остаточных угроз и возможные исправления для многопутевого TCP (MPTCP)
  • RFC 8041 — Варианты использования и опыт работы с многопутевым TCP
  • RFC 8684 — расширения TCP для многопутевой работы с несколькими адресами (v1)
  • RFC 8803 — протокол преобразования TCP 0-RTT

См. также

[ редактировать ]
  1. ^ Рабочая группа Multipath TCP
  2. ^ Пааш, Кристоф; Деталь, Грегори; Дюшен, Фабьен; Райчу, Костин; Бонавентура, Оливье (2012). «Изучение передачи обслуживания мобильной связи/Wi-Fi с помощью многопутевого TCP» . Материалы семинара ACM SIGCOMM 2012 г. по теме «Сотовые сети: эксплуатация, проблемы и будущее проектирование» — Cell Net '12 . Семинар ACM SIGCOMM по сотовым сетям (Cellnet'12). п. 31. дои : 10.1145/2342468.2342476 . ISBN  9781450314756 .
  3. ^ Jump up to: а б С. Похрель; М. Панда; Х. Ву (24 февраля 2017 г.). «Аналитическое моделирование многопутевого TCP в беспроводной сети последней мили». Транзакции IEEE/ACM в сети . 25 (3): 1876–1891. дои : 10.1109/TNET.2017.2663524 . S2CID   21518823 .
  4. ^ С. Похрель; М. Манджес (24 марта 2019 г.). «Улучшение производительности многопутевого TCP в сетях Wi-Fi и сотовых сетях: аналитический подход». Транзакции IEEE на мобильных компьютерах . 25 (3): 1876–1891. дои : 10.1109/TMC.2018.2876366 . S2CID   69263415 .
  5. ^ Райчу; Барре; Плантке; Гринхал; Вищик; Хэндли (2011). «Повышение производительности и надежности центра обработки данных с помощью многопутевого TCP» . Обзор компьютерных коммуникаций ACM SIGCOMM . 41 (4): 266. CiteSeerX   10.1.1.306.3863 . дои : 10.1145/2043164.2018467 . S2CID   61962047 .
  6. ^ К. Пааш; Г. Деталь; С. Барре; Ф. Дюшен; О. Бонавентура. «Самое быстрое TCP-соединение с Multipath TCP» . Проверено 20 сентября 2013 г.
  7. ^ Афзал, Зишан (2020). Жизнь промежуточного блока безопасности. Проблемы с новыми протоколами и технологиями (доктор философии). ISBN  978-91-7867-103-8 . OCLC   1139703033 .
  8. ^ Jump up to: а б с «Проект MultiPath TCP ядра Linux» . Проверено 28 ноября 2014 г.
  9. ^ Хесманс, Б.; Деталь, Г.; Барре, С.; Бодуэн, Р.; Бонавентура, О. (2015). «СМАПП». SMAPP для интеллектуальных приложений с поддержкой Multipath TCP . стр. 1–7. дои : 10.1145/2716281.2836113 . ISBN  9781450334129 . S2CID   9940025 .
  10. ^ Хесманс, Бенджамин; Бонавентура, Оливье (2016). «Расширенный API сокетов для Multipath TCP». Материалы семинара 2016 года по прикладным сетевым исследованиям - ANRW 16 . стр. 1–6. дои : 10.1145/2959424.2959433 . ISBN  9781450344432 . S2CID   13799560 .
  11. ^ «Обзор внедрения MPTCP (Интернет-проект, 2013 г.)» . Проверено 20 сентября 2013 г.
  12. ^ Барре; Пааш; Бонавентура (2011). «MultiPath TCP: от теории к практике» . Сеть ИФИП .
  13. ^ Райчу; Пааш; Барре; Форд; Хонда; Дюшен; Бонавентура; Хэндли (2012). «Насколько это может быть сложно? Проектирование и реализация развертываемого многопутевого TCP» . Усеникс NSDI : 399–412.
  14. ^ «Проект Linux MPTCP Upstream» .
  15. ^ «Многопутевой TCP для FreeBSD v0.1» . Проверено 23 сентября 2013 г.
  16. ^ «Примечание к выпуску: BIG-IP LTM и TMOS 11.5.0» . f5 Сети. 30 мая 2014 г. Проверено 30 мая 2014 г.
  17. ^ Джон Гудмундсон (28 мая 2013 г.). «Увеличьте удобство работы мобильных пользователей с помощью NetScaler Multipath TCP» . Цитрикс . Проверено 20 сентября 2013 г.
  18. ^ «Кажется, Apple тоже верит в Multipath TCP» . Проверено 20 сентября 2013 г.
  19. ^ «MPTCP БЕСПЛАТНО (ПО УМОЛЧАНИЮ!) – OS X YOSEMITE» . 20 октября 2014 г. Проверено 16 сентября 2015 г.
  20. ^ Георг Хампель (26 октября 2012 г.). «Выпуск кода для прокси-сервера MPTCP» . Алкатель-Люсент . Проверено 28 декабря 2016 г.
  21. ^ Георг Хампель; Анил Рана (26 октября 2012 г.). «MPTCP ПРОКСИ» (PDF) . Bell Labs / Алкатель-Люсент . Проверено 28 декабря 2016 г.
  22. ^ Рао, Шоаиб. «Некоторые комментарии к RFC 6824» . Проверено 25 июня 2015 г.
  23. ^ «Проект добычи MPTCP» . 17 декабря 2019 г. Проверено 10 января 2020 г.
  24. ^ «GiGA LTE от КТ» (PDF) .
  25. ^ Бонавентура, Оливье; См., Сон Хун (2016). «Многопутевое развертывание TCP» . Журнал IETF .
  26. ^ К. Пааш, Обновления реализации iOS и Linux, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/
  27. ^ С. Со, GiGA LTE от KT - развертывание мобильного прокси-сервера MPTCP, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp- прокси-развитие-01.pdf
  28. ^ Грегори Деталь, Себастьян Барре, Барт Пейренс, Оливье Бонавентюр, «Использование многопутевого TCP для создания сетей гибридного доступа», SIGCOMM'17 (промышленная демонстрация), http://conferences.sigcomm.org/sigcomm/2017/files/program- Industrial-demos/sigcomm17industrialdemos-paper4.pdf
  29. ^ 3GPP TR 23.793, «Исследование управления, переключения и разделения трафика доступа в системной архитектуре 5G (выпуск 16)», https://www.3gpp.org/ftp/Specs/latest/Rel-16/23_series/23793 -g00.zip
  30. ^ «Номера типов TCP-опций реестра протоколов IANA» . Проверено 24 сентября 2013 г.
  31. ^ Пааш, Кристоф; Бонавентура, Оливье (апрель 2014 г.). «Многопутевой TCP» . Коммуникации АКМ . 57 (4): 51–57. дои : 10.1145/2578901 . S2CID   17581886 .
  32. ^ Райчу, Костин; Айенгар, Джанардхан; Бонавентура, Оливье (2013). Хаддади, Хамед; Бонавентура, Оливье (ред.). Последние достижения в области надежных транспортных протоколов . АСМ СИГКОММ.
  33. ^ Халили, Рамин; Гаст, Николас; Попович, Мирослав; Упадхьяй, Уткарш; Ле Будек, Жан-Ив (2012). «MPTCP не является парето-оптимальным». Материалы 8-й международной конференции «Новые сетевые эксперименты и технологии» . стр. 1–12. дои : 10.1145/2413176.2413178 . ISBN  9781450317757 . S2CID   14210629 .
  34. ^ Пэн, Цюй; Валид, Анвар; Хван, Джэхён; Лоу, Стивен Х. (2013). «Многопутевой TCP: анализ, проектирование и реализация». Транзакции IEEE/ACM в сети . 24 : 596–609. arXiv : 1308.3119 . Бибкод : 2013arXiv1308.3119P . дои : 10.1109/TNET.2014.2379698 . S2CID   250322 .
  35. ^ Jump up to: а б с П. Родригес; Э. Бирсак (1 июля 2002 г.). «Динамический параллельный доступ к тиражируемому контенту в Интернете» (PDF) . Транзакции IEEE/ACM в сети. Архивировано из оригинала (PDF) 27 сентября 2013 г.
  36. ^ «Проект-ietf-avtcore-MPRTP-03» .
  37. ^ «Черновик-ietf-TSVWG-multipath-DCCP-04» .
  38. ^ К. Де Конинк; О. Бонавентура (30 октября 2010 г.). «Расширение Multipath для QUIC» . IETF
  39. ^ К. Де Конинк; О. Бонавентура (12 декабря 2010 г.). «Многопутевой QUIC: проектирование и оценка» (PDF) . Учеб. Conext'2017, Сеул, Корея.
  40. ^ Р. Чакраворти; И. Пратт; П. Родригес (1 июля 2003 г.). «Маршрутизатор мобильного доступа» . Кембриджский университет, Microsoft Research.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 41efaf4af5c9a44887cc8329fa720a5c__1713882120
URL1:https://arc.ask3.ru/arc/aa/41/5c/41efaf4af5c9a44887cc8329fa720a5c.html
Заголовок, (Title) документа по адресу, URL1:
Multipath TCP - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)