Многопутевый TCP - Multipath TCP
Эта статья должна быть обновлено.Январь 2020) ( |
Набор интернет-протоколов |
---|
Уровень приложения |
Транспортный уровень |
Интернет-уровень |
Связующий слой |
Многопутевый TCP (MPTCP) - постоянная работа Инженерная группа Интернета рабочая группа по протоколу Multipath TCP (IETF), цель которой - позволить Протокол управления передачей (TCP) для использования нескольких путей для максимального использования ресурсов и увеличения избыточности.[1]
В январе 2013 года IETF опубликовала спецификацию Multipath в качестве экспериментального стандарта в RFC 6824. Он был заменен в марте 2020 года спецификацией Multipath TCP v1 в RFC 8684.
Льготы
Избыточность, предлагаемая Multipath TCP, позволяет обратное мультиплексирование ресурсов и, таким образом, увеличивает пропускную способность TCP до суммы всех доступных уровень ссылок каналов вместо использования одного, как того требует обычный TCP. Многопутевый TCP обратно совместим с обычным TCP.
Многопутевый TCP особенно полезен в контексте беспроводных сетей.[2]; используя оба Wi-Fi и Мобильная сеть типичный вариант использования.[3] В дополнение к увеличению пропускной способности за счет обратного мультиплексирования, ссылки могут добавляться или удаляться по мере того, как пользователь входит или выходит из зоны покрытия, не прерывая сквозного TCP-соединения.[4]
Проблема ссылки сдавать таким образом решается абстракцией в транспортный уровень, без каких-либо специальных механизмов на сеть или ссылка на сайт уровень. Функциональность хэндовера может быть реализована на конечных точках, не требуя специальных функций в подсети - в соответствии с Интернетом сквозной принцип.
Многопутевый TCP также обеспечивает повышение производительности в Дата центр среды.[5] В отличие от Ethernet соединение каналов с использованием 802.3ad агрегация каналов, Multipath TCP может сбалансировать одно TCP-соединение через несколько интерфейсов и достичь очень высокой пропускной способности.[6]
Многопутевый TCP вызывает ряд новых проблем. С точки зрения сетевой безопасности, многопутевая маршрутизация вызывает фрагментацию данных между путями, в результате чего брандмауэры и сканеры вредоносных программ становятся неэффективными, когда они видят трафик только по одному пути. Кроме того, расшифровка SSL станет неэффективной из-за протоколов сквозного шифрования.[7].
Пользовательский интерфейс
Для облегчения развертывания Multipath TCP представляет тот же интерфейс сокетов, что и TCP. Это означает, что любое стандартное приложение TCP может использоваться выше Multipath TCP, фактически распределяя данные по нескольким подпотокам.[8]
Некоторым приложениям может быть полезен расширенный API для управления лежащим в основе стеком Multipath TCP. Было предложено два разных API, чтобы предоставить приложениям некоторые функции стека Multipath TCP: API, расширяющий Netlink в Linux[9] и улучшенный API сокетов.[10]
Реализация
В июле 2013 года рабочая группа MPTCP сообщила о пяти независимых реализациях Multipath TCP,[11] включая эталонную реализацию[8] в ядре Linux.[12][13]
Доступные в настоящее время реализации находятся:
- Ядро Linux (эталонная реализация) из Католический университет Лувена исследователи и другие сотрудники,[8]
- FreeBSD (Только IPv4) от Технологический университет Суинберна,[14]
- F5 Сети BIG-IP LTM,[15]
- Citrix Netscaler,[16]
- яблоко IOS 7, выпущенный 18 сентября 2013 г., является первым крупномасштабным коммерческим развертыванием Multipath TCP.[17]. поскольку IOS 7, любое приложение может использовать Multipath TCP.
- яблоко Mac OS X 10.10, выпущен 16 октября 2014 г.[18]
- Alcatel-Lucent выпустила исходный код прокси MPTCP версии 0.9 26 октября 2012 г.[19][20]
В июле 2014 года Oracle сообщила, что реализация на Солярис разрабатывался. В июне 2015 года работа ведется.[21]
Во время встречи рабочей группы MPTCP на IETF 93 Сон Хун Сео объявил, что с середины июня KT развернула коммерческую услугу, которая позволяет пользователям смартфонов достигать скорости 1 Гбит / с с помощью прокси-службы MPTCP.[22]. Tessares использует реализацию ядра Linux для развертывания Гибридные сети доступа
Постоянно прилагаются усилия по продвижению новой реализации Multipath TCP в основное ядро Linux, [23]
Сценарии использования
Многопутевый TCP был разработан для обеспечения обратной совместимости с обычным TCP. Таким образом, он может поддерживать любое приложение. Однако некоторые конкретные развертывания[24] использовать возможность одновременного использования разных путей.
яблоко использует Multipath TCP для поддержки Siri приложение на iPhone. Siri отправляет образцы голоса по HTTPS сеанс к серверам Apple. Эти серверы отвечают информацией, запрошенной пользователями. Согласно с яблоко инженеры, основные преимущества[25] Multipath TCP с этим приложением:
- Обратная связь с пользователем (время до первого слова) на 20% быстрее в 95-м процентиле
- 5-кратное сокращение количества сбоев сети
В другом развертывании используется протокол Multipath TCP для агрегирования пропускной способности различных сетей. Например, несколько типов смартфонов, особенно в Корее, используют Multipath TCP для связи Wi-Fi и 4G через прокси-серверы SOCKS.[26]. Другой пример - Гибридные сети доступа которые развертываются операторами сети, желающими объединить сети xDSL и LTE. В этом развертывании Multipath TCP используется для эффективного балансирования трафика через xDSL и сеть LTE.[27].
Параметры многопутевого TCP
Multipath TCP использует параметры, которые подробно описаны в RFC 6824. Все параметры многопутевого TCP кодируются как параметры TCP с параметром Kind 30, зарезервированным IANA.[28]
Параметр Multipath TCP имеет вид (30), длину (переменную), а остальная часть содержимого начинается с 4-битного поля подтипа, для которого IANA создал и будет поддерживать подрегистрацию «Подтипы опций MPTCP» в реестре «Параметры протокола управления передачей (TCP)». Эти поля подтипа определены следующим образом:
Ценность | Символ | имя |
---|---|---|
0x0 | MP_CAPABLE | Возможность многолучевого распространения |
0x1 | MP_JOIN | Присоединиться к подключению |
0x2 | DSS | Сигнал последовательности данных (подтверждение данных и отображение последовательности данных) |
0x3 | ADD_ADDR | Добавить адрес |
0x4 | REMOVE_ADDR | Удалить адрес |
0x5 | MP_PRIO | Изменить приоритет подпотока |
0x6 | MP_FAIL | Отступать |
0x7 | MP_FASTCLOSE | Быстрое закрытие |
0xf | (ЧАСТНЫЙ) | Частное использование на контролируемых испытательных стендах |
Значения от 0x8 до 0xe в настоящее время не присвоены.
Работа протокола
Упрощенное описание
Основная идея многопутевого TCP состоит в том, чтобы определить способ установления соединения между двумя хостами, а не между двумя интерфейсами (как это делает стандартный TCP).
Например, у Алисы есть смартфон с интерфейсами 3G и WiFi (с IP-адресами 10.11.12.13 и 10.11.12.14), а у Боба есть компьютер с интерфейсом Ethernet (с IP-адресом 20.21.22.23).
В стандартном TCP соединение должно быть установлено между двумя IP-адресами. Каждое TCP-соединение идентифицируется четырьмя кортежами (адреса и порты источника и назначения). Учитывая это ограничение, приложение может создать только одно TCP-соединение по одной ссылке. Многопутевый TCP позволяет соединению использовать несколько путей одновременно. Для этого Multipath TCP создает одно TCP-соединение, называемое подпотоком, по каждому пути, который необходимо использовать.
Цель различных протокольных операций (определенных в RFC 6824 ) находятся:
- обрабатывать, когда и как добавлять / удалять пути (например, если соединение потеряно из-за некоторого контроля перегрузки)
- быть совместимым с устаревшим оборудованием TCP (например, с некоторыми брандмауэрами, которые могут автоматически отклонять TCP-соединения, если порядковый номер не является последовательным)
- для определения стратегии справедливого контроля перегрузки между разными ссылками и разными хостами (особенно с теми, которые не поддерживают MPTCP)
Многопутевый TCP добавляет новые механизмы к TCP-передачам:
- Система подпотока, используемая для сбора нескольких стандартных TCP-соединений (путей от одного хоста к другому). Подпотоки идентифицируются во время трехстороннего подтверждения TCP. После рукопожатия приложение может добавлять или удалять некоторые подпотоки (подтипы 0x3 и 0x4).
- Опция MPTCP DSS содержит порядковый номер данных и номер подтверждения. Это позволяет получать данные из нескольких подпотоков в исходном порядке без какого-либо повреждения (подтип сообщения 0x2)
- Измененный протокол повторной передачи обеспечивает контроль перегрузки и надежность.
Подробная спецификация
Подробная спецификация протокола представлена в RFC 8684. Несколько обзорных статей содержат введение в протокол.[29][30]
Контроль перегрузки
Для многопутевого TCP определено несколько механизмов управления перегрузкой. Их главное отличие от классических схем управления перегрузкой TCP состоит в том, что они должны реагировать на перегрузку на разных путях, не проявляя несправедливости к источникам TCP с одним путем, которые могут конкурировать с ними на одном из путей.[3] Четыре схемы управления перегрузкой Multipath TCP в настоящее время поддерживаются реализацией Multipath TCP в ядре Linux.
- Алгоритм связанного увеличения, определенный в RFC 6356
- Оппортунистический связанный алгоритм увеличения[31]
- Алгоритм управления перегрузкой на основе задержки wVegas
- Алгоритм сбалансированного связанного увеличения[32]
Альтернативы
Протокол передачи управления потоком
Протокол передачи управления потоком (SCTP) - надежный дейтаграмма Потоковый транспортный протокол, изначально предназначенный для передачи сигналов электросвязи. Он поддерживает одновременное использование множественных ссылок доступа и позволяет приложению влиять на выбор интерфейса доступа на основе потока дейтаграмм. Он также поддерживает мобильность посредством повторного согласования доступа. Следовательно, SCTP также является решением транспортного уровня. Он предлагает гранулярность потока 3-го типа с параллелизмом, но с большим контролем планирования потока, чем Multipath TCP. Он также полностью поддерживает мобильность аналогично протоколу Multipath TCP.[33]
IMS SIP
В рамках Подсистема IP-мультимедиа (IMS) архитектура, Протокол инициирования сеанса (SIP) может поддерживать одновременное использование нескольких контактных IP-адресов для регистрации одного или нескольких пользовательских агентов IMS. Это позволяет создавать несколько трактов сигнализации IMS. На этих путях сигнализации сигнальные сообщения переносят Протокол описания сеанса (SDP) обмен сообщениями для согласования медиапотоков. SDP позволяет (повторно) согласовывать потоки одного сеанса мультимедиа по нескольким путям. В свою очередь, это обеспечивает многопутевый транспорт на уровне приложений. С этой точки зрения IMS может предложить поддержку многолучевого распространения на прикладном уровне с детализацией потока и одновременным доступом. Расширение многолучевого распространения для Транспортный протокол в реальном времени (RTP) в настоящее время обсуждается в IETF. Многопутевый RTP может предлагать детализацию потока с одновременным доступом и мобильностью (через IMS, сигнализацию SDP или протокол управления RTP).[33]
Multipath QUIC
В IETF в настоящее время разрабатывает QUIC протокол, который объединяет функции, которые традиционно присутствуют в TCP, TLS и HTTP протоколы. Благодаря гибкости и расширяемости QUIC, его можно расширить для поддержки нескольких путей и решения тех же вариантов использования, что и Multipath TCP. Был предложен первый дизайн для Multipath QUIC.[34], реализовано и оценено[35].
Другие протоколы и эксперименты
На уровне сеанса в рамках проекта «Маршрутизатор мобильного доступа» в 2003 г. проводился эксперимент с объединением множества беспроводных подключений с использованием гетерогенных технологий, прозрачно балансируя трафик между ними в зависимости от предполагаемой производительности каждого из них.[36]
Схемы параллельного доступа[33] используется для ускорения переводов за счет использования Запросы диапазона HTTP для инициирования подключений к нескольким серверам реплицированного контента, не эквивалентны протоколу Multipath TCP, поскольку они включают уровень приложений и ограничены контентом известного размера.
RFC
- RFC 6181 - Анализ угроз для расширений TCP для многопутевой работы с несколькими адресами
- RFC 6182 - Руководство по архитектуре для разработки многопутевого TCP
- RFC 6356 - Двойное управление перегрузкой для многопутевых транспортных протоколов
- RFC 6824 - Расширения TCP для работы с несколькими путями с несколькими адресами (v0; заменено на RFC 8684 )
- RFC 6897 - Особенности интерфейса приложения Multipath TCP (MPTCP)
- RFC 7430 - Анализ остаточных угроз и возможные исправления для многопутевого TCP (MPTCP)
- RFC 8041 - Примеры использования и опыт работы с Multipath TCP
- RFC 8684 - Расширения TCP для работы с несколькими путями с несколькими адресами (v1)
- RFC 8803 - Протокол преобразования TCP 0-RTT
Смотрите также
использованная литература
- ^ Рабочая группа по многопутевому TCP
- ^ Пааш, Кристоф; Деталь, Григорий; Дюшен, Фабьен; Райчиу, Костин; Бонавентура, Оливье (2012). Изучение передачи мобильного / Wi-Fi с помощью многопутевого TCP. Семинар ACM SIGCOMM по сотовым сетям (Cellnet'12). п. 31. Дои:10.1145/2342468.2342476. ISBN 9781450314756.
- ^ а б С. Похрель; М. Панда; Х. Ву (24 февраля 2017 г.). «Аналитическое моделирование многопутевого TCP через беспроводную связь последней мили». Транзакции IEEE / ACM в сети. 25 (3): 1876–1891. Дои:10.1109 / TNET.2017.2663524.
- ^ С. Похрель; М. Манджес (24 марта 2019 г.). «Повышение производительности многопутевого TCP через WiFi и сотовые сети: аналитический подход». IEEE Transactions по мобильным вычислениям. 25 (3): 1876–1891. Дои:10.1109 / TMC.2018.2876366.
- ^ Райчиу; Барре; Плунтке; Гринхалг; Вишик; Хэндли (2011). «Повышение производительности и надежности центра обработки данных с помощью многопутевого TCP». Обзор компьютерных коммуникаций ACM SIGCOMM. 41 (4): 266. CiteSeerX 10.1.1.306.3863. Дои:10.1145/2043164.2018467.
- ^ К. Пааш; Г. Деталь; С. Барре; Ф. Дюшен; О. Бонавентура. «Самое быстрое TCP-соединение с Multipath TCP». Получено 2013-09-20.
- ^ Афзал, Зишан (2020). Жизнь промежуточного ящика безопасности Проблемы с новыми протоколами и технологиями (Кандидат наук). ISBN 978-91-7867-103-8. OCLC 1139703033.
- ^ а б c "Проект MultiPath TCP ядра Linux". Получено 2014-11-28.
- ^ Hesmans, B .; Деталь, Г .; Barre, S .; Bauduin, R .; Бонавентура, О. (2015). «СМАПП». SMAPP к приложениям с поддержкой Smart Multipath TCP. С. 1–7. Дои:10.1145/2716281.2836113. ISBN 9781450334129.
- ^ «Обзор реализаций MPTCP (Интернет-проект, 2013)». Получено 2013-09-20.
- ^ Барре; Пааш; Бонавентура (2011). «MultiPath TCP: от теории к практике». Сеть IFIP.
- ^ Райчиу; Пааш; Барре; Форд; Хонда; Дюшен; Бонавентура; Хэндли (2012). «Насколько это может быть сложно? Разработка и реализация развертываемого многопутевого TCP». Усеникс Нсди: 399–412.
- ^ "Многопутевый TCP для FreeBSD v0.1". Получено 2013-09-23.
- ^ «Примечание к выпуску: BIG-IP LTM и TMOS 11.5.0». f5 Сети. 2014-05-30. Получено 2014-05-30.
- ^ Джон Гудмундсон (28 мая 2013 г.). «Максимизируйте удобство работы мобильных пользователей с NetScaler Multipath TCP». Citrix. Получено 2013-09-20.
- ^ «Apple, кажется, тоже верит в Multipath TCP». Получено 2013-09-20.
- ^ "MPTCP БЕСПЛАТНЫЙ РОУМ (ПО УМОЛЧАНИЮ!) - OS X YOSEMITE". 2014-10-20. Получено 2015-09-16.
- ^ Георг Хампель (26.10.2012). "выпуск кода для прокси MPTCP". Alcatel-Lucent. Получено 2016-12-28.
- ^ Георг Хампель; Анил Рана (26.10.2012). "MPTCP ПРОКСИ" (PDF). Bell Labs /Alcatel-Lucent. Получено 2016-12-28.
- ^ Рао, Шоаиб. «Некоторые комментарии к RFC 6824». Получено 25 июн 2015.
- ^ "KT's GiGA LTE" (PDF).
- ^ «Проект MPTCP Upstream». 2019-12-17. Получено 2020-01-10.
- ^ Бонавентура, Оливье; См. SungHoon (2016). «Развертывания многопутевого TCP». Журнал IETF.
- ^ К. Пааш, Обновления реализации iOS и Linux, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/
- ^ С. Сео, KT's GiGA LTE - развертывание мобильного прокси-сервера MPTCP, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-01.pdf
- ^ Грегори Деталь, Себастьен Барре, Барт Пейренс, Оливье Бонавентур, «Использование многопутевого TCP для создания гибридных сетей доступа», SIGCOMM'17 (промышленная демонстрация), http://conferences.sigcomm.org/sigcomm/2017/files/program-industrial-demos/sigcomm17industrialdemos-paper4.pdf
- ^ "Типовые номера вариантов TCP реестра IANA". Получено 2013-09-24.
- ^ Пааш, Кристоф; Бонавентура, Оливье (апрель 2014 г.). "Многопутевый TCP". Коммуникации ACM. 57 (4): 51–57. Дои:10.1145/2578901.
- ^ Райчиу, Костин; Айенгар, Джанардхан; Бонавентура, Оливье (2013). Хаддади, Хамед; Бонавентура, Оливье (ред.). Последние достижения в надежных транспортных протоколах. ACM SIGCOMM.
- ^ Халили, Рамин; Гаст, Николас; Попович, Мирослав; Упадхьяй, Уткарш; Ле Будек, Жан-Ив (2012). MPTCP не является парето-оптимальным. Материалы 8-й Международной конференции по новым сетевым экспериментам и технологиям - CoNEXT '12. п. 1. Дои:10.1145/2413176.2413178. ISBN 9781450317757.
- ^ Пэн, Цююй; Валид, Анвар; Хван, Джэхён; Низкий, Стивен Х. (2013). «Многопутевый TCP: анализ, проектирование и реализация». Транзакции IEEE / ACM в сети. 24: 596–609. arXiv:1308.3119. Bibcode:2013arXiv1308.3119P. Дои:10.1109 / TNET.2014.2379698.
- ^ а б c П. Родригес; Э. Бирсак (01.07.2002). «Динамический параллельный доступ к реплицируемому контенту в Интернете» (PDF). Транзакции IEEE / ACM в сети. Архивировано из оригинал (PDF) на 2013-09-27.
- ^ К. Де Конинк; О. Бонавентура (30.10.2010). «Расширение Multipath для QUIC». Проект Интернета IETF.
- ^ К. Де Конинк; О. Бонавентура (12.12.2010). «Multipath QUIC: проектирование и оценка» (PDF). Proc. Conext'2017, Сеул, Корея.
- ^ Р. Чакраворти; И. Пратт; П. Родригес (2003-07-01). «Маршрутизатор мобильного доступа». Кембриджский университет, Microsoft Research.