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

Dit artikel is onderdeel van onze Time to First Byte (TTFB) handleiding. De verbindingsduur is het vierde onderdeel van de TTFB en vertegenwoordigt de tijd die de browser besteedt aan het opzetten van een TCP-verbinding en het onderhandelen van TLS-versleuteling met de server. Voor gebruikers die zich geografisch ver van de server bevinden, kan de verbindingsduur 100 tot 500 milliseconden toevoegen aan de TTFB vanwege de meerdere round trips die nodig zijn voor de TCP- en TLS-handshakes.

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

• Wachten + Redirect (of wachtduur)
• Worker + Cache (of cacheduur)
• DNS (of DNS-duur)
• Verbinding (of verbindingsduur)
• Aanvraag (of aanvraagduur)

Wil je de Time to First Byte optimaliseren? Dit artikel biedt een diepgaande analyse van het onderdeel verbindingsduur van de Time to First Byte. Als je de Time to First Byte wilt begrijpen of oplossen en niet weet wat de verbindingsduur betekent, lees dan wat is de Time to First Byte en TTFB-problemen oplossen en identificeren voordat je aan dit artikel begint.

Het onderdeel verbindingsduur van de Time to First Byte bestaat uit de tijd waarin de browser verbinding maakt met de webserver. Na die verbinding voegen de browser en server meestal een encryptielaag (TLS) toe. Het proces van het onderhandelen over deze 2 verbindingen kost tijd, en die tijd wordt opgeteld bij de Time to First Byte.

Het 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 three-way handshake:

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

TCP zorgt ervoor dat gegevens in de juiste volgorde worden verzonden en ontvangen, verstuurt verloren pakketten opnieuw en beheert flow control om aan te sluiten bij 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 veilig communicatiekanaal op te zetten:

• ClientHello: De client stuurt een "ClientHello"-bericht naar de server, waarin de ondersteunde TLS-versies, cipher suites en een willekeurig nummer (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 nummer (Server Random).
• Certificaat en Sleuteluitwisseling: 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.
• Sessiesleutel Generatie: 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.
• Voltooid Berichten: De client en server wisselen berichten uit die zijn versleuteld 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 veilige, versleutelde verbinding tot stand gebracht. Dit zorgt ervoor dat alle uitgewisselde gegevens beschermd zijn tegen afluisteren en manipulatie door derden.

TLS 1.3 vs TLS 1.2: Waarom het belangrijk is voor TTFB

De versie van TLS die je server gebruikt, heeft een directe invloed op de verbindingsduur. TLS 1.3 is aanzienlijk sneller dan TLS 1.2 omdat het het aantal round trips vermindert dat nodig is om de handshake te voltooien:

TLS 1.3 reduceert de handshake van twee round trips naar één. Voor een gebruiker die zich op 100ms afstand van de server bevindt (round trip time), bespaart dit ongeveer 100ms op elke nieuwe verbinding. Voor terugkerende bezoekers stelt TLS 1.3's 0-RTT (zero round trip time) hervatting de client in staat om direct versleutelde gegevens te verzenden bij het opnieuw verbinden door eerder uitgewisselde sessie-informatie te hergebruiken. Dit kan de TLS-handshake overhead tot bijna nul reduceren voor terugkerende bezoekers.

HTTP/3 en QUIC: De Toekomst van Snelle Verbindingen

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

HTTP/3 brengt verschillende verbeteringen ten opzichte van HTTP/2 die direct van invloed zijn op de verbindingsduur:

• Gecombineerde handshake: Bij HTTP/2 over TCP vinden de TCP-handshake en TLS-handshake na elkaar plaats (3 round trips in totaal voor een nieuwe verbinding). HTTP/3 over QUIC combineert de transport- en TLS-handshake in een enkele round trip. Voor nieuwe verbindingen bespaart dit een volledige round trip vergeleken met HTTP/2.
• 0-RTT verbindingshervatting: Net als TLS 1.3 ondersteunt QUIC 0-RTT hervatting. Terugkerende bezoekers kunnen direct beginnen met het verzenden van gegevens zonder te wachten tot een handshake is voltooid. Dit is vooral effectief voor mobiele gebruikers die vaak schakelen tussen wifi en mobiele verbindingen.
• Geen head-of-line blocking: Bij HTTP/2 over TCP blokkeert een enkel verloren pakket alle streams op die verbinding totdat het pakket opnieuw is verzonden. QUIC gebruikt UDP en behandelt streams onafhankelijk, dus een verloren pakket beïnvloedt alleen de specifieke stream waartoe het behoort. Dit resulteert in consistentere verbindingsprestaties op onbetrouwbare netwerken.
• Verbindingsmigratie: QUIC-verbindingen worden geïdentificeerd door een connection ID in plaats van een bron-IP en poort. Dit betekent dat wanneer een mobiele gebruiker overschakelt van wifi naar mobiel (en hun IP-adres verandert), de QUIC-verbinding blijft bestaan zonder opnieuw te moeten worden opgezet. Dit voorkomt de volledige TCP + TLS-handshake die anders nodig zou zijn.

Hoe beïnvloedt de Verbindingstijd de Time to First Byte?

Hoe de Impact van Verbindingstijd op de TTFB te Minimaliseren

Gebruik Preconnect voor Kritieke Origins

De <link rel="preconnect"> resource hint vertelt de browser om een verbinding (DNS + TCP + TLS) op te zetten naar een specifieke origin voordat bronnen van die origin daadwerkelijk nodig zijn. Dit elimineert de verbindingsduur van het kritieke pad wanneer de bron uiteindelijk wordt aangevraagd:

<!-- Preconnect naar kritieke third-party origins -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

Gebruik preconnect spaarzaam (maximaal 3 tot 5 origins). Elke preconnect opent een volledige TCP + TLS-verbinding, wat CPU- en netwerkbronnen verbruikt. Preconnect alleen naar origins die nodig zijn bij elke paginalading. Voor origins die slechts af en toe nodig zijn, gebruik in plaats daarvan dns-prefetch (zie onze DNS-duur handleiding).

Serverconfiguratie voor TLS 1.3 en HTTP/3

• 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. Vereist voor 0-RTT Verbindingshervatting.
• 0-RTT Verbindingshervatting: TLS 1.3-functie waarmee terugkerende clients direct versleutelde gegevens kunnen verzenden bij het opnieuw verbinden door eerder uitgewisselde informatie te hergebruiken.
• TCP Fast Open: maakt het mogelijk om gegevens te verzenden in het initiële SYN-pakket, wat de round-trip tijd voor de TCP-handshake vermindert.
• TLS False Start: staat vroege verzending van gegevens toe voordat de TLS-handshake voltooid is.
• OCSP Stapling: versnelt certificaatvalidatie door de noodzaak voor de client om direct contact op te nemen met de certificaatautoriteit te elimineren.

Hier is een voorbeeld Nginx-configuratie die TLS 1.3 en OCSP Stapling inschakelt:

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Schakel OCSP Stapling in
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Schakel sessiehervatting in (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest van je serverconfiguratie
}

Voor Apache, enable TLS 1.3 met:

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Schakel OCSP Stapling in
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Schakel sessiehervatting in
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest van je virtual host configuratie
</VirtualHost>

Time to First Byte TIP: een CDN levert niet alleen kortere round trip tijden op. Het gebruik van een CDN zal vaak direct de TCP- en TLS-verbindingstijden verbeteren omdat premium CDN-providers deze instellingen correct voor je hebben geconfigureerd. Bekijk onze handleiding over hoe je Cloudflare configureert voor prestaties om te beginnen.

Verbindingsduur Meten met JavaScript

Je kunt het onderdeel verbindingsduur van de TTFB direct in de browser meten met behulp van de Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocol:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

De nextHopProtocol eigenschap onthult welk protocol is gebruikt voor de verbinding. Veelvoorkomende waarden zijn "h2" (HTTP/2), "h3" (HTTP/3) en "http/1.1". Als je server HTTP/3 ondersteunt maar je RUM-gegevens laten zien dat de meeste verbindingen "h2" gebruiken, kan dit erop wijzen dat HTTP/3-ondersteuning niet goed wordt geadverteerd via de Alt-Svc header.

Hoe TTFB-problemen door Trage Verbindingstijd te Vinden

Om de impact te vinden die echte gebruikers ervaren door verbindingslatentie, moet je een RUM-tool zoals CoreDash gebruiken. Real User Monitoring laat je de Core Web Vitals in meer detail volgen en zonder de 28-daagse vertraging van Google.

Klik in CoreDash op "Time to First Byte breakdown" om het verbindingsonderdeel van de Time to First Byte te visualiseren.

Verder Lezen: Optimalisatie Handleidingen

Voor gerelateerde optimalisatietechnieken die verbindingsoptimalisatie aanvullen, verken deze handleidingen:

• 103 Early Hints: de server kan resource hints (preload, preconnect) sturen terwijl de hoofdrespons nog wordt verwerkt, waardoor de browser eerder kan beginnen met het opzetten van verbindingen.
• Configureer Cloudflare voor Prestaties: Cloudflare schakelt automatisch HTTP/3, TLS 1.3 en OCSP Stapling in. Het gebruik van een CDN brengt je server ook dichter bij gebruikers, wat de round trip tijden voor alle verbindingen vermindert.

TTFB-onderdelen: Deep Dive Artikelen

De verbindingsduur is een van de vijf onderdelen van de TTFB. Verken de andere onderdelen om het volledige plaatje te begrijpen:

• TTFB-problemen Oplossen en Identificeren: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Wachtduur: redirects, browser queuing en HSTS-optimalisatie.
• Cacheduur: service worker prestaties, browser cache lookups en bfcache.
• DNS-duur: DNS-provider selectie, TTL-configuratie en dns-prefetch.