Optimiser la durée de connexion (TCP + TLS), sous-partie du Time to First Byte

Optimiser la durée de connexion (TCP + TLS), sous-partie du Time to First Byte

Le Time to First Byte (TTFB) peut être décomposé en les sous-parties suivantes :

• Attente + Redirection (ou durée d'attente)
  
• Worker + Cache (ou durée de cache)
• DNS (ou durée DNS)
• Connexion  (ou durée de connexion)
• Requête (ou durée de requête)

Vous cherchez à optimiser le Time to First Byte ? Cet article fournit une analyse approfondie de la partie durée DNS du Time to First Byte. Si vous cherchez à comprendre ou corriger le Time to First Byte et ne savez pas ce que signifie la durée d'attente, veuillez consulter ce qu'est le Time to First Byte et corriger et identifier les problèmes de Time to First Byte avant de commencer cet article.

La partie durée de connexion du Time to First Byte consiste en un laps de temps où le navigateur se connecte au serveur web. Après cette connexion, le navigateur et le serveur ajoutent généralement une couche de chiffrement (TLS). Le processus de négociation de ces 2 connexions prendra un peu de temps et ce temps est ajouté au Time to First Byte.

Processus de connexion en détail

Le protocole de contrôle de transmission (TCP) est responsable de l'établissement d'une connexion fiable entre le client (navigateur) et le serveur. Ce processus implique une négociation en trois temps (3-way handshake) :

• Paquet SYN (Synchronize) : Le client envoie un paquet SYN au serveur pour initier la connexion et demander la synchronisation.
• Paquet SYN-ACK (Synchronize-Acknowledge) : Le serveur répond par un paquet SYN-ACK, accusant réception du paquet SYN et acceptant d'établir une connexion.
• Paquet ACK (Acknowledge) : Le client renvoie un paquet ACK au serveur, confirmant la réception du paquet SYN-ACK. À ce stade, une connexion TCP est établie, permettant le transfert fiable de données entre le client et le serveur.

TCP garantit que les données sont envoyées et reçues dans le bon ordre, renvoyant tout paquet perdu et gérant le contrôle de flux pour correspondre à la capacité du réseau.

Une fois la connexion TCP établie, le protocole TLS (Transport Layer Security) est utilisé pour sécuriser la connexion. Le handshake TLS implique plusieurs étapes pour authentifier le serveur et établir un canal de communication sécurisé :

• ClientHello : Le client envoie un message "ClientHello" au serveur, indiquant les versions TLS prises en charge, les suites de chiffrement et un nombre aléatoire (Client Random).
• ServerHello : Le serveur répond par un message "ServerHello", sélectionnant la version TLS et la suite de chiffrement dans la liste du client, et fournissant son certificat numérique et un nombre aléatoire (Server Random).
• Échange de certificat et de clé : Le serveur envoie son certificat numérique au client pour authentification. Le client vérifie le certificat auprès des autorités de certification de confiance.
• Secret pré-maître (Premaster Secret) : Le client génère un secret pré-maître, le chiffre avec la clé publique du serveur (issue du certificat) et l'envoie au serveur.
• Génération de clé de session : Le client et le serveur utilisent tous deux le secret pré-maître, ainsi que le Client Random et le Server Random, pour générer une clé de session partagée pour le chiffrement symétrique.
• Messages terminés : Le client et le serveur échangent des messages chiffrés avec la clé de session pour confirmer que le handshake a réussi et que les deux parties disposent de la bonne clé de session.

Une fois le handshake TLS terminé, le client et le serveur ont établi une connexion sécurisée et chiffrée. Cela garantit que toutes les données échangées sont protégées contre l'écoute clandestine et la falsification par des tiers.

HTTP/3 accélère les connexions TLS en s'intégrant au protocole QUIC, qui réduit le nombre d'allers-retours nécessaires pour établir une connexion sécurisée en combinant les processus de handshake en un seul, et prend en charge la reprise 0-RTT pour des reconnexions plus rapides. De plus, l'utilisation de l'UDP par QUIC élimine le blocage de tête de ligne et améliore le contrôle de congestion, conduisant à une transmission de données plus efficace et des chargements de page plus rapides.

• HTTP/3 - apporte le protocole QUIC sur UDP au lieu de TCP, permettant un transfert de données plus rapide et plus efficace
  
• TLS 1.3 Ajoute plus de sécurité et réduit les allers-retours de handshake et est requis pour la reprise de connexion 0-RTT. 
• Reprise de connexion 0-RTT - Fonctionnalité TLS 1.3 qui permet aux clients revenants d'envoyer des données chiffrées immédiatement lors de la reconnexion en réutilisant des informations précédemment échangées.
  
• TCP Fast Open. Permet d'envoyer des données dans le paquet SYN initial, réduisant le temps d'aller-retour pour le handshake TCP.
• TLS False Start - Permet l'envoi précoce de données avant que le handshake TLS ne soit terminé.
  
• Agrafage OCSP (OCSP Stapling) -  Accélère la validation du certificat en éliminant le besoin pour le client de contacter directement l'autorité de certification

Conseil Time to First Byte : non seulement un CDN offre des temps d'aller-retour plus courts, mais tirer parti d'un CDN améliorera souvent immédiatement les temps de connexion TCP et TLS car les fournisseurs de CDN premium auront correctement configuré ces paramètres pour vous !

Comment trouver les problèmes de TTFB causés par un temps de connexion lent 

Pour trouver l'impact que les vrais utilisateurs subissent à cause des redirections, vous devrez utiliser un outil RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals plus en détail et sans le délai de 28 jours de Google.

Dans CoreDash , cliquez simplement sur 'Time to First Byte breakdown' pour visualiser la partie connexion du Time to First Byte.