Кратко

  • Multipath TCP предоставляет приложению один надёжный упорядоченный поток байтов, хотя конечные узлы могут переносить его по одному или нескольким обычным TCP-подпотокам.
  • MP_CAPABLE согласует соединение, MP_JOIN аутентифицирует дополнительный подпоток, а общая нумерация данных позволяет повторно отправить те же байты по другому пути после сбоя.
  • Два интерфейса не доказывают устойчивость: пути могут иметь общее узкое место, промежуточное устройство может удалить опции, а политика узла решает, будет ли второй путь активным, резервным или неиспользуемым.

Один сокет за границей Wi-Fi

Смена доступа выглядит как замена адреса: один перестаёт работать, другой становится доступен. Но для приложения ценен не адрес, а уже накопленное состояние и последовательность байтов, которая должна прийти надёжно и в правильном порядке.

RFC 8684 разделяет соединение и путь. Одно MPTCP-соединение соответствует одному сокету приложения, но может содержать несколько подпотоков. Каждый ведёт себя как TCP на собственном пути. Уровень соединения над ними сохраняет надёжность и порядок. Поэтому завершение одного подпотока не обязано завершать всё соединение.

Это условная возможность, а не гарантия. Оба узла должны согласовать MPTCP, хотя бы один пригодный подпоток должен сохраниться или быть создан, а общее состояние — уцелеть. Протокол даёт механизм непрерывности, но не подтверждает покрытие, физическую независимость или качество запасного пути.

Новый путь должен быть допущен

Первый подпоток несёт обмен MP_CAPABLE. Узлы подтверждают поддержку MPTCP и обмениваются ключевым материалом соединения. Если другая сторона не поддерживает протокол или устройство на пути блокирует опции, соединение может вернуться к обычному TCP.

Дополнительный адрес не присоединяется сам. Новый handshake содержит MP_JOIN: токен указывает нужное соединение, а случайные числа и HMAC на основе исходных ключей подтверждают тех же участников. Локальная политика всё равно вправе отказать. Второй путь сначала проходит допуск и лишь затем может переносить данные.

ADD_ADDR объявляет адрес, REMOVE_ADDR отзывает его. Идентификаторы адресов помогают при переписывании заголовков NAT. Однако объявление создаёт только кандидата; оно не доказывает достижимость, независимость, цену или производительность.

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

Общий реестр байтов над отдельными TCP

У каждого подпотока остаются собственные номера последовательности TCP. MPTCP добавляет 64-битный номер последовательности данных для всего соединения. DSS связывает байты подпотока с общим пространством и подтверждает прогресс на уровне соединения.

Этот второй реестр создаёт возможность восстановления. Если один подпоток не доставил данные, те же байты соединения можно повторно отправить по другому с новым отображением. Приложение продолжает получать единый надёжный упорядоченный поток и не объединяет два независимых соединения самостоятельно.

Порядок одновременно создаёт ограничение. Пропуск на медленном пути способен задержать выдачу более поздних байтов, уже пришедших по быстрому. Планировщик пакетов, перенос повторной отправки и управление перегрузкой определяют, добавят ли несколько путей полезную ёмкость или ожидание. RFC 8041 описывает это как практическую эксплуатационную задачу.

У резервного пути есть цена

Подпоток может быть обычным или резервным, а MP_PRIO позволяет запросить смену приоритета. За маленьким флагом скрывается экономическое решение. Сотовый доступ может спасти соединение, но тарифицироваться по объёму. Спутниковый путь может оставаться доступным с высокой задержкой. Два фиксированных доступа могут сходиться в одном канале или у одного вышестоящего оператора.

RFC 6182 предупреждает: разные пары адресов не гарантируют раздельных путей. Архитектура стремится повысить пропускную способность и устойчивость, сохранить модель TCP и не ущемлять других пользователей в общем узком месте. Это цели проектирования, а не измерение конкретной сети.

Значит, доказательством служит согласованное соединение: фактически созданные подпотоки, активные и резервные роли, разные домены отказа, продвижение общих подтверждений и байты, которым пришлось сменить путь. Число интерфейсов показывает варианты, но не непрерывность.

Откат тоже является результатом

Промежуточные устройства могут удалить TCP-опции, переписать адреса или несовместимо изменить данные. RFC 8684 задаёт безопасные реакции: первый подпоток может перейти к обычному TCP, дефектный дополнительный — закрыться, а путь, потерявший корректные отображения, должен считаться сломанным.

Поэтому приложение может работать без multipath. Мониторинг, который фиксирует только успех, смешивает два случая: соединение выжило по другому подпотоку или MPTCP никогда не работал, а обычный TCP продолжил обмен. Если соединение стало больше одного пути, эксплуатационное доказательство тоже должно стать шире.

Источники