Применение Multipath TCP
РедакцияПротокол MPTCP (Multipath Transmission Control Protocol), описанный в RFC 6824, стал новейшим расширением заслуженного протокола TCP. TCP был создан тогда, когда у хостов был один сетевой интерфейс и один IP-адрес. Каждое соединение TCP идентифицируется четверкой данных (исходный и целевой адреса, исходный и целевой порты), и каждый пакет, относящийся к этому соединению, содержит эту четверку. Несмотря на юный возраст, Multipath TCP уже массово используется в коммерческих сервисах. На смартфонах он комбинирует сотовые сети и сети Wi-Fi, повышая пропускную способность и ускоряя работу приложений, чувствительных к задержке.
Протокол MPTCP (Multipath Transmission Control Protocol), описанный в RFC 6824, стал новейшим расширением заслуженного протокола TCP. TCP был создан тогда, когда у хостов был один сетевой интерфейс и один IP-адрес. Каждое соединение TCP идентифицируется четверкой данных (исходный и целевой адреса, исходный и целевой порты), и каждый пакет, относящийся к этому соединению, содержит эту четверку. После установки соединения TCP невозможно изменить ни один из элементов четверки, не разорвав соединение, а в современных сетях это обстоятельство превращается в существенное ограничение по следующим причинам:
Многие хосты поддерживают одновременно IPv4 и IPv6. Даже если интерфейс у них один, адресов оказывается два и более, и между каждой парой обменивающихся данными хостов есть несколько сетевых маршрутов.
У многих хостов по нескольку интерфейсов (смартфоны, планшеты и пр.).
Сегодня в Интернете все возрастает количество мобильных хостов, чьи адреса могут изменяться при переходе из одной беспроводной сети в другую.
Multipath TCP решает эти проблемы, дополняя TCP таким образом, что обмен данными, относящимися к одному соединению, становится возможен по различным маршрутам. Для этой цели Multipath TCP комбинирует несколько соединений TCP (названных в RFC 6824 субпотоками – subflow) в одно соединение Multipath TCP. Первый субпоток начинается с тройственного рукопожатия, как и обычное соединение TCwP. Основное отличие в том, что пакет SYN содержит опцию MP_CAPABLE, которая задает использование Multipath TCP и случайных ключей.
Как только первый субпоток установлен, любой из хостов, участвующих в коммуникации, может создать дополнительный субпоток с любого из своих адресов на любой адрес удаленного хоста, отправив новый SYN с опцией MP_JOIN. Такие субпотоки могут создаваться и закрываться в любой момент, что очень важно для мобильных хостов. Данные можно передавать по любому из субпотоков, входящих в соединение Multipath TCP в данный конкретный момент. Если субпоток перестал работать, то все данные, которые передавались по нему и до сих пор не подтверждены, будут повторно переданы по другим субпотокам.
Сегодня существует несколько независимых реализаций Multipath TCP, совместимых друг с другом. Самые распространенные – iOS/macOS и Linux (www.multipath-tcp.org). Multipath TCP поддерживается балансировщиками нагрузки, а также ведутся работы по внедрению протокола на FreeBSD и Solaris. В настоящей статье описан ряд коммерческих сервисов, использующих уникальные возможности Multipath TCP.
Смартфоны
Самая масштабная реализация Multipath TCP – для смартфонов.
Сквозная реализация Multipath TCP
Смартфоны часто подключены сразу и к точке доступа Wi-Fi, и к сотовой сети. Если пользователь подключен к Интернету по Wi-Fi и выходит из зоны досягаемости точки доступа Wi-Fi, то смартфон теряет подключение, а значит, TCP-соединение по Wi-Fi тоже «отваливается». Одним из преимуществ Multipath TCP является способность без труда переключаться с одного интерфейса на другой, это делает его лучшим кандидатом на решение подобных проблем со связью (рис. 1).
Siri – электронный помощник в операционных системах Apple iOS и macOS. Поскольку распознавание речи требует огромной вычислительной мощности, Siri передает голосовые команды потоком в центр данных Apple для распознавания, а потом получает от него результат. Хотя длительность взаимодействия пользователя с Siri относительно невелика, паттерн использования помощника делает Siri идеальным клиентом для MPTCP.
Многие используют Siri на ходу или в машине. По мере того как пользователь удаляется от точки доступа Wi-Fi, TCP-соединение, по которому Siri передает голосовую команду, в конце концов, разрывается, и вместо ожидаемого результата хозяин смартфона получает сообщение об ошибке.
Чтобы решить эту проблему, Apple использует MPTCP, начиная с версии iOS 7. Когда пользователь отдает голосовую команду Siri, iOS устанавливает MPTCP-соединение по Wi-Fi и сотовой связи. Если телефон теряет соединение с точкой доступа Wi-Fi, трафик перенаправляется по сотовому интерфейсу. Бывает так, что Wi-Fi-соединение, не разрываясь, теряет качество настолько, что по нему практически ничего нельзя передать. В этом случае происходит еще один тайм-аут повторной передачи, и iOS перенаправляет трафик по сотовому каналу.
Чтобы еще больше снизить задержку, iOS измеряет значения круговой задержки (RTT) на двух интерфейсах. Чудовищная задержка часто образуется в случае излишней буферизации (bufferbloat). У канала Wi-Fi значение RTT может быть гораздо выше, чем у сотового канала. Когда iOS обнаруживает, что RTT у Wi-Fi значительно выше, чем у сотового канала, она направляет голосовой поток через сотовый интерфейс.
И, наконец, используется ввод Wi-Fi Assist и триггер для переключения на сотовый интерфейс. Для пользователей Siri внедрение MPTCP обернулось значительным сокращением числа сетевых ошибок. После создания двух субпотоков (один – по Wi-Fi, второй – по сотовой сети) количество сетевых ошибок сократилось на 80%.
Благодаря измерению RTT и смене субпотока по его результатам Siri также стал быстрее реагировать на команды пользователя. Теперь Siri может обрабатывать команды пользователя на 20% больше в 95-й перцентили и на 30% больше в 99-й перцентили.
Развертывание MPTCP в Интернете произошло практически безболезненно. Способность MPTCP справляться с помехами от промежуточных устройств и потом возвращаться к обычному TCP оказалась полезной и не обнаружила крупных проблем. Однако примерно 5% соединений по-прежнему возвращаются к обычному TCP, вследствие внедрения прозрачных TCP-прокси в сотовых сетях и убирания опций MPTCP брандмауэрами.
Одна из проблем MPTCP – это трудность отладки. Обработка субпотоков связана со значительной сложностью кода: интерфейсы Wi-Fi появляются и пропадают. В некоторых сетях имеются промежуточные устройства, которые вмешиваются в работу MPTCP, что делает невозможным создание субпотоков. Пограничные сценарии, которые трудно воспроизвести и которые реализуются только тогда, когда продукты развертываются в огромных количествах, требуют основательного механизма журналирования для того, чтобы отследить поведение MPTCP-соединения.
Из-за неопределенностей, вносимых в сеть промежуточными устройствами, крайне трудно выявить истинные причины проблем. В результате не всегда можно разграничить программные ошибки и вмешательство промежуточного устройства.
Multipath TCP поверх прокси SOCKS
Помимо серверов, развертываемых именно для предыдущего сценария, очень немного серверов уже поддерживают Multipath TCP. Несмотря на это, ряд сетевых операторов стремится повысить быстродействие для пользователей смартфонов, комбинируя существующие сотовые и Wi-Fi-сети. Сетевые операторы в нескольких странах полагаются на SOCKS (RFC 1928), чтобы одновременно использовать Wi-Fi-сети и сотовые сети. С точки зрения оператора, основным преимуществом совмещения SOCKS и MPTCP является легкость в развертывании, поскольку в существующей основной инфраструктуре сотовых сетей и Wi-Fi практически не существует зависимостей (www.ietf.org/proceedings/93/slides/slides-93-mptcp-3.pdf).
Ряд моделей коммерческих смартфонов на платформе Android содержат реализацию Multipath TCP в ядре Linux и в клиенте SOCKS. Клиент SOCKS, выполняемый на смартфоне, перехватывает любые попытки подключения по TCP к далеким серверам. Затем он создает подключение к серверу SOCKS, управляемому сетевым оператором.
После аутентификации пользователя клиент SOCKS отправляет команду на сервер SOCKS, который создает подключение TCP с удаленным сервером. В этот момент существует соединение Multipath TCP между смартфоном и сервером SOCKS и соединение TCP между сервером SOCKS и удаленным сервером. Сервер SOCKS пересылает все данные, отправленные по соединению Multipath TCP, по соединению TCP и наоборот. Смартфоны создают дополнительные субпотоки в направлении сервера SOCKS через другие доступные интерфейсы. Результатом становится большее удобство для пользователя, за счет агрегирования пропускной способности и гладкого переключения субпотоков.
Гибридные сети доступа
Еще один важный сценарий использования Multipath TCP – это сети доступа. Во многих регионах мира имеющиеся сети доступа ограничивают полосу пропускания. Типичный пример – сельская местность, где для сетевых операторов очень затратно развертывать сети доступа с большой полосой пропускания. Даже если полоса пропускания сети доступа ограничена, часто можно подписаться на другие сетевые сервисы, которые в комплексе дают большую полосу пропускания и надежность.
Несколько компаний развернули решения, которые используют уникальные возможности Multipath TCP. Одна использует прокси SOCKS и позволяет конечным пользователям эффективно комбинировать сетевые сервисы различных провайдеров. Вторая нацелена на сетевых операторов, которые хотят объединить проводные (например, xDSL) и беспроводные (например, LTE) сети, чтобы предоставить потребителям большую пропускную способность (www.broadband-forum.org/technical/download/TR-348.pdf).
Комбинирование сетей доступа с помощью SOCKS
SOCKS также используется совместно с Multipath TCP для комбинирования различных сетей доступа. В этой инсталляции конечными пользователями являются обычные хосты, не поддерживающие Multipath TCP. Чтобы можно было воспользоваться возможностями Multipath TCP, в LAN конечного пользователя устанавливается промежуточное оборудование. Оно выступает в роли клиента SOCKS и взаимодействует с сервером в облаке. И промежуточное оборудование, и облачный сервер используют Multipath TCP, а следовательно, могут работать с любыми доступными сетями доступа, если промежуточному оборудованию присвоен IP-адрес в каждой из сетей доступа.
Как правило, промежуточное оборудование выступает в роли шлюза по умолчанию для LAN конечного пользователя. Оно перехватывает все пакеты TCP, которые хосты в LAN отправляют вовне, и затем по прокси передает их по каналам Multipath TCP на сервер SOCKS, находящийся в облаке. Этот сервер закрывает соединения Multipath TCP и открывает обычные соединения TCP с конечными точками пакетов.
Это решение уже находится в коммерческой эксплуатации в двух странах. Пользователи сообщают об успешном комбинировании различных типов ссылок доступа, включая xDSL (от ADSL до VDSL), DOCSIS, 3G, 4G и спутниковые каналы.
Multipath TCP в гибридных сетях доступа
Некоторые сетевые операторы развернули как проводные (например, xDSL), так и беспроводные (например, LTE) сети и желают комбинировать их, чтобы предлагать большую пропускную способность. Multipath TCP также может использоваться для оказания таких услуг (рис. 2).
В этой инсталляции Multipath TCP не поддерживается ни клиентом, ни сервером. Multipath TCP используется на конечном пользовательском оборудовании (Customer Premise Equipment, CPE) и гибридном агрегирующем шлюзе (Hybrid Aggregation Gateway, HAG), находящемся в центре данных сетевого оператора, который управляет обеими сетями доступа (datatracker.ietf.org/doc/draft-peirens-mptcp-transparent/).
Когда клиент открывает TCP-соединение с удаленным сервером, он отправляет пакет SYN. Этот пакет перехватывается CPE, который виртуально терминирует соединение TCP и затем добавляет опцию MP_CAPABLE в TCP-пакет, перед тем как переслать его по сети xDSL. HAG, находящийся на пути, по которому проходят все пакеты, отправляемые клиентом по сети xDSL, перехватывает пакет SYN. Он виртуально терминирует соединение Multipath TCP и затем пересылает SYN серверу, удалив опцию MP_CAPABLE. После этого сервер подтверждает установку соединения, отправив SYN+ACK. HAG перехватывает и этот пакет, обновляет его статус для этого соединения и добавляет опцию MP_CAPABLE, а затем пересылает его на CPE. CPE действует аналогично. Он обновляет состояние пакета и пересылает SYN+ACK на клиента (отрезав опцию MP_CAPABLE), чтобы подтвердить установку соединения. В этот момент открыто три соединения TCP. Первое – обычное соединение TCP. Оно начинается на клиенте и виртуально терминируется на CPE. Второе – соединение Multipath TCP, которое виртуально терминируется на CPE и HAG. Третье – опять же обычное соединение TCP между HAG и удаленным сервером. С операционной точки зрения важно отметить, что при использовании IPv6 ни CPE, ни HAG не нужно транслировать адреса исходного и целевого хостов в пересылаемых TCP-пакетах. IP-адрес клиента остается виден целевому серверу. Это важное преимущество по сравнению с решениями на базе SOCKS.
Кроме того, в этой структуре соединение между клиентом и сервером можно создать в рамках времени приема-передачи (round trip time).
Выводы
Несмотря на юный возраст, Multipath TCP уже массово используется в коммерческих сервисах. На смартфонах он комбинирует сотовые сети и сети Wi-Fi, повышая пропускную способность и ускоряя работу приложений, чувствительных к задержке. В сетях доступа он поддерживает гибридные сети доступа, которые повышают удобство для пользователя, эффективно комбинируя существующие проводные и беспроводные сети.
Благодарности
Авторы благодарят Кристофа Пааша (Christoph Paasch) и Саймона Леливра (Simon Lelievre).