Multipath TCP (MPTCP, набор расширений спецификации протокола управления передачей) находится в разработке с 2013 года (RFC 6824) и вызывает значительный интерес со стороны как исследователей, так и представителей промышленности. Протокол направлен на одновременное использование нескольких доступных сетевых путей между конечными точками.

Несколько организаций объявили о включении MPTCP в свои продукты и услуги, в том числе Apple и Linux:

  • Apple использует MPTCP в своих iOS-устройствах (например, Siri, Music, Maps, Wi-Fi Assist), а также позволяет сторонним разработчикам использовать протокол в несистемных приложениях.

  • Linux использует MPTCPv1 (RFC 8684) на всех своих машинах с ядром версии 5.6 и выше. Старая версия разработки теперь известна как MPTCP версии 0 (MPTCPv0).

Несмотря на значительный интерес со стороны этих и других компаний, текущее состояние развертывания и использования MPTCP в Интернете остается в значительной степени неизвестным. В этой статье мы обобщим основные результаты нашего исследования, что поможет обрисовать наиболее точную картину истинного развертывания MPTCP на сегодняшний день. Часть исследования была опубликована в IFIP Networking 2021, а расширенная версия в настоящее время находится на рассмотрении. Если вам интересно узнать больше о нашей работе, рекомендуем прочитать подробный анализ и скачать актуальные результаты сканирования на mptcp.io.

Ключевые моменты:

  • Развертывание MPTCP охватывает экономику более 80 стран.

  • Поддержка MPTCPv1 до октября 2021 года практически отсутствовала как для IPv4, так и для IPv6.

  • Почти половина всех хостов IPv4 MPTCPv0 развернута в Гонконге благодаря Hong Kong Broadband.

  • В конце 2021 года Apple занимала второе место по поддержке MPTCPv0 в IPv4, но имела наибольшее присутствие в IPv6 и была единственной компанией, которая активно поддерживала MPTCPv1. В феврале 2022 года поддержка MPTCPv1 поверх IPv4 была увеличена в 10 раз.

Сканирование для MPTCP — пособие для начинающих

Чтобы понять нашу методологию измерения, важно сначала понять реализацию и работу протокола MPTCP.

MPTCP расширяет обычный протокол TCP и использует необязательные поля заголовка TCP для передачи сигналов (см. RFC 6824). Наиболее примечательной опцией является MP_CAPABLE, которая включает флаг MP_CAPABLE, сигнализирующий о том, что конкретный хост поддерживает MPTCP во время установления соединения. Кроме того, опция также включает случайную 64-битную последовательность, известную как ключ отправителя, которую хосты используют для аутентификации.

На рисунке 1 показана процедура установления соединения MPTCPv0 между двумя хостами, Бобом и Алисой. Процедура имитирует трехэтапное рукопожатие TCP. Боб инициирует соединение отправкой пакета SYN, содержащего флаг MP_CAPABLE с поддержкой MPTCPv0 и собственный ключ отправителя. Если Алиса также поддерживает MPTCP, она ответит SYN-ACK, содержащим флаг MP_CAPABLE и собственный ключ отправителя. Наконец, Боб устанавливает соединение, отправив ACK с обоими ключами в опции MP_CAPABLE. Если во время обмена какая-либо из опций MPTCP сбрасывается (например, Алиса не поддерживает MPTCP), соединение возвращается к обычному TCP.

Рисунок 1 — Обмен ключами MPTCPv0 при установлении соединения.
Рисунок 1 — Обмен ключами MPTCPv0 при установлении соединения.

Установление соединения MPTCPv1, с другой стороны, немного отличается от MPTCPv0. В дополнение к различным номерам версий MPTCP в MP_CAPABLE, Боб не отправляет ключ отправителя в SYN, ключ отправляется Алисе только в финальном SYN-ACK. Мы обсудим влияние этого изменения на механизм рукопожатия немного позже.

Рисунок 2 — Поиск поддержки MPTCP с помощью ZMap
Рисунок 2 — Поиск поддержки MPTCP с помощью ZMap

