sysops.it

Outsourcing IT pozwoli ci prowadzić biznes taniej

info@sysops.it
+48 666 930 111

Nowości z bloga

TCP Fast Open

Opis modyfikacji stosu TCP, która może przyspieszyć prędkość ładowania popularnych stron od 4% do 41%.

Wyszukiwarki i Sphinx

Słowo wstępu o Sphinksie - silniku wspierającym wyszukiwanie pełnotekstowe.

Kwestia IPv6 NAT w Linuksie

IPv6 NAT w Linuksie - walka ideologii z rzeczywistością.

TCP Fast Open

TCP Fast Open

Większa cześć ruchu internetowego w dzisiejszych czasach składa się krótkich połączeń TCP składających z kilku cykli tam-i-z-powrotem. Przykładem takiej wymiany danych jest transfer stron internetowych za pomocą protokołu HTTP, który korzysta z TCP jako warstwy transportowej.

Prędkość strumienia TCP zależna jest od dwóch czynników:

  • opóźnienie transmisji (szerokość strumienia danych),
  • opóźnienie propagacji (czas potrzebny na przebycie danych z jednego końca połączenia na drugi).

Opóźnienie transmisji zależne jest głównie od przepustowości połączeń sieciowych, które w są sukcesywnie zwiększane wraz z rozwojem internetu. Z drugiej strony, czas propagacji jest składową opoźnień wprowadzanych przez routery sieciowe oraz prędkości światła. Z natury rzeczy, czas propagacji jest więc czynnikiem, na który rozwój techniki ma relatywnie mniejszy wplyw niż na przepustowość. Z biegiem czasu opóźnienie propagacji stało sie więc dominujące w całkowitych opóźnieniach występujących podczas transmisji danych w internecie.

Z propozycją optymalizacji tego procesu poprzez zmniejszenie ilości cykli tam-i-z-powrotem wyszli pracownicy Google i zaproponowali implementację mechanizmu TCP Fast Open (TFO). Z przeprowadzonych przez ww. pracowników badań wynika, że zastosowanie tego mechanizmu może przyspieszyć prędkość ładowania popularnych stron od 4% do 41%.

TCP three-way handshake

Żeby zrozumieć istotę zaproponowanej optymalizacji warto przypomnieć sobie jak działa obecny system nawiązywania połączeń TCP zwany three-way handshake. Proces three-way handshake jest inicjowany gdy klient wysyła żądanie połączenia do serwera. W warstwie aplikacji jest to jednoznaczne z wykonaniem wywołania systemowego connect ().

3WHS

Rys. 1. Proces TCP Three-way handshake między klientem a serwerem

Podczas procesu three-way handshake oba końce połączenia TCP wymieniają pakiety SYN (synchronize) zawierąjace parametry połączenia, np. parametr MSS (maximum segment size), tj. maksymalna ilość bajtów, którą odbiorca może zaakceptować w pojedyńczym segmencie danych czy np. parametr ISN (initial sequence numbers) czyli numery sekwencji wykorzystywane podczas samego połączenia.

Proces three-way handshake posiada jeszcze jedna ważną zaletę, a mianowicie pozwala na wykrycie ewentualnych duplikatów pakietów SYN (co może być wynikiem awarii jak również celowego nadużycia) tworząc w efekcie tylko jedno połączenie TCP.

Problem z obecną implementacją TCP jest taki, ze dane (z punktu widzenia aplikacji) mogą być wymienione między węzłami połączenia dopiero po zakończeniu samego procesu three-way handshake. Innymi słowy, dane mogą zostać przesłane od klienta do serwera dopiero w trzecim kroku procesu three-way handshake. W wyniku tego jeden pełny cykl tam-i-z-powrotem jest “zmarnowany” zanim jeszcze właściwe dane zaczną “płynąć” między węzłami. Ten “zmarnowany” jeden cykl stanowi znaczący udział w całkowitych opóźnieniach występujących w przypadku krótkich połączeń HTTP.

Aplikacje takie jak przeglądarki internetowe stosują różne metody aby zminimalizować opisany narzut na proces three-way handshake. Istnieje np. metoda ponownego wykorzystywania istniejących połączeń TCP przez klienta do przesłania kolejnych requestów HTTP lecz często w przypadku webserverów czas życia “wiszących” sesji jest świadomie skracany ze względu na oszczędność zasobów (w Apache 2.0 domyślnie jest to 15 sekund, natomiast w Apache 2.2 jest to 5 sekund).

Eliminowanie cyklu tam-i-z-powrotem

Czysto teoretycznie, inicjujący połączenie pakiet SYN może zawierać dane (RFC 793), tj. specyfikacja protokołu TCP dopuszcza taką możliwość. Jednak stos TCP odbiorcy zabrania dostarczania danych do aplikacji dopóki proces three-way handshake zostanie zakończony. To jest niezbędny środek bezpieczeństwa by zapobiegać przed różnego rodzaju atakami sieciowymi.

Celem wykorzystania technologii TCP Fast Open (TFO) jest wyeliminowanie marnowanych cykli tam-i-z-powrotem poprzez dopuszczenie transmisji danych w ramach pakietów inicjujących SYN. Zeby jednak można było na to zezwolić z punktu widzenia bezpieczeństwa wymagany jest dodatkowy spoób na identyfikacje klienta jako członka transmisji. Tym dodatkowym elementem są tzw. security cookies (TFO cookies). Security cookie jest generowany jednorazowo po stronie serwera i przesyłany do klienta na potrzeby dalszej transmisji. Znaczniki cookies składają się z adresu IP klienta zaszyfrowanego w sposób znany serwerowi ale trudny do odgadnięcia przez potencjalnego napastnika. Samo żądanie, generowanie i transmisja znacznika cookie jest całkowicie przezroczysta dla warstwy aplikacyjnej.

TFO1

Rys. 2. Generowanie znacznika TFO cookie

W warstwie połączenia TCP, klient wysyła żądanie znacznika cookie w ramach pakietu SYN do serwera. Serwer generuje znacznik cookie i odsyła go w powrotnym pakiecie SYN-ACK. Klient przechowuje otrzymany znacznik na potrzeby przyszłej komunikacji z tym serwerem.

Rzeczywisty przykład komunikacji, tj. żądanie znacznika cookie:

14:31:07.395223 IP 79.96.255.243.59176 > 173.194.70.139.80: Flags [S], seq 618884843, win 14600, options [mss 1460,sackOK,TS val 3998201212 ecr 0,nop,wscale 7,experimental: Fast Open Cookie Request], length 0 14:31:07.425721 IP 173.194.70.139.80 > 79.96.255.243.59176: Flags [S.], seq 1292446930, ack 618884844, win 42540, options [mss 1430,sackOK,TS val 764642046 ecr 3998201212,nop,wscale 6,experimental: Fast Open Cookie 8314afcfd514803f], length 0

Na tym etapie klient posiada token w postaci znacznika cookie, który może być dowodem podczas przyszłej komunikacji, że proces three-way handshake z tym serwerem został wcześniej zakończony z sukcesem.

TFO2

Rys. 3. Wykorzystanie znacznika TFO cookie w komunikacji

Posiadając cookie klient może wykorzystać uproszczony model komunikacji TCP:

  1. Klient wysyła pakiet SYN zawierający TFO security cookie (jako opcja TCP) oraz dane aplikacji.
  2. Serwer dokonuje walidacji przesłanego znacznika cookie poprzez powtórzenie procesu szyfrowania adresu IP nadawcy. Jeżeli cookie jest poprawny to dowodzi, że pakiet SYN pochodzi od “prawdziwego” nadawcy pakietu (np. eliminując próbę spoofowania). Oznacza to, że serwer może przekazać dane z pakietu SYN od razu do aplikacji.
  3. Od tego miejsca, wymiana pakietów TCP przebiega standardowo, tj. serwer odsyła pakiet SYN-ACK, ktory jest następnie zatwierdzany przez klienta (ACK) co kończy proces three-way handshake. Serwer może od razu przesłać dane, zanim jeszcze otrzyma potwierdzenie od klienta ACK.

W powyższych krokach, jeżeli weryfikacja znacznika cookie się nie powiedzie, serwer odrzuca dane zawarte w pakiecie SYN przesłanym od klienta i odpowiada jedynie SYN-ACK - zgodnie ze standardowym procesem three-way handshake. Innymi słowy, transmisja zostaje kontynuowana w “normalnym” trybie TCP. Jeżeli klient jest jednak autentyczny, wykona retransmisje danych przesłanych wcześniej w pakiecie SYN (transparentnie dla aplikacji).

W efekcie opisanej modyfikacji sposobu komunikacji TCP “oszczędzony” został jeden cykl tam-i-z-powrotem dla pakietów wymienianych miedzy klientem a serwerem.

Przykłady rzeczywistej komunikacji

Standardowy three-way handshake w przypadku wywolania HTTP:

15:02:02.389496 IP 79.96.255.243.51626 > 173.194.70.100.80: Flags [S], seq 196354777, win 14600, options [mss 1460,sackOK,TS val 3998664960 ecr 0,nop,wscale 7], length 0 15:02:02.420066 IP 173.194.70.100.80 > 79.96.255.243.51626: Flags [S.], seq 486968049, ack 196354778, win 42540, options [mss 1430,sackOK,TS val 201581714 ecr 3998664960,nop,wscale 6], length 0 15:02:02.420145 IP 79.96.255.243.51626 > 173.194.70.100.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 3998664968 ecr 201581714], length 0 15:02:02.420234 IP 79.96.255.243.51626 > 173.194.70.100.80: Flags [P.], seq 1:34, ack 1, win 115, options [nop,nop,TS val 3998664968 ecr 201581714], length 33 GET / HTTP/1.1 Host: google.com 15:02:02.450490 IP 173.194.70.100.80 > 79.96.255.243.51626: Flags [.], ack 34, win 665, options [nop,nop,TS val 201581744 ecr 3998664968], length 0 15:02:02.488242 IP 173.194.70.100.80 > 79.96.255.243.51626: Flags [P.], seq 1:570, ack 34, win 665, options [nop,nop,TS val 201581782 ecr 3998664968], length 569 HTTP/1.1 301 Moved Permanently Location: http://www.google.com/ [...]

W przypadku standardowego three-way handshake dane aplikacji w postaci requestu HTTP GET wysłane zostały dopiero w czwartym pakiecie do serwera. Trzy wcześniejsze pakiety stanowią sam proces three-way handshake.

TCP Fast Open w przypadku gdy klient posiada już znacznik TFO cookie, otrzymany wcześniej od serwera:

14:34:17.083194 IP 79.96.255.243.59562 > 173.194.70.139.80: Flags [S], seq 2836262420:2836262453, win 14600, options [mss 1460,sackOK,TS val 3998248634 ecr 0,nop,wscale 7,experimental: Fast Open Cookie 8314afcfd514803f], length 33 GET / HTTP/1.1 Host: google.com 14:34:17.113793 IP 173.194.70.139.80 > 79.96.255.243.59562: Flags [S.], seq 2554322938, ack 2836262454, win 42540, options [mss 1430,sackOK,TS val 187010501 ecr 3998248634,nop,wscale 6], length 0 14:34:17.113872 IP 79.96.255.243.59562 > 173.194.70.139.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 3998248641 ecr 187010501], length 0 14:34:17.150880 IP 173.194.70.139.80 > 79.96.255.243.59562: Flags [P.], seq 1:570, ack 34, win 665, options [nop,nop,TS val 187010538 ecr 3998248634], length 569 HTTP/1.1 301 Moved Permanently Location: http://www.google.com/

Request HTTP GET został wysłany od razu w pierwszym pakiecie SYN. W czwartym pakiecie klient otrzymał już odpowiedź od aplikacji serwerowej. Dla przypomnienia, w przypadku standardowego three-way handshake w czwartym pakiecie wysłany został dopiero sam request HTTP.

TCP FO
Dodano dn. 12 listopada 2013 roku przez rob.