En juin 2009, des ingénieurs de Google expliquaient que beaucoup des protocoles de l'Internet ont été développés à une époque où la connexion bas-débit prédominait. Ces derniers ne sont donc pas optimisés pour les lignes ADSL d'aujourd'hui. La société souhaitait ainsi former un groupe de travail planchant sur les protocoles HTTP et TCP/IP.
En novembre 2009, Google présentait ainsi SPDY, un protocole de transfert sur Internet qui serait deux fois plus rapide que le traditionnel HTTP. Contrairement au protocole HTTP qui envoie chacune des requêtes pour l'ensemble des éléments de la page (feuille de style, images, JavaScript) SPDY les compresse toutes en amont. Il en résulterait un gain de temps moyen de 55%.
L'ingénieur Yuchung Cheng s'intéresse cette fois au TCP. A l'heure actuelle, afin de contourner les limitations du protocole TCP, le navigateur web ouvre plusieurs connexions parallèles ; un mécanisme qui résulterait cependant en plusieurs temps de latence. Lorsqu'une nouvelle connexion est effectuée, la machine procède à l'envoi de trois paquets pour vérifier cette dernière et garantir la communication avec serveur. Google propose d'augmenter ce nombre de paquets à 10 afin d'envoyer immédiatement une requête HTTP complète, laquelle pourra être exécutée sans devoir attendre un retour de confirmation de la part du serveur.
Au sein du mécanisme permettant de contrôler la congestion du réseau, par défaut, le port TCP attend 3 secondes la confirmation du serveur. Si aucun retour n'est effectué, les données transmises sont considérées comme perdues et une requête est à nouveau envoyée pour récupérer celles-ci. Google explique que ce temps d'attente était justifié à l'époque de l'Internet bas-débit et souhaite diminuer celui-ci à 1 seconde.
M. Cheng propose également l'adoption de l'algorithme Proportional Rate Reduction (PPR). Actuellement, en cas de réseau saturé et de perte de données lors d'une transmission, celles-ci sont retransmises plus lentement pour permettre de récupérer les pertes. PPR permet pour sa part d'ajuster automatiquement la vitesse de cette nouvelle transmission en fonction de la perte des données. L'algorithme est déjà embarqué au sein du kernel de Linux et est en passe d'être standardisé par l'IETF.
Reste à savoir si ces propositions permettront de mettre à niveau le protocole TCP pour répondre aux besoins d'aujourd'hui. Davantage d'informations sont diponibles sur cette page.
