 |
|
Previous: 4.4.3.5 Протокол TFRC
UP:
4.4.3 Протокол TCP |
|
|
|
Previous: 4.4.3.5 Протокол TFRC
UP:
4.4.3 Протокол TCP |
Сетевые технологии становятся все более динамичными, быстро растут требования к пропускной способности. Одним из возможных путей увеличения полосы пропускания является распараллеливание информационных потоков.
На рисунке ниже представлен пример многопотоковой передачи данных с привлечением протокола MPTCP (рисунок взят из "MPTCP and Product Support Overview", Document ID: 116519 Contributed by Jay Young and Daniel Wing, Cisco TAC Engineers. Sep 17, 2013)
Пример многопотоковой передачи данных компьютер-сервер
Для решения подобных проблем и был разработан протокол многомаршрутной передачи данных в рамках модифицированного протокола ТСР (RFC-6824). Эта техника позволяет получить большую пропускную способность без замены оборудования или коммуникационных каналов. В случае серверов с большим входным потоком запросов можно снабдить его одним или более сетевым интерфейсом, подключенным к отдельному каналу.
Многомаршрутный TCP (MPTCP) является набором расширений регулярного протокола TCP для предоставления сервисов Multipath TCP, которые делают возможным для одного соединения передачу данных через несколько маршрутов одновременно. Здесь рассматриваются три аспекта реализации протокола:
Для того, чтобы ограничить потенциально огромный объем работы, группа разработки ввела два ключевых ограничения для реализации Multipath TCP:
Для упрощения структуры, мы предполагаем, что присутствие нескольких адресов компьютеров достаточно, чтобы можно было говорить о многомаршрутности. Эти маршруты не должны быть полностью изолированы: они могут совместно использовать один или более маршрутизаторов. Даже в такой ситуации, применение многомаршрутности привлекательно, так как улучшает эффективность использования ресурсов и гибкость системы подавления перегрузки. Выбранные алгоритмы управления перегрузкой действуют так, чтобы не нанести вреда приложениям. Более того, могут быть некоторые сценарии, где разные TCP-порты на одном компьютере могут предоставлять несовместимые маршруты (например, в случае применения ECMP (Equal-Cost Multipath), протокол MPTCP может поддерживать использование портов в идентификаторах маршрутов.
Существует три аспекта обратной совместимости, упомянутой выше (более подробно это описано в [2]):
Внешние ограничения: Протокол должен работать с большинством промежуточных узлов, таких как NAT, firewall и прокси и должен быть по возможности сходен с существующим TCP. Более того, протокол не должен предполагать, что сегменты, которые он посылает, доставляются к месту назначения неизмененными: они могут быть расщеплены или объединены, а TCP-опции могут быть удалены или дублированы.
Ограничения приложения: Протокол должен быть применим без изменений к существующим приложениям, которые работают с традиционными TCP-приложениями (хоты разумно, чтобы не все возможности были доступны для такого приложения). Более того, протокол должен обеспечить для приложения тот же набор сервисов, что и регулярный TCP.
MPTCP работает на транспортном уровне и должен быть прозрачным для более высоких и более низких уровней. Он является набором дополнительных возможностей поверх стандартного TCP. Рис. 1 иллюстрирует эту послойную структуру. Протокол MPTCP устроен так, чтобы быть применимым наследуемыми приложениями без необходимости внесения каких-либо изменений в код. Детальное описание его взаимодействия с приложением представлено в [6].
Рис. 1. Сравнение стандартного TCP и стеков MPTCP-протокола
Маршрут: Последовательность каналов между отправителем и получателем, определенная в этом контексте двумя парами адрес-порт отправителя и получателя.
Субпоток: Поток TCP-сегментов, передаваемых по индивидуальному маршруту, который составляет часть MPTCP-соединения. Субпоток запускается и прерывается также как и обычное TCP-соединение.
Соединение MPTCP: Набор из одного или более субпотоков, через которые приложение может взаимодействовать с двумя компьютерами. Существует соответствие один-к-одному между соединением и прикладным сокетом.
Уровень данных (Data-level): Поле данных в норме передается через соединение, которое в свою очередь транспортируется посредством субпотоков. Таким образом, термин "data-level" является синонимом "уровень соединения", в отличие от "уровень субпотока", который относится к свойствам индивидуального субпотока.
Маркер (token): Локально уникальный идентификатор, присвоенный компьютером многомаршрутному соединению. Может также называться идентификатором соединения ("ID-соединения").
Компьютер: Компьютер, на котором работает приложение MPTCP, и либо инициализирует, либо воспринимает MPTCP-соединение.
В этом разделе предоставлено высокоуровневое описание нормальной работы MPTCP, а на рис 2 показан сценарий такой работы. Детальное описание работы представлено в разделе 3.
Рис. 2. Пример сценария использования MPTCP
Этот раздел описывает общую схему работы протокола MPTCP. Здесь будут рассмотрены ключевые функции, полная спецификация помещена в разделе 3. В этом разделе особое внимание уделено символическим именам опций MPTCP. Формат опций определен в спецификации, которая имеется в разделе 3.
Соединение многомаршрутного TCP обеспечивает двухсторонний байтовый обмен между двумя компьютерами, взаимодействующими друг с другом в рамках традиционного протокола TCP и, таким образом, не требуется каких-либо изменений в приложениях. Однако, многомаршрутный TCP позволяет компьютерам использовать разные маршруты с разными IP-адресами для обмена пакетами, принадлежащими MPTCP-соединению. Соединение многомаршрутного TCP выглядит для приложения подобно обычному TCP-соединению. Однако, на сетевом уровне, каждый субпоток MPTCP выглядит как регулярный TCP-поток, сегменты которого несут в себе новые типы ТСР-опций. MPTCP управляет созданием, удалением и использованием этих субпотоков для передачи информации. Число субпотоков, которые управляются соединением MPTCP не определено и может изменяться в период существования MPTCP-соединения.
Все операции MPTCP управляются с помощью TCP-опций -- один числовой тип для MPTCP, с "субтипами" для каждого MPTCP-сообщения.
Система установления соединения здесь идентична используемой в нормальном протоколе TCP, но пакеты SYN, SYN/ACK и ACK несут в себе также опцию MP_CAPABLE. Она имеет переменную длину и служит многим целям. Сначала, она проверяет, поддерживает ли удаленный компьютер MPTCP; далее, эта опция позволяет компьютерам обмениваться некоторой информацией для аутентификации установления дополнительных субпотоков. Дальнейшие подробности можно найти в разделе 3.1.
Компьютер A Компьютер B
------ ------
MP_CAPABLE ->
[A's key, флаги]
<- MP_CAPABLE
[B's key, флаги]
ACK + MP_CAPABLE ->
[A's key, B's key, флаги]
Обмен ключами в диалоге MP_CAPABLE обеспечивает материал, который может использоваться для аутентификации оконечных узлов, когда формируются новые субпотоки. Дополнительные субпотоки стартуют аналогично нормальным TCP-соединениям, но пакеты SYN, SYN/ACK и ACK несут в себе опцию MP_JOIN.
Компьютер A инициирует новый субпоток между одним из своих адресов и одним из адресов компьютера B. Маркер -- сформированный из ключа -- используется для идентификации того, какое MPTCP-соединение подключается, а HMAC (Hash-based Message Authentication Code) служит для аутентификации. HMAC использует ключевой обмен в режиме диалога MP_CAPABLE, а также случайные числа, передаваемые в опциях MP_JOIN. MP_JOIN содержит также флаги и IP-адрес, который можно использовать в качестве адреса отправителя. При этом не нужно знать был ли адрес преобразован системой NAT. Дополнительные подробности представлены на разделе 3.2.
Компьютер A Компьютер B
------ ------
MP_JOIN ->
[B's маркер, A's nonce,
A's Address ID, флаги]
<- MP_JOIN
[B's HMAC, B's nonce,
B's Address ID, флаги]
ACK + MP_JOIN ->
[A's HMAC]
<- ACK
Набор IP-адресов, ассоциированный с многопортовым компьютером, может меняться за время жизни MPTCP-соединения. MPTCP поддерживает добавление и удаление адресов как явно, так и неявно. Если компьютер A сформировал субпоток, начинающийся от адреса IP#-A1 и хочет открыть второй субпоток, начинающийся от адреса IP#-A2, он просто инициирует установление субпотока, как это было описано выше. Удаленный компьютер будет неявно информирован об этом новом адресе.
В некоторых обстоятельствах, компьютер может захотеть анонсировать удаленному компьютеру доступность адреса без установления нового субпотока, например, когда NAT препятствует этому в одном из направлений. В примере ниже компьютер A информирует компьютер B о своем альтернативном IP-адресе (IP#-A2). Компьютер B может позднее послать MP_JOIN по этому новому адресу. Из-за присутствия промежуточных узлов (middleboxes), которые могут преобразовывать IP-адреса, эта опция использует идентификатор адреса для однозначного определения адреса компьютера. Дальнейшие детали описаны в разделе 3.4.1.
Компьютер A Компьютер B
------ ------
ADD_ADDR ->
[IP#-A2,
IP#-A2's Address ID]
Существует соответствующий сигнал для удаления адреса. Он использует идентификатор адреса, который был установлен в процессе диалога добавления адреса. Дальнейшие подробности содержатся в разделе 3.4.2.
Компьютер A Компьютер B
------ ------
REMOVE_ADDR ->
[IP#-A2's Address ID]
Чтобы гарантировать надежную, упорядоченную доставку данных через субпотоки, которые могут появиться и исчезнуть в любое время, протокол MPTCP использует 64-битный порядковый номер данных DSN (data sequence number), чтобы пронумеровать все данные передаваемые через MPTCP-соединение. Каждый субпоток имеет свой собственный 32-битный порядковый номер и опция MPTCP устанавливает соответствие между пространством номеров субпотоков и пространством номеров данных. Таким образом, данные могут быть переданы различными субпотоками (с привязкой к одному и тому же DSN) в случае сбоя.
"Data Sequence Signal" несет в себе "Data Sequence Mapping". Привязка порядковых номеров данных состоит из порядкового номера субпотока, порядкового номера данных и длины, для которой справедлива эта привязка. Эта опция может также нести подтверждение уровня соединения ("Data ACK") для полученного DSN.
Для MPTCP, все субпотоки используют общий входной буфер и анонсируют то же самое окно приема. В MPTCP существует два уровня подтверждения. Подтверждения регулярного TCP используется для каждого субпотока при подтверждении получения сегмента, посланного через субпоток, вне зависимости от их DSN. Кроме того, существует подтверждение уровня соединения для пространства порядковых номеров данных. Эти подтверждения отслеживают поток байтов и управляют скользящим входным окном.
Дальнейшие подробности можно найти в разделе 3.3.
Компьютер A Компьютер B
------ ------
DATA_SEQUENCE_SIGNAL ->
[Data Sequence Mapping]
[Data ACK]
[Checksum]
Компьютеры могут индицировать исходное установление субпотока, в зависимости от того, хотят ли они использовать субпоток в регулярном или в режиме backup маршрута -- backup маршрут будет использоваться, если не существует регулярного маршрута. Во время соединения компьютер A может запросить изменения приоритета субпотока с помощью сигнала MP_PRIO, направленного компьютеру B. Дальнейшие подробности можно найти в разделе 3.3.8.
Компьютер A Компьютер B
------ ------
MP_PRIO ->
Когда компьютер A хочет проинформировать компьютер B о том, что у него нет больше данных для отправки, он посылает "Data FIN" в качестве части сигнала последовательности данных (Data Sequence Signal) (смотри выше). Он имеет ту же семантику и поведение, что и регулярный TCP FIN, но на уровне соединения. Когда все данные соединения MPTCP успешно доставлены, доставка сообщения подтверждается на уровне соединения с помощью DATA_ACK. Дальнейшие подробности можно найти в разделе 3.3.3.
Компьютер A Компьютер B
------ ------
DATA_SEQUENCE_SIGNAL ->
[Data FIN]
<- (MPTCP DATA_ACK)
Следует подчеркнуть, система управления в MPTCP создавалась с учетом следующих ключевых требований:
Этот раздел описывает работу MPTCP-протокола, он разделен на подразделы для каждой ключевой протокольной операции.
Все операции MPTCP обеспечиваются с использованием полей опций TCP-заголовка. Один номер опции TCP - сорт (Kind) был назначен IANA для MPTCP (см. раздел 8), а индивидуальные сообщения определяются субтипами, значения которых также хранятся в IANA-регистрах (они перечислены в разделе 8).
В данном описании, когда производится ссылка на символическое имя опции MPTCP, такое как MP_CAPABLE, это относится к TCP-опции и субтипу символического имени, как показано в разделе 8. Этот субтип представляет собой 4-битовое поле -- первые 4 бита поля данных опции, как показано на рис. 3. Сообщения MPTCP определены в последующих разделах.
Рис. 3. Формат опций MPTCP
Эти опции MPTCP, ассоциированные с инициацией субпотока, используются в пакетах с установленным флагом SYN. Кроме того, существует одна MPTCP опция для метаданных, которая помогает гарантировать правильное восстановление информации в случае сегментации.
Остальные опции, однако, являются сигналами, которым не нужны специальные пакеты, например, для объявления дополнительных адресов. В то же время реализация может пожелать посылать MPTCP-опции так быстро, как только возможно. Может быть невозможно комбинировать все желательные опции (как для MPTCP так и для регулярного TCP, такую как SACK (селективное подтверждение) [11]) в одном пакете. Следовательно, реализация может решить послать дублированное ACK, содержащее дополнительную сигнальную информацию. Это изменяет семантику двойного подтверждения (duplicate ACK); которое посылается обычно только как сигнал потери сегмента [12] в регулярном TCP. Следовательно, MPTCP реализация, получая дублированное подтверждение ACK, которое содержит MPTCP-опцию, не должно рассматривать ее в качестве сигнала перегрузки. Кроме того, MPTCP реализация не должна посылать более двух дублирующих ACK подряд для целей передачи MPTCP-опций, для того, чтобы гарантировать, что прочие промежуточные узлы не будут ошибочно интерпретировать это, как сигнал перегрузки.
Более того, стандартные проверки корректности TCP (такие как контроль порядковых номеров и числа подтверждений в пределах окна) должны производиться до обработки любых MPTCP-сигналов, как это описано в [13].
Инициация соединения начинается с обмена SYN, SYN/ACK, ACK для каждого из маршрутов. Каждый пакет содержит опцию (MP_CAPABLE) TCP (Рис. 4). Эта опция декларирует, что ее отправитель способен работать с MP TCP и хочет это делать в данном конкретном соединении.
Эта опция используется, чтобы декларировать 64-битный ключ, который сгенерировал отправитель для данного MPTCP-соединения. Этот ключ используется для аутентификации добавления будущего субпотока к данному соединению. Это единственное время, когда ключ посылается по каналу открыто (если только не используется "fast close" (быстрое закрытие), раздел 3.5); все будущие субпотоки будут идентифицировать соединение, используя 32-битный "маркер". Этот маркер является криптографическим хэшем данного ключа. Алгоритм этого процесса зависит от выбранного алгоритма аутентификации.
Этот ключ генерируется отправителем, а его метод генерации зависит от конкретной реализации. Этот ключ должно быть практически невозможно угадать, и он должен быть уникален для данного компьютера-отправителя. Рекомендации по генерации случайных чисел для ключей представлены в [14]. Соединения будут индексироваться каждым компьютером с помощью маркера (однонаправленный хэш ключа). Следовательно, реализация будет требовать соответствия для каждого маркера соответствующего соединения и ключами соединения.
Имеется риск того, что два разных ключа в результате хэширования дадут идентичный маркер. Риск столкновения хэшей обычно невелик, если только компьютер не работает с десятками тысяч соединений. Следовательно, реализация должна проверять свой список маркеров соединений, чтобы гарантировать отсутствия столкновений, прежде чем посылать свой ключ в SYN/ACK. Это будет однако достаточно дорого для серверов с тысячами соединений. Механизм диалога для субпотока (раздел 3.2) будет гарантировать, что новый субпоток присоединится только к правильному соединению. В крайнем случае, если произошло столкновение маркеров, новый субпоток не будет сформирован, но MPTCP-соединение продолжит осуществлять регулярные TCP-сервисы.
Опция MP_CAPABLE используется с пакетами SYN, SYN/ACK и ACK, которые запускают первый субпоток MPTCP-соединения. Данные, передаваемые каждым пакетом, могут быть следующими (где A = инициатор и B = слушатель):
Содержимое опции определяется флагами пакета SYN и ACK, верифицируемыми полем длины опции. На диаграмме, показанной на рис. 4, "отправитель" и "получатель" относятся к отправителю или получателю TCP-пакета (которым может быть любой из компьютеров). Если флаг SYN установлен, включается один ключ; если установлен только флаг ACK, присутствуют оба ключа.
Ключ B подтверждается в ACK для того, чтобы позволить слушателю (компьютер B) действовать вне зависимости от состояния, пока TCP-соединение не придет в состояние ESTABLISHED.
Этот обмен обеспечивает безопасную передачу опций MPTCP в SYN-пакетах. Если любая из этих опций потеряна, MPTCP перейдет в режим регулярного одномаршрутного TCP, как это описано в разделе 3.6. Заметим, что новые субпотоки не должны устанавливаться (используя процесс, описанный в разделе 3.2) пока не будет получена опция DSS (Digital Signature Standard) (как показано в разделе 3.3).
Рис. 4. Опция MP_CAPABLE
Первые 4 бита первого октета в опции MP_CAPABLE (Рис. 4) определяют субтип опции MPTCP (см раздел 8; для MP_CAPABLE, этот код равен 0), а остальные 3 бита этого октета специфицируют используемую версию MPTCP (для данной спецификации код равен 0).
Второй октет зарезервирован для флагов, используется следующее распределение назначения битов:
Должен быть специфицирован криптоалгоритм. Если биты флага с C по H все равны 0, опция MP_CAPABLE должна считаться некорректной и игнорироваться (т.е., это должно рассматриваться как регулярный диалог TCP).
Выбор алгоритма аутентификации влияет также на алгоритм, используемый для генерации маркера и начального значения порядкового номера данных (IDSN). В этой спецификации, с единственным алгоритмом SHA-1 (бит "H") маркер должен быть укорочен. Должны быть оставлены старшие 32 бита хэша SHA-1 ([4], [15]) ключа. 64-битовое укорочение (младшие 64 бита) хэша SHA-1 ключа должно использоваться в качестве начального значения порядкового номера данных. Заметим, что ключ должен быть хэширован с сетевым порядком байт. Заметим также, что "самые младшие" биты должны быть самыми правыми битами дайджеста SHA-1 [4]. Будущие спецификации использования крипто битов могут задать другие алгоритмы для генерации маркера и IDSN.
Согласование использования крипто средств и битов контрольной суммы осуществляется сходным образом. Для контрольной суммы нужен бит, помеченный как "A", если любой из компьютеров требует использования контрольных сумм, контрольные суммы должны использоваться. Другими словами, единственная возможность не использовать контрольные суммы, - установка обоими компьютерами в своих SYN A=0. Это решение подтверждается путем установки бита "A" в третьем пакете (ACK) в процессе диалога. Например, если инициатор устанавливает в SYN A=0, но партнер откликается SYN/ACK с A=1, контрольные суммы должны использоваться для обоих направлений и инициатор установит в своем ACK A=1.
Для крипто согласования партнер имеет выбор. Инициатор формирует предложение, устанавливая биты для каждого алгоритма, который он поддерживает =1 (в настоящей спецификации, имеется только одно предложение, т.е. бит "H" будет всегда установлен равным 1). Партнер откликается с битами =1 для алгоритмов, которые он поддерживает. Рациональным для такого поведения может быть вариант, когда партнером является сервер с тысячами возможных соединений, так что он может пожелать выбрать алгоритм с минимальной вычислительной сложностью Если партнер не поддерживает (или не хочет поддерживать) любое из предложений инициатора, он может послать отклик без опции MP_CAPABLE, что потребует возврата к регулярному протоколу TCP.
Опция MP_CAPABLE используется только в первом субпотоке соединения, для того, чтобы идентифицировать соединение. Все последующие субпотоки будут использовать для присоединение к существующему соединению опцию "Join" (см. раздел 3.2).
Если SYN содержит опцию MP_CAPABLE, а SYN/ACK - нет, предполагается, что пассивный партнер, открывающий соединение, не поддерживает многомаршрутность; тогда, MPTCP-сессия должна работать как регулярная одномаршрутная TCP-сессия. Если SYN не содержит опцию MP_CAPABLE, отклик SYN/ACK не должен содержать ее также. Если третий пакет (ACK) не содержит опцию MP_CAPABLE, тогда сессия должна реализоваться как одномаршрутная, регулярная ТСР-сессия. Это сделано для совместимости с вариантами с наличием промежуточных узлов (middleboxes), которые могут удалить некоторые или все опции TCP. Заметим, что реализация может выбрать вариант с попыткой посылки MPTCP-опций более одного раза, прежде чем принять решение о переходе к регулярному TCP (см раздел 3.8).
Если пакеты SYN не подтверждены, все решается на уровне локальной политики. Ожидается, что отправитель будет переходить к регулярному одномаршрутному TCP (т.е., без опции MP_CAPABLE) для того, чтобы работать с промежуточными узлами, которые могут отбрасывать пакеты с незнакомыми опциями; однако, число предпринимаемых многомаршрутных попыток определяется локальной политикой. Возможно, что MPTCP и не-MPTCP SYN будут поменяны местами в сети. Следовательно, окончательное состояние определяется наличием или отсутствием опции MP_CAPABLE в третьем пакете TCP-диалога. Если эта опция отсутствует, соединение должно вернуться в режим регулярного TCP, как описано в разделе 3.6.
Исходный порядковый номер данных для соединения MPTCP генерируется на основе ключа. Алгоритм для генерации IDSN также определяется диалогом алгоритма аутентификации. В данной спецификации, где специфицирован только алгоритм SHA-1, IDSN компьютера должно быть равно младшим 64 битам хэша SHA-1 его ключа, т.е., IDSN-A = Hash(Key-A) и IDSN-B = Hash(Key-B). Такая генерация IDSN позволяет получателю быть уверенным, что при установлении соединения не будет пропусков в пространстве номеров. SYN с MP_CAPABLE занимает первый октет в пространстве порядковых номеров данных, хотя и нет нужды убеждаться в этом на уровне соединения пока не будут посланы первые данные (см. раздел 3.3).
Раз MPTCP-соединение началось с обмена MP_CAPABLE, последующие субпотоки могут быть добавлены к соединению позднее. Компьютеры знают свои собственные адреса, и могут запросить другой компьютер относительно его адресов посредством стандартного диалога, как это описано в разделе 3.4. Используя эту информацию, компьютер может инициировать новый субпоток через пока неиспользуемые пары адресов. Любому компьютеру в соединении разрешено инициировать создание нового субпотока, но ожидается, что это будет в норме исходный инициатор соединения (см. раздел 3.8). Новый субпоток стартует с обычного обмена TCP SYN/ACK. Опция ТСР MP_JOIN (Join Connection) TCP используется для идентификации соединения, к которому должен подключиться новый субпоток. Он использует ключевой материал, который был получен в результате исходного MP_CAPABLE диалога (раздел 3.1), и который также согласовал крипто-алгоритм, используемый для диалога MP_JOIN.
Этот раздел специфицирует поведение MP_JOIN, использующего алгоритм HMAC-SHA1. Опция MP_JOIN присутствует в SYN, SYN/ACK и ACK трехшагового диалога, хотя в каждом случае формат может быть разным.
В первом SYN-пакете MP_JOIN, показанном на рис. 5, инициатор посылает маркер, случайное число и идентификатор адреса.
Маркер используется для идентификации MPTCP-соединения и является криптографическим хэшем ключа получателя, полученного в процессе первичного диалога MP_CAPABLE (раздел 3.1). В данной спецификации, маркер, присутствующий в этой опции, генерируется с помощью алгоритма SHA-1 ([4], [15]), укорачивается до 32 старших бит. Маркер в опции MP_JOIN, является маркером, который получатель пакета использует для идентификации соединения, т.е., компьютер A пошлет маркер-B (который сформирован из Key-B). Заметим, что алгоритм генерации хэша может быть переписан диалогом выбора криптографического алгоритма, как определено в разделе 3.1.
MP_JOIN SYN посылает не только маркер (который является статическим для соединения), но также случайные числа (nonces), которые используются для предотвращения атак отклика против метода аутентификации. Рекомендации для генерации случайных чисел для данных целей представлены в [14].
Опция MP_JOIN включает в себя "Address ID" (идентификатор адреса). Это идентификатор, который имеет значение только в пределах одного соединения, где он идентифицирует адрес отправителя данного пакета, даже если IP-заголовок был модифицирован промежуточным узлом. Идентификатор адреса позволяет удалять адрес (раздел 3.4.2) без необходимости знать адрес отправителя на уровне получателя, допуская таким образом удаление адресов в NAT. Идентификатор адреса также позволяет контролировать взаимозависимость между попытками сформировать новые субпотоки и адресным управлением (раздел 3.4.1), чтобы предотвратить установление дублирующих субпотоков на одном и том же маршруте, если MP_JOIN и ADD_ADDR посланы в одно и то же время.
Идентификаторы адреса субпотока используемые в исходном SYN-обмене первого субпотока в соединении, подразумеваются равными нулю. Компьютер должен запомнить соответствие между идентификатором адреса и адресами партнеров обмена. Реализации будет также нужно знать, какие локальные и удаленные идентификаторы адреса относятся к конкретным установленным субпотокам, для того чтобы без ошибок выполнять удаление адресов для локального и удаленного компьютеров.
Опция MP_JOIN пакетов с установленным флагом SYN включает в себя 4 бита флагов, 3 из которых в настоящее время зарезервированы и должны быть установлены отправителем равными нулю. Последний бит, помеченный "B", индицирует, хочет ли отправитель использовать субпоток в качестве резервного маршрута (B=1) на случай отказа другого пути, или хочет ли он использовать часть соединения немедленно. Установив B=1, отправитель опции запрашивает другой компьютер посылать данные только через данный субпоток, если не существует субпотоков, где B=0. Политика субпотоков обсуждена более подробно в разделе 3.3.8.
Рис. 5. Опция MP_JOIN (для исходного SYN)
Когда получен SYN с опцией MP_JOIN, которая содержит корректный маркер для существующего MPTCP-соединения, получатель должен откликнуться отправкой SYN/ACK, который содержит опцию MP_JOIN, содержащую случайное число и самые левые 64 бита HMAC (Hash-based Message Authentication Code). Эта версия опции показана на рис. 6. Если маркер неизвестен, или компьютер не хочет создавать субпоток (например, из-за ограничения предельного числа субпотоков) получатель пошлет сигнал сброса (RST), аналогично случаю с неизвестным номером порта TCP. Хотя вычисление HMAC требует криптографических операций, считается, что 32-битный маркер в MP_JOIN SYN дает достаточную защиту против атак (blind state exhaustion). Следовательно, нет нужды предоставлять механизм, позволяющий партнеру работать, игнорируя состояние MP_JOIN на данном этапе.
HMAC посылается обоими компьютерами -- инициатором (компьютер A) в третьем пакете (ACK) и его партнером (компьютер B) во втором пакете (SYN/ACK). Выполнение HMAC-обмена на этом этапе позволяет обоим компьютерам получить случайные числа (в первых двух SYN-пакетах), которые используются в качестве "сообщения". Данная спецификация определяет, что HMAC, как это сказано в [10] используется, вместе с алгоритмом хэша SHA-1 [4], таким образом генерируя 160-битный / 20-октетный HMAC. Из-за ограничений размера опции, HMAC, включенный в SYN/ACK, укорачивается, сохраняя левые 64 бита, но это вполне приемлемо, так как используются случайные числа; таким образом, атакер имеет только один шанс угадать HMAC (если HMAC некорректен, TCP-соединение закрывается, так как требуется новое согласование MP_JOIN с новыми случайными числами).
Информация аутентификации инициатора посылается с первым подтверждением ACK (третий пакет диалога), как это показано на рис. 7. Эти данные нужно послать с гарантией доставки, так как это единственное время, когда посылается HMAC; следовательно, получение этого пакета должно активировать отправку регулярного TCP ACK, а пакет должен быть послан повторно, если этот ACK не получен. Другими словами, посылка пакета ACK/MP_JOIN переводит субпоток в состояние PRE_ESTABLISHED, и он переходит в состояние ESTABLISHED только после прихода ACK от получателя. В состоянии PRE_ESTABLISHED данные посылать не разрешено. Резервные биты в этой опции должны быть сброшены отправителем в нуль.
Ключ для алгоритма HMAC, в случае сообщения, переданного компьютером A, будет ключом A, за которым следует ключ B, а в случае компьютера B, ключ-B, за которым следует ключ-A. Это ключи, которыми осуществляется обмен во время диалога MP_CAPABLE. "Сообщение" для алгоритма HMAC в каждом случае являются объединением случайного числа для каждого из компьютеров (обозначено с помощью R): для компьютера A, R-A, за которым следует R-B; и для компьютера B, R-B, за которым следует R-A.
Рис. 6. Опция подключения соединения (MP_JOIN) (для отклика SYN/ACK)
Рис. 7. Опция Join соединение (MP_JOIN) (для третьего ACK)
Эти TCP-опции взаимно согласованы для обеспечения установления аутентифицированных субпотоков, как это показано на рис. 8.
Рис. 8. Пример использования аутентификации в MPTCP
Если маркер, полученный компьютером B неизвестен или локальная политика запрещает прием нового субпотока, получатель должен откликнуться посредством TCP RST для данного субпотока.
Если маркер принят компьютером B, но HMAC, присланный компьютеру A, не соответствует ожидаемому, компьютер A должен закрыть субпоток с помощью TCP RST.
Если компьютер B не получит ожидаемого HMAC, или опция MP_JOIN отсутствует в ACK, он должен закрыть субпоток посредством TCP RST.
Если HMACs восприняты как правильные, тогда оба компьютера аутентифицировали друг друга и рассматриваются партнерами, как это было на момент начала соединения, и они согласны относительно того, какому соединению соответствует данный субпоток.
Если SYN/ACK, полученный компьютером A, не имеет опции MP_JOIN, компьютер A должен закрыть субпоток с помощью RST.
Это покрывает все случаи потери MP_JOIN. Если MP_JOIN оказался удален из SYN по пути от A к B, и компьютер B не имеет партнера, подключенного к соответствующему порту, он среагирует посредством RST в рамках нормальной процедуры. Если в отклике на SYN с опцией MP_JOIN, SYN/ACK получен без опции MP_JOIN (либо так как она была удалена на обратном пути, либо она была утрачена на исходящем маршруте компьютер B реагирует так, будто это новая регулярная TCP-сессия), когда субпоток не используется, компьютер A должен закрыть его с помощью RST.
Заметим, что дополнительные субпотоки могут быть сформированы между любой парой портов (см. раздел 3.8); никаких запросов со стороны прикладного уровня для открытия дополнительного субпотока не требуется. Чтобы ассоциировать новый субпоток с существующим соединением, маркер, поставляемый во время SYN-обмена, используется для демультиплексирования. Это затем связывает кортеж параметров TCP-субпотока с локальным маркером соединения. Следствием является то, что имеется возможность использовать любую пару портов соединения.
Демультиплексирование SYN субпотока должно осуществляться с помощью маркера; это не похоже на традиционный TCP, где порт назначения используется для демультиплексирования SYN-пакетов. Когда субпоток сформирован, для демультиплексирования пакетов используется кортеж из 5 параметров, как в традиционном TCP. Этот кортеж будет поставлен в соответствие локальному идентификатору соединения (маркеру).
В этом разделе обсуждается работа MPTCP по передаче данных. На высоком уровне реализация MPTCP будет брать один входной информационный поток от приложения, и разделяет его на один или более субпотоков, с достаточной контрольной информацией, чтобы позволить приложению получателя осуществить успешную сборку.
Привязка различных частей данных и информационных ACK осуществляется с помощью опции DSS (Data Sequence Signal) (Рис. 9). Порядковая привязка данных определяет, как пространство номеров элементов в субпотоке сопрягается с уровнем соединения.
Рис. 9. Опция DSS (Data Sequence Signal)
Флаги, когда установлены, определяют содержимое этой опции следующим образом:
Флаги 'a' и 'm' имеют значение, если соответствующие флаги 'A' или 'M' =1; в противном случае, они будут игнорироваться. Максимальная длина этой опции со всеми установленными флагами составляет 28 октетов.
Флаг 'F' индицирует "DATA_FIN". Если он присутствует, это означает, что соответствие эквивалентно уровню соединения с FIN флагом в одномаршрутном TCP. Соединение не закрывается, пока не будет осуществлен обмен DATA_FIN или не произойдет таймаут.
Заметим, что контрольная сумма присутствует только в этой опции, если применение контрольного суммирования было согласовано при диалоге MP_CAPABLE MPTCP (см. раздел 3.1). О присутствии контрольной суммы можно узнать на основе длины опции. Если контрольная сумма присутствует, но ее использование не согласовано при диалоге MP_CAPABLE, поле контрольной суммы игнорируется. Если контрольная сумма отсутствует, когда ее использование было согласовано, получатель должен закрыть субпоток посредством RST, так как он считается неисправным.
Поток данных, как целое может быть реассемблирован путем использования DSS-опции (Рис. 9), которая определяет соответствие между последовательным номером субпотока и последовательным номером данных. Это делается получателем, чтобы гарантировать отсутствие перепутывания порядка фрагментов данных на прикладном уровне. Между тем, последовательные номера уровня субпотока (т.е., регулярные последовательные номера TCP-заголовка) имеют смысл только на уровне субпотока. Ожидается (но не является обязательным), чтобы для улучшения эффективности на уровне субпотока использовался SACK [11].
Согласование последовательных номеров данных специфицирует согласованность последовательных номеров данных и номеров субпотоков. Это выражается в терминах начальных номеров на уровне субпотока и данных. Это становится особенно важно в случае сегментации сообщений. Эта техника может покрывать большое число пакетов при передаче больших массивов данных.
Согласование заключается в том, что по завершении этого процесса последовательный номер субпотока связан с последовательным номером данных. Отправитель не должен изменять эту привязку, после того, как она была декларирована. Однако, один и тот же номер данных может быть сопряжен с различными субпотоками для осуществления ретрансмиссии (см. раздел 3.3.6). Это может также помочь послать некоторые данные одновременно через несколько субпотоков для целей повышения эффективности или гибкости системы, особенно при работе с каналами с высоким BER.
Порядковый номер данных специфицирован как абсолютная величина, тогда как порядковый номер субпотока является относительным (SYN при запуске субпотока имеет номер субпотока равный 0). Это позволяет промежуточным узлам изменять начальное значение порядкового номера субпотока, таким как firewall'ы, которые осуществляют рэндомизацию ISN.
Установление соответствия порядковых номеров данных включает в себя контрольное суммирование данных, которые покрыты этим соответствием (mapping) если контрольное суммирование согласовано на фазе обмена MP_CAPABLE. Контрольные суммы используются, чтобы детектировать модификацию информации промежуточными узлами, не поддерживающими MPTCP. Если контрольная сумма неверна, запускается процесс ликвидации субпотока, как это описано в разделе 3.6, так как MPTCP не может быть уверен, что принимающая сторона правильно воспримет полученные данные.
Алгоритм вычисления контрольной суммы, используемый в стандартном TCP [1], для области данных, покрытой мэпингом, определяемым псевдозаголовком, как это показано на рис. 10.
Рис. 10. Псевдозаголовок для контрольной суммы DSS
Заметим, что порядковый номер данных, используемый в псевдо-заголовке всегда является 64-битным кодом, вне зависимости от того, какая длина использована в самой опции DSS. Был выбран стандартный алгоритм контрольного суммирования TCP, так как он все равно используется для TCP-субпотоков. Более того, так как контрольная сумма TCP является аддитивной, контрольная сумма для DSN_MAP может быть определена простым добавлением к сумме данных суммы псевдозаголовка.
Заметим, что контрольное суммирование базируется на TCP-субпотоке, содержащем непрерывные данные; следовательно, TCP-субпоток не должен использовать указателя срочной информации (Urgent Pointer) для прерывания существующей номерной привязки. Далее заметим, однако, что, если в субпотоке получена информация помеченная Urgent, она должна быть привязана к пространству номеров данных и доставлена приложению, как это делается в регулярном протоколе TCP.
Чтобы избежать возможных тупиковых сценариев, обработка уровня субпотока должна осуществляться отдельно от процессов уровня соединения. Следовательно, даже если нет согласования между пространствами номеров субпотоков и данных, получение данных следует подтверждать посредством ACK на уровне субпотока (если он находится в пределах окна). Эти данные, однако, не могут подтверждаться на уровне данных, (раздел 3.3.2), так как порядковые номера этих данных неизвестны. Реализации могут держать такие непривязанные по номеру данные в ожидании, что привязка будет вскоре осуществлена. Такие не привязанные по номеру данные не могут считаться находящимися на уровне соединения в пределах входного окна, так как для этого номера данных должны быть известны, таким образом, если у получателя нехватает памяти для хранения таких данных, он их просто отбросит. Если номерная привязка для пространства уровня субпотока не будет осуществлена в пределах входного окна данных, субпоток следует считать прерванным (закрытым посредством RST), и все не привязанные данные отбрасываются.
Как и стандартный порядковый номер TCP, порядковый номер данных не должен начинаться с нуля, а со случайного числа, чтобы затруднить перехват сессии хакером. Эта спецификация требует установки начального значения порядкового номера данных (IDSN) каждого компьютера равным младшим 64 битам хэша SHA-1 ключа компьютера, как описано в разделе 3.1.
Чтобы обеспечить полную гибкость протокол MPTCP осуществляет подтверждения на уровне соединения, как в случае комулятивного ACK для соединения. Это поле "Data ACK" опции DSS (Рис. 9). Data ACK аналогично по поведению со стандартным кумулятивным подтверждением ТСР, указывая на то, сколько данных успешно получено (без пропусков) Подтверждения на уровне субпотоков действуют аналогично TCP SACK, что допускает пробелы в потоке данных на уровне соединения. Data ACK специфицирует следующий порядковый номер данных, который должен быть получен следующим.
Data ACK, как и в случае DSN, может быть послан в виде 64-битного кода, или младших 32 бит. Если данные получены с 64-битным DSN, они должны быть подтверждены посредством 64-битного Data ACK. Если полученный DSN имеет 32 бита, реализация может послать как 32-битное так и 64-битное Data ACK.
Data ACK подтверждает, что данные, и все необходимые сигналы MPTCP, были получены и приняты на удаленном конце соединения. Ключевым использованием сигнала Data ACK, является то, что он служит для индикации левого края анонсированного входного окна. Как объяснено в разделе 3.3.4, входное окно совместно используется всеми субпотоками. По этой причине реализации не должны использовать поле RCV.WND ТСР-сегмента на уровне соединения, если он не несет также опцию DSS с полем Data ACK. Более того, отделение подтверждения уровня соединения от уровня субпотока позволяет раздельно обрабатывать данные и получатель имеет свободу отбрасывать сегменты после подтверждения на уровне субпотока, например, из-за ограничений по объему памяти, когда сегменты приходят неупорядочено.
Отправитель MPTCP не должен удалять данные из выходного буфера до тех пор, пока не подтверждено их получение посредством Data ACK, в любом из субпотоков и на уровне субпотока во всех потоках, которые реализуют передачу данных. Первое условие гарантирует живучесть соединения, а последнее сохранность субпотока, в случае возникновения необходимости повторной передачи данных. Заметим, однако, что если некоторые данные нужно переслать повторно несколько раз, существует риск блокировки окна отправления. В этом случае, отправитель MPTCP может решить прервать плохой субпоток, послав RST.
Data ACK может быть включено во все сегменты; однако, в продвинутых реализациях должна быть предусмотрена оптимизация, где Data ACK присутствует в сегментах, только когда значение Data ACK изменяется, такое поведение должно рассматриваться как корректное. Эта схема гарантирует то, что буфер отправителя опорожняется, и уменьшает избыточность, когда данные передаются в одном направлении.
В регулярном TCP, флаг FIN уведомляет приемник о том, что у отправителя нет больше данных для передачи. Для того чтобы позволить субпотокам функционировать независимо. MPTCP воздействует только на субпоток, который он посылает. Это открывает узлам значительную свободу для всех используемых маршрутов в любое время. Семантика FIN остается той же, что и для регулярного TCP.
Когда приложение вызывает close() для сокета, это указывает, что нет более данных на отправку; для регулярного TCP, это вызовет посылку FIN для данного соединения. Для MPTCP, необходим эквивалентный механизм и это реализуется через DATA_FIN.
DATA_FIN указывает на то, что у отправителя нет больше данных для отправки, и как таковое может использоваться для верификации того, что все данные были успешно доставлены. DATA_FIN, также как FIN в регулярном TCP-соединении, является однонаправленным сигналом.
DATA_FIN сигнализируется путем установки флага 'F' в опции Data Sequence Signal (Рис. 9) равным 1. DATA_FIN занимает 1 октет (последний октет). Заметим, что DATA_FIN включается в длину уровня данных (Data-Level Length), но не на уровне субпотока: например, сегмент с DSN 80, и Data-Level Length =11, с DATA_FIN=1, поставит в соответствие 10 октетов из субпотока в пространство порядковых номеров данных 80-89, DATA_FIN равен DSN 90. Следовательно, этот сегмент, включая DATA_FIN следует подтвердить посредством DATA_ACK = 91.
Заметим, что когда DATA_FIN не присоединено к TCP-сегменту, содержащему данные, сигнал последовательности данных (Data Sequence Signal) должен иметь последовательный номер субпотока, равный 0, a длину уровня данных (Data-Level Length) = 1, и порядковый номер данных, который корреспондируется с самим DATA_FIN. Контрольная сумма в этом случае будет покрывать только псевдозаголовок.
DATA_FIN имеет семантику и поведение, как и у регулярного TCP FIN, но на уровне соединения. В частности, именно DATA_ACK служит для подтверждения успешной доставки всех данных на уровне соединения. Заметим, что DATA_FIN отсоединен от FIN субпотока. Разрешается только комбинировать эти сигналы для субпотоков, еcли только нет каких-то проблем с данными в других субпотоках. В противном случае, может быть необходимо повторно передать данные в субпотоках, где это требуется. Важно то, что компьютер не должен закрывать все работающие субпотоки если только это не приведет к отрицательным последствиям, т.е., до тех пор пока доставка всех данных не будет подтверждена посредством DATA_ACK, или до тех пор пока сегмент с установленным флагом DATA_FIN не станет единственным, который не подтвержден.
Раз получение DATA_FIN подтверждено, все оставшиеся субпотоки должны быть закрыты путем стандартных FIN-обменов. Оба компьютера должны послать FIN для всех субпотоков. Желательно также уменьшить значения таймаутов MSL (Maximum Segment Life) для всех субпотоков. В частности, любые субпотоки, где имеется очередь неподтвержденных сегментов (которые были повторно переданы через другие субпотоки для того, чтобы получить подтвержденный DATA_FIN) могут быть закрыты посредством RST.
Соединение считается закрытым, когда DATA_FIN обоих компьютеров подтверждены DATA_ACK.
Как специфицировано выше, стандартный TCP FIN индивидуального субпотока прерывает только тот субпоток, куда он послан. Если все субпотоки закрыты посредством обмена FIN, но не было получено и подтверждено DATA_FIN MPTCP-соединение будет считаться закрытым после таймаута. Это предполагает, что реализация будет иметь состояния TIME_WAIT, как на уровне субпотоков, так и на уровне соединения (см. приложение C). Это позволяет сценарии типа "break-before-make", где коннективность теряется во всех субпотоках, прежде чем какой-то новый субпоток будет установлен.
Обычный протокол TCP анонсирует входное окно в каждом пакете, сообщая отправителю, сколько данных получатель готов принять после коммулятивного ack. Входное окно используется для управления потоком, тормозя быстрых отправителей, когда получатель за ним не поспевает.
В MPTCP также применяется уникальное входное окно, совместно используемое субпотоками. Идея заключается в том, чтобы позволить любому субпотоку посылать данные столько времени, сколько получатель готов их принимать. Альтернативой является поддержка входных окон субпотоков, когда одни субпотоки могут притормаживать, в то время как другие не используют свои входные окна.
Входное окно связано с DATA_ACK. Как в TCP, получатель не должен сдвигать правый край входного окна (т.е., DATA_ACK + входное окно). Получатель будет использовать порядковый номер данных, чтобы сообщить, должен ли пакет быть принят на уровне соединения.
Принимая решение о приеме пакетов на уровне субпотока, регулярный TCP проверяет, лежит ли порядковый номер пакета в допусках входного окна. В многомаршрутном варианте такая проверка осуществляется с помощью окна лишь на уровне соединения. Проверка корректности должна быть выполнена на уровне субпотока, чтобы убедиться, что субпоток и сопряженный с ним порядковый номер данных соответствуют друг другу: SSN - SUBFLOW_ACK <= DSN - DATA_ACK, где SSN порядковый номер субпотока полученного пакета, а SUBFLOW_ACK равно RCV.NXT (следующий ожидаемый номер сегмента) субпотока (с эквивалентными определениями уровня соединения для DSN и DATA_ACK).
В регулярном TCP, раз сегмент в окне, он либо помещается во входную очередь или в очередь пакетов, пришедших в неправильном порядке. В многомаршрутном TCP, то же самое происходит, но только на уровне соединения: сегмент помещается в то или иную очередь, если он в пределах окна на уровне соединения и на уровне субпотока. Стек должен помнить для каждого субпотока, какие сегменты получены успешно, так что он может подтвердить их на уровне субпотока. Обычно, это реализуется путем формирования для каждого субпотока очередей сегментов, пришедших не по-порядку. Эти очереди содержат только заголовки пакетов без полей данных. Запоминаются значения кумулятивных ACK.
Для разработчиков важно понимать, насколько большой входной буфер приемлем. Нижним пределом для использования во всей сети является максимальное произведение полосы на задержку для любого из маршрутов. Однако, этого может быть недостаточно, когда пакет теряется в более медленном субпотоке и его надо послать повторно (см. раздел 3.3.6). Верхней границей будет максимальное значение RTT (round-trip time) любого маршрута, умноженное на полную полосу всех маршрутов. Это позволяет всем субпотокам работать на максимальной скорости, в то время как быстро повторно передаются сегменты для пути с максимальным RTT. Даже этого может быть недостаточно для поддержания нужных рабочих характеристик в случае таймаута на маршруте с максимальным RTT.
Отправитель запоминает анонсирования входного окна, приходящие от получателя. Он должен обновлять значения входного окна, когда увеличиваются допустимые наибольшие значения порядковых номеров (т.е., DATA_ACK + входное окно), по получении DATA_ACK. Важно позволить использование путей с различными RTT, и таким образом с разными петлями обратной связи.
MPTCP использует одно входное окно для всех субпотоков и, если входное окно гарантировано не меняется, компьютер может всегда читать самое новое значение входного окна. Однако, некоторые классы промежуточных узлов могут менять входное окно TCP-уровня. Обычно они уменьшают предлагаемое окно, хотя для короткого периода времени окно может быть и больше. Следовательно, если размеры входных окон отличаются в разных субпотоках, при посылке данных MPTCP должен выбрать для вычислений самое большое значение входного окна из числа последних.
Отправитель должен также запомнить окна, анонсированные каждым субпотоком. Допустимое значение окна для субпотока i равно (ack_i, ack_i + rcv_wnd_i), где ack_i кумулятивное подтверждение уровня субпотока ACK i. Это гарантирует, что данные не будут посланы в промежуточный узел, пока не будет достаточного места для данных в буфере.
Объединив эти два правила вместе, мы получаем следующее: отправителю позволено посылать сегменты данных с порядковыми номерами уровня данных между (DATA_ACK, DATA_ACK + receive_window). Каждый из этих сегментов будет привязан к субпотоку, при условии, что порядковый номер субпотока находится в пределах допустимого. Заметим, что порядковые номера субпотоков не влияют на управление потока, если одни и те же входные окна анонсированы всем субпотокам. Они осуществляют управление потоков посредством анонсирования меньших значений входных окон.
Буфер отправки должен, как минимум, быть столь же велик, как и входной буфер, чтобы позволить отправителю достичь максимальной пропускной способности.
Установление соответствия порядковых номеров данных отправителями позволяет осуществить повторную передачу данных с идентичными номерами через разные субпотоки. При выполнении этого компьютер должен повторно передавать исходные данные через исходные субпотоки, для того чтобы сохранить целостность субпотока (промежуточные узлы могут повторно передавать старые данные и/или могут запрещать пробелы в субпотоках), а получатель проигнорирует эти повторные передачи.
Эта спецификация протокола не регламентирует каких-либо определенных механизмов повторных передач, и это сильно зависит от локальной политики (как обсуждено в разделе 3.3.8). Кто-то может предполагать агрессивную политику ретрансмиссий на уровне соединения, где каждый потерянный пакет субпотока повторно пересылается через разные субпотоки (следовательно, полоса пропускания расходуется неэффективно, но, возможно, сокращаются задержки доставки приложение-приложение), или консервативную политику ретрансмиссий, где уровень соединения включает ретрансмиссию после нескольких попыток повторной передачи на уровне субпотока (после таймаута).
Предусматривается, что стандартный механизм ретрансмиссий на уровне соединения базируется на очереди данных уровня соединения: все сегменты, которые еще не получили DATA_ACK, запоминаются. Таймер запускается, когда верхний элемент очереди уровня соединение подтвержден на уровне субпотока, но соответствующие данные не подтверждены на уровне данных. Этот таймер будет отслеживать сбои ретрансмиссии из-за промежуточных узлов.
Отправитель должен хранить данные в своем выходном буфере, пока доставка данных не будут подтверждена как на уровне соединения, так на уровне субпотока. Таким путем, отправитель всегда будет повторно послать данные, если это необходимо, через тот же субпоток или через другой. Особая ситуация возникает, когда субпоток не смог обеспечить доставку: отправитель повторно пошлет данные через другой рабочий субпоток после таймаута и будет пытаться повторно передать данные через отказавший субпоток. Отправитель декларирует отказ субпотока после заданного числа попыток повторных передач, или после получения сигнала ошибки от протокола ICMP, и только тогда стирает сегменты из буфера.
Множественные повторные передачи указывают на плохую работу субпотока и компьютер должен перезапустит субпоток посредством RST. Однако, требуется дополнительное исследование, чтобы понять ситуацию с субпотоком. Например, маршрут оказался крайне асимметричным, что не было своевременно диагностировано.
Различные субпотоки в MPTCP-соединении имеют разные окна перегрузки. Чтобы достичь оптимизации использования ресурсов, следует иметь окно перегрузки в каждом субпотоке, для того, чтобы переправить большую часть трафика в незагруженные каналы. Алгоритм решения этой задачи представлен в [5]; алгоритм не гарантирует полной оптимизации использования ресурсов, но он безопасен и может быть реализован через современный Интернет.
Можно предсказать, что для MPTCP будут реализованы разные контроллеры перегрузки с разными эксплуатационными характеристиками.
В пределах локальной реализации MPTCP, компьютер может использовать любую локальную политику, чтобы решать, как распределять трафик по имеющимся маршрутам.
В типовом случае использования, когда главной целью является достижение максимальной пропускной способности, для передачи данных будут использованы все имеющиеся маршруты с привлечением соответствующих механизмов подавления перегрузки, как это описано в [5]. Ожидается, однако, что могут реализоваться и другие варианты.
Например, возможный вариант 'все-или-ничего', т.е., имеем второй маршрут готовый в случае отказа подменить первый, но альтернативы могут включать и вариант, когда второй путь включается, когда возможности первого маршрута полностью исчерпаны. Такие варианты чаще всего определяются стоимостными соображениями, но могут учитываться и другие параметры канала, такие как задержка или разброс задержки в канале, когда стабильность задержки важнее полосы пропускания.
Пока тонкая настройка является наилучшим решением, которое будет требовать некоторого механизма, такого как перезагрузка ECN (Explicit Congestion Notification) [17], которая нежелательна, и ощущается, что не будет достаточно выигрышно, чтобы оправдать эту процедуру. Следовательно, опция MP_JOIN (см. раздел 3.2) содержит бит 'B', который позволяет компьютеру уведомить своего партнера, что этот маршрут следует рассматривать как резервный, используемый только в случае отказа другого работающего субпотока (т.е., субпотока, где получатель индицировал B=1, не должен использоваться, если только нет субпотока, где B=0).
В случае, когда доступное число путей изменяется, компьютер может сигнализировать партнеру об изменении приоритетов субпотоков (напр., субпоток, который был предназначен ранее в качестве резервного, получает высший приоритет по сравнению с остальными субпотоками). Следовательно, опция MP_PRIO, показанная на рис. 11, может быть использована для изменения флага 'B' субпотока.
Рис. 11. Изменение опции приоритета субпотока (MP_PRIO)
Следует заметить, что флаг резервного (backup) потока представляет собой запрос получателя данных отправителю и отправитель должен устанавливать его в своих запросах. Компьютер не может предполагать, что отправитель будет это делать, однако, в силу локальной политики или технических трудностей может переписать MP_PRIO-запросы. Заметим также, что этот сигнал применяется лишь к одному направлению и поэтому отправитель этой опции может продолжить использование субпотока для отправки данных даже в случае посылки им B=1 другому компьютеру.
Эта опция может также быть применена к другим субпотокам помимо того, который ее послал, установив опционное поле идентификатора адреса. Это установление B применимо ко всем субпотокам данного соединения, которое использует адрес, заданный данным идентификатором Address ID. Присутствие этого поля определяется длиной опции; если Длина==4, тогда она присутствует. Если Длина==3, тогда это применимо только для текущего субпотока. Используя такую технику компьютер может сигнализировать своему партнеру, что адрес временно недоступен и партнер должен переключить на резервный маршрут все субпотоки, использующие этот Address ID.
Мы используем термин "управление маршрутом" в отношении обмена информацией между компьютерами о дополнительных маршрутах между ними.
Существует два метода обмена адресной информацией, оба могут использоваться для соединения. Во-первых, прямая конфигурация новых субпотоков, уже описанная в разделе 3.2, где инициатор имеет дополнительный адрес. Второй метод, описанный в последующих субразделах, позволяет компьютеру сигнализировать об адресах явно своему партнеру, чтобы позволить ему сформировать новые субпотоки. Эти два механизма являются взаимно дополняющими: первый является безусловным и простым, в то время как другой - более сложен, но и более надежен. Вместе эти механизмы позволяют свободно обмениваться адресами (и таким образом поддерживать работу даже через NAT, так как не нужно знать адрес отправителя), и позволяет также сигнализировать о неизвестных ранее адресах, и адресах, принадлежащих другим адресным семействам (напр., как IPv4, так и IPv6).
Ниже приведен пример типичной работы протокола:
Возможны другие пути использования двух сигнальных механизмов; например, адреса из других адресных семейств могут использоваться только с помощью опции Add Address.
TCP-опция добавления адреса (ADD_ADDR) анонсирует дополнительные адреса (и опционно порты) через которые компьютер достижим (рис. 12). Могут быть добавлены несколько опций TCP в одно сообщение, если имеется достаточно места в пространстве TCP-опций; в противном случае, посылается несколько TCP-сообщений, содержащих эту опцию. Эта опция может использоваться в рамках соединения любое время в зависимости оттого, когда отправитель захочет активировать несколько маршрутов, и/или когда маршруты являются доступными. Со всеми сигналами MPTCP, получатель должен выполнить стандартные TCP проверки, прежде чем их использовать.
Каждый адрес имеет Address ID, который может использоваться, однозначно идентифицируя адрес соединения для выполнения операции удаления адреса. Он также используется для идентификации опций MP_JOIN (см. раздел 3.2), относящихся к тому же адресу, даже когда используются преобразователи адресов. Идентификатор адреса должен однозначно идентифицировать адрес отправителя (в диапазоне соединения).
Все идентификаторы адреса, полученные через MP_JOIN или ADD_ADDR должны быть запомнены получателем в информационной структуре, в которой собираются все идентификаторы адреса и их соответствие адресам соединения (идентифицированные парой маркеров). Таким путем, запоминается соответствие между Address ID, наблюдаемым адресом отправителя и парой маркеров для будущей обработки контрольной информации соединения. Заметим, что реализация может удалить пришедшее анонсирование адреса, например, для того чтобы избежать мэппинга, или потому что анонсированный адрес не может быть использован (например, IPv6-адреса, когда применимы только IPv4). Следовательно, компьютер должен рассматривать анонсирование адреса вариативным и он может осуществлять обновления периодически.
Эта опция показана на рис. 12. Размеры полей соответствуют адресам IPv4 (IPVer = 4). Для IPv6, поле IPVer будет содержать 6, и длина адреса будет равняться 16 октетам (вместо 4).
Присутствие последних 2 октетов, специфицирующих номер порта TCP, является опционным и может быть определена на основании длины опции. Хотя ожидается, что в большинстве случаев будет использоваться одна и та же пара портов, как это имеет место для исходного субпотока (напр., порт 80 остается портом 80 во всех субпотоках), могут быть случаи (например, балансировка нагрузки, базирующаяся на применении портов), где требуется явная спецификация другого номера порта. Если никакого порта не специфицировано, MPTCP должен попытаться подключиться к специфицированному адресу через порт, который уже используется субпотоком, на который уже был послан сигнал ADD_ADDR; это обсуждено подробнее в разделе 3.8.
Рис. 12. Опция добавления адреса (ADD_ADDR)
Благодаря широкому распространению NAT, разумно считать, что один компьютер может попытаться анонсировать частный адрес [18]. Это нежелательно запрещать, так как могут быть случаи, когда оба компьютера имеют дополнительные интерфейсы для этой частной сети и компьютер может пожелать анонсировать такой адрес. Диалог MP_JOIN для формирования нового субпотока (раздел 3.2) предоставляет механизмы для минимизации рисков безопасности. Сообщение MP_JOIN содержит 32-битный марке, который однозначно идентифицирует соединение с принимающим компьютером. Если маркер неизвестен, компьютер откликнется посылкой RST. В маловероятном случае, когда маркер известен, формирование субпотока продолжится, но должен быть произведен обмен HMAC для аутентификации. Из этого ничего не выйдет, и это обеспечит достаточную защиту против двух неподключенных компьютеров, случайно устанавливающих новый субпоток с использованием частного адреса.
В идеале опции ADD_ADDR и REMOVE_ADDR следует пересылать конечному адресату надежным образом и в правильном порядке. Это будет гарантировать то, что данное управление адресами не обязательно приведет к разрыву соединения, когда операции удаления/добавления адресов выполняются в обратном порядке, а также гарантирует, что все возможные пути используются. Заметим, однако, что утрата надежности в сохранении правильного порядка не приведет к разрыву многомаршрутного соединения, она лишь уменьшит возможность открытия многомаршрутного пути.
Следовательно, введение сигналов надежности для этих опций TCP не является обязательным. Для того, чтобы минимизировать воздействие потери этих опций, однако, рекомендуется, чтобы отправитель посылал эти опции всем доступным субпотокам. Если эти опции нужно получить в правильном порядке, реализации следует только послать одну опцию ADD_ADDR/REMOVE_ADDR для каждого RTT, чтобы минимизировать риск перепутывания доставки.
Компьютер может послать сообщение ADD_ADDR с уже вставленным идентификатором адреса, но адрес должен быть тем же, что был присвоен данному идентификатору адреса, а порт должен быть другим и не совпадающим с уже используемым для данного идентификатора адреса. Если эти условия не выполнены, получатель должен игнорировать ADD_ADDR. Компьютер, желающий заменить существующий идентификатор адреса должен сначала удалить его (раздел 3.4.2).
Компьютер, который получает ADD_ADDR, но обнаруживает конфигурацию соединения, у которого IP-адрес и номер порта неудачны, не должен осуществлять попытки соединения для этой комбинации адреса/порта. Отправитель, который хочет сформировать новое входящее соединение для ранее анонсированной комбинации адреса/порта может, следовательно, обновить информацию ADD_ADDR, послав опцию еще раз.
Во время нормальной работы MPTCP, маловероятно, что будет достаточно места для опций ADD_ADDR, куда будут включены также и порядковые номера данных (раздел 3.3.1). Следовательно, ожидается, что реализация MPTCP пошлет опцию ADD_ADDR с отдельным ACK. Как это обсуждалось ранее, однако, реализация MPTCP не должна рассматривать дублированные ACK вместе с другими MPTCP-опциями, за исключением опции DSS, в качестве индикации перегрузки [12], и реализация MPTCP не должна посылать более двух дублированных ACK подряд для целей управления.
Если, за время жизни MPTCP-соединения, ранее анонсированный адрес перестал быть действующим (напр., если интерфейс исчез), компьютер, сопряженный с ним, должен анонсировать это, чтобы партнер мог удалить субпоток, связанный с этим адресом.
Это выполняется посредством опции удаления адреса (REMOVE_ADDR) (Рис. 13), которая удалит добавленный ранее адрес (или список адресов) из соединения и завершит любые субпотоки, использующие этот адрес.
Для целей безопасности, если компьютер получает опцию REMOVE_ADDR, он должен гарантировать, что эффективный путь более не используется, прежде чем закрывать маршрут. Получение REMOVE_ADDR должно сначала осуществить для данного маршрута посылку TCP keepalive [19], и если отклик получен, проход следует ликвидировать. Должен быть выполнен также обычный тест корректности TCP для субпотока (напр., гарантирующая правильность последовательности и корректность номеров ACK). Реализация может использовать индикацию в случае невыполнения условий этого теста как части детектирования вторжения или процедуры фиксации ошибки.
Отправка и получение (если не получено keepalive-отклика) этого сообщения должно запускать отправку RST обоими компьютерами, работающими с данным субпотоком, удаление адреса предпринимается по идентификатору, чтобы разрешить использование NAT и других промежуточных узлов, которые модифицируют адреса отправителя. Если адреса для запрашиваемого идентификатора нет, получатель игнорирует запрос.
Субпоток, который все еще функционирует, должен быть закрыт посредством FIN-обмена, как и в регулярном TCP, а не посредством этой опции. Дополнительную информацию можно найти в разделе 3.3.3.
Рис. 13. Опция удаления адреса (REMOVE_ADDR)
Регулярный TCP имеет средства для отправки сигнала (RST) для внезапного закрытия соединения. В протоколе MPTCP, область действия RST ограничивается одним субпотоком и закроет только определенный субпоток, но не повлияет на остальные субпотоки. MPTCP-соединение останется живым на информационном уровне, для того, чтобы позволить взаимодействие между субпотоками. Следовательно необходимо обеспечить уровень MPTCP сигналом "сброс", чтобы разрешить внезапное закрытие всего MPTCP-соединения, и таким сигналом является опция MP_FASTCLOSE.
MP_FASTCLOSE используется для уведомления партнера о том, что соединение будет внезапно закрыто и не будет более принято никаких данных. Причины для запуска MP_FASTCLOSE определяются конкретной реализацией. Регулярный TCP не позволяет посылать RST, когда соединение находится в синхронизованном состоянии [1]. Несмотря на это реализации позволено посылать RST в этом состоянии, если, например, у операционной системы закончились ресурсы. В этих случаях, MPTCP должен послать MP_FASTCLOSE. Эта опция показана на рис. 14.
Рис. 14. Опция быстрого закрытия (MP_FASTCLOSE)
Если компьютер A хочет закрыть MPTCP-соединение, процедура быстрого закрытия в протоколе MPTCP осуществляется следующим образом:
Иногда, промежуточные узлы располагаются на пути, что может помешать работе MPTCP. MPTCP должен быть устроен так, чтобы справляться с модификациями конфигурации промежуточных узлов (см. раздел 6), но все же существуют случаи, когда субпотоки не могут реализовать нормальную работу MPTCP. Это следующие случаи: потеря TCP опции на маршруте и модификация поля данных. Если такой случай реализуется, необходимо осуществить возврат ("fall back") к предыдущему рабочему варианту. Это может быть возврат к регулярному TCP или удаление проблемного субпотока.
При формировании MPTCP-соединения (т.е., первый субпоток), важно гарантировать, что проход полностью соответствует требованиям протокола MPTCP и нужные опции TCP могут достичь любого компьютера. Диалог, как это описано в разделе 3.1 должен возвращать систему к регулярному TCP, если либо SYN-сообщение не имеет MPTCP-опций, либо компьютер не может работать с MPTCP, или маршрут не поддерживает MPTCP-опции. Когда предпринимается попытка подключения к существующему MPTCP-соединению (раздел 3.2), если маршрут не может работать с MPTCP а TCP-опции не могут пройти через SYN, субпоток будет закрыт согласно логике MP_JOIN.
Существует, однако, другой крайний случай, который следует рассмотреть. Имеется одна из опций MPTCP, передаваемая посредством SYN, а не регулярными пакетами. Проблема может быть решена, если субпоток является первым субпотоком, и таким образом все данные являются смежными, с использованием следующих правил.
Отправитель должен включить опцию DSS в каждый из посылаемых сегментов, пока один из посланных сегментов не будет подтвержден посредством DSS-опции, содержащей Data ACK. После получения подтверждения отправитель имеет подтверждение, что опция DSS проходит в обоих направлениях и может выбрать вариант с посылкой меньшего числа DSS-опций, чем по штуке на сегмент.
Если, однако, получен ACK для данных без опции DSS, содержащий Data ACK, отправитель определяет путь как MPTCP-непригодный. В случае, когда это происходит с дополнительным субпотоком (т.е., который стартовал с MP_JOIN), компьютер должен закрыть субпоток посредством RST. В случае первого субпотока (т.е., который стартовал с MP_CAPABLE), система должна вернуться к регулярному TCP. Отправитель пошлет финальную информационную последовательность со значением Data-Level Length равным 0, и затем вернуться к посылке данных через один субпоток без каких-либо опций MPTCP.
Заметим, что это правило по существу запрещает посылку данных третьим пакетом диалога MP_CAPABLE или MP_JOIN, так как обе эти опции и DSS не могут уложиться в пространство опций TCP. Если инициатор послал первый сегмент, следующий сегмент будет содержать данные и DSS. Заметим также, что дополнительный субпоток не может использоваться до тех пор, пока исходный проход не признан приемлемым для MPTCP. Эти правила должны покрывать все случаи, где могут произойти такие отказы: для прямого и обратного маршрутов, вне зависимости от того клиент или сервер послал данные первым. Если потеря опций пакетов данных происходит в любом другом субпотоке, вне исходного субпотока, это событие должно рассматриваться как стандартный отказ маршрута. Данные не будут подтверждены DATA_ACK, и субпоток может быть закрыт посредством RST.
Случай, описанный выше, является вариантом fallback, это вариант с отсутствием поддержки MPTCP, он детектируется до подтверждения каких-либо данных на уровне соединения субпотока. В более общем случае, fallback может оказаться необходим в любой точке в процессе соединения, если промежуточный узел модифицирует поток данных.
Как описано в разделе 3.3, каждая порция данных, для которой имеется привязка, защищается контрольной суммой. Используется специальный механизм для детектирования модификации поля данных промежуточным узлом (добавление, удаление, или модификация данных). Проверка контрольной суммы не пройдет, если данные были модифицированы. Это может быть детектировано, если длина поля данных в субпотоке увеличилась или уменьшилась, и это означает, что мэпинг данных более не корректен. Отправитель уже не знает, какой порядковый номер уровня субпотока получателя корректен, и он не может сигнализировать о дальнейшем соответствии номеров. Следовательно, всем данным от начала сегмента при ошибке контрольной суммы доверять нельзя.
Когда используется несколько субпотоков, данные субпотока не образуют непрерывный массив, так как сегменты разбросаны по нескольким субпотокам. Из-за проблем, отмеченных выше, невозможно определить, какие изменения внесены в данные (особенно, любые изменения последовательных номеров данных в субпотоке). Следовательно, невозможно восстановить субпоток, и вовлеченные субпотоки должны быть немедленно закрыты посредством RST (рис. 15). Заметим, что опция MP_FAIL требует использования полного 64-битного порядкового номера, даже если используются 32-битовые порядковые номера в сигналах DSS канала.
Рис. 15. Опция откат (MP_FAIL)
Получатель должен отбросить все данные, следующие за специфицированным порядковым номером данных. Отброшенные данные не должны быть DATA_ACK и будут повторно переданы по другим субпотокам (раздел 3.3.6).
Специальный случай реализуется, когда имеется всего один субпоток и в нем регистрируется ошибка контрольной суммы. Если известно, что все неподтвержденные данные являются непрерывными, может быть использован бесконечный мэпинг субпотока без необходимости его закрытия и, что существенно, без блокировки последующего MPTCP управления. В этом случае получатель, зарегистрировавший ошибку контрольной суммы, пошлет назад опцию MP_FAIL на уровне ACK субпотока, указывая на порядковый номер данных начала сегмента, где была зафиксирована ошибка контрольной суммы. Отправитель получит это, и если все подтвержденные данные являются непрерывными объявит бесконечный мэпинг. Этот бесконечный мэпинг означает посылку опции DSS в очередном пакете (раздел 3.3), содержащем номер данных, указывающий на начало сегмента, для которого зарегистрирована ошибка контрольной суммы.
В редких случаях, когда данные не являются непрерывными (что может случиться, когда имеется один субпоток, но там повторно передаются данные субпотока, который был недавно не вполне корректно закрыт) получатель должен закрыть субпоток посредством RST с MP_FAIL. Получатель должен выбросить все данные, которые следуют за специфицированным порядковым номером. Отправитель может попытаться создать новый субпоток, принадлежащий тому же соединению, и, если выбран такой вариант, должен перевести субпоток в одномаршрутный режим путем введения бесконечного мэпинга. Этот мэпинг будет начинаться с порядкового номера уровня данных, декларированного в MP_FAIL.
После того как отправитель сигнализирует о бесконечном мэпинге, он должен использовать только ACK субпотока, чтобы очистить буфер отправки. Это делается из-за того, что Data ACK могут оказаться перепутаны с ACK субпотока, где промежуточный узел вносит или удаляет данные. Получатель должен остановить генерацию Data ACK после получения бесконечного мэпинга.
Когда соединение разрушено, только один субпоток может посылать данные; иначе, получатель не будет знать, как переупорядочены данные. На практике это означает, что все MPTCP-субпотоки кроме одного будут закрыты. Раз MPTCP вернулся к регулярному TCP, он не должен возвращаться позднее к MPTCP в рамках имеющегося соединения.
Следует подчеркнуть, что мы не пытаемся препятствовать использованию промежуточных узлов (middleboxes) которые могут модифицировать поле данных. Адаптированные к MPTCP промежуточные узлы могут обеспечить требуемую функциональность путем переписывания контрольных сумм.
В дополнение к механизму отката, описанному выше, стандартные классы TCP-ошибок могут нуждаться в обработке в специфическом для MPTCP стиле. Заметим, что изменение семантики -- такое как обоснованность RST -- рассмотрено в разделе 4.
Следующий список покрывает возможные ошибки и соответствующее поведение MPTCP:
Существует много эвристики, которая необходима для работы или применению, но которая не нужна для обеспечения нормальной работы протокола. Заметим, что обсуждение буферизации и поведения входных окон отправителя и получателя представлено в разделах 3.3.4 и 3.3.5, а ретрансмиссия в разделе 3.3.6.
При обычной операции, реализация MPTCP должна использовать номер порта, который уже используется. Другими словами, порт назначения SYN, содержащий опцию MP_JOIN должен быть тем же что и удаленный порт первого субпотока в соединении. Локальный порт для такого SYN должен быть тем же, что и для первого субпотока (реализация должна резервировать порты для всех локальных IP-адресов). Эта стратегия ориентирована на то, чтобы иметь максимум вероятности, что SYN будут разрешены firewall'ами или NAT на стороне получателя и это не приведет к проблемам работы программ сетевого мониторинга.
Могут быть случаи, однако, где пассивная открывающая сторона пожелает сигнализировать другому компьютеру, что должен использоваться специфический порт, и эта возможность реализуется посредством опции Add Address, как это документировано в разделе 3.4.1. Следовательно, вполне реально позволить существование нескольких субпотоков между двумя адресами, но при разных номерах портов, и эта возможность может быть использована, чтобы позволить балансировку нагрузки в сети, базирующейся на 5-элементах (напр., некоторые ECMP-реализации [7]).
Многие TCP-соединения являются короткоживущими и состоят из очень малого числа сегментов и избыточность использования MPTCP перевешивает любые выгоды. Эвристика необходима, следовательно, чтобы решить, когда начать использовать дополнительные субпотоки в MPTCP-соединении. Нужны результаты экспериментальных исследований, для того чтобы верифицировать корректность этого предложения.
Если компьютер имеет буферизованные данные для своего партнера (который предполагает, что приложение получило запрос данных), компьютер открывает один субпоток для каждого исходного окна в зависимости от объема буферизованных данных.
Заметим, что эта эвристика не является эффективной. Трафик для многих общих приложений, таких как загрузки программ, являются крайне асимметричными и компьютер, который является многодомным, может быть клиентом, который никогда не заполнит свои буферы, и следовательно никогда не будет использовать протокол MPTCP. Продвинутые API, которые разрешают приложению сигнализировать о своих требованиях по трафику, могут помочь решить эту проблему.
Может использоваться дополнительная эвристика, открывающая дополнительные субпотоки по прошествии заданного времени.
Требования для обработки неожиданных сигналов для MPTCP представлены в разделе 3.7. Существуют другие случаи отказов, однако, где компьютеры могут выбрать соответствующее поведение.
Например, раздел 3.1 рекомендует, чтобы компьютер возвращался в режим регулярных TCP SYN после одного или более отказов MPTCP SYN для соединения. Компьютер может иметь общесистемный кэш, где хранится такая информация, так что он может уходить от использования MPTCP, сначала для данного конкретного компьютера-адресата, и в конечном счете для всего интерфейса, если MPTCP-соединения продолжают терпеть неудачу.
Другой отказ может случится, когда диалог MP_JOIN терпит неудачу. В разделе 3.7 специфицировано, что некорректный диалог должен приводить к закрытия субпотока посредством RST. Компьютер, работающий в качестве активной системы детектирования вторжений, может решить запустить блокировку пакетов MP_JOIN, поступающих от отправителя, если наблюдается множественные неудачные попытки MP_JOIN. С точки зрения инициатора соединения, если MP_JOIN терпит неудачу, он не должен пытаться соединиться с тем же IP-адресом и портом за время жизни соединения, если только другой компьютер не обновил информацию с другой опцией ADD_ADDR. Заметим, что опция ADD_ADDR является лишь информационной, и не гарантирует того, что другой компьютер попытается установить соединение.
В дополнение, реализация может исследовать некоторое число соединений и узнать, что некоторые интерфейсы или адреса места назначения постоянно отказывают и могут по умолчанию не пытаться использовать MPTCP для них. Может быть также изучено поведение определенных плохо себя ведущих субпотоков или субпотоков, который регулярно обрываются в процессе использования, для того чтобы не использовать (временно) эти маршруты.
Для того, чтобы поддерживать многомаршрутные операции, семантика некоторых компонент TCP изменилась.
Порядковый номер: Порядковый номер (в заголовке) TCP является специфическим для субпотока. Чтобы позволить получателю упорядочить данные приложения, используется дополнительное пространство порядковых номеров уровня данных. В этом пространстве номеров исходный SYN и конечный DATA_FIN занимают 1 октет пространства. Существует соответствие порядковых номеров пространства данных и пространства номеров субпотоков, которое управляется с помощью TCP-опций в информационных пакетах.
ACK: Поле ACK в TCP-заголовке подтверждает получение только порядкового номера субпотока, не из пространства номеров уровня данных. Реализации не должны пытаться делать предположения о подтверждениях уровня данных из подтверждений субпотока. Это разделяет обработку конечным компьютером на уровнях субпотоков и соединения.
Дублированный ACK: Дублированный ACK, который включает любые сигналы MPTCP (за исключением опции DSS) не должны интерпретироваться, как сигнал перегрузки. Чтобы ограничить шансы некорректной интерпретации дублированных ACK (принятие их за сигналы перегрузки), MPTCP не должен посылать более двух дублированных ACK подряд, содержащих (non-DSS) сигналы MPTCP.
Входное окно: Входное окно в заголовке TCP указывает объем свободного буферного пространства для всего уровня данных соединения, которое доступно для получателя. Это понятие имеет ту же семантику, что и в регулярном TCP, но в рамках этой семантики входное окно должно интерпретироваться отправителем как относительное по отношению к порядковому номеру, заданному DATA_ACK, а не ACK заголовка ТСР субпотока. Таким образом, исходный контроль потока сохраняется. Заметим, что некоторые промежуточные узлы могут изменить входное окно и тогда компьютер должен использовать максимальное значение, выявленное для входного окна субпотоков уровня соединения.
FIN: Флаг FIN в заголовке TCP относится только к субпотоку, в котором он послан, а не ко всему соединению. Для семантики уровня соединения FIN используется опция DATA_FIN.
RST: Флаг RST в заголовке TCP относится только к субпотоку, в котором он послан, а не ко всему соединению. Опция MP_FASTCLOSE обеспечивает большее быстродействие при выполнении закрытия MPTCP-соединения посредством RST.
Список адресов: Управление списком адресов (т.е., знание списка IP-адресов, доступных на локальном и удаленном компьютерах) обрабатывается независимо для каждого соединения. Это позволяет приложению реализовать политику индивидуально для каждого соединения. Добавление адреса к соединению (явно, с помощью сообщения Add Address, или неявно - посредством Join) не влияет на другие соединения данной пары компьютеров.
5-кортеж: 5-звенный кортеж (протокол, локальный адрес, локальный порт, удаленный адрес, удаленный порт) передаваемый API ядра прикладному уровню в не-многомаршрутном приложении воспринимается также как в первом субпотоке, даже если субпоток был закрыт и удален из соединения. Эти аспекты подробно освещены в [6].
Как описано в [9], добавление многомаршрутности в TCP приносит много новых классов угроз. Для того, чтобы предотвратить их, [2] предлагает набор требований для программных решений MPTCP. Фундаментальной целью безопасности MPTCP является стремление быть "не хуже" регулярного сегодняшнего TCP, и ключевыми требованиями являются:
Для того, чтобы достичь этих целей, MPTCP включает в себя алгоритм диалога, базирующийся на хэшах, описанный в разделах 3.1 и 3.2.
Безопасность MPTCP-соединения держится на использовании ключей, которые получаются при формировании первого субпотока и никогда более не пересылаются по сети снова (если только не реализуется механизм быстрого закрытия, раздел 3.5). Чтобы облегчить демультиплексирование и в то же не раскрывать криптографический материал, будущие субпотоки укорачивают криптографический хэш и представляют его в виде идентификационного "маркера" соединения. Ключи объединяются и используются как ключи для создания HMAC (Hash-based Message Authentication Codes), применяемого при формировании субпотока, для того, чтобы верифицировать партнеров в процессе диалога. Это также обеспечивает верификацию того, что партнеры могут получать данные по этому новому адресу. Атаки воспроизведения будут все же возможны, когда используются только ключи; следовательно, диалоги с использованием одноразовых случайных чисел (nonces) на обоих концах -- гарантирует, что HMAC никогда не будет тем же самым в двух диалогах. Руководство по генерации случайных чисел, пригодных для использования в качестве ключей представлено в [14] и обсуждено в разделе 3.1.
Использование битов криптовозможностей в исходном диалоге формирования соединения позволяет выбрать определенный алгоритм и применить какие-то дополнительные возможности в будущем. Заметим, что эта схема восприимчива к атакам bid-down (понижения цены), только если атакер находится на действующем маршруте (и таким образом, способен модифицировать каким-то образом данные). Механизм обеспечения безопасности, представленный в данном документе, должен обеспечить защиту против всех форм атак перегрузки и перехвата обсуждается [9].
Во время обычной работы механизма защиты регулярного TCP (такого как гарантирование того, что порядковые номера находятся в пределах входного окна) будет обеспечен тот же уровень защиты против атак индивидуального субпотока TCP, что существует у обычного протокола TCP. Реализации создадут дополнительные буферы по сравнению с регулярным TCP, чтобы восстановить данные на уровне соединения. Выбор окна приложения будет минимизировать риск DoS-атак, съедающих ресурсы.
Как это обсуждалось в разделе 3.4.1, компьютер может анонсировать свои частные адреса, но они могут указывать на разные компьютеры в сети получателя. Диалог MP_JOIN (раздел 3.2) будет гарантировать, что не будет сформирован субпоток с некорректным компьютером. Однако, это может все же создавать нежелательный TCP-трафик диалога. Эта особенность MPTCP может стать мишенью для DoS-атак, с вредоносными участниками в MPTCP соединениях.
Небольшой риск безопасности может быть связан с повторным использованием ключей, но для того, чтобы реализовать атаку воспроизведения, ключи отправителя и получателя и случайные числа отправителя и получателя в диалоге MP_JOIN должны быть взаимно согласованы (раздел 3.2).
Пока данная спецификация определяет "среду" безопасности, отвечающую критериям, специфицированным в этом разделе, и анализ угроз ([9]). Так как атаки всегда становятся только хуже, похоже, что будущая версия стандарта MPTCP потребует поддержки более сильной безопасности. Существует несколько путей, посредством которых безопасность MPTCP может быть улучшена; некоторые из них будут совместимы с MPTCP, как это описано в данном документе, в то время как другие могут быть не совместимы.
Возможные пути улучшения безопасности MPTCP могут включать:
В протоколе MPTCP предусмотрены методы для создания новых механизмов безопасности, включая:
Многомаршрутный TCP был создан для существующей сетевой среды. Он был сконструирован с учетом поведения существующих промежуточных узлов (middlebox). В этом разделе, мы рассматриваем некоторые виды сценариев отказов, сопряженные с такими устройствами, и то, как многомаршрутный TCP их преодолевает. Далее, мы перечисляем конструктивные решения, которые приспосабливают данный протокол для работы с промежуточными узами.
Главным вопросом является использование новых TCP-опций. Промежуточные узлы должны переадресовывать пакеты с неизвестными опциями без модификации. Мы ожидаем, что они либо удаляют опции и передают данные, выбрасывают пакеты с новыми опциями, копируют опции в несколько сегментов (напр., когда осуществляют сегментацию), или отбрасывают опции при сборке сегментов.
MPTCP использует одну новую TCP-опцию сорт (Kind), и все типы сообщений определяются как значения субтипов (см. раздел 8). Это должно сократить шансы передачи только некоторых типов опций, а ключевыми характеристиками являются разные маршруты и присутствие флага SYN.
Пакеты MPTCP SYN в первом субпотоке соединения содержат опцию MP_CAPABLE (раздел 3.1). Если она потеряна, MPTCP должен перейти к регулярному TCP. Если потеряны пакеты с опцией MP_JOIN (раздел 3.2), маршруты просто не будут использоваться.
Если промежуточный узел удаляет опции, а в остальном передает пакета без изменений, MPTCP будет работать безопасно. Если опция MP_CAPABLE удаляется на исходящем или обратном пути, компьютер-инициатор может вернуться к регулярному ТСР, как это показано на рис. 16 и обсуждено в разделе 3.1.
SYN субпотока содержит опцию MP_JOIN. Если эта опция удалена в исходящем потоке, SYN будет выглядеть для компьютера B, как регулярный SYN. В зависимости от того имеется ли слушающий сокет в порту получателя, компьютер B откликнется либо SYN/ACK, либо RST (субпоток соединения ликвидируется). Когда компьютер A получает SYN/ACK, он посылает RST, так как SYN/ACK не содержит опцию MP_JOIN и ее маркер. В любом случае, процедура формирования субпотока отменяется, но без последствий для MPTCP-соединения в целом.
Рис. 16. Установление соединения с промежуточным узлом, который удаляет опции из пакетов
Мы теперь рассматриваем поток данных с MPTCP, предполагая, что поток сформирован корректно, что предполагает разрешение опций в SYN-пакетах промежуточными узлами. Если опции разрешены, то работа MP TCP может осуществляться без проблем.
Случай, когда опции удаляются из информационных пакетов, обсужден в разделе "Откат". Если часть опций удалена, поведение системы непредсказуема. Если некоторые фрагменты мэпинга последовательности данных утрачены, соединение может функционировать, если имеется мэпинг для данных субпотока. Если некоторое пространство номеров уровня субпотока не имеет привязки, субпоток считается неисправным и закрывается, этот процесс, описан в разделе 3.6. MPTCP должен выживать с потерей некоторых Data ACK, но рабочие характеристики будут деградировать, так как доля удаленных фракций увеличится. Мы не ожидаем, что такие случаи произойдут на практике, хотя большинство промежуточных узлов будут либо удалять все опции, либо разрешат их свободный проход.
Мы завершаем этот раздел списком классов промежуточных узлов, их поведения, и элементов системы MPTCP, которые допускают работу через промежуточные узлы:
Кроме того, все классы промежуточных узлов (middleboxes) могут влиять на TCP-трафик следующими путями:
В данном документе определена новая TCP-опция для MPTCP, эта опция имеет код 30 (десятичный) из пространства опций TCP. Это значение поля Сорт (Kind). Его величина определена как:
Таблица 1: Значения TCP-опций Сорт (Kind)
| Сорт | Длина | Значение | Ссылка |
| 30 | N | Multipath TCP (MPTCP) | RFC 6824 |
Этот документ определяет 4-бита поля субтипа, для которого IANA создала и намерена поддерживать субрегистр с названием "MPTCP Option Subtypes" (Субтипы опций МРТСР) в регистре "Transmission Control Protocol (TCP) Parameters". Исходные значения для субтипов опции MPTCP представлены ниже; будущие назначения должны определяться стандартными действиями (Standards Action), как это определено в [25]. Определения состоят из символического имени субтипа MPTCP и соответствующего значения, как в таблице ниже.
Таблица 2: Опции субтипов MPTCP
| Значение | Символ | Имя | Ссылка |
| 0x0 | MP_CAPABLE | Многомаршрутность возможна | раздел 3.1 |
| 0x1 | MP_JOIN | Подключение к соединению | раздел 3.2 |
| 0x2 | DSS | Data Sequence Signal (Data ACK и мэпинг порядка данных) | Раздел 3.3 |
| 0x3 | ADD_ADDR | Добавление адреса | раздел 3.4.1 |
| 0x4 | REMOVE_ADDR | Удаление адреса | Раздел 3.4.2 |
| 0x5 | MP_PRIO | Изменение приоритета субпотока | раздел 3.3.8 |
| 0x6 | MP_FAIL | Откат | раздел 3.6 |
| 0x7 | MP_FASTCLOSE | Быстрое закрытие | раздел 3.5 |
Значения с 0x8 по 0xe в настоящее время не используются. Значение 0xf зарезервировано для частного использования в пределах контролируемых исследовательских систем.
IANA создала другой субрегистр, "MPTCP Handshake Algorithms" в регистре "Transmission Control Protocol (TCP) Parameters", базирующемся на флагах из MP_CAPABLE (раздел 3.1). Флаги состоят из 8 бит, помеченные от "A" до "H", и в данном документе им присвоены следующие значения:
| Бит флага | Значение | Ссылка |
| A | Контрольная сумма необходима | RFC 6824, раздел 3.1 |
| B | Расширение | RFC 6824, раздел. 3.1 |
| С-G | Не определены | - |
| H | HMAC-SHA1 | RFC 6824, раздел 3.2 |
Таблица Алгоритмы диалога MPTCP
Заметим, что значения битов с C до H могут зависеть от бита B, и определяется тем, какая расширяемость определена в будущей спецификации; см. раздел 3.1.
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] Ford, A., Raiciu, C., Handley, M., Barre, S., и J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] National Institute of Science и Technology, "Secure Hash Standard", Federal Information Processing Standard
(FIPS) 180-3, October 2008, <http://csrc.nist.gov/publications/
fips/fips180-3/fips180-3_final.pdf>.
[5] Raiciu, C., Handley, M., и D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.
[6] Scharf, M. и A. Ford, "MPTCP Application Interface Considerations", Work in Progress, October 2012.
[7] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[8] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., и M. Handley, "How Hard Can It
Be? Designing и Implementing a Deployable Multipath TCP", Usenix Symposium on Networked Systems Design and
Implementation 012, 2012, <https://www.usenix.org/conference/
nsdi12/how-hard-can-it-be-designing-and-implementing-
deployable-multipath-tcp>.
[9] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[10] Krawczyk, H., Bellare, M., и R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[11] Mathis, M., Mahdavi, J., Floyd, S., и A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[12] Allman, M., Paxson, V., и E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[13] Gont, F., "Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations", Work in Progress, March 2012.
[14] Eastlake, D., Schiller, J., и S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[15] Eastlake, D. и T. Hansen, "US Secure Hash Algorithms (SHA и SHA-based HMAC и HKDF)", RFC 6234, May 2011.
[16] Jacobson, V., Braden, B., и D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[17] Ramakrishnan, K., Floyd, S., и D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[18] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., и E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[19] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[20] Ramaiah, A., "TCP option space extension", Work in Progress,
March 2012.
[21] Srisuresh, P. и K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[22] Border, J., Kojo, M., Griner, J., Montenegro, G., и Z.Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[23] Handley, M., Paxson, V., и C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, и End-to-End
Protocol Semantics", Usenix Security 2001, 2001,
<http://www.usenix.org/events/sec01/full_papers/
handley/handley.pdf>.
[24] Freed, N., "Behavior of и Requirements for Internet Firewalls", RFC 2979, October 2000.
[25] Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Рис. in RFCs", BCP 26, RFC 5226, May 2008.
1. Multipath TCP for FreeBSD Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology. Nigel Williams
2. Design Overview of Multipath TCP version 0.3 for FreeBSD-10. Nigel Williams, Lawrence Stewart, Grenville Armitage
3. MPTCP and Product Support Overview. Jay Young and Daniel Wing, Cisco TAC Engineers
4. A 50 Gbps Connection With Multipath TCP
5. Multi-Path TCP Page
Пространство опций TCP ограничено из-за длины поля Data Offset в заголовке TCP (4 бита), которое определяет длину TCP-заголовка, измеряемого в 32-битовых словах. При стандартном TCP-заголовке в 20 байт, это оставляет максимум 40 байт для опций.
Пакеты SYN обычно включают в себя MSS (Maximum Segment Size) (4 байта), масштаб окна (3 байта), разрешенный SACK (2 байта), и временную метку (10 байт). Некоторые операционные системы дополняют каждую опцию до границы слова, таким образом используя 24 байт (Windows XP и Mac OS X это делают, в то время как Linux - нет). В лучшем случае у нас имеется 21 свободный байт, или 16 если производится выравнивание на границы слов. В любом случае, однако, SYN-версии Multipath Capable (12 байт) и опции Join (12 или 16 байт) поместятся в оставшемся пространстве.
Информационные пакеты TCP обычно несут в себе опции временной метки в каждом пакете, занимая 10 байт (или 12 с заполнителем). Это оставляет 30 байт (или 28, если производится выравнивание по границам слов). Опция Data Sequence Signal (DSS) имеет переменную длину, в зависимости от того, включен или нет мэпинг данных и DATA_ACK, и используются ли последовательные номера длиной 4 или 8 октетов. Максимальный размер опции DSS равен 28 байт, так что пространства хватит даже этой опции. Но если соединение не является двунаправленным и широкополосным, вряд ли все пространство будет использовано каждой DSS-опцией.
В пределах DSS-опции не обязательно включать мэпинг данных и DATA_ACK в каждый пакет. Возможны также варианты 4- и 8-байтовых последовательных номеров в каждой опции.
При формировании субпотока и соединения, опция MPTCP устанавливается в третьем пакете (ACK). Они имеют 20 байт (для Multipath Capable) и 24 байта (для Join), обе из которых умещаются в свободном пространстве опций.
ACK в TCP обычно содержит только временную метку (10 байт). Протоколу MP TCP нужно закодировать только DATA_ACK (максимум 12 байт). Иногда, ACK будет содержать информацию SACK. В зависимости от числа потерянных пакетов, SACK может использовать все пространство опций. Если DATA_ACK должна быть включена, тогда вероятно необходимо уменьшить число блоков SACK, чтобы приспособиться к DATA_ACK. Однако, присутствие DATA_ACK вряд ли необходимо в случае, где используется SACK, так как некоторые блоки SACK должны пересылаться повторно, кумулятивные ACK уровня данных не будут перемещаться вперед.
Опция ADD_ADDR может занимать от 8 до 22 байт, в зависимости от того используется ли IPv4 или IPv6, и присутствует ли номер порта. Маловероятно, чтобы такие сигналы подходили для информационных пакетов (хотя, если имеется место, будет хорошо это сделать). Рекомендуется использовать дублирующие ACK без другого поля данных или опций, для того чтобы передать эти редкие сигналы. Заметим, что это является причиной требования, чтобы дублирующий ACK с MPTCP-опциями не будет воспринимался, как сигнал перегрузки.
Наконец, существуют проблемы с надежной доставкой опций. Так опции могут также быть посланы просто с ACK, они посланы ненадежно. Не существует проблемы для DATA_ACK из-за их кумулятивной природы, но может быть проблема для опций ADD_ADDR/REMOVE_ADDR. Здесь рекомендуется посылать эти опции с некоторой избыточностью, (при множественных маршрутах или одиночном пути посылать несколько ACK -- но раздельно по отношению к данным, для того чтобы избежать интерпретации как сигнал перегрузки). Случаи, где опции удаляются промежуточными узлами, обсуждены разделе 6.
Концептуально, MPTCP-соединение может быть представлено, как блок управления MPTCP, который содержит несколько переменных, которые отслеживают процесс, состояние MPTCP-соединения и набор подключенных блоков управления, которые соответствуют сформированным субпотокам.
RFC 793 [1] специфицирует несколько переменных состояния. Всякий раз, когда возможно, мы вновь используем ту же самую терминологию, что и RFC 793, для описания переменных состояния, которые поддерживаются MPTCP.
Блок управления MPTCP содержит следующие переменные, характеризующие соединение.
Local.Token (32 бита): Это маркер выбранный локальным компьютером для данного MPTCP-соединения. Маркер должен быть уникальным для всех установленных MPTCP-соединений, сформированным на основе локального ключа.
Local.Key (64 бита): Это ключ, посланный локальным компьютером для MPTCP-соединения.
Remote.Token (32 бита): Это маркер, выбранный удаленным компьютером для данного MPTCP-соединения, вычисленный на основе удаленного ключа.
Remote.Key (64 бита): Это ключ, выбранный удаленным компьютером для данного MPTCP-соединения.
MPTCP.Checksum (флаг): Этот флаг устанавливается в состояние "истинно", если по крайней мере один компьютер имеет установленный бит C в опциях MP_CAPABLE, пересланных в процессе установления соединения, и принимает значение "ложно", в противном случае. Если этот флаг установлен, контрольная сумма должна быть вычислена для всех опций DSS.
SND.UNA (64 бита): Это порядковый номер следующего байта данных, который должен быть подтвержден, на уровне соединения MPTCP. Эта переменная обновляется при получении опции DSS, содержащей DATA_ACK.
SND.NXT (64 бита): Это порядковый номер следующего байта данных, который должен быть послан. SND.NXT используется для определения значения DSN в опции DSS.
SND.WND (32 бита для RFC 1323, 16 бит в противном случае): Это окно посылки. MPTCP поддерживает окно посылки на уровне соединения MPTCP, одно и то же окно используется всеми субпотоками. Все субпотоки используют MPTCP уровень соединения SND.WND, чтобы вычислить значение SEQ.WND, которое посылается в передаваемом сегменте.
RCV.NXT (64 бита): это порядковый номер данных следующего байта, который ожидается в соединении MPTCP. Эта переменная состояния модифицируется при получении последовательности данных. Значение RCV.NXT используется для спецификации DATA_ACK, которое посылается в опции DSS всех субпотоков.
RCV.WND (32 бита с RFC 1323, 16 бит в противном случае): Это входное окно уровня соединения, которое является максимумом RCV.WND всех субпотоков.
Блок управления MPTCP содержит также список блоков управления TCP, которые ассоциируются с MPTCP-соединением.
Заметим, что блок управления TCP субпотоков TCP не содержит переменных состояния RCV.WND и SND.WND, так как они поддерживаются на уровне MPTCP-соединение, а не на уровне субпотоков.
В каждом управляющем блоке TCP определены следующие переменные состояния.
SND.UNA (32 бита): Это последовательный номер следующего байта, который должен быть подтвержден в субпотоке. Эта переменная обновляется при получении каждого TCP-подтверждения в субпотоке.
SND.NXT (32 бита): Это порядковый номер следующего байта, который нужно послать в субпотоке. SND.NXT используется, чтобы задать значение SEG.SEQ при передаче следующего сегмента.
RCV.NXT (32 бита): Это порядковый номер следующего байта, который должен быть доставлен субпотоком. Эта переменная состояния модифицируется при получении следующих по порядку сегментов. Значение RCV.NXT копируется в поле SEG.ACK следующего передаваемого сегмента субпотока.
RCV.WND (32 бита для RFC 1323, 16 бит в противном случае): Это приемное окно уровня субпотока, которое обновляется полем окна с помощью сегментов, полученных в субпотоке.
Диаграмма на рис. 17 показывает машину конечных состояний для закрытия соединения. Это иллюстрирует, как сигнал DATA_FIN (обозначаемый как флаг DFIN в DATA_ACK) взаимодействует с FIN уровня субпотока, и позволяет "break-before-make" передачу между субпотоками.
Рис. 17: Машина конечных состояний для закрытия соединения
|
Previous: 4.4.3.5 Протокол TFRC
UP:
4.4.3 Протокол TCP |