Po 40 latach intensywnego wykorzystania protokół TCP wciąż ma się dobrze. Rośnie jednak grono tych, którzy chętnie zafundowaliby mu facelifting. Jedną z najciekawszych propozycji jest rozszerzenie protokołu o możliwość przesyłania danych jednocześnie wieloma potokami, wykorzystującymi różne ścieżki sieciowe. Taki zabieg umożliwia lepsze wykorzystanie dostępnej infrastruktury i podniesienie niezawodności transmisji danych. Wielopotokowy protokół TCP może zmniejszyć złożoność sieci, które m.in. właśnie z powodu niezmienności TCP, stały się bardzo skomplikowane. Ma też szanse uprościć zarządzanie i zmniejszyć koszty utrzymania infrastruktury sieciowej. Interesująco zapowiadają się interfejsy API, dzięki którym aplikacje będą mogły automatycznie optymalizować swoje działanie na podstawie informacji uzyskiwanych z warstwy sieciowej. Specyfikacja Multipath TCP jest już w stadium zaawansowanym. Ma kilka niezależnych implementacji, a nawet wielkoskalowe wdrożenia komercyjne.

Od kilku lat pod egidą IETF trwają prace nad Multipath TCP (MPTCP), czyli wielopotokową wersją protokołu TCP. Koncepcja jest już bardzo dojrzała. Dokument RFC 6824 nie został wprawdzie jeszcze zgłoszony do formalnego rozpatrzenia, ale istniejące drafty standardu są już w obiegu prawie dwa lata i w tym czasie zostały uzupełnione i wzbogacane o dokumenty szczegółowe. Równolegle technologia Multipath TCP doczekała się kilku implementacji open source i komercyjnych, a także zaskakująco dużych wdrożeń produkcyjnych. Ratyfikacja standardu jest już tylko kwestią czasu. Jakie będą konsekwencje upowszechnienia się Multipath TCP?

Wiele ścieżek: i co z tego?

Cele przyświecające twórcom MPTCP to lepsze wykorzystanie dostępnego pasma oraz zapewnienie niezawodności komunikacji w sieciach o słabych parametrach, w szczególności bezprzewodowych. Multipath TCP jest także próbą ułatwienia nawiązywania połączeń i zapewnienia im bezpieczeństwa transmisji w sieciach, w których pomiędzy komunikującymi się stronami występuje wiele urządzeń pośredniczących. Urządzenia te, takie jak zapory sieciowe, bramy NAT, serwery proxy, bramy VPN itp., mogą ingerować w strukturę i zawartość nagłówków pakietów, a także w przesyłane w nich dane, utrudniając nawiązanie sesji lub jej utrzymanie.

Multipath TCP ma potencjał, by uprościć zarządzanie operacyjne w sieciach, które często doświadczają przeciążeń. Zapobieganie i automatyczne rozładowywanie spiętrzeń ruchu zostało potraktowane jako jedno z kluczowych założeń funkcjonalnych wielopotokowego TCP. Nowy protokół TCP zapobiega przeciążeniu pojedynczych połączeń przez automatyczne uruchamianie dodatkowych potoków, przebiegających alternatywnymi ścieżkami. Przewiduje także automatyczne zmiany priorytetów poszczególnych ścieżek w reakcji na zmieniające się warunki transmisji.

Pośrednio, Multipath TCP zapobiega spowolnieniom transmisji w ramach pojedynczej ścieżki. Nie dopuszcza bowiem do jej nasycenia i wzrostu poziomu strat pakietów, skutkującego automatycznym ograniczeniem przepływności. Wydaje się, że Multipath TCP może z biegiem czasu wyeliminować z sieci dedykowane loadbalancery i routery z protokołem BGP – przynajmniej w pewnych scenariuszach. Dziś może to być nieoczywiste. Gdy jednak Multipath TCP zacznie być obsługiwany na większości platform sieciowych, zakup dodatkowych, czy też droższych urządzeń będzie trudny do usprawiedliwienia.

Jak działa Multipath TCP

Transmisja wielopotokowa rozpoczyna się identycznie jak w przypadku zwykłego połączenia TCP – aplikacja żąda od warstwy sieciowej otwarcia określonego portu, by nawiązać połączenie z określonym adresem IP. W rezultacie, między nadawcą i odbiorcą następuje tradycyjne, trzystopniowe nawiązanie sesji w postaci przesłania pakietów SYN, SYN/ACK i ACK. Gdy połączenie dojdzie do skutku, nadawca lub odbiorca mogą sygnalizować drugiej stronie chęć ustanowienia kolejnych potoków w ramach tej samej sesji. Nowe potoki mogą być tworzone i zamykane w dowolnym momencie.

„Transmisja wielopotokowa rozpoczyna się identycznie jak w przypadku zwykłego połączenia TCP. Gdy połączenie dojdzie do skutku, nadawca lub odbiorca mogą sygnalizować drugiej stronie chęć ustanowienia kolejnych potoków w ramach tej samej sesji. Nowe potoki mogą być tworzone i zamykane w dowolnym momencie”

Aby sesja miała status wielopotokowy, musi zostać zainicjowana jako taka. Pakiety inicjujące sesję Multipath TCP (SYN, SYN/ACK i ACK) muszą zawierać flagę MP_CAPABLE w polu nagłówka przeznaczonym na flagi opcjonalne. Brak flagi MP_CAPABLE w którymkolwiek z pakietów służących do nawiązania sesji symbolizuje brak możliwości lub intencji komunikowania się wielopotokowo i nawiązanie połączenia w trybie jednopotokowym. Aby dodać kolejny potok do już istniejącej sesji, odbywa się kolejny TCP handshake w postaci kolejnej trzystopniowej sekwencji SYN, SYN/ACK i ACK. Tym razem w polu opcjonalnym nagłówków pakietów wpisywany jest ciąg MP_JOIN.

Strony mogą informować się o udostępnieniu na potrzeby wzajemnej komunikacji dodatkowych adresów IP. W tym celu wykonują TCP handshake z flagą ADD_ADDR. Analogicznie informują się o usunięciu adresu z puli adresów dostępnych dla potoków w ramach danego połączenia (flaga REMOVE_ADDR). Przekazywanie drugiej stronie adresów w ten sposób jest sprytnym obejściem problemu z nawiązaniem połączenia wynikającego z translacji adresów sieciowych (NAT) lub restrykcyjnie skonfigurowanej usługi proxy, usuwającej wszelkie informacje o faktycznym adresie źródłowym pakietu.

Sesje i potoki w szczegółach

W trakcie inicjacji sesji Multipath TCP każda ze stron generuje unikalny 64-bitowy klucz oraz 32-bitowy skrót jednokierunkowy (hasz) tego klucza. Strony przesyłają sobie klucze i sygnalizują jakiego algorytmu należy użyć do wyliczenia 32-bitowych skrótów. Jeśli sesja zostanie pomyślnie nawiązana, skróty te będą jednoznacznie identyfikować sesję dla każdej ze stron. Metody generowania kluczy i tworzenia ich skrótów twórcy specyfikacji Multipath TCP pozostawiają w gestii twórców sterowników. Istniejące implementacje stosują SHA-1, zakłada się, że z biegiem czasu komunikujące się strony będą mogły wybierać algorytmy generowania kluczy i skrótów kluczy w zależności od aktualnie dostępnej mocy i/lub obciążenia.

W trakcie tworzenia nowego potoku powiązanego z istniejącym połączeniem/sesją strona inicjująca nowy potok wysyła do drugiej strony pakiet SYN zawierający wpis MP_JOIN w polu opcji, do tego skrót z klucza sesyjnego odbiorcy (co służy jako uwierzytelnienie) oraz wygenerowany ad hoc 32-bitowy ciąg losowy. W odpowiedzi, odbiorca również generuje 32-bitowy ciąg losowy i łączy (konkatenuje) oba ciągi w jeden, stawiając swój ciąg na początku. Następnie wylicza na jego podstawie 160-bitowy skrót jednokierunkowy, wykorzystując jako klucz konkatenację klucza własnego i klucza strony-inicjatora nowego potoku (w tej kolejności). Wyliczony skrót jest następnie skracany do 64 bitów i wysyłany w pakiecie SYN/ACK do strony-inicjatora nowego potoku, wraz z własnym ciągiem losowym.

Otrzymawszy ciąg losowy odbiorcy, inicjator nowego potoku również dokonuje konkatenacji ciągu własnego i drugiej strony, stawiając własny na początku. Na podstawie tej konkatenacji wylicza własny 160-bitowy skrót kryptograficzny, „obcina” go, pozostawiając jedynie pierwsze 64 bity, i tak oto uzyskuje własny, uwierzytelniony u drugiej strony identyfikator nowego potoku. Wysyła go drugiej stronie w pakiecie ACK, oczekując pustego pakietu z flagą ACK. Gdy ta procedura się dokona, nowy potok może funkcjonować. W każdym czasie strony mogą sygnalizować sobie, czy potok ma być traktowany jako główny, czy też zapasowy. Aby jednoznacznie zadeklarować potok jako zapasowy, bit B w sekcji flag nagłówka powinien zawierać wartość 1.

W przypadku, gdy wszystkie dane zostały przesłane, aplikacja nadawcy może zamknąć połączenie wysyłając odbiorcy pakiet z flagą DATA_FIN. Jeśli uzyska potwierdzenie z tą samą flagą, każdy indywidualny potok zostaje zamknięty poprzez wysłanie i potwierdzenie pakietu z flagą FIN, jak w normalnym połączeniu TCP. Zamknięcie transmisji na poziomie pojedynczego potoku nie oznacza zamknięcia sesji. Wielostopniowe kończenie sesji jest kluczowe dla zachowania niezawodności połączenia. Pozwala także zasygnalizować urządzeniom pośredniczącym w transmisji poszczególnych potoków, że mogą wyczyścić swoje bufory pakietów skojarzone z tymi potokami.

Jeśli z jakichś powodów, np. przeciążenia, jedna ze stron zdecyduje się na nagłe zamknięcie połączenia, musi wysłać w jednym z potoków pakiet ACK z flagą MP_FASTCLOSE, a w pozostałych z flagą RST. Połączenie zostanie zamknięte, jeśli nadawca otrzyma pakiet ACK z flagą RST w potoku, w którym wysłał pakiet z flagą MP_FASTCLOSE.

Zarządzanie transmisją

W Multipath TCP dane są serializowane w ramach całych sesji, a nie poszczególnych potoków. Sprawdzenie poprawności i spójności transmisji następuje jednak zarówno na poziomie potoków, jak i sesji. Ponieważ opóźnienia na poszczególnych ścieżkach są zwykle różne, sterowniki zgodne z Multipath TCP utrzymują nieco większe bufory pamięci na dane otrzymane, niż w przypadku tradycyjnego TCP. Wynika to z założenia, że odbiorca komunikujący się wielopotokowo może zgłaszać nadawcy większe okno transmisji, czyli liczbę bajtów, jaką jest gotowy przyjąć. Większy bufor jest użyteczny na potrzeby „składania” danych napływających z różnymi opóźnieniami. Pomaga też w identyfikacji i usuwaniu duplikatów, jeśli w wyniku opóźnień dane zostaną wysłane ponownie.

„W Multipath TCP dane są serializowane w ramach całych sesji, a nie poszczególnych potoków. Sprawdzenie poprawności i spójności transmisji następuje jednak zarówno na poziomie potoków, jak i sesji”

W domyślnej konfiguracji Multipath TCP aplikacje nadawcy i odbiorcy nie są „świadome”, że dane są przesyłane między nimi w wielu potokach po wielu odrębnych ścieżkach. Sterowniki implementujące Multipath TCP przedstawiają się aplikacjom tak samo, jak sterowniki dotychczasowe. Zmiany dotyczą warstwy sieciowej, przeźroczystej dla aplikacji. Niezależnie od tego, projektanci przewidzieli możliwość programistycznego konfigurowania komunikacji wielopotokowej z poziomu aplikacji, za pomocą dedykowanych interfejsów API.

Uczynienie aplikacji „świadomymi” istnienia wielopotokowości może być korzystne na wiele sposobów. Aplikacje mogą tworzyć nowe potoki i zmieniać ich priorytety na podstawie zmieniających się warunków sieciowych. Mogą tworzyć klasy potoków i przypisywać do nich sesje aplikacyjne, a nawet przełączać sesje użytkowników między potokami, jeśli transmisja daną ścieżką nie spełnia określonych parametrów jakościowych (np. w scenariuszu replikacji danych do zdalnego ośrodka z wykorzystaniem iSCSI). W ustalonych sytuacjach mogą kierować określony ruch do potoków, na ścieżce których znajdują się systemy zabezpieczeń, by podnieść bezpieczeństwo transmisji. To tylko przykłady. Możliwości jest znacznie więcej.

Problemy możliwe do ominięcia

Projektanci Multipath TCP przewidzieli i zaadresowali w propozycji specyfikacji standardu potencjalne wyzwania dla jego szerszej adopcji. Wyrazem tego jest m.in.: całkowita „przeźroczystość” faktu transmisji wielopotokowej dla istniejących aplikacji, nawiązywanie połączeń wielopotokowych tylko jako opcji, uaktywnianej wyłącznie gdy obie komunikujące się strony jawnie na to zezwalają, automatyczny powrót do „zwykłego” TCP w razie wystąpienia problemów z nawiązaniem sesji wielopotokowej, wykorzystanie opcjonalnych pól nagłówków pakietów do sygnalizacji, czy też ograniczenie zastosowania wielopotokowości do hostów w sieciach obsługujących multihoming. Wszystko to czyni z Multipath TCP propozycję realistyczną, mającą rzeczywiste szanse na wdrożenia.

„Projektanci Multipath TCP przewidzieli i zaadresowali w propozycji specyfikacji standardu potencjalne wyzwania dla jego szerszej adopcji. Wyrazem tego jest m.in.: całkowita „przeźroczystość” faktu transmisji wielopotokowej dla istniejących aplikacji, nawiązywanie połączeń wielopotokowych tylko jako opcji, a także automatyczny powrót do „zwykłego” TCP w razie wystąpienia problemów”

Problemy na pewno będą, jednak głównie tam, gdzie przepływ pakietów znany ze standardowego protokołu TCP został poddany istotnym modyfikacjom. Dotyczy to np. akceleratorów sieciowych stosujących techniki wyprzedzającego potwierdzania otrzymania pakietów w celu zwiększenia wydajności. Problemy stwarzać będą filtry pakietów i serwery proxy blokujące pakiety z flagami opcji lub automatycznie modyfikujące wszelkie opcje wg własnego uznania. Kłopotem dla wdrożenia może okazać się normalizator ruchu, który przerwę w sekwencji bajtów zinterpretuje jako potrzebę retransmisji, nie wiedząc, że „brakujące” bajty zostały wysłane innym potokiem, po innej ścieżce.

Skanery ruchu nie rozpoznające ruchu Multipath TCP jako takiego mogą z kolei fałszywie sygnalizować próby włamania do sieci, a konkretnie: próby rozproszonego przesyłania treści potencjalnie groźnej dla sieci lub aplikacji. Gdy jednak kolejne wersje skanerów będą w stanie identyfikować potoki i „składać” je w jedną sesję na podstawie identyfikujących je skrótów sesyjnych zawartych w nagłówkach pakietów, ten problem powinien zniknąć. Oprócz tego, zapory sieciowe mogą nie dopuszczać wielu połączeń z tego samego adresu. To jednak da się łatwo obejść, jeśli komunikujące się strony posiadają wiele adresów IP i wykorzystają opcję ADD_ADDR.

Materiały źródłowe

W niniejszym artykule technologia Multipath TCP została omówiona na pewnym poziomie ogólności, aby nie męcząc Czytelników detalami ponad miarę, przedstawić koncepcję i założenia leżące u jej podstaw. Więcej szczegółów można znaleźć w drafcie specyfikacji (RFC 6824) oraz powiązanych z nim dokumentach szczegółowych firmowanych przez IETF. Dwa z nich zasługują na szczególną uwagę. RFC 6181 omawia Multipath TCP w kontekście potencjalnych wektorów zagrożeń dla bezpieczeństwa sieci, z kolei draft informacyjny MPTCP Application Interface Considerations szeroko dyskutuje kierunki myślenia o sterowaniu parametrami Multipath TCP za pomocą interfejsów programistycznych. Odsyłamy też Czytelników do prac naukowych poświęconych Multipath TCP, w szczególności zaś do pracy How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP. Zachęcamy Czytelników do dzielenia się opiniami i diagnozami oraz komentarzami na temat Multipath TCP.

1. RFC 6824 – TCP Extensions for Multipath Operation with Multiple Addresses
http://tools.ietf.org/html/rfc6824

2. RFC 6181 – Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
http://tools.ietf.org/html/rfc6181

3. IETF Information draft – MPTCP Application Interface Considerations
http://tools.ietf.org/html/draft-ietf-mptcp-api-07

4. Praca naukowa – How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP
https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

5. Prezentacja autorów pracy naukowej How Hard… na 9 sympozjum Usenix poświęconemu projektowaniu i wdrażaniu systemów sieciowych, która odbyła się w San Jose w Kalifornii w dniach 25-27 kwietnia 2012 r.
https://www.usenix.org/sites/default/files/conference/protected-files/mptcp-nsdi.pdf

Ważniejsze implementacje Multipath TCP

• Apple iOS 7 wykorzystuje wielopotokową wersją TCP do utrzymania niezawodnej komunikacji swoich smartfonów z serwerami usługi Siri. Jeśli zasięg sieci komórkowej zaniknie, sesja jest podtrzymywana przez lokalną sieć Wi-Fi – i odwrotnie.

• Oprogramowanie NetScaler firmy Citrix, optymalizujące dostęp do usług i aplikacji, umożliwia pracownikom zdalnym wygodną i niezawodną pracę z aplikacjami centralnymi. Podobnie jak w wypadku Apple, sieć Wi-Fi i sieć komórkowa są traktowane przez klienta NetScaler jako dwie ścieżki dostępne dla tego samego połączenia.

• Pracownicy naukowi Uniwersytetu Katolickiego w Louvain (Belgia) rozwijają otwartą implementację Multipath TCP w formie modułu jądra systemu Linux oferują stabilne rozwiązanie wraz z usługami wsparcia technicznego. Więcej informacji: http://mptcp.info.ucl.ac.be