Performance Web – L’impact de TCP

Voici le 4e billet de la série Performance Web. Nous sommes plus ou moins à mi-chemin, et une grosse partie nous attend aujourd’hui: l’impact de TCP. Ce protocole, utilisé partout, a un fonctionnement particulier et une incidence directe sur la manière dont nous devons concevoir nos sites et applications. Objectif 1000ms !

<- Partie 3 : Indicateurs de mesure Partie 5 : A venir ->

Un peu d’histoire

On trouve 2 protocoles au coeur du fonctionnement d’Internet : TCP et IP. Les premiers travaux autour de ces protocoles ont lieu en 1974 avec la RFC 675. Il faut attendre 1984 pour voir la publication des spécifications de TCP et IP tels que nous les connaissons aujourd’hui. La v4 de ces spécifications est éditée en 2 RFC : RFC 971 (IP) et RFC 793 (TCP).

Depuis, plusieurs améliorations ont eu lieu, mais le mode de fonctionnement de base est le même. TCP est depuis le protocole de choix pour utiliser le « Web », les emails, les transferts de fichiers, etc.

TCP est un protocole qui garantit l’intégrité des données envoyées, la retransmission des données perdues.. il est optimisé pour un distribution précise et fiable des données, pas pour la rapidité du transfert.

Comment çà marche ?

Toutes les connections TCP débutent par ce qu’on appelle le « Three-Way Handshake ».

Three-way Handshake - High Performance Browser Networking, O’Reilly

Three-way Handshake – High Performance Browser Networking, O’Reilly

Nous ne détaillerons pas ici ce processus, simplifions en disant que le client et le serveur doivent se mettre d’accord sur plusieurs paramètres avant de pouvoir commencer à échanger des données. Le temps de trajet complet nécessaire à cet échange est appelé Round-Trip Time (RTT).

L’image ci-dessus illustre une négociation utilisant un protocole HTTP simple. L’utilisation d’HTTPS requiert un 2e RTT.

Quel impact ?

L’impact est très important. A chaque nouvelle connection TCP, on doit repasser par un Three-Way Handshake. Le client peut envoyer un paquet dès réception du SYN-ACK, le serveur doit, lui, attendre la réception du ACK avant de pouvoir envoyer la moindre donnée. Si on reprend l’image ci-dessus, illustrant une négociation TCP entre Londres et New-York, la moindre connection TCP coûte 56ms.

Si l’on ajoute à cela les négociations DNS, prenant en moyenne 200ms (sur desktop, parfois beaucoup plus sur mobile), on commence à voir que notre budget « temps » de 1000ms est déjà bien entamé, avant même d’avoir affiché le moindre octet à notre visiteur.

Au vu de fonctionnement de TCP, le nombre de requêtes à un impact direct sur la performance - Dareboost.com

Au vu de fonctionnement de TCP, le nombre de requêtes à un impact direct sur la performance – Dareboost.com

Le seuil des 14kb

Non, 14Kb n’est pas un magic number. Les 14 premiers kilobytes de votre site Internet sont extrèmement importants. Pourquoi ? Là encore, l’histoire de TCP va nous éclairer.

La congestion, ce fléau

Début 1984, John Nagle documente ce qu’il appelle le « congestion collapse »

[…] We have discovered that the Department of Defense’s Internet Protocol (IP), a pure datagram protocol, and Transmission Control Protocol (TCP), a transport layer protocol, when used together, are subject to unusual congestion problems caused by interactions between the transport and datagram layers.[…]

On ne rentrera pas dans le détail du pourquoi de la congestion, mais étudions son impact sur la performance. Suite à ces études, plusieurs solutions sont envisagées: Flow Control, Window Scaling…

Malgré cela, la congestion devient un réel problème vers la fin des années 1980. En 1988, 4 nouveaux algorithmes sont testés pour résoudre ce souci, par Van Jacobson and Michael J. Karels. Tous les 4 ont rapidement intégré les spécifications TCP, permettant du même coup au protocole de tenir le choc face à l’augmentation grandissante du traffic au début des années 90.

TCP Slow-start

Parmi ces protocoles, un nous intéresse particulièrement : TCP Slow-start. Afin d’éviter la congestion, une « unité » a été mise en place : la « congestion window size » (cwnd).

Congestion window size is the sender-side limit on the amount of data the sender can have in flight before receiving an acknowledgment (ACK) from the client. – High Performance Browser Networking, O’Reilly

Et pour déterminer la valeur optimale de cette fenêtre de congestion, la solution est de commencer petit, en augmentant la valeur exponentiellement au fur et à mesure de la réception des paquets.

À l’origine, la cwnd était d’1 network segment, soit 1460 bytes. Depuis avril 1999, la valeur de base est de 4 network segments, et c’est encore la valeur la plus répandue aujourd’hui. Pourtant, depuis avril 2013, le noyau 2.6.39+ (IW10) peut prendre une valeur initiale de 10 network segments, soit environ 14kb !

 

Augmentation de la fenêtre de congestion - High Performance Browser Networking, O’Reilly

Augmentation de la fenêtre de congestion – High Performance Browser Networking, O’Reilly

C’est donc dans ces fameux 14kb qu’il faut essayer de placer tout ce qui est nécessaire pour que le contenu « above the fold » (au-dessus de la ligne de flotaison) soit affiché à l’utilisateur, dès les 1res millisecondes de transfert ! (voir le CSS Critical Path dans les prochains billets)

Car l’accumulation des RTT devient vite coûteuse. Par exemple, pour atteindre un transfert de seulement 64kb entre client et serveur, il faut compter environ 224ms, hors négociation DNS et hors 3-way handshake (cwnd initiale 4 segments, RTT de 56ms Londres-New York).

Temps nécessaire pour atteindre un cwnd de taille N - High Performance Browser Networking, O’Reilly

Temps nécessaire pour atteindre un cwnd de taille N – High Performance Browser Networking, O’Reilly

Récapitulons

Négociation DNS : ~ 200ms (desktop)

3-Way Handshake HTTP : 56 ms (Londres <-> New-York)

Transfert de 30kb de datas (cwnd initiale 4 segments. 1+2+4+8+16) : ~110ms

Soit près d’1/2 seconde pour recevoir une trentaine de kilobytes..

Principaux temps de latence, fibre. - High Performance Browser Networking, O’Reilly

Principaux temps de latence, fibre. – High Performance Browser Networking, O’Reilly

Il est donc absolument capital de réduire le nombre de requêtes nécessaire à l’affichage du contenu de nos sites web, pour améliorer l’expérience utilisateur. Car contrairement à ce que l’on pourrait croire, l’amélioration de la bande passante n’a que très peu d’effet sur ce mécanisme. La réception de la très grande majorité des ressources d’un site web est « Latency related ».

Temps de latence vs bande passante

La performance de nos sites est intimement liée au temps de latence. Le transfert des ressources est limité par les RTT effectuées.

Et augmenter la bande passante n’a plus d’effet :

Effet de la latence et de la bande passante sur le temps de chargement - High Performance Browser Networking, O’Reilly

Effet de la latence et de la bande passante sur le temps de chargement – High Performance Browser Networking, O’Reilly

Comme on le voit, seul le passage d’un débit de 1Mbps à 2Mbps a un impact significatif sur le temps de chargement d’une page. En revanche, l’impact d’une diminution du temps de latence est flagrant. De fait, une réduction de RTT de 150ms à 100ms serait plus efficace qu’une augmentation de BP de 4Mbps à 10Mbps, voire même à 1Gbps.

L »impact du temps de latence est faible lorsque l’on streame une vidéo par exemple. En quelques centaines de millisecondes (ou même secondes), on atteindra la cwnd optimale et la bande passante pourra entrer en jeu.

Mais nos sites web et applications ne sont pas constitués de gros fichiers. C’est une multitude de ressources (html, js, css, images, fonts, API tierce, etc.) qui se succèdent pour offrir votre contenu au visiteur.

Maintenant que nous avons vu comment mesurer la performance, et pris en compte les impondérables liés à la technologie sur laquelle repose le Web nous verrons, dans les prochains billets, quels sont les leviers à notre disposition pour rendre nos sites web plus performants.

Ah, au fait, vous vous demandez pourquoi je parle d’un objectif de 1000ms ?

Délai et perception utilisateur -  - High Performance Browser Networking, O’Reilly

Délai et perception utilisateur – High Performance Browser Networking, O’Reilly

<- Partie 3 : Indicateurs de mesure Partie 5 : A venir ->

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *