Optimieren Sie die Verbindungsdauer (TCP + TLS) Teilkomponente der Time to First Byte

Optimieren Sie die Verbindungsdauer (TCP + TLS) Teilkomponente der Time to First Byte

Die Time to First Byte (TTFB) kann in die folgenden Teilbereiche unterteilt werden:

• Warten + Redirect (oder Wartezeit)
  
• Worker + Cache (oder Cache-Dauer)
• DNS (oder DNS-Dauer)
• Verbindung  (oder Verbindungsdauer)
• Anfrage (oder Anfragedauer)

Möchten Sie die Time to First Byte optimieren? Dieser Artikel bietet eine eingehende Analyse des DNS-Dauer-Teils der Time to First Byte. Wenn Sie die Time to First Byte verstehen oder beheben möchten und nicht wissen, was die Wartezeit bedeutet, lesen Sie bitte was ist die Time to First Byte und Time to First Byte-Probleme finden und beheben, bevor Sie mit diesem Artikel beginnen.

Der Verbindungsdauer-Teil der Time to First Byte besteht aus einiger Zeit, in der der Browser eine Verbindung zum Webserver herstellt. Nach dieser Verbindung fügen Browser und Server normalerweise eine Verschlüsselungsschicht (TLS) hinzu. Der Prozess der Aushandlung dieser 2 Verbindungen dauert ein wenig Zeit und diese Zeit wird zur Time to First Byte hinzugefügt.

Verbindungsprozess im Detail

Das Transmission Control Protocol (TCP) ist dafür verantwortlich, eine zuverlässige Verbindung zwischen dem Client (Browser) und dem Server herzustellen. Dieser Prozess umfasst einen Drei-Wege-Handshake:

• SYN (Synchronize) Paket: Der Client sendet ein SYN-Paket an den Server, um die Verbindung zu initiieren und Synchronisation anzufordern.
• SYN-ACK (Synchronize-Acknowledge) Paket: Der Server antwortet mit einem SYN-ACK-Paket, bestätigt den Empfang des SYN-Pakets und stimmt zu, eine Verbindung herzustellen.
• ACK (Acknowledge) Paket: Der Client sendet ein ACK-Paket zurück an den Server, um den Empfang des SYN-ACK-Pakets zu bestätigen. An diesem Punkt ist eine TCP-Verbindung hergestellt, die es ermöglicht, Daten zuverlässig zwischen Client und Server zu übertragen.

TCP stellt sicher, dass Daten in der richtigen Reihenfolge gesendet und empfangen werden, sendet alle verlorenen Pakete erneut und verwaltet die Flusskontrolle, um der Kapazität des Netzwerks zu entsprechen.

Sobald die TCP-Verbindung hergestellt ist, wird das Transport Layer Security (TLS) Protokoll verwendet, um die Verbindung zu sichern. Der TLS-Handshake umfasst mehrere Schritte, um den Server zu authentifizieren und einen sicheren Kommunikationskanal herzustellen:

• ClientHello: Der Client sendet eine "ClientHello"-Nachricht an den Server, die die unterstützten TLS-Versionen, Cipher Suites und eine Zufallszahl (Client Random) angibt.
• ServerHello: Der Server antwortet mit einer "ServerHello"-Nachricht, wählt die TLS-Version und Cipher Suite aus der Liste des Clients aus und stellt sein digitales Zertifikat und eine Zufallszahl (Server Random) bereit.
• Zertifikats- und Schlüsselaustausch: Der Server sendet sein digitales Zertifikat zur Authentifizierung an den Client. Der Client überprüft das Zertifikat bei vertrauenswürdigen Zertifizierungsstellen.
• Premaster Secret: Der Client generiert ein Premaster Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers (aus dem Zertifikat) und sendet es an den Server.
• Session Key Generation: Sowohl der Client als auch der Server verwenden das Premaster Secret zusammen mit dem Client Random und Server Random, um einen gemeinsamen Sitzungsschlüssel für die symmetrische Verschlüsselung zu generieren.
• Finished Messages: Der Client und der Server tauschen Nachrichten aus, die mit dem Sitzungsschlüssel verschlüsselt sind, um zu bestätigen, dass der Handshake erfolgreich war und dass beide Parteien den richtigen Sitzungsschlüssel haben.

Sobald der TLS-Handshake abgeschlossen ist, haben Client und Server eine sichere, verschlüsselte Verbindung hergestellt. Dies stellt sicher, dass alle ausgetauschten Daten vor Abhören und Manipulation durch Dritte geschützt sind.

HTTP/3 beschleunigt TLS-Verbindungen durch die Integration mit dem QUIC-Protokoll, das die Anzahl der Round-Trips reduziert, die zum Herstellen einer sicheren Verbindung erforderlich sind, indem die Handshake-Prozesse in einem kombiniert werden, und unterstützt 0-RTT-Wiederaufnahme für schnellere Wiederverbindungen. Darüber hinaus eliminiert die Verwendung von UDP durch QUIC Head-of-Line-Blocking und verbessert die Überlastungskontrolle, was zu effizienterer Datenübertragung und schnelleren Ladezeiten von Seiten führt.

• HTTP/3 - bringt das QUIC-Protokoll über UDP anstelle von TCP, was eine schnellere und effizientere Datenübertragung ermöglicht
  
• TLS 1.3 Fügt mehr Sicherheit hinzu und reduziert Handshake-Round-Trips und ist für die 0-RTT Connection Resumption erforderlich. 
• 0-RTT Connection Resumption - TLS 1.3-Funktion, die es wiederkehrenden Clients ermöglicht, verschlüsselte Daten sofort bei der Wiederverbindung zu senden, indem zuvor ausgetauschte  Informationen wiederverwendet werden.
  
• TCP Fast Open. Ermöglicht das Senden von Daten im anfänglichen SYN-Paket, wodurch die Round-Trip-Zeit für den TCP-Handshake reduziert wird.
• TLS False Start - Ermöglicht das frühe Senden von Daten, bevor der TLS-Handshake abgeschlossen ist.
  
• OCSP Stapling -  Beschleunigt die Zertifikatsvalidierung, indem die Notwendigkeit für den Client eliminiert wird, die Zertifizierungsstelle direkt zu kontaktieren.

Time to First Byte TIPP: Ein CDN liefert nicht nur kürzere Round-Trip-Zeiten. Die Nutzung eines CDN verbessert oft sofort die TCP- und TLS-Verbindungszeiten, da Premium-CDN-Anbieter diese Einstellungen korrekt für Sie konfiguriert haben!

Wie man TTFB-Probleme findet, die durch langsame Verbindungszeit verursacht werden

Um die Auswirkungen zu finden, die echte Benutzer durch Redirect erfahren, müssen Sie ein RUM-Tool wie CoreDash verwenden. Real User Monitoring lässt Sie die Core Web Vitals bis ins Detail verfolgen und ohne die 28-tägige Google-Verzögerung.

In CoreDash klicken Sie einfach auf 'Time to Fist Byte Breakdown', um den Verbindungsteil der Time to First Byte zu visualisieren.