Le but principal de SPDY est d’améliorer les capacités du protocole HTTP, c’est-à-dire de réduire la latence des échanges HTTP entre le client et le serveur (= réduire la durée de téléchargement des pages Web).
En effet, Google part de la constatation suivante pour le développement de SPDY : le HTTP n’a pas été conçu au départ pour réduire la latence. En plus de cela, le Web a énormément évolué depuis la création de HTTP et les pages sont aujourd’hui très différentes (inclusion de styles CSS, de médias, de fichiers JavaScript, etc.) et le HTTP ne s’est pas bien adapté à tous ces changements.
Parmi les facteurs limitant la performance, il est notamment cité que HTTP/1 ne peut extraire qu’une ressource à la foi ce qui entraine à priori de gros problèmes de latente due aux nombreux aller-retours client / serveur nécessaires pour récupérer les différentes ressources d’une page. Les navigateurs contournent ce problème en utilisant plusieurs connexions mais cela reste non optimal.
En plus de cela, avec HTTP, seul le client peut initier une demande. Même si le serveur sait que le client a besoin d’une ressource, il n’a aucun mécanisme pour informer le client et doit plutôt attendre de recevoir une demande de la ressource du client.
En outre, le HTTP/1 ne possède pas de mécanisme de compression des en-têtes et certains en-têtes sont renvoyés plusieurs fois dans différentes requêtes ce qui augmente inutilement le poids de chaque requête.
SPDY a pour but de s’attaquer à ces problèmes en fournissant des solutions d’optimisation au-dessus de HTTP. Les principales techniques utilisées sont :
- La compression des en-têtes HTTP ;
- La pré-lecture des requêtes ;
- La priorisation des requêtes ;
- Le multiplexage.
SPDY utilise des techniques de compression des en-tête HTTP. En plus de cela, SPDY conserve une liste des en-têtes HTTP déjà envoyés durant une session afin de ne pas les renvoyer inutilement.
SPDY permet également à certains serveurs d’effectuer une pré-lecture / de deviner que certaines ressources vont être nécessaires au client et de les envoyer avant même que le client n’envoie une requête. Par exemple, si un client demande au fichier HTML qui contient des liens vers des feuilles de style CSS, un serveur SPDY pourrait analyser le code HTML, et envoyer le CSS sans attendre que le demande.
HTTP/1 gère des connexions parallèles de manière limitée (entre 6 et 8 selon le navigateur). Si les connexions sont plus nombreuses, il faudra attendre que les connexions précédentes soient résolues. SPDY permet de contourner cette limitation en utilisant des flux hiérarchisés de façon à ce que les requête les plus importantes soient résolues en premier.
SPDY permet aussi le multiplexage qui permet également de résoudre le problème des connexions parallèles limitées. Le multiplexage correspond à la combinaison de nombreux signaux en un seul : un navigateur utilisant SPDY va combiner plusieurs requêtes en une seule qui va être envoyée au serveur. Le serveur va ensuite décomposer cette requête pour récupérer l’ensemble des requêtes originales combinées. C’est ce qu’on appelle le démultiplexage.
Dès 2012, Google se rapproche de l’IETF (le groupe responsable du développent de HTTP entre autres) afin que SPDY soit standardisé. SPDY est intégré dans HTTP/2 dès sa sortie (en mai 2015) et Google abandonne donc le développement du protocole, laissant son évolution à l’IETF.