Мы можем использовать механизм рукопожатия MPTCP для определения поддержки MPTCP в Интернете. Мы использовали ZMap и сгенерировали MPTCP SYN с опцией MP_CAPABLE. Для сканирования MPTCPv0 мы также использовали фиксированную 64-битную последовательность в качестве ключа и отправляли ее в пакете SYN. Если целевой хост ответил SYN-ACK, который также включал параметр MP_CAPABLE и ключ отправителя, он, вероятно, поддерживал MPTCP.

Мы проверили все адресное пространство IPv4 на 80 порту (≈74 млн уникальных отвечающих IP-адресов) и на порту 443 (≈52 млн уникальных IP-адресов с откликом). В IPv6 мы использовали Hitlist IPv6 для проверки порта 80 (≈746 тыс. реагирующих IP-адресов) и порта 443 (≈544 тыс. реагирующих IP-адресов) из-за размера адресного пространства. Мы получили результаты сканирования MPTCPv0 за восемнадцать месяцев (с июля 2020 г. по декабрь 2021 г.) и MPTCPv1 за девять месяцев (с апреля по декабрь 2021 г.). Более того, сканирование все еще продолжается, и наши последние результаты доступны на mptcp.io.

Рисунок 3. Мы планируем продолжить сканирование для принятия MPTCP в обозримом будущем, которое можно просмотреть и скачать на сайте mptcp.io.
Рисунок 3. Мы планируем продолжить сканирование для принятия MPTCP в обозримом будущем, которое можно просмотреть и скачать на сайте mptcp.io.

Промежуточные устройства Интернета против MPTCP: борьба за совместимость

Во-первых, мы обнаружили, что лишь небольшой процент опробованных хостов отвечает на наши сканирования флагом MP_CAPABLE в SYN-ACK (≈5%). Глядя на абсолютное количество хостов, а не на проценты (около 300 000 в MPTCPv0 и 200 000 в MPTCPv1), может показаться, что MPTCP широко поддерживается в Интернете. Однако при сканировании MPTCPv0 мы заметили, что только часть из 300 000 хостов (≈4%) отправила нам значение ключа отправителя в SYN-ACK, отличное от значения статического ключа отправителя, которое мы отправили в исходном SYN. Такое поведение противоречит RFC 6824, в котором говорится: «… ключ должен быть трудно угадываемым, и он должен быть уникальным для отправляющего хоста в любой момент времени».

Рисунок 4 — Весовое распределение Хэмминга ключа отправителя от хостов MPTCPv0 IPv6 в SYN-ACK.
Рисунок 4 — Весовое распределение Хэмминга ключа отправителя от хостов MPTCPv0 IPv6 в SYN-ACK.

Поскольку ключ представляет собой случайную 64-битную последовательность, сумма независимых случайных величин должна стремиться к нормальному распределению в соответствии с центральной предельной теоремой. На рис. 4 показан вес Хэмминга ключей отправителя, полученных от потенциальных хостов MPTCP IPv6 через порт 443. Обратите внимание на выброс с весом Хэмминга 16, который не соответствует распределению. Мы обнаружили, что этот выброс присутствует во всех наших сканированиях MPTCPv0 для портов 80 и 443 (более распространен в IPv4, чем в IPv6). Интересно, что вес Хэмминга выброса точно соответствует весу статического ключа, который мы отправили в нашем SYN-пакете хостам.

В распределении подчеркивается распространенность промежуточных устройств в Интернете, которые не поддерживают расширения заголовков TCP и поэтому обрабатывают такие пакеты нетипичными способами. Многие промежуточные устройства отбрасывают пакеты с расширениями заголовка TCP, в то время как другие могут удалять расширения, но пересылать пакет адресату. Приведенный выше кейс показывает, что на сканирование MPTCPv0 влияют промежуточные устройства, которые повторяют расширения в заголовке SYN пакета обратно нам в ответе. Мы отфильтровали такие промежуточные устройства из нашего анализа, проверив, отличается ли возвращенный ключ отправителя в SYN-ACK от отправленного в SYN.

Обратите внимание, что проектное решение MPTCPv1 по удалению ключа отправителя в SYN было направлено на особую обработку подобных устройств-повторителей, поскольку ожидается, что возвращенный SYN-ACK будет иметь значение ключа отправителя вместе с установленными опциями MP_CAPABLE. Мы отфильтровали промежуточные устройства в нашем анализе MPTCPv1, используя именно этот критерий.

После фильтрации мы обнаружили, что количество отвечающих хостов значительно сократилось — почти 100 000 IPv4 и 2000 IPv6 для MPTCPv0 и 120 IPv4 и 80 IPv6 для MPTCPv1. Мы также обнаружили, что поддержка MPTCPv1 практически отсутствовала как для IPv4, так и для IPv6 до октября 2021 года, после которого мы наблюдали внезапный всплеск отзывчивых хостов.

Поддержка MPTCP в IPv4 и IPv6

Мы дополнительно проверили наличие мешающих промежуточных устройств, запустив Tracebox для всех целей, которые отправили параметр MP_CAPABLE в наших сканированиях ZMap. В ответе Tracebox мы получили ответы от промежуточных маршрутизаторов на пути, включая все сделанные модификации. Чтобы ознакомиться с подробной методологией, рекомендуем прочитать вот эту статью.

Во-первых, мы заметили, что большой процент целей не отвечал на наши запросы Tracebox и был недоступен. В IPv4 почти 90% и 48% хостов на портах 443 и 80 были недоступны. В IPv6 только порт 443 имел недоступные хосты (≈82%). Дальнейший анализ показал, что одной из основных причин является блокировка со стороны интернет-провайдера целевого хоста.

Рисунок 5 — Поддержка MPTCP (v0 и v1) для HTTP и HTTPS в IPv4.
Рисунок 5 — Поддержка MPTCP (v0 и v1) для HTTP и HTTPS в IPv4.

После удаления недоступных хостов мы обнаружили, что истинная поддержка MPTCPv0 в IPv4 на конец декабря 2021 года составляет ≈16 500 на порту 80 и ≈13 500 на порту 443. В случае IPv6 1195 и 1184 хоста на портах 80 и 443 действительно поддерживает MPTCPv0.

Поддержка MPTCPv1 значительно ниже, чем MPTCPv0, поскольку 100–150 хостов поддерживают более новую версию для IPv4 и IPv6 на портах 80 или 443. На рисунке 5 показано покрытие по портам для хостов с действительной поддержкой MPTCP (как v0, так и v1), и оно подчеркивает значительную одновременную поддержку как HTTP, так и HTTPS.

Использование MPTCP в организациях

Мы также обнаружили, что почти половина всех хостов IPv4 MPTCPv0 развернута в Гонконге благодаря гонконгской (HK) широкополосной связи (таблица 1), на долю которой приходится наибольшая доля. Большинство хостов HK Broadband заработали в 2021 году, до этого самая высокая поддержка MPTCPv0 была у Apple.

Номер автономной системы (ASN)

#Port80

#Port443

Позиция

Экономика

Владелец

AS9269

6461

6370

364

HK

HK Broadband

AS6185

1347

1344

13,577

US

Apple

AS61157

674

534

1,368

DE

Plus Server

AS1221

529

456

76

AU

Telstra

AS18618

390

390

3,915

US

West Central

AS18943

353

352

3,533

US

Yelcot

AS7922

419

209

27

US

Comcast

AS11976

232

231

2,360

US

Fidelity

AS202870

404

2

16,712

IT

Dimensione

AS15129

369

1

4,034

US

Geneseo Tele.

Таблица 1 — Топ-10 AS, на которых размещаются хосты IPv4 MPTCPv0.

В конце 2021 года Apple занимала второе место по поддержке MPTCPv0 в IPv4, но имела наибольшее присутствие в IPv6 (таблица 2), при этом большинство ее серверов находились в США.

ASN

#Port80

#Port443

Позиция

Экономика

Владелец

AS6185

1163

1163

14,234

US

Apple

AS63949

4

3

7,042

US

Linode

AS4811

3

3

2,034

CN

China Telecom

AS714

2

2

6,949

US

Apple

AS201155

2

2

26,184

CH

EmbeDD

Таблица 2 — Топ-5 AS, на которых размещаются хосты IPv6 MPTCPv0.

Мы также видим, что Apple — единственная организация в Интернете, которая начала активно поддерживать новую версию MPTCPv1 (таблица 3).

ASN

#Port80

#Port443

Позиция

Экономика

Владелец

AS6185

98

98

14,234

US

Apple

AS396986

2

2

16,570

US

Bytedance

AS206293

0

3

22,645

DE

ProIO GmbH

AS714

1

2

6,949

US

Apple

AS3209

0

2

221

DE

Vodafone

Таблица 3 — Топ-5 AS, на которых размещаются хосты IPv4 MPTCPv1.

На рис. 6 показано количество хостов IPv4 в сетях Apple (AS6185 и AS714), которые, как сообщается, поддерживают MPTCPv0 и MPTCPv1 с апреля 2021 года. Хосты Apple MPTCPv0 остаются довольно стабильными — вероятно, они поддерживают основные приложения и сервисы Apple. Мы обнаружили, что Apple не поддерживала MPTCP в IPv6 до сентября 2021 года и MPTCPv1 в IPv4 до октября 2021 года, что также является причиной внезапного роста числа хостов MPTCPv1 во всем мире.

Рисунок 6 — IPv4-узлы MPTCP (v0 и v1) в Apple AS.
Рисунок 6 — IPv4-узлы MPTCP (v0 и v1) в Apple AS.

В феврале 2022 года Apple увеличила поддержку MPTCPv1 по сравнению с IPv4 в 10 раз, почти сравнявшись с хостами MPTCPv0. Дальнейшее расследование показало, что это те же самые хосты, которые ранее поддерживали MPTCPv0, а теперь также поддерживают MPTCPv1.

Кроме того, многие сетевые операторы и интернет-провайдеры по всему миру используют MPTCP для улучшения своей работы, например, Korea Telecom и Yelcot Telecom. В целом мы обнаружили, что текущее развертывание MPTCP охватывает более 80 стран по всему миру.

Вы используете MPTCP? Если да, напишите нам

В обозримом будущем мы планируем продолжить наше исследование поддержки MPTCP, которое можно просмотреть и скачать на сайте mptcp.io. Чтобы узнать больше о влиянии промежуточных устройств на передачу данных MPTCP и распределение трафика MPTCP IPv4 и IPv6 в Интернете, читайте эту статью.

Нам также очень интересно узнать о приложениях, использующих MPTCP в Интернете. Если вы знаете о таких вариантах использования, управляете серверами, участвующими в таких обменах, или хотите узнать на эту тему больше, свяжитесь с нами по адресу info@mptcp.io.


Приходите на открытое занятие «Внедрение Firewall в фабрику». Определим, зачем необходим Firewall и как он мешает работе сервиса. Рассмотрим дизайн построения сетевой фабрики. Разберем особенности и недостатки внедрения Firewall. Реализуем внедрение Firewall в сетевую фабрику. Регистрация по ссылке.

Комментарии (6)


  1. BigD
    09.09.2022 18:26

    Домашнее применение для агрегации каналов интереснее


  1. vrangel
    09.09.2022 18:44

    Я активно использую mptcp для агрегации низкоскоростных каналов. Схема стандартная: Пользовательское устройство -- Wifi роутер с shadowsocks клиентом -- несколько каналов -- shadowsocks сервер -- сервер ресурсов, который запрашивает клиент.

    Схема рабочая, но не очень элегантная. Было бы круто обойтись без промежуточного сервера, на котором разбираются mptcp сессии. Пока единственный сценарий нативного использования - агрегация 4/5g и wifi на мобильных аппаратах.

    Кстати, на просторах интернета встречал сообщения, что есть интернет операторы, которые в своей сети режут пакеты с mptcp. Непонятно, зачем они это делают.


    1. Aelliari
      09.09.2022 19:06

      Если бы все хосты поддерживали его нативно... Но к сожалению приходится использовать суммирующий сервер.


      1. vrangel
        09.09.2022 19:39

        Поддержка на хостах - это одно. Еще проблема в том, что на конечных пользовательских устройствах чаще всего один канал передачи данных. Например, wifi. А уж wifi роутер, в свою очередь, может иметь несколько. Mptcp же работает, когда именно на стороне конечных участников, сервера и/или клиента есть несколько независимых канала. Wifi точка доступа в этом сценарии просто роутер и наличие на ней работающего mptcp без проксирования tcp не поможет.


    1. BigD
      10.09.2022 10:58

      А можно детали? Кажется то, что нужно, но связи между shadowsocks и mptcp не понял.


    1. BigD
      10.09.2022 19:20

      И какой роутер?