Optimaliseer de verbindingsduur (TCP + TLS) sub-onderdeel van de Time to First Byte

Optimaliseer de verbindingsduur (TCP + TLS) sub-onderdeel van de Time to First Byte

De Time to First Byte (TTFB) kan worden opgesplitst in de volgende subonderdelen:

• Waiting + Redirect (of wachttijd)
  
• Worker + Cache (of cacheduur)
• DNS (of DNS-duur)
• Connectie  (of connectieduur)
• Request (of requestduur)

Wil je de Time to First Byte optimaliseren? Dit artikel biedt een diepgaande analyse van het connectieduur gedeelte van de Time to First Byte. Als je de time to first byte wilt begrijpen of oplossen en niet weet wat de wachttijd betekent, lees dan alsjeblieft wat is de time to first byte en time to first byte problemen vinden en oplossen voordat je aan dit artikel begint

Het connectieduur gedeelte van de time to first byte bestaat uit enige tijd waarin de browser verbinding maakt met de webserver. Na die verbinding zullen de browser en server meestal een encryptielaag (TLS) toevoegen. Het proces van het onderhandelen over deze 2 verbindingen zal een beetje tijd in beslag nemen en die tijd wordt toegevoegd aan de Time to First Byte.

Verbindingsproces in detail

Het Transmission Control Protocol (TCP) is verantwoordelijk voor het opzetten van een betrouwbare verbinding tussen de client (browser) en de server. Dit proces omvat een drievoudige handdruk:

• SYN (Synchronize) Packet: De client stuurt een SYN-packet naar de server om de verbinding te initiëren en synchronisatie aan te vragen.
• SYN-ACK (Synchronize-Acknowledge) Packet: De server reageert met een SYN-ACK-packet, bevestigt de ontvangst van het SYN-packet en stemt ermee in een verbinding tot stand te brengen.
• ACK (Acknowledge) Packet: De client stuurt een ACK-packet terug naar de server, ter bevestiging van de ontvangst van het SYN-ACK-packet. Op dit punt is een TCP-verbinding tot stand gebracht, waardoor data betrouwbaar kan worden overgedragen tussen de client en server.

TCP zorgt ervoor dat data in de juiste volgorde wordt verzonden en ontvangen, verzendt verloren pakketten opnieuw en beheert flow control om overeen te komen met de capaciteit van het netwerk.

Zodra de TCP-verbinding tot stand is gebracht, wordt het Transport Layer Security (TLS) protocol gebruikt om de verbinding te beveiligen. De TLS-handshake omvat verschillende stappen om de server te authenticeren en een beveiligd communicatiekanaal tot stand te brengen:

• ClientHello: De client stuurt een "ClientHello"-bericht naar de server, waarin de ondersteunde TLS-versies, cipher suites en een willekeurig getal (Client Random) worden aangegeven.
• ServerHello: De server reageert met een "ServerHello"-bericht, selecteert de TLS-versie en cipher suite uit de lijst van de client, en verstrekt zijn digitale certificaat en een willekeurig getal (Server Random).
• Certificate and Key Exchange: De server stuurt zijn digitale certificaat naar de client voor authenticatie. De client verifieert het certificaat bij vertrouwde certificaatautoriteiten.
• Premaster Secret: De client genereert een premaster secret, versleutelt dit met de publieke sleutel van de server (uit het certificaat) en stuurt het naar de server.
• Session Key Generation: Zowel de client als de server gebruiken het premaster secret, samen met de Client Random en Server Random, om een gedeelde sessiesleutel te genereren voor symmetrische encryptie.
• Finished Messages: De client en server wisselen berichten uit die versleuteld zijn met de sessiesleutel om te bevestigen dat de handshake succesvol was en dat beide partijen de juiste sessiesleutel hebben.

Zodra de TLS-handshake is voltooid, hebben de client en server een beveiligde, versleutelde verbinding tot stand gebracht. Dit zorgt ervoor dat alle uitgewisselde data beschermd is tegen afluisteren en manipulatie door derden.

HTTP/3 versnelt TLS-verbindingen door te integreren met het QUIC-protocol, wat het aantal round-trips vermindert dat nodig is om een beveiligde verbinding tot stand te brengen door de handshake-processen in één te combineren, en ondersteunt 0-RTT hervatting voor snellere herverbindingen. Bovendien elimineert het gebruik van UDP door QUIC head-of-line blocking en verbetert congestiecontrole, wat leidt tot efficiëntere gegevensoverdracht en snellere laadtijden van pagina's.

• HTTP/3 - brengt het QUIC-protocol over UDP in plaats van TCP, wat zorgt voor snellere en efficiëntere gegevensoverdracht
  
• TLS 1.3 Voegt meer beveiliging toe en vermindert handshake round-trips en is vereist voor 0-RTT Connection resumption. 
• 0-RTT Connection Resumption - TLS 1.3-functie waarmee terugkerende clients onmiddellijk versleutelde data kunnen verzenden bij herverbinding door eerder uitgewisselde  informatie opnieuw te gebruiken.
  
• TCP Fast Open. Maakt het mogelijk om data te verzenden in het initiële SYN-packet, waardoor de round-trip tijd voor de TCP-handshake wordt verminderd.
• TLS false start - Staat vroege verzending van data toe voordat de TLS-handshake voltooid is.
  
• OCSP Stapling -  Versnelt certificaatvalidatie door de noodzaak voor de client om rechtstreeks contact op te nemen met de certificaatautoriteit te elimineren

Time to Fist Byte TIP: een CDN levert niet alleen kortere round-trip tijden. Het gebruik van een CDN zal vaak onmiddellijk de TCP- en TLS-verbindingstijden verbeteren omdat premium CDN-providers deze instellingen correct voor je hebben geconfigureerd!

Hoe TTFB problemen veroorzaakt door trage verbindingstijd te vinden

Om de impact te vinden die echte gebruikers ervaren door redirect zul je een RUM-tool zoals CoreDash moeten gebruiken. Real user monitoring laat je de Core Web Vitals tot in groter detail volgen en zonder de 28 dagen Google vertraging.

In CoreDash klik je gewoon 'op Time to Fist Byte breakdown' om het verbindingsgedeelte van de Time to First Byte te visualiseren.