Optimer forbindelsesvarigheden (TCP + TLS) underdelen af Time to First Byte
Forbindelsesvarigheden af TTFB består af opsætning af TCP- og TLS-forbindelsen. Forstå underdelen af TTFB for at reducere den samlede Time to First Byte

Optimer forbindelsesvarigheden (TCP + TLS) underdelen af Time to First Byte
Time to First Byte (TTFB) kan opdeles i følgende underdele:
- Ventetid + Omdirigering (eller ventevarighed)
- Worker + Cache (eller cachevarighed)
- DNS (eller DNS-varighed)
- Forbindelse (eller forbindelsesvarighed)
- Anmodning (eller anmodningsvarighed)
Vil du optimere Time to First Byte? Denne artikel giver en dybdegående analyse af DNS-varighedsdelen af Time to First Byte. Hvis du ønsker at forstå eller rette Time to First Byte og ikke ved, hvad ventevarigheden betyder, læs venligst hvad er Time to First Byte og ret og identificer Time to First Byte-problemer før du starter med denne artikel
Forbindelsesvarighedsdelen af Time to First Byte består af noget tid, hvor browseren opretter forbindelse til webserveren. Efter den forbindelse vil browseren og serveren normalt tilføje et krypteringslag (TLS). Processen med at forhandle disse 2 forbindelser tager lidt tid, og den tid lægges til Time to First Byte.
Forbindelsesprocessen i detaljer
Transmission Control Protocol (TCP) er ansvarlig for at etablere en pålidelig forbindelse mellem klienten (browseren) og serveren. Denne proces involverer et tre-vejs handshake:

- SYN (Synchronize) Packet: Klienten sender en SYN-pakke til serveren for at starte forbindelsen og anmode om synkronisering.
- SYN-ACK (Synchronize-Acknowledge) Packet: Serveren svarer med en SYN-ACK-pakke, bekræfter modtagelsen af SYN-pakken og accepterer at etablere en forbindelse.
- ACK (Acknowledge) Packet: Klienten sender en ACK-pakke tilbage til serveren og bekræfter modtagelsen af SYN-ACK-pakken. På dette tidspunkt er en TCP-forbindelse etableret, hvilket gør det muligt at overføre data pålideligt mellem klient og server.
TCP sikrer, at data sendes og modtages i den korrekte rækkefølge, gensender eventuelle tabte pakker og håndterer flowkontrol for at matche netværkets kapacitet.
Når TCP-forbindelsen er etableret, bruges Transport Layer Security (TLS) protokollen til at sikre forbindelsen. TLS-handshake involverer flere trin for at autentificere serveren og etablere en sikker kommunikationskanal:
- ClientHello: Klienten sender en "ClientHello"-besked til serveren, der angiver de understøttede TLS-versioner, cipher suites og et tilfældigt tal (Client Random).
- ServerHello: Serveren svarer med en "ServerHello"-besked, vælger TLS-versionen og cipher suite fra klientens liste og leverer sit digitale certifikat og et tilfældigt tal (Server Random).
- Certifikat og nøgleudveksling: Serveren sender sit digitale certifikat til klienten til autentificering. Klienten verificerer certifikatet mod betroede certifikatmyndigheder.
- Premaster Secret: Klienten genererer en premaster secret, krypterer den med serverens offentlige nøgle (fra certifikatet) og sender den til serveren.
- Generering af sessionsnøgle: Både klienten og serveren bruger premaster secret sammen med Client Random og Server Random til at generere en delt sessionsnøgle til symmetrisk kryptering.
- Afsluttende beskeder: Klienten og serveren udveksler beskeder krypteret med sessionsnøglen for at bekræfte, at handshake var vellykket, og at begge parter har den korrekte sessionsnøgle.
Når TLS-handshake er fuldført, har klienten og serveren etableret en sikker, krypteret forbindelse. Dette sikrer, at alle udvekslede data er beskyttet mod aflytning og manipulation af tredjeparter.
HTTP/3 fremskynder TLS-forbindelser ved at integrere med QUIC-protokollen, som reducerer antallet af rundrejser, der er nødvendige for at etablere en sikker forbindelse, ved at kombinere handshake-processerne til én, og understøtter 0-RTT-genoptagelse for hurtigere genforbindelser. Derudover eliminerer QUICs brug af UDP head-of-line blocking og forbedrer congestion control, hvilket fører til mere effektiv dataoverførsel og hurtigere sideindlæsninger.
Sådan minimerer du forbindelsestidens påvirkning af TTFB
- HTTP/3 - bringer QUIC-protokollen over UDP i stedet for TCP, hvilket muliggør hurtigere og mere effektiv dataoverførsel
- TLS 1.3 Tilføjer mere sikkerhed og reducerer handshake-rundrejser og er påkrævet for 0-RTT-forbindelsesgenoptagelse.
- 0-RTT-forbindelsesgenoptagelse - TLS 1.3-funktion, der gør det muligt for tilbagevendende klienter at sende krypterede data umiddelbart ved genforbindelse ved at genbruge tidligere udvekslede oplysninger.
- TCP Fast Open. Muliggør afsendelse af data i den indledende SYN-pakke, hvilket reducerer rundrejsetiden for TCP-handshake.
- TLS false start - Tillader tidlig afsendelse af data, før TLS-handshake er fuldført.
- OCSP Stapling - Fremskynder certifikatvalidering ved at eliminere behovet for, at klienten kontakter certifikatmyndigheden direkte
Time to First Byte TIP: ikke kun leverer en CDN kortere rundrejsetider. Brug af en CDN vil ofte umiddelbart forbedre TCP- og TLS-forbindelsestider, fordi premium CDN-udbydere vil have korrekt konfigureret disse indstillinger for dig!
Sådan finder du TTFB-problemer forårsaget af langsom forbindelsestid
For at finde den påvirkning, som rigtige brugere oplever forårsaget af omdirigering, skal du bruge et RUM-værktøj som CoreDash. Real user monitoring giver dig mulighed for at spore Core Web Vitals i større detalje og uden Googles 28-dages forsinkelse.
I CoreDash klik blot på 'Time to First Byte breakdown' for at visualisere forbindelsesdelen af Time to First Byte.

Stop debating in Jira.
Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis

