diff --git a/fr/README.md b/fr/README.md index 37b2dcd..98b9728 100644 --- a/fr/README.md +++ b/fr/README.md @@ -13,6 +13,6 @@ CONTRIBUTIONS ------------- J'encourage et apprécie l'aide et les contributions de chaque personne qui désire apporter des améliorations. Nous acceptons les [pull -requests](https://github.com/bagder/http2-explained/pulls), mais vous pouvez également simplement créer un [ticket](https://github.com/bagder/http2-explained/issues) ou encore envoyer un courriel à daniel-http2@haxx.se avec vos suggestions! +requests](https://github.com/bagder/http2-explained/pulls), mais vous pouvez également simplement créer un [ticket](https://github.com/bagder/http2-explained/issues) ou encore envoyer un courriel à daniel-http2@haxx.se avec vos suggestions ! / Daniel Stenberg diff --git a/fr/part1.md b/fr/part1.md index 0efa614..99956f9 100644 --- a/fr/part1.md +++ b/fr/part1.md @@ -6,11 +6,11 @@ La RFC 7540 est le nom officiel de la spécification http2 finale, elle a été Toute erreur dans ce document est mienne et le résultat de mes approximations. Merci de me les indiquer afin que je les corrige pour les prochaines versions. -Dans ce document, j'ai essayé d'utiliser le terme "http2" pour décrire le nouveau protocole en termes purement techniques, le nom officiel est HTTP/2. J'ai fait ce choix pour améliorer la fluidité de lecture et obtenir une meilleure lisibilité. +Dans ce document, j'ai essayé d'utiliser le terme "http2" pour décrire le nouveau protocole alors que techniquement le nom officiel est HTTP/2. J'ai fait ce choix pour améliorer la fluidité de lecture et obtenir une meilleure lisibilité. ## 1.1 Auteur -Mon nom est Daniel Stenberg et je travaille chez Mozilla. J'ai travaillé dans l'open source et la réseautique, depuis plus de 20 ans, sur de nombreux projets. Je suis plus connu peut-être en tant que développeur principal de curl et libcurl. J'ai été impliqué dans le groupe de travail de l'IETF HTTPbis pendant plusieurs années où j'ai maintenu à jour les spécifications HTTP 1.1 et participé à la standardisation de http2. +Mon nom est Daniel Stenberg. J'ai travaillé dans l'open source et la réseautique, depuis plus de 20 ans, sur de nombreux projets. Je suis peut-être surtout connu en tant que développeur principal de curl et libcurl. J'ai été impliqué dans le groupe de travail de l'IETF HTTPbis pendant plusieurs années où j'ai maintenu à jour les spécifications HTTP 1.1 et participé à la standardisation de http2. Email: daniel@haxx.se @@ -20,9 +20,9 @@ Mon nom est Daniel Stenberg et je travaille chez Mozilla. J'ai travaillé dans l Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) -## 1.2 Aide! +## 1.2 Aide ! -Si vous trouvez des erreurs, oublis, fautes ou mensonges éhontés dans ce document, je vous prierais de bien vouloir m'envoyer une version corrigée que je publierai dans une édition révisée. Je mentionnerai clairement les noms des contributeurs! J'espère améliorer ce document avec le temps. +Si vous trouvez des erreurs, oublis, fautes ou mensonges éhontés dans ce document, je vous prierais de bien vouloir m'envoyer une version corrigée que je publierai dans une édition révisée. Je mentionnerai clairement les noms des contributeurs ! J'espère améliorer ce document avec le temps. Ce document est disponible ici: [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) @@ -54,14 +54,14 @@ La première édition de ce document fut publiée le 25 avril 2014. Voici les ch ### Version 1.11 : -- Nombreuses améliorations de style linguistique (Note du traducteur: en anglais) +- Nombreuses améliorations de style linguistique (Note du traducteur : en anglais) - 8.3.1: Mention des développements spécifiques nginx et Apache httpd ### Version 1.10 : - 1: Le protocole est "presque approuvé" -- 4.1: Rafraîchissement du style linguistique (Note traducteur: en anglais) -- Converture: ajout de l'image et légende "http2 explained", lien corrigé +- 4.1: Rafraîchissement du style linguistique (Note traducteur : en anglais) +- Converture : ajout de l'image et légende "http2 explained", lien corrigé - 1.4: Ajout de la section "Historique" - Diverses corrections orthographiques - 14: Ajout de remerciements pour les contributeurs @@ -78,4 +78,4 @@ La première édition de ce document fut publiée le 25 avril 2014. Voici les ch - 8.5: Ajout des chiffres d'utilisation - 8.3: Mention d'Internet Explorer - 8.3.1: Ajout des "implémentations manquantes" -- 8.4.3: Mention que TLS améliore le taux de réussite \ No newline at end of file +- 8.4.3: Mention que TLS améliore le taux de réussite diff --git a/fr/part10.md b/fr/part10.md index a427ba3..5f51bf6 100644 --- a/fr/part10.md +++ b/fr/part10.md @@ -2,14 +2,15 @@ L'équipe Chromium a implémenté http2 depuis un certain temps via les canaux beta et dev. Depuis Chrome 40, sorti le 27 janvier 2015, http2 est activé par défaut pour un certain nombre d'utilisateurs. Ce nombre a commencé petit pour devenir important au fil du temps. -Le support SPDY sera retiré. Dans un blog, il est annoncé en [février 2015](https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html): +Le support de SPDY a été retiré dans Chrome 51, au profit de http2. Dans un blog, il est annoncé en [février 2016](https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html) : -> “Chrome supporte SPDY depuis Chrome 6, mais comme les bénéfices sont présents -dans HTTP/2, il est temps de lui dire au revoir. Le support SPDY sera retiré début 2016.” +> “Plus de 25% des ressources dans Chrome sont actuellement délivrées en HTTP/2, contre moins de 5% pour SPDY. Vu ces chiffres, Chrome ne supportera plus SPDY à partir du 15 mai, date anniversaire du RFC HTTP/2.” ## 10.1. Assurez-vous de l'activer -Allez sur "chrome://flags/#enable-spdy4" dans la barre d'URL et cliquez sur "enable" si ce n'est déjà fait. +Si vous utilisez une version de Chrome très ancienne, vous pouvez vérifier si http2 est géré. + +Allez sur "chrome://flags/#enable-spdy4" dans la barre d'URL et cliquez sur "enable" si ce n'est déjà fait. Dans les versions récentes http2 est activé d'office et ce réglage a été retiré. ## 10.2. TLS uniquement @@ -17,8 +18,8 @@ Souvenez-vous que Chrome n'implémente http2 que sur TLS. Vous ne verrez du http ## 10.3. Voir l'utilisation http2 -Il existe des plug-ins Chrome permettant de visualiser si un site utilise http2. En voici un: [“SPDY Indicator”](https://chrome.google.com/webstore/detail/spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin). +Il existe des plug-ins Chrome permettant de visualiser si un site utilise http2. En voici un : [“SPDY Indicator”](https://chrome.google.com/webstore/detail/spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin). ## 10.4. QUIC -Les tests QUIC en cours masquent un peu les résultats HTTP/2. (voir chapitre 12.1) \ No newline at end of file +Les tests QUIC en cours masquent un peu les résultats HTTP/2. (voir chapitre 12.1) diff --git a/fr/part11.md b/fr/part11.md index 8858e3d..8780e87 100644 --- a/fr/part11.md +++ b/fr/part11.md @@ -4,7 +4,7 @@ Le [projet curl](https://curl.haxx.se/) a fourni un support http2 expérimental Dans l'esprit curl, nous voulons supporter toutes les fonctionnalités http2 possibles. curl est souvent utilisé comme outil de test et nous voulons que ce soit le cas pour http2 également. -curl utilise une librairie distincte [nghttp2](https://nghttp2.org/) pour la couche http2. curl requiert nghttp2 1.0 ou plus. +curl utilise une bibliothèque distincte [nghttp2](https://nghttp2.org/) pour la couche http2. curl requiert nghttp2 1.0 ou plus. Notez qu'actuellement, sous linux, curl et libcurl ne sont pas toujours délivrés avec le support du protocole HTTP/2 activé. @@ -16,28 +16,28 @@ En interne, curl convertit les en-têtes entrant http2 en en-têtes du style HTT curl supporte http2 sur TCP via l'en-tête Upgrade:. Si vous initiez une requête HTTP en demandant HTTP 2, curl demandera au serveur de mettre à niveau (Upgrader) sa connexion en http2. -## 11.3. Quelles librairies TLS ? +## 11.3. Quelles bibliothèques TLS ? -curl supporte différentes librairies TLS et c'est toujours valide pour http2. La difficulté avec TLS et http2 est le support de ALPN et potentiellement NPN. +curl supporte différentes bibliothèques TLS et c'est toujours valide pour http2. La difficulté avec TLS et http2 est le support de ALPN et potentiellement NPN. Compilez curl avec des versions récentes d'OpenSSL ou NSS pour avoir ALPN et NPN. Avec GnuTLS et PolarSSL vous n'aurez que ALPN et pas NPN. ## 11.4. Ligne de commande à utiliser -Pour indiquer à curl d'utiliser http2, en clair ou TLS, utilisez l'option `--http2` ("tiret tiret http2"). curl utilise HTTP/1.1 par défaut, d'où cette option nécessaire pour http2. +Pour indiquer à curl d'utiliser http2, en clair ou avec TLS, utilisez l'option `--http2` ("tiret tiret http2"). curl utilise HTTP/1.1 par défaut pour les URL en HTTP: donc cette option est nécessaire si vous voulez utiliser http2 en clair. Pour les URL en HTTPS:, curl essaiera http2. ## 11.5. Options libcurl ### 11.5.1 Activez HTTP/2 -Votre application utilisera http:// ou https:// comme d'habitude, mais vous pouvez régler la variable curl_easy_setopt de `CURLOPT_HTTP_VERSION` vers `CURL_HTTP_VERSION_2` pour que libcurl tente d'utiliser http2. Il le fera en best effort sinon utilisera HTTP 1.1. +Votre application utilisera http:// ou https:// comme d'habitude, mais vous pouvez régler la variable curl_easy_setopt de `CURLOPT_HTTP_VERSION` vers `CURL_HTTP_VERSION_2` pour que libcurl tente d'utiliser http2. Il le fera si possible sinon utilisera HTTP 1.1. ### 11.5.2 Multiplexage Etant donné que libcurl essaye de maintenir ses anciens comportements dans la mesure du possible, vous devez activer le multiplexage HTTP/2 pour votre application via l'option [CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Sinon elle continuera à utiliser une requête à la fois par connexion. -Un autre détail à garder à l'esprit et que si vous demandez plusieurs transferts en simultanés à libcurl, en utilisant son interface multi, une application peut très bien commencer autant de transfert que voulu, et que si vous préférez que libcurl attende un peu pour les placer tous sur la même connexion, plutôt que d'ouvrir une connexion pour chacun, utilisez l'option [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) pour chaque transfert que vous préférez attendre. +Un autre détail à garder à l'esprit est que si vous demandez plusieurs transferts simultanés à libcurl, en utilisant son interface multi, une application peut très bien commencer autant de transfert que voulu, et que si vous préférez que libcurl attende un peu pour les placer tous sur la même connexion, plutôt que d'ouvrir une connexion pour chacun, utilisez l'option [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) pour chaque transfert que vous préférez attendre. ### 11.5.3 Server push -libcurl 7.44.0 et plus supporte le server push de HTTP/2. Vous pouvez tirez des avantages de cette fonctionnalité en configurant un callback de push avec l'option [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Si le push est accepté par l'application, il créera un nouveau transfert en tant que CURL easy handle et l'utilisera pour délivrer le contenu, comme tout autre transfert. \ No newline at end of file +libcurl 7.44.0 et plus supporte le server push de HTTP/2. Vous pouvez tirez avantage de cette fonctionnalité en configurant un callback de push avec l'option [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Si le push est accepté par l'application, il créera un nouveau transfert en tant que CURL easy handle et l'utilisera pour délivrer le contenu, comme tout autre transfert. diff --git a/fr/part12.md b/fr/part12.md index d0a1f51..5e7fefa 100644 --- a/fr/part12.md +++ b/fr/part12.md @@ -12,4 +12,4 @@ Le protocole [QUIC](https://www.chromium.org/quic) (Quick UDP Internet Connectio QUIC permet la création de connexions avec moins de latence, il résout la perte de paquet en ne bloquant qu'un flux particulier au lieu de tous les flux en HTTP/2 et il permet d'établir des connexions à travers différentes interfaces réseau, et du coup, couvre des problématiques que MPTCP résout. -QUIC est pour l'instant uniquement disponible à travers Chrome et les serveurs Google et le code n'est pas facilement réutilisable, même s'il existe une [libquic](https://github.com/devsisters/libquic) pour ce faire justement. Le protocole a été soumis en tant que [draft](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) à l'IETF transport working group. \ No newline at end of file +QUIC est pour l'instant uniquement disponible à travers Chrome et les serveurs Google et le code n'est pas facilement réutilisable, même s'il existe une [libquic](https://github.com/devsisters/libquic) pour ce faire justement. Le protocole a été soumis en tant que [draft](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) au groupe de travail transport de l'IETF. diff --git a/fr/part13.md b/fr/part13.md index 21aaca7..906d802 100644 --- a/fr/part13.md +++ b/fr/part13.md @@ -1,6 +1,6 @@ # 13. Lecture complémentaire -Si vous pensez que ce document était léger en contenu ou détails techniques, voici quelques ressources pour satisfaire votre curiosité: +Si vous pensez que ce document était léger en contenu ou détails techniques, voici quelques ressources pour satisfaire votre curiosité : - La mailing-list HTTPbis et ses archives : https://lists.w3.org/Archives/Public/ietf-http-wg/ @@ -12,4 +12,4 @@ Si vous pensez que ce document était léger en contenu ou détails techniques, - Les sites web http2: https://http2.github.io/ et en particulier la FAQ : https://http2.github.io/faq/ -- Le chapitre de Ilya Grigorik sur HTTP/2 dans son livre “High Performance Browser Networking”: https://hpbn.co/http2/ \ No newline at end of file +- Le chapitre de Ilya Grigorik sur HTTP/2 dans son livre “High Performance Browser Networking” : https://hpbn.co/http2/ diff --git a/fr/part14.md b/fr/part14.md index 15d18ce..3f40bd3 100644 --- a/fr/part14.md +++ b/fr/part14.md @@ -8,8 +8,8 @@ Le graphique RTT (Aller-Retour) vient des présentations de Mike Belshe. Mes enfants Agnès et Rex pour m'avoir prêté leurs Lego. -Merci à mes amis pour les relectures et commentaires : Kjell Ericson, Bjorn Reese, Linus Swalas et Anthony Bryan. Votre aide est appréciée et a réellement amélioré ce document! +Merci à mes amis pour les relectures et commentaires : Kjell Ericson, Bjorn Reese, Linus Swalas et Anthony Bryan. Votre aide est appréciée et a réellement amélioré ce document ! -Pendant les diverses itérations du document, les personnes suivantes ont fourni ou suggéré des améliorations: Mikael Olsson, Remi Gacogne, Benjamin Kircher, saivlis, florinandrei-tp, Brett Anthoine, Nick Parlante, Matthew King, Nicolas Peels, Jon Forrest, sbrickey, Marcin Olak, Gary Rowe, Ben Frain, Mats Linander, Raul Sile, Alex Lee et Richard Moore. +Pendant les diverses itérations du document, les personnes suivantes ont fourni ou suggéré des améliorations : Mikael Olsson, Remi Gacogne, Benjamin Kircher, saivlis, florinandrei-tp, Brett Anthoine, Nick Parlante, Matthew King, Nicolas Peels, Jon Forrest, sbrickey, Marcin Olak, Gary Rowe, Ben Frain, Mats Linander, Raul Sile, Alex Lee et Richard Moore. Le traducteur de cette version française, Olivier Cahagne, souhaite remercier Luc Trudeau, Mehdi Achour, Pascal Borreli et Remi Gacogne pour leurs relectures, nombreuses corrections et suggestions. diff --git a/fr/part2.md b/fr/part2.md index 74b715e..a5b7bff 100644 --- a/fr/part2.md +++ b/fr/part2.md @@ -40,7 +40,7 @@ D'autres usages qui nécessitent une latence faible sont certains types de vidé ## 2.6. Blocage en tête de file (Head-of-line blocking) -Le pipelining HTTP est une manière d'envoyer une requête additionnelle sans attendre la réponse de la requête précédente. C'est semblable à la file d'attente d'une caisse à la banque ou au supermarché. Vous ne savez pas si le client vous précédant est rapide ou s'il s'agit d'une personne qui prendra son temps. Ce phénomène décrit parfaitement le : “head-of-line blocking”. +Le pipelining HTTP est une manière d'envoyer une requête additionnelle sans attendre la réponse de la requête précédente. C'est semblable à la file d'attente d'une caisse à la banque ou au supermarché. Vous ne savez pas si le client vous précédant est rapide ou s'il s'agit d'une personne qui prendra son temps. Ce phénomène décrit parfaitement le “head-of-line blocking”. diff --git a/fr/part4.md b/fr/part4.md index d503f41..ed114dd 100644 --- a/fr/part4.md +++ b/fr/part4.md @@ -1,6 +1,6 @@ # 4. Mettre à jour HTTP -Ce serait sympa d'améliorer ce protocole, n'est-ce pas ? Notamment: +Ce serait sympa d'améliorer ce protocole, n'est-ce pas ? Notamment : 1. Un protocole moins sensible au RTT (Round Trip Time, Aller-Retours) 2. En corrigeant le pipelining et le head of line blocking @@ -10,11 +10,11 @@ Ce serait sympa d'améliorer ce protocole, n'est-ce pas ? Notamment: ## 4.1. IETF et le groupe de travail HTTPbis -L'IETF (Internet Engineering Task Force) est une organisation qui développe et promeut les standards de l'Internet, et ce essentiellement au niveau protocolaire. Très connue pour la série de RFC documentant tout depuis TCP, DNS, FTP, HTTP aux bonnes pratiques en passant par des variantes de protocoles qui n'ont jamais vu le jour. +L'IETF (Internet Engineering Task Force) est une organisation qui développe et promeut les standards de l'Internet, et ce essentiellement au niveau protocolaire. Elle est très connue pour la série de RFC documentant tout depuis TCP, DNS, FTP, HTTP aux bonnes pratiques en passant par des variantes de protocoles qui n'ont jamais vu le jour. Au sein de l'IETF existent des groupes de travail se penchant sur un sujet bien établi avec des objectifs précis. Ils établissent une charte qui définit les règles et limitations liées à l'objectif. Toute personne intéressée peut se joindre aux discussions et au développement, et chaque participant bénéficie du même droit de parole et du même poids que les autres. Peu d'importance est apportée aux sociétés pour lesquelles les participants travaillent (le cas échéant). -Le groupe de travail HTTPbis (voir plus tard pour l'origine du nom) a été créé à l'été 2007 et chargé de mettre à jour la spécification HTTP 1.1. Des discussions sur une nouvelle version de HTTP ont réellement commencé fin 2012. La mise à jour HTTP 1.1 s'est terminée début 2014 avec la série des [RFC 7320](https://tools.ietf.org/html/rfc7320). +Le groupe de travail HTTPbis (voir plus tard pour l'origine du nom) a été créé à l'été 2007 et chargé de mettre à jour la spécification HTTP 1.1. Des discussions sur une nouvelle version de HTTP ont réellement commencé fin 2012. La mise à jour de HTTP 1.1 s'est terminée début 2014 avec la série des [RFC 7230](https://tools.ietf.org/html/rfc7230). La réunion finale d'interopérabilité pour le groupe de travail HTTPbis s'est tenue à New York en juin 2014. Toutefois les discussions en suspens et les procédures IETF nécessaires pour obtenir la RFC officielle continueront jusque l'année suivante. diff --git a/fr/part5.md b/fr/part5.md index 218bc16..c221575 100644 --- a/fr/part5.md +++ b/fr/part5.md @@ -20,7 +20,7 @@ Elles sont plutôt strictes avec des contraintes. Comme mentionné, les formats d'URL existants ne peuvent pas être modifiées, http2 doit donc gérer les URI actuelles. Comme elles sont déjà utilisées en HTTP 1.x, on doit pouvoir mettre à niveau (“upgrader”) le protocole vers http2 ou demander au serveur d'utiliser http2 plutôt que les anciens protocoles. -HTTP 1.1 a défini un moyen de le faire, l'en-tête Upgrade:, qui permet au serveur de renvoyer une réponse avec le nouveau protocole quand la requête était envoyée avec un protocole plus ancien. Au prix d'un aller-retour (round-trip). +HTTP 1.1 a un moyen de le faire, l'en-tête Upgrade:, qui permet au serveur de renvoyer une réponse avec le nouveau protocole quand la requête était envoyée avec un protocole plus ancien, au prix d'un aller-retour (round-trip) supplémentaire. Le coût de cet aller-retour n'est pas quelque chose que l'équipe SPDY allait tolérer. Comme ils n'implémentaient SPDY qu'au dessus de TLS, ils ont développé une extension TLS permettant de raccourcir la négociation de façon drastique. Cette extension, appelée NPN pour Next Protocol Negotiation, permet au serveur d'indiquer au client quels protocoles il connaît, celui-ci choisissant alors d'utiliser celui qu'il préfère. @@ -30,15 +30,15 @@ Une attention particulière a été portée au bon fonctionnement du protocole h Les motivations pour imposer TLS impliquent le respect de la vie privée et les mesures montrant que le nouveau protocole avait plus de chances de succès avec TLS. En effet, il est couramment répandu que tout ce qui passe sur le port TCP 80 est du HTTP 1.1 et pas mal d'intermédiaires réseau interfèrent ou cassent le trafic quand d'autres protocoles sont utilisés. -Le sujet TLS obligatoire a causé pas mal d'agitation dans les meetings et mailing-list, est-ce bien ou mal ? C'est une question typiquement empoisonnée, attention quand vous abordez ce sujet avec un membre du groupe! +Le sujet TLS obligatoire a causé pas mal d'agitation dans les meetings et mailing-list, est-ce bien ou mal ? C'est une question très controversée, attention quand vous abordez ce sujet avec un membre du groupe ! De même, il y eut un long débat pour savoir si http2 devrait forcer une liste obligatoire d'algorithmes de chiffrement (ciphers en anglais) avec TLS, ou en bloquer certains ou encore laisser cette tâche au groupe de travail TLS. La spécification indique finalement la version minimale TLS à utiliser, 1.2, et une restriction sur les algorithmes à utiliser. ## 5.3. Négociation http2 en TLS -Next Protocol Negotiation (NPN) est le protocole utilisé pour négocier l'usage de SPDY avec les serveurs TLS. Ce n'était pas un protocole standardisé, après passage à l'IETF, il devint ALPN: Application Layer Protocol Negotiation. ALPN est promu pour son utilisation en http2, tandis que les clients et serveurs SPDY continuent d'utiliser NPN. +Next Protocol Negotiation (NPN) est le protocole utilisé pour négocier l'usage de SPDY avec les serveurs TLS. Ce n'était pas un protocole standardisé, après passage à l'IETF, il devint ALPN : Application Layer Protocol Negotiation. ALPN est promu pour son utilisation en http2, tandis que les clients et serveurs SPDY continuent d'utiliser NPN. -Le fait que NPN arriva en premier et que la standardisation d'ALPN prit du temps, eut la conséquence d'avoir des clients et serveurs http2 implémentant les deux extensions pour négocier http2. Puisque NPN est utilisé dans SPDY et que de nombreux serveurs offrant SPDY et http2, supporter à la fois NPN et ALPN fait sens. +Le fait que NPN arriva en premier et que la standardisation d'ALPN prit du temps eut la conséquence d'avoir des clients et serveurs http2 implémentant les deux extensions pour négocier http2. Puisque NPN est utilisé dans SPDY et que de nombreux serveurs offrent SPDY et http2, supporter à la fois NPN et ALPN fait sens. ALPN diffère de NPN sur qui décide du protocole à utiliser. Avec ALPN, le client indique au serveur la liste des protocoles et ses préférences, le serveur obtient le dernier mot. Au contraire avec NPN, c'est le client qui impose son choix. @@ -46,4 +46,6 @@ ALPN diffère de NPN sur qui décide du protocole à utiliser. Avec ALPN, le cli Comme indiqué précédemment, en HTTP 1.1 et en clair, la façon de négocier du http2 est de le demander au serveur avec l'en-tête Upgrade:. Si le serveur parle http2, il répond avec le code "101 Switching" et passe en http2 pour cette connexion. Bien que cette procédure d'upgrade coûte un aller-retour réseau, elle peut être conservée et réutilisée de manière bien plus efficace qu'une connexion HTTP1, amortissant ainsi le coût initial. -Même si certains porte-paroles de navigateurs ont indiqué qu'ils n'implémenteraient pas cette méthode, l'équipe d'Internet Explorer le fera, et curl la supporte déjà. +Même si certains porte-paroles de navigateurs ont indiqué qu'ils n'implémenteraient pas cette méthode, l'équipe d'Internet Explorer a indiqué qu'elle le ferait -- mais ne l'a jamais fait. curl et quelques autres clients savent gèrer http2 en clair. + +Aujourd'hui, aucun des navigateurs majeurs ne gère http2 sans TLS. diff --git a/fr/part6.md b/fr/part6.md index f1f60a6..3cd3aba 100644 --- a/fr/part6.md +++ b/fr/part6.md @@ -1,6 +1,6 @@ # 6. Le protocole http2 -Assez sur la gestation et la politique qui nous ont mené ici. Plongeons dans les spécificités du protocole: les détails et concepts qui font http2. +Assez sur la gestation et la politique qui nous ont menés ici. Plongeons dans les spécificités du protocole : les détails et concepts qui font http2. ## 6.1. Binaire @@ -10,9 +10,9 @@ Posons-nous un moment. Si vous avez déjà travaillé sur des choix de protocole http2 est binaire pour rendre le découpage (framing en anglais) plus simple. Trouver le début et la fin d'une trame en HTTP 1.1 et dans les protocoles textuels en général est toujours très compliqué. En évitant les blancs optionnels et les diverses façons d'écrire la même chose, les implémentations sont plus simples. -De plus, cela permet de séparer plus nettement les parties du protocole et le découpage. Ce manque de séparation nette a toujours été perturbant avec HTTP1. +De plus, cela permet de séparer plus nettement le protocole proprement dit du découpage. Ce manque de séparation nette a toujours été perturbant avec HTTP1. -Le fait que le protocole utilise la compression et TLS diminue la valeur ajoutée de garder du texte pur puisqu'on ne verra pas de texte en clair passer de tout façon. Nous devons simplement nous habituer à utiliser un analyseur de trafic type Wireshark pour comprendre exactement ce qu'il passe au niveau protocolaire http2. +Le fait que le protocole utilise la compression et TLS diminue la valeur ajoutée de garder du texte pur puisqu'on ne verra pas de texte en clair passer de tout façon. Nous devons simplement nous habituer à utiliser un analyseur de trafic type Wireshark pour comprendre exactement ce qu'il se passe au niveau protocolaire http2. Débugger ce protocole se fera du coup probablement via des outils type curl ou le dissecteur http2 de Wireshark. @@ -20,24 +20,24 @@ Débugger ce protocole se fera du coup probablement via des outils type curl ou -http2 envoit des trames binaires. Il y a différentes types de trames envoyées et elles ont toutes le même format: +http2 envoie des trames binaires. Il y a différents types de trames envoyées et elles ont toutes le même format : Longueur, Type, Flags, Identifiant de Flux (Stream ID) et contenu (payload). -Il y a dix trames différentes définies dans la spec http2 et deux sont fondamentales car répliquent le fonctionnement HTTP 1.1 avec DATA (données ou contenu) et HEADERS (en-tête). Je décris ces trames plus en détail par la suite. +Il y a dix trames différentes définies dans la spec http2 et deux sont fondamentales car elles répliquent le fonctionnement de HTTP 1.1 avec DATA (données ou contenu) et HEADERS (en-tête). Je décris ces trames plus en détail par la suite. ## 6.3. Multiplexage de flux -L'identifiant de flux (Stream Identifier) mentionné dans le chapitre précédent permet d'associer à chaque trame http2 un "flux" (stream). Un flux est une association logique: une séquence indépendante et bidirectionnelle de trames échangées entre un client et un serveur via une connexion http2. +L'identifiant de flux (Stream Identifier) mentionné dans le chapitre précédent permet d'associer à chaque trame http2 un "flux" (stream). Un flux est une association logique : une séquence indépendante et bidirectionnelle de trames échangées entre un client et un serveur via une connexion http2. Une seule connexion http2 peut contenir plusieurs flux simultanés, avec chaque extrémité de la connexion pouvant entrelacer les flux. Les flux sont établis et utilisés unilatéralement ou de concert par le client ou le serveur. Ils peuvent être terminés par l'un ou l'autre côté de la connexion. L'ordre d'envoi des trames dans un flux est important. Le traitement des trames reçues se fait dans l'ordre de réception. -Multiplexer des flux implique que des groupes de trames sont mélangés (ou “mixés”) sur une même connexion. Deux (ou plusieurs) trains de données sont fusionnés en un seul puis scindés à nouveau à la réception. Voici deux trains: +Multiplexer des flux implique que des groupes de trames sont mélangés (ou “mixés”) sur une même connexion. Deux (ou plusieurs) trains de données sont fusionnés en un seul puis séparés à nouveau à la réception. Voici deux trains : ![un train](https://raw.githubusercontent.com/bagder/http2-explained/master/images/train-justin.jpg) ![un autre train](https://raw.githubusercontent.com/bagder/http2-explained/master/images/train-ikea.jpg) -Ils sont mélangés l'un dans l'autre sur la même connexion via multiplexage: +Ils sont mélangés l'un dans l'autre sur la même connexion par le multiplexage : ![multiplexed train](https://raw.githubusercontent.com/bagder/http2-explained/master/images/train-multiplexed.jpg) @@ -51,9 +51,9 @@ En utilisant la trame PRIORITY, un client peut indiquer au serveur quel autre fl Les priorités peuvent changer dynamiquement, ce qui permettra aux navigateurs d'indiquer quelles images sont importantes quand on fait défiler une page remplie d'images, ou encore de prioriser les flux affichés à l'écran quand on passe d'un onglet à un autre. -## 6.5. Compression de l'en-tête. +## 6.5. Compression de l'en-tête -HTTP est un protocole sans état (state-less). Cela veut dire que chaque requête doit apporter tous les détails requis au serveur pour traiter la requête, sans que le serveur ait besoin de conserver les informations ou meta-données des requêtes précédentes. Comme http2 ne change pas ce principe, il doit en faire de même. +HTTP est un protocole sans état (stateless). Cela veut dire que chaque requête doit apporter tous les détails requis au serveur pour traiter la requête, sans que le serveur ait besoin de conserver les informations ou meta-données des requêtes précédentes. Comme http2 ne change pas ce principe, il doit en faire de même. Cela rend HTTP répétitif. Quand un client demande plusieurs ressources d'un même site, comme les images d'un site web, il y a aura une série de requêtes quasi identiques. Une série de points identiques appelle un besoin de compression. @@ -66,25 +66,25 @@ Les tailles de requêtes HTTP 1.1 sont devenues tellement importantes qu'elles d Les compressions HTTPS et SPDY ont été vulnérables aux attaques [BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) et [CRIME](https://en.wikipedia.org/wiki/CRIME). En insérant un texte connu dans le flux et en analysant les changements résultant, l'attaquant peut déduire ce qui a été envoyé. -Compresser du contenu dynamique sans devenir vulnérable à une de ces attaques requiert de la réflexion. L'équipe HTTPbis s'y attelle. +Compresser du contenu dynamique sans devenir vulnérable à une de ces attaques requiert de la réflexion. L'équipe HTTPbis s'y est attelée. -Voici [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2 (compression d'en-tête pour HTTP/2), qui, comme son nom l'indique, est un format de compression spécialement créé pour les entêtes http2 et spécifié dans un draft IETF distinct. Le nouveau format, avec d'autres contre-mesures comme un bit qui interdit aux intermédiaires de compresser un en-tête spécifique ou du remplissage de trames (padding), devrait rendre plus compliqué l'exploitation de cette compression. +Voici [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2 (compression d'en-tête pour HTTP/2), qui, comme son nom l'indique, est un format de compression spécialement créé pour les en-têtes http2 et spécifié dans un draft IETF distinct. Le nouveau format, avec d'autres contre-mesures comme un bit qui interdit aux intermédiaires de compresser un en-tête spécifique ou du remplissage de trames (padding), devrait rendre plus compliqué l'exploitation de cette compression. -Voici les les mots de Roberto Peon (l'un des créateurs de HPACK): +Voici les mots de Roberto Peon (l'un des créateurs de HPACK) : -> “HPACK a été conçu pour rendre difficile la fuite d'information avec une implémentation s'y conformant, rendre le codage et décodage très rapide et peu coûteux, fournir au destinataire un contrôle sur la taille du contexte de compression, permettre une réindexation par un proxy, et permettre une comparaison rapide avec des chaînes codées avec un algorithme Huffman.”. +> “HPACK a été conçu pour rendre difficile la fuite d'information avec une implémentation s'y conformant, rendre le codage et décodage très rapide et peu coûteux, fournir au destinataire un contrôle sur la taille du contexte de compression, permettre une réindexation par un proxy, et permettre une comparaison rapide avec des chaînes codées avec l'algorithme de Huffman.”. ## 6.6. Reset - changez de perspective -Un des inconvénients de HTTP 1.1: quand le message HTTP est envoyé avec un en-tête Content-Length d'une taille particulière, on ne peut pas l'interrompre facilement. Bien sûr vous pouvez toujours terminer la session TCP mais cela a un coût: renégocier le handshake TCP. +Un des inconvénients de HTTP 1.1 : quand le message HTTP est envoyé avec un en-tête Content-Length d'une taille particulière, on ne peut pas l'interrompre facilement. Bien sûr vous pouvez toujours terminer la session TCP mais cela a un coût : renégocier le handshake TCP. Une meilleure solution serait simplement d'interrompre le message et en démarrer un nouveau. Cela peut se faire en http2 avec la trame RST_STREAM qui permet d'éviter de gâcher de la bande passante et de terminer des connexion TCP. ## 6.7. Server push -Cette fonctionnalité est aussi connue comme "cache push". Cas typique: un client demande une ressource X au serveur, le serveur sait qu'en général ce client aura besoin de la ressource Z par la suite et la lui envoie sans que le client l'ait demandée. Cela aide le client à mettre Z dans son cache pour qu'elle soit disponible quand il en aura besoin. +Cette fonctionnalité est aussi connue comme "cache push". Cas typique : un client demande une ressource X au serveur, le serveur sait qu'en général ce client aura besoin de la ressource Z par la suite et la lui envoie sans que le client l'ait demandée. Cela aide le client en mettant Z dans son cache pour qu'elle soit disponible quand il en aura besoin. -Le Push Serveur (Server Push) doit être explicitement autorisée par le client et, quand bien même le client l'autorise, ce dernier se réserve le droit de terminer un flux "poussé" avec un RST_STREAM. +Le Push Serveur (Server Push) doit être explicitement autorisé par le client et, quand bien même le client l'autorise, ce dernier se réserve le droit de terminer un flux "poussé" avec un RST_STREAM. ## 6.8. Contrôle de flux diff --git a/fr/part7.md b/fr/part7.md index 748db0f..3dada52 100644 --- a/fr/part7.md +++ b/fr/part7.md @@ -1,10 +1,10 @@ # 7. Extensions -Le protocole oblige le destinataire à lire et ignorer toutes les trames inconnues utilisant un type de trame inconnu. Les deux parties peuvent ainsi négocier l'utilisation d'un nouveau type de trame de manière unitaire; ces trames ne seront pas autorisées à changer d'état et ne bénéficieront pas de contrôle de flux. +Le protocole oblige le destinataire à lire et ignorer toutes les trames inconnues (c'est à dire celles dont le type est inconnu). Deux parties peuvent négocier l'utilisation d'un nouveau type de trame en "hop-by-hop" ; ces trames ne seront pas autorisées à changer l'état et ne seront pas soumises au contrôle de flux. -Le fait d'autoriser ou non les extensions dans http2 a été débattu pendant le développement du protocole avec des opinions pour et contre. Depuis le draft-12, la balance a penché en faveur du pour: les extensions sont autorisées. +Le fait d'autoriser ou non les extensions dans http2 a été débattu pendant le développement du protocole avec des opinions pour et contre. Depuis le draft-12, la balance a penché en faveur du pour : les extensions sont autorisées. -Les extensions ne font pas partie du protocole actuel mais seront documentées en dehors de la spécification principale. En l'état, il existe deux types de trames qui pouvaient faire partie du protocole et qui seront probablement les premières trames définies comme extensions. Je les décris ici car elles sont populaires et étaient considérées auparavant comme des trames "natives": +Les extensions ne font pas partie du protocole lui même mais seront documentées en dehors de la spécification principale. En l'état, il existe deux types de trames qui pouvaient faire partie du protocole et qui seront probablement les premières trames définies comme extensions. Je les décris ici car elles sont populaires et étaient considérées auparavant comme des trames "natives" : ## 7.1. Services Alternatifs @@ -12,7 +12,7 @@ Avec http2 adopté, on peut suspecter que les connexions TCP seront plus longues Cela affectera comment les load balancers HTTP réagissent quand un site voudra que les utilisateurs se connectent sur un autre host, pour des raisons de performance ou pour réaliser une maintenance. -Le serveur enverra alors [l'en-tête Alt-Svc:](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (ou la trame http2 ALTSVC) pour indiquer au client un service alternatif. Une autre route pour le même contenu, utilisant un autre service, host et numéro de port. +Le serveur enverra alors [l'en-tête Alt-Svc:](https://tools.ietf.org/html/rfc7838) (ou la trame http2 ALTSVC) pour indiquer au client un service alternatif : une autre route pour le même contenu, utilisant un autre service, host et numéro de port. Un client est alors susceptible d'essayer de se connecter à ce service de manière asynchrone et n'utiliser que celui-ci s'il fonctionne. @@ -26,7 +26,7 @@ Cette fonctionnalité est débattue. Cette connexion serait du TLS non authentif Ce type de trame doit être envoyée une seule fois par un client http2 quand des données doivent être envoyées alors que le contrôle de flux l'interdit. L'idée est que si votre implémentation reçoit une telle trame, cela vous indique que quelque chose cloche dans votre implémentation et que vous avez une performance suboptimale. -Une citation du draft-12, avant que cette trame ne soit retirée pour devenir une extension: +Une citation du draft-12, avant que cette trame ne soit retirée pour devenir une extension : -> “La trame BLOCKED est incluse dans ce draft pour en faciliter son expérimentation. Si les resultats de cette expérimentation ne donnent pas de feedback positif, elle pourra être retirée” +> “La trame BLOCKED est incluse dans ce draft pour en faciliter son expérimentation. Si les resultats de cette expérimentation ne donnent pas de retour positif, elle pourra être retirée” diff --git a/fr/part8.md b/fr/part8.md index e2545bf..3523a2e 100644 --- a/fr/part8.md +++ b/fr/part8.md @@ -10,7 +10,7 @@ http2 réduit le nombre d'aller-retours nécessaires et évite le head of line b Il permet un nombre important de flux parallèles, plus important que ce qui est requis par les sites utilisant massivement le sharding aujourd'hui. -Si les priorités de flux sont utilisées correctement, on a une chance que les clients obtiennent les données les plus importantes avant les moins importantes. Tout compris, je dirais qu'il y de très bonnes chances pour que cela mène à un meilleur temps de chargement des pages et à des sites web plus réactifs. En résumé: une meilleure expérience web. +Si les priorités de flux sont utilisées correctement, on a une chance que les clients obtiennent les données les plus importantes avant les moins importantes. Tout compris, je dirais qu'il y de très bonnes chances pour que cela mène à un meilleur temps de chargement des pages et à des sites web plus réactifs. En résumé : une meilleure expérience web. Dans quelle mesure cela sera plus rapide, je ne pense pas qu'on puisse y répondre pour l'instant. La technologie est encore très jeune et nous n'avons pas encore vu d'implémentations client et serveur tirer parti de toutes les possibilités que le protocole offre. @@ -32,7 +32,7 @@ Il y avait déjà un certain nombre d'implémentations très tôt, et ce nombre Firefox a été le navigateur le plus en avance, Twitter a suivi et propose ses services en http2. Google commença en avril 2014 à offrir ses services en http2 sur quelques serveurs et depuis mai 2014 via les versions de développement de Chrome. Microsoft a montré une préversion d'Internet Explorer supportant http2. -curl et libcurl supportent http2 non-TLS et TLS à partir d'une des librairies TLS disponibles. +curl et libcurl supportent http2 non-TLS et TLS à partir d'une des bibliothèques TLS disponibles. ### 8.3.1. Implémentations manquantes @@ -97,13 +97,15 @@ C'est vrai. L'objectif de conserver certains paradigmes HTTP/1.1 font que certai ## 8.5. http2 sera-t-il largement déployé ? +(Cette section a été écrite en 2015 et discute l'état des choses à ce moment. Les choses ont beaucoup évolué depuis.) + Il est encore trop tôt pour le dire, mais je peux le deviner et l'estimer, voici comment. Les esprits négatifs montreront "regardez comme IPv6 a marché" comme un exemple qui a pris des décennies pour juste commencer à être largement déployé. http2 n'est pas IPv6. C'est un protocole au-dessus de TCP utilisant les mécanismes d'upgrade HTTP, un port standard, TLS, etc. Il ne requiert pas un changement de la plupart des routeurs et firewalls. Avec SPDY, Google a prouvé au monde que l'on pouvait déployer et utiliser un nouveau protocole en peu de temps. Même si la somme des serveurs SPDY avoisine les 1% aujourd'hui, le volume de données est plus important. Certains des plus gros sites utilisent SPDY. -http2, basé sur les mêmes principes que SPDY et ratifié par l'IETF, devrait être encore plus largement déployé. Les déploiements SPDY ont toujours été limités par le syndrome "inventé par Google" +http2, basé sur les mêmes principes que SPDY et ratifié par l'IETF, devrait être encore plus largement déployé. Les déploiements SPDY ont toujours été limités par le syndrome "inventé par Google". Il y a plusieurs navigateurs importants derrière http2. Des représentants de Firefox, Chrome, Safari, Internet Explorer et Opera ont tous indiqué leur intention de livrer des navigateurs avec http2 et ont montré des implémentations fonctionnelles. diff --git a/fr/part9.md b/fr/part9.md index 14ae255..2f50919 100644 --- a/fr/part9.md +++ b/fr/part9.md @@ -4,19 +4,17 @@ Firefox a suivi les drafts de près et fourni des protocoles de test de http2 de ## 9.1. Assurez-vous de l'activer -Toute version de Firefox 35 et ultérieure, depuis le 13 janvier 2015, a le support http2 activé par défaut. - -Allez dans "about:config" depuis la barre d'URL et cherchez l'option appelée "network.http.spdy.enabled.http2draft". Assurez-vous qu'elle est à "true". Firefox 36 ajouta une option activée par défaut "network.http.spdy.enabled.http2". Cette dernière contrôle la version finale de http2 tandis que la première active ou non la négociation des versions drafts de http2. Les deux sont activées depuis Firefox 36. +Toutes les versions de Firefox à partir de la 36, du 24 février 2015, ont le support http2 activé par défaut. ## 9.2. TLS uniquement Souvenez-vous que Firefox n'implémente http2 que sur TLS. Vous ne verrez du http2 que si vous allez sur les sites https:// qui offrent http2. -## 9.3. Transparent! +## 9.3. Transparent ! ![ Copie d'écran montrant que Firefox utilise http2 draft-12](https://raw.githubusercontent.com/bagder/http2-explained/master/images/firefox-screenshot.png) -Il n'y a pas d'indication graphique que vous utilisez http2. Vous ne pouvez pas le voir facilement. Une manière de le trouver est d'activer "Web developer->Network" et de vérifier l'en-tête de réponse. Elle doit comporter "HTTP/2.0", Firefox insère son propre entête "X-Firefox-Spdy:" comme montré sur la copie d'écran précédente. +Il n'y a pas d'indication graphique que vous utilisez http2. Vous ne pouvez pas le voir facilement. Une manière de le trouver est d'activer "Web developer->Network" et de vérifier l'en-tête de réponse. Elle doit comporter "HTTP/2.0", Firefox insère son propre en-tête "X-Firefox-Spdy:" comme montré sur la copie d'écran précédente. Les en-têtes que vous voyez dans l'outil ont été convertis du format binaire http2 vers un format qui ressemble aux en-têtes HTTP 1.x.