Optymalizacja czasu połączenia (TCP + TLS) w ramach Time to First Byte

Optymalizacja czasu połączenia (TCP + TLS) w ramach Time to First Byte

Time to First Byte (TTFB) można podzielić na następujące części:

• Oczekiwanie + przekierowanie (czas oczekiwania)
  
• Worker + Cache (czas cache)
  
• DNS (czas DNS)
  
• Połączenie (czas połączenia)
• Żądanie (czas żądania)

Chcesz zoptymalizować Time to First byte? Ten artykuł zawiera szczegółową analizę części czasu DNS w Time to First Byte. Jeśli chcesz zrozumieć lub naprawić time to first byte i nie wiesz, co oznacza czas oczekiwania, przeczytaj czym jest time to first byte oraz napraw i zidentyfikuj problemy z time to first byte zanim rozpoczniesz lekturę tego artykułu

Część czasu połączenia w time to first byte składa się z czasu, w którym przeglądarka łączy się z serwerem. Po nawiązaniu połączenia przeglądarka i serwer zwykle dodają warstwę szyfrowania (TLS). Proces negocjacji tych 2 połączeń zajmuje trochę czasu, który jest dodawany do Time to First Byte.

Proces połączenia szczegółowo

Transmission Control Protocol (TCP) jest odpowiedzialny za ustanowienie niezawodnego połączenia między klientem (przeglądarką) a serwerem. Proces ten obejmuje trójstronny uścisk dłoni:

• Pakiet SYN (Synchronize): Klient wysyła pakiet SYN do serwera, aby zainicjować połączenie i poprosić o synchronizację.
• Pakiet SYN-ACK (Synchronize-Acknowledge): Serwer odpowiada pakietem SYN-ACK, potwierdzając otrzymanie pakietu SYN i zgadzając się na nawiązanie połączenia.
• Pakiet ACK (Acknowledge): Klient wysyła pakiet ACK z powrotem do serwera, potwierdzając otrzymanie pakietu SYN-ACK. W tym momencie połączenie TCP jest ustanowione, umożliwiając niezawodny transfer danych między klientem a serwerem.

TCP zapewnia, że dane są wysyłane i odbierane we właściwej kolejności, ponownie wysyłając wszelkie utracone pakiety i zarządzając kontrolą przepływu, aby dostosować się do pojemności sieci.

Po ustanowieniu połączenia TCP, protokół Transport Layer Security (TLS) jest używany do zabezpieczenia połączenia. Uścisk dłoni TLS obejmuje kilka kroków w celu uwierzytelnienia serwera i ustanowienia bezpiecznego kanału komunikacji:

• ClientHello: Klient wysyła wiadomość "ClientHello" do serwera, wskazując obsługiwane wersje TLS, zestawy szyfrów i liczbę losową (Client Random).
• ServerHello: Serwer odpowiada wiadomością "ServerHello", wybierając wersję TLS i zestaw szyfrów z listy klienta oraz przekazując swój certyfikat cyfrowy i liczbę losową (Server Random).
• Certyfikat i wymiana klucza: Serwer wysyła swój certyfikat cyfrowy do klienta w celu uwierzytelnienia. Klient weryfikuje certyfikat względem zaufanych urzędów certyfikacji.
• Premaster Secret: Klient generuje premaster secret, szyfruje go kluczem publicznym serwera (z certyfikatu) i wysyła do serwera.
• Generowanie klucza sesji: Zarówno klient, jak i serwer używają premaster secret wraz z Client Random i Server Random do wygenerowania wspólnego klucza sesji do szyfrowania symetrycznego.
• Wiadomości Finished: Klient i serwer wymieniają wiadomości zaszyfrowane kluczem sesji, aby potwierdzić, że uścisk dłoni zakończył się pomyślnie i że obie strony mają prawidłowy klucz sesji.

Po zakończeniu uścisku dłoni TLS klient i serwer mają ustanowione bezpieczne, zaszyfrowane połączenie. Zapewnia to, że wszelkie wymieniane dane są chronione przed podsłuchiwaniem i manipulacją przez osoby trzecie.

HTTP/3 przyspiesza połączenia TLS, integrując się z protokołem QUIC, który zmniejsza liczbę wymaganych podróży w obie strony do ustanowienia bezpiecznego połączenia, łącząc procesy uścisku dłoni w jeden, i obsługuje wznowienie 0-RTT dla szybszych ponownych połączeń. Dodatkowo wykorzystanie UDP przez QUIC eliminuje blokowanie na początku kolejki i poprawia kontrolę przeciążenia, prowadząc do bardziej efektywnej transmisji danych i szybszego ładowania stron.

• HTTP/3 - wprowadza protokół QUIC przez UDP zamiast TCP, umożliwiając szybszy i bardziej efektywny transfer danych
  
• TLS 1.3 Dodaje więcej bezpieczeństwa i zmniejsza liczbę podróży w obie strony podczas uścisku dłoni, jest wymagany do wznowienia połączenia 0-RTT. 
• Wznowienie połączenia 0-RTT - Funkcja TLS 1.3, która pozwala powracającym klientom natychmiast wysyłać zaszyfrowane dane po ponownym połączeniu, wykorzystując wcześniej wymienione informacje.
  
• TCP Fast Open. Umożliwia wysyłanie danych w początkowym pakiecie SYN, skracając czas podróży w obie strony dla uścisku dłoni TCP.
• TLS false start - Pozwala na wczesne wysyłanie danych przed zakończeniem uścisku dłoni TLS.
  
• OCSP Stapling -  Przyspiesza walidację certyfikatu eliminując potrzebę kontaktowania się klienta bezpośrednio z urzędem certyfikacji

Wskazówka dotycząca Time to Fist Byte: CDN nie tylko zapewnia krótsze czasy podróży w obie strony. Wykorzystanie CDN często natychmiast poprawi czasy połączeń TCP i TLS, ponieważ dostawcy premium CDN będą mieli poprawnie skonfigurowane te ustawienia dla Ciebie!

Jak znaleźć problemy z TTFB spowodowane powolnym czasem połączenia

Aby znaleźć wpływ, którego doświadczają prawdziwi użytkownicy spowodowany przekierowaniem, będziesz potrzebować narzędzia RUM, takiego jak CoreDash. Real user monitoring pozwoli śledzić Core Web Vitals z większą szczegółowością i bez 28-dniowego opóźnienia Google.

W CoreDash po prostu "kliknij na rozbicie Time to Fist Byte", aby zwizualizować część połączenia w Time to First Byte.