badania TCP
Argument zwiększenia początkowego okresu przeciążenia TCP
Przepływy TCP zaczynają się od początkowego okna przeciążenia wynoszącego maksymalnie 4 segmenty lub około 4 KB danych. Większość transakcji internetowych jest krótkoterminowa, więc początkowe okno zatorów ma kluczowe znaczenie przy określaniu szybkości zakończenia przepływów. Chociaż w ciągu ostatniej dekady szybkość dostępu do sieci na całym świecie gwałtownie wzrosła, standardowa wartość początkowego okresu przeciążenia TCP nie zmieniła się. W tym dokumencie proponujemy zwiększenie początkowego okna przeciążenia TCP do co najmniej 10 segmentów (około 15 KB). Dzięki eksperymentom internetowym na dużą skalę mierzymy korzyści związane z opóźnieniem i koszty wynikające z korzystania z większego okna za pomocą funkcji przepustowości sieci, czasu błądzenia (RTT), opóźnienia przepustowości (BDP) i charakteru aplikacji. Wykazujemy, że średni czas oczekiwania odpowiedzi HTTP zmniejszył się o około 10%, a największe korzyści te odpowiadają sieciom o dużym RTT i BDP. W naszych eksperymentach opóźnienie sieci o małej przepustowości znacznie się zmniejszyło. Średnia szybkość ponownego przesyłania wzrosła o niewielkie 0,5%, przy czym większość wzrostu pochodzi z aplikacji skutecznie obchodzących algorytm powolnego uruchamiania TCP przez korzystanie z wielu równoczesnych połączeń. Na podstawie wyników naszych eksperymentów sądzimy, że początkowy okres zatoru powinien obejmować co najmniej 10 segmentów. Ten sam okres powinien zostać zbadany przez IETF pod kątem standaryzacji.
Szybkie otwieranie TCP
Obecnie usługi internetowe są zdominowane przez przepływy TCP tak krótkie, że po uzgadnianiu połączenia przerywają one kilka połączeń w obie strony. Taki uzgadnianie połączenia jest istotnym źródłem opóźnień w przypadku takich przepływów. W tym dokumencie opisujemy konstrukcję, implementację i wdrożenie protokołu TCP Fast Open Protocol, nowego mechanizmu umożliwiającego wymianę danych podczas wstępnego uzgadniania połączenia TCP. W ten sposób funkcja TCP Fast Open zmniejsza opóźnienie sieci aplikacji o jeden pełny czas błądzenia w obie strony, zmniejszając opóźnienie występujące w przypadku takich krótkich transferów TCP. Rozwiązujemy problemy związane z bezpieczeństwem związane z zezwalaniem na wymianę danych podczas uzgadniania połączenia trójkierunkowego. Eliminujemy wtedy problemy z bezpieczeństwem, które eliminują problemy przy użyciu tokena zabezpieczeń, który weryfikuje własność adresu IP. Omawiamy też inne zastępcze mechanizmy obrony i rozwiązujemy problemy związane z modułami pośredniczącymi, zgodnością wsteczną z istniejącymi stosami sieciowymi oraz wdrażaniem przyrostowym. Na podstawie analizy ruchu i emulacji sieci wykazujemy, że szybkie otwarcie TCP przyspieszy transakcję HTTP skróci czas oczekiwania w sieci transakcji HTTP o 15%, a czas wczytywania całej strony średnio o ponad 10%, a w niektórych przypadkach nawet o 40%.
Proporcjonalna redukcja liczby żądań TCP
Utracone pakiety zwiększają czas oczekiwania dla użytkowników internetu. Szybkie odzyskiwanie to kluczowy mechanizm odzyskiwania pakietów przez protokół TCP. W tym dokumencie analizujemy niektóre słabe strony algorytmu standardowego opisanego w dokumencie RFC 3517 oraz niestandardowe algorytmy zaimplementowane w systemie Linux. Odkryliśmy, że te algorytmy odbiegają od zamierzonego działania w świecie rzeczywistym z powodu łączonego efektu krótkich przepływów, straganów z aplikacjami, utraty powtórek, utraty potwierdzenia (ACK) i zmiany kolejności oraz rozciągania potwierdzeń. Linux zmaga się z nadmiernym skróceniem okna przeciążenia, podczas gdy standard RFC 3517 przesyła duże impulsy w przypadku dużych strat. Oba te problemy szkodzą reszty procesu i zwiększają opóźnienie połączenia internetowego. Głównym wkładem jest nowy projekt kontroli transmisji w szybkim procesie przywracania zwany proporcjonalnym redukcją tempa (PRR). PRR szybko, sprawnie i precyzyjnie naprawia straty, optymalizując tempo ponownego przesyłania w przypadku otrzymanych potwierdzenia tożsamości. Oprócz PRR, oceniamy też algorytm wczesnego ponownego przesyłania TCP (ER), który obniża próg zduplikowanego potwierdzenia w przypadku krótkich transferów i pokazuje, że opóźnienie wczesnej ponownej transmisji przez krótki czas skutecznie zapobiega przypadkowemu ponownemu przesyłaniu danych w przypadku niewielkiego stopnia zmiany kolejności. Protokół PRR i ER zmniejsza opóźnienie TCP w przypadku utraconych połączeń o 3–10% w zależności od rozmiaru odpowiedzi. Korzystając z naszych narzędzi na serwerach Google Web i YouTube w Stanach Zjednoczonych i Indiach, przedstawiamy również najważniejsze statystyki dotyczące charakteru ponownego przesyłania TCP.
Laminar TCP
Laminar to nowa platforma do kontrolowania przeciążenia TCP, która oddziela planowanie transmisji, co pozwala dokładnie określić, kiedy dane są wysyłane – od czystej kontroli zatorów, która określa łączną ilość danych wysyłanych podczas każdego RTT. Oczekuje się, że Laminar umożliwi korzystanie z nowych, zaawansowanych algorytmów umożliwiających dokładniejsze regulowanie ruchu TCP.
Wersje robocze SSL i TLS
Protokół TLS (Transport Layer Security)
Fałszywy start jest opcjonalnym działaniem w implementacjach TLS. Ma wpływ tylko na czasy protokołu, a nie na dane protokołu, i może być wdrażany jednostronnie. Funkcja TLS False Start zwiększa opóźnienie o 1 ruch w obie strony w przypadku niektórych uzgadniania połączenia.
Rozszerzenie negocjowania protokołu TLS (Transport Layer Security)
Rozszerzenie TLS do negocjowania protokołu warstwy aplikacji. Pozwala to warstwie aplikacji negocjować, który protokół należy wykonać przez zabezpieczone połączenie. Pozwala to uniknąć dodatkowych transferów w obie strony i jest niezależny od protokołów warstwy aplikacji.
Wersja robocza DNS
Podsieć klienta w żądaniach DNS
Ta wersja robocza definiuje rozszerzenie EDNS0 do przenoszenia informacji o sieci, która wygenerowała zapytanie DNS, oraz sieci, w przypadku której odpowiedź może być przechowywana w pamięci podręcznej.