Ciepły HTTPS a ciepły VPN: porównaj tę samą ścieżkę żądania

Prawdopodobnie czytasz, że HTTPS otwiera nowe połączenie TCP i nowy uścisk dłoni TLS dla każdego żądania API, więc tunel utrzymywany przez godzinę wydaje się tańszy. Pierwsza połowa tego zdania jest zwykle nieprawdziwa. Obsługiwany klient używa ponownie ustanowionego połączenia do wielu wymian, a pomiar, który tworzy nowego klienta przy każdym wywołaniu, mierzy cykl życia, a nie ochronę. Reszta tej strony mówi, co mierzyć zamiast tego.

Czego naprawdę wymaga ponowne użycie

Trwałość jest częścią modelu HTTP, a nie sztuczką: jedno połączenie niesie wiele wymian żądania i odpowiedzi. Połączenie kończy się, gdy jedna ze stron je zamknie, gdy serwer wycofa bezczynne lub przeciążone połączenie albo gdy nagłówek lub reguła protokołu mówi, że połączenia nie można użyć ponownie. HTTPS umieszcza tę rozmowę wewnątrz TLS, nie wymagając nowego uścisku dłoni dla każdej wymiany. Drugie żądanie nie powtarza więc uścisku dłoni pierwszego, chyba że coś zakończyło połączenie w międzyczasie.

Ponowne użycie ma też jeden warunek, który aplikacje łatwo łamią. Klient, który zamierza użyć połączenia ponownie, musi odczytać całą treść odpowiedzi, a odpowiedź porzucona w połowie to zwykły sposób, w jaki pula połączeń znika, zanim ktokolwiek to zauważy.

Sprawdź obsługiwanego klienta biblioteki i cykl życia puli połączeń, zamiast zakładać, że łączenie w pule jest włączone lub wyłączone. Zapisz też wynegocjowaną wersję HTTP, ponieważ HTTP/2 i HTTP/3 obsługują ponowne użycie połączeń inaczej niż HTTP/1.1. Traktuj wynegocjowaną wersję jako część pomiaru, a nie przypis.

Dlaczego porównanie mierzy cykl życia

Tworzenie nowego klienta dla każdej operacji i porównywanie go z tunelem połączonym od godziny porównuje zestawienie połączenia ze stanem ustalonym. To uzasadniony pomiar i nie jest to HTTPS kontra VPN. Dwa przebiegi z tą samą konfiguracją klienta opisują zachowanie lepiej niż jeden, zwłaszcza gdy pierwszy przebieg rozgrzewa resolver lub pamięć podręczną połączeń.

Utrzymuj stałą operację API, serwer, konto i dane, inaczej porównanie niesie więcej niż jedną zmienną. Z góry zdecyduj, gdzie umieścisz stoper, bo zestawienie, negocjacja TLS, wykonanie aplikacji i dostarczenie odpowiedzi wnoszą różny wkład do sumy. Jeden pomiar pierwszego żądania charakteryzuje zestawienie i nic nie mówi o stałym ruchu, który naprawdę prowadzisz. Zapisz granice pomiaru obok liczb.

Oddziel zimne zestawienie od ciepłych żądań

Mierz pierwsze żądanie osobno od kolejnych. Potem dodaj to, co usługa naprawdę widzi: okresy bezczynności, skoki, współbieżność, rozmiar odpowiedzi i ponowne połączenia.

Zostaw włączoną weryfikację certyfikatów i HTTPS na obu ścieżkach, bo ich usunięcie mierzy inny projekt bezpieczeństwa, a nie szybszy. Jeśli tunel zmienia trasę lub położenie bramy, zgłoś tę różnicę osobno, zamiast przypisywać każdą zmianę czasu szyfrowaniu, ponieważ trasa, straty i kolejka mogą zdominować małe żądanie. Uruchom każdą ścieżkę dwa razy po tej samej trasie, zanim wyciągniesz wniosek. Zapisz wynegocjowany protokół i granice pomiaru przy obu przebiegach.

Licz się z połączeniem, które się zamyka

Trwały nie znaczy wieczny. Serwer, proxy lub zmiana sieci mogą zamknąć połączenie w okresie bezczynności, a klient musi się odtworzyć zgodnie z zachowaniem obsługiwanym przez swoją bibliotekę. To odtworzenie ma maszynę stanów: żądanie mogło zostać ukończone na serwerze albo mogło się nie powieść, zanim serwer je odczytał, a zamknięte gniazdo nie mówi wywołującemu, co się stało. Nieidempotentnej operacji w tym miejscu nie można po prostu powtórzyć, bo powtórzenie zamienia nieznany wynik w podwójny zapis. Tu ciepły tunel i ciepłe połączenie zachowują się tak samo, bo oba mogą zawieść w chwili, gdy praca jest w toku.

Użyj udokumentowanego mechanizmu ponawiania lub idempotencji usługi zamiast pętli, która otwiera gniazdo ponownie. Przetestuj odtworzenie wprost: zamknij bezczynne połączenie i obserwuj, co klient zrobi dalej. Ponowne otwarcie gniazda nie czyni powtórzenia wywołania zmieniającego stan bezpiecznym.

Najpierw wybierz granicę, potem dostrajaj

Wybierz granicę sieci na podstawie wymagań dostępu i zaufania, zanim cokolwiek zoptymalizujesz. VPN chroni segment między swoimi partnerami, podczas gdy punkty końcowe aplikacji i każdy segment czystego tekstu poza tunelem nadal się liczą. Następnie dostrój cykl życia połączenia w obrębie tej granicy. Wniosek o tańszym tunelu wynika tylko z przekonania, że każde żądanie powtarza uścisk dłoni, i właśnie to przekonanie jest tu sprawdzane.

Rozdział RFC 9112 o trwałości jest odniesieniem do tego, co ponowne użycie naprawdę obiecuje, wraz z warunkami, które kończą połączenie. Przeczytaj go raz, zanim zaufasz pomiarowi, który je ignoruje.