Duże pobierania a VPN: wybierz ścieżkę przy żądaniu

„Wyślij duże pobierania obok VPN, a małe odpowiedzi zostaw na nim” brzmi jak polityka routingu, ale nią nie jest. Router decyduje na podstawie informacji dostępnych w danej chwili: adresów, portów, protokołu, oznaczeń firewalla, zidentyfikowanego przepływu. Końcowy rozmiar odpowiedzi nie należy do tego zbioru, bo jeszcze nie nadszedł, a gdy router mógłby zmierzyć bajty, już je przenosi. Jeśli chcesz sterować według zadania, decyzja musi przenieść się do punktu, który zna zadanie, a lista kontrolna poniżej pokazuje, czy twój projekt ma taki punkt.

Dlaczego router nie może zmierzyć odpowiedzi

W chwili, gdy pakiet potrzebuje trasy, router widział co najwyżej pierwsze kilka pakietów przepływu. Potrafi powiedzieć, kto z kim rozmawia, przez jaki protokół, z jakim oznaczeniem i ile bajtów dotąd przeszło. Dotychczasowe bajty opisują przeszłość. Rozmiar odpowiedzi jest cechą odpowiedzi, która jeszcze nie powstała, a przy odpowiedziach dzielonych lub strumieniowych może nigdy nie być znany z góry.

Nawet metadane samego protokołu są słabsze, niż wyglądają. HTTP dopuszcza odpowiedzi, których długości nie ogłasza się przed ciałem, a jedna akcja użytkownika może wytworzyć wiele żądań, których łączny koszt nie przypomina żadnej pojedynczej wartości nagłówka. Traktowanie nagłówka jako rozmiaru zadania to błąd modelowania, zanim staje się błędem routingu.

Kontrola 1: czy istnieje punkt decyzyjny, który może wybrać ścieżkę?

Nazwij komponent, który dokona wyboru, a potem nazwij, co wie w chwili wyboru. Aktualizator pobierający z udokumentowanego zestawu hostów zna swój cel, zanim zacznie się transfer. Usługa pobierania, która sprawdza metadane i dopiero potem otwiera żądanie, zna zadanie, zanim powstanie połączenie. Współpracujące proxy może stosować politykę na poziomie żądania lub buforować odpowiedź, nie udając routera.

Jeśli odpowiedź brzmi „brama”, lista już zawiodła. Brama potrafi klasyfikować znane przepływy według celu, oznaczenia lub segmentu klienta i wysyłać je zdefiniowaną ścieżką od pierwszego pakietu, co często wystarcza zatwierdzonemu aktualizatorowi i nigdy nie wystarcza nieznanemu rozmiarowi odpowiedzi.

Kontrola 2: co naprawdę mówią metadane?

Sterowanie świadome aplikacji jest tak dobre, jak pola, które czyta. Reguły długości odpowiedzi w semantyka HTTP dopuszczają przypadki, gdy długość nie jest dostępna na początku, a kodowania treści i tak czynią liczbę przesłanych bajtów różną od rozmiaru reprezentacji. Dlatego polityka zmieniająca ścieżkę, gdy nagłówek przekroczy próg, będzie działać niekonsekwentnie, i to głównie właśnie przy dużych transferach, które miała wychwycić.

To, co metadane aplikacji mogą wesprzeć, to decyzja o zadaniu: ten przepływ pracy to synchronizacja zbiorcza, ten jest interaktywny, ten to aktualizacja oprogramowania ze znanego źródła. To polityka zapisana językiem intencji i jest wystarczająco stabilna, by ją testować. „Ta odpowiedź będzie większa niż czterdzieści megabajtów” nie jest taką polityką.

Kontrola 3: czy przepływ już istnieje?

Routing może się zmienić dla przepływu bez zmiany tożsamości połączenia, i tę różnicę warto trzymać precyzyjnie. Połączenie TCP jest identyfikowane przez adresy i porty swoich końców, a pakiety mogą pójść inną drogą, jeśli tablica routingu zmieni się pod nimi. To, co nie może zmienić się niewidocznie, to stan tłumaczenia adresów sieciowych: przeniesienie ruchu na inne wyjście zwykle zmienia publiczną krotkę źródłową, a drugi koniec zobaczy innego partnera bez pasującego stanu.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Praktyczna zasada jest więc taka, że przeniesienie w środku połączenia z jednego wyjścia na drugie jest nową relacją, nie migracją. Jeśli projekt wymaga, by to samo połączenie trwało, decyzję trzeba było podjąć przed pierwszym SYN, a żadna dodana później reguła pakietów nie odtworzy jej czysto.

Kontrola 4: czy prawdziwym wymaganiem jest opóźnienie, a nie wyjście?

Bardzo wiele żądań „wyślij ruch zbiorczy gdzie indziej” to w istocie skargi, że duży transfer sprawia, iż praca interaktywna wydaje się wolna. To problem planowania i ma odpowiedź z planowania: sprawiedliwe kolejkowanie lub obsługiwana polityka przepustowości na istniejącej ścieżce nie pozwala przepływowi zbiorczemu zagłodzić wiadomości czatu, nie przenosząc żadnego z nich.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Takie podejście do objawu zostawia decyzję o wyjściu tam, gdzie postawiła ją polityka bezpieczeństwa, i jest odwracalne jednym poleceniem. Zmiana wyjścia dla całej klasy ruchu to zmiana polityki z konsekwencjami dla uwierzytelniania, rejestrowania i reguł dostępu, więc nie powinna być pierwszym narzędziem przy skardze na opóźnienie.

Jeśli wymaganiem naprawdę jest inne wyjście do internetu, powiedz to tymi słowami i zrealizuj na obsługiwanej granicy: nowe połączenie z zatwierdzonego przepływu pracy albo aplikacja, która otwiera własne żądanie przez wybrane wyjście. Następnie zapisz, które zadania używają którego wyjścia, aby następna osoba nie musiała tego wywnioskować z tablicy routingu.

Trzymaj listę kontrolną w zapisie zmiany: punkt decyzyjny, pole lub zadanie, które nim kieruje, czy przepływ już istnieje i czy zmierzonym objawem było opóźnienie, czy wyjście. Cztery pytania, a polityka, która odpowiada na wszystkie cztery, jest tą, którą można obsługiwać, a nie bronić.