diff --git a/README.md b/README.md index 7d61b38..24453fc 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ LICENSE ------- The document is distributed under the Creative Commons Attribution 4.0 -license: http://creativecommons.org/licenses/by/4.0/ +license: https://creativecommons.org/licenses/by/4.0/ CONTRIBUTING ------------ diff --git a/de/README.md b/de/README.md index 069ea6b..dcb0039 100644 --- a/de/README.md +++ b/de/README.md @@ -9,7 +9,7 @@ Es beschreibt das Konzept, das Protokoll einige Implementierungen und über die Die Original-Seite zu diesem Projekt findest du unter folgender URL. -http://daniel.haxx.se/http2/ +https://daniel.haxx.se/http2/ Unter https://github.com/bagder/http2-explained ist der Quelltext zum ganzen Buch mit allen Übersetzungen zu finden. diff --git a/de/part1.md b/de/part1.md index 8ff2688..e96c16e 100644 --- a/de/part1.md +++ b/de/part1.md @@ -5,7 +5,7 @@ Dieses Dokument beschreibt den technischen Aufbau und das Protokoll http2. Was als Präsentation im April 2014 in Stockholm anfing wurde daraufhin zu einer detaillierten Dokumentation und fügte einige sachgerechte Erklärungen hinzu RFC 7540 ist der offizielle Standard der letzten Spezifikation von http2. Am 15. Mai 2015 wurde diese veröffentlicht. -URL: http://www.rfc-editor.org/rfc/rfc7540.txt +URL: https://www.rfc-editor.org/rfc/rfc7540.txt Jegliche Fehler in diesem Dokument basieren auf meinem Verständnis der Materie. Ich bin offen für jede Korrektur welche beim update auf eine neue Version behoben wird. @@ -20,21 +20,21 @@ Der Name des original Autors ist Daniel Stenberg welcher für Mozilla arbeitet. Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 Hilfe! Falls du Fehler, Missverständnisse oder offensichtliche Lügen in diesem Dokument findest sende mir bitte eine verbesserte Version des betroffene Paragrafen und Ich erstelle eine novelliert Version des Dokumentes. Du wirst natürlich als Autor ordnungsgemäß als Mitautor aufgelistet. Ich hoffe damit dieses Dokument mit der Zeit immer wieder zu verbessern. -Dieses Dokument ist unter der folgenden URL verfügbar. [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +Dieses Dokument ist unter der folgenden URL verfügbar. [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 Lizenz -Dieses Dokument ist unter der „Creative Commons Attribution 4.0“ Lizenz veröffentlicht: http://creativecommons.org/licenses/by/4.0/ +Dieses Dokument ist unter der „Creative Commons Attribution 4.0“ Lizenz veröffentlicht: https://creativecommons.org/licenses/by/4.0/ ## 1.4 Dokument Historie diff --git a/en/part1.md b/en/part1.md index 293e08e..f595e84 100644 --- a/en/part1.md +++ b/en/part1.md @@ -5,7 +5,7 @@ out as a presentation Daniel did in Stockholm in April 2014 that was subsequently converted and extended into a full-blown document with all details and proper explanations. -RFC 7540 is the official name of the final http2 specification and it was published on May 15th 2015: http://www.rfc-editor.org/rfc/rfc7540.txt +RFC 7540 is the official name of the final http2 specification and it was published on May 15th 2015: https://www.rfc-editor.org/rfc/rfc7540.txt All and any errors in this document are my own and the results of my shortcomings. Please point them out and they will be fixed in updated @@ -37,13 +37,13 @@ the http2 standardization work. If you find mistakes, omissions, errors or blatant lies in this document, please send me a refreshed version of the affected paragraph and I'll make amended versions. I will give proper credits to everyone who helps out! I hope to make this document better over time. -This document is available at [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +This document is available at [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 License -This document is licensed under the Creative Commons Attribution 4.0 license: http://creativecommons.org/licenses/by/4.0/ +This document is licensed under the Creative Commons Attribution 4.0 license: https://creativecommons.org/licenses/by/4.0/ ## 1.4 Document history diff --git a/en/part11.md b/en/part11.md index 71b5772..4cdbf76 100644 --- a/en/part11.md +++ b/en/part11.md @@ -1,6 +1,6 @@ # 11. http2 in curl -The [curl project](http://curl.haxx.se/) has been providing experimental http2 +The [curl project](https://curl.haxx.se/) has been providing experimental http2 support since September 2013. In the spirit of curl, we intend to support just about every aspect of http2 that we possibly can. curl is often used as a test tool and tinkerer's way to poke on web sites and we intend to keep that up for http2 as well. @@ -46,7 +46,7 @@ if it can, but otherwise continue to operate with HTTP 1.1. As libcurl tries to maintain existing behaviors to a far extent, you need to enable HTTP/2 multiplexing for your application with the -[CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) +[CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) option. Otherwise it will continue using one request at a time per connection. Another little detail to keep in mind is that if you ask for several transfers @@ -54,14 +54,14 @@ at once with libcurl, using its multi interface, an applicaton can very well start any number of transfers at once and if you then rather have libcurl wait a little to add them all over the same connection rather than opening new connections for all of them at once, you use the -[CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) option +[CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) option for each individual transfer you rather wait. ### 11.5.3 Server push libcurl 7.44.0 and later supports HTTP/2 server push. You can take advantage of this feature by setting up a push callback with the -[CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) +[CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) option. If the push is accepted by the application, it'll create a new transfer as an CURL easy handle and deliver content on it, just like any other transfer. diff --git a/en/part12.md b/en/part12.md index d733092..8c6e770 100644 --- a/en/part12.md +++ b/en/part12.md @@ -12,4 +12,4 @@ Google's [QUIC](https://www.chromium.org/quic) (Quick UDP Internet Connections) QUIC allows the creation of connections with much less latency, it solves packet loss to only block individual streams instead of all of them like it does for HTTP/2 and it makes connections possible to be done over different network interfaces easily - thus also covering areas MPTCP is meant to solve. -QUIC is so far only implemented by Google in Chrome and their server ends and that code is not easily re-used elsewhere, even if there's a [libquic](https://github.com/devsisters/libquic) effort trying exactly that. The protocol has been brought as a [draft](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) to the IETF transport working group. +QUIC is so far only implemented by Google in Chrome and their server ends and that code is not easily re-used elsewhere, even if there's a [libquic](https://github.com/devsisters/libquic) effort trying exactly that. The protocol has been brought as a [draft](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) to the IETF transport working group. diff --git a/en/part13.md b/en/part13.md index fbf21a0..db95f94 100644 --- a/en/part13.md +++ b/en/part13.md @@ -2,14 +2,14 @@ If you think this document was a bit light on content or technical details, here are additional resources to help you satisfy your curiosity: -- The HTTPbis mailing list and its archives: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- The HTTPbis mailing list and its archives: https://lists.w3.org/Archives/Public/ietf-http-wg/ - The actual http2 specification in a HTMLified version: https://httpwg.github.io/specs/rfc7540.html - Firefox http2 networking details: https://wiki.mozilla.org/Networking/http2 -- curl http2 implementation details: http://curl.haxx.se/docs/http2.html +- curl http2 implementation details: https://curl.haxx.se/docs/http2.html -- The http2 web site: http://http2.github.io/ and perhaps in particular the FAQ: http://http2.github.io/faq/ +- The http2 web site: https://http2.github.io/ and perhaps in particular the FAQ: https://http2.github.io/faq/ -- Ilya Grigorik's HTTP/2 chapter in his book “High Performance Browser Networking”: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- Ilya Grigorik's HTTP/2 chapter in his book “High Performance Browser Networking”: https://hpbn.co/http2/ diff --git a/en/part14.md b/en/part14.md index e09517c..2b2f77d 100644 --- a/en/part14.md +++ b/en/part14.md @@ -2,7 +2,7 @@ Inspiration and the package format Lego image from Mark Nottingham. -HTTP trend data comes from http://httparchive.org. +HTTP trend data comes from https://httparchive.org/. The RTT graph comes from presentations done by Mike Belshe. diff --git a/en/part4.md b/en/part4.md index d3f5a54..71c7650 100644 --- a/en/part4.md +++ b/en/part4.md @@ -27,11 +27,11 @@ Some of the bigger players in the HTTP field have been missing from the working ### 4.1.1. The "bis" part of the name -The group is named HTTPbis where the "bis" part comes from the [Latin adverb for two](http://en.wiktionary.org/wiki/bis#Latin). Bis is commonly used as a suffix or part of the name within the IETF for an update or the second take on a spec; in this case, the update to HTTP 1.1. +The group is named HTTPbis where the "bis" part comes from the [Latin adverb for two](https://en.wiktionary.org/wiki/bis#Latin). Bis is commonly used as a suffix or part of the name within the IETF for an update or the second take on a spec; in this case, the update to HTTP 1.1. ## 4.2. http2 started from SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) is a protocol that was developed and spearheaded by Google. They certainly developed it in the open and invited everyone to participate but it was obvious that they benefited by being in control over both a popular browser implementation and a significant server population with well-used services. +[SPDY](https://en.wikipedia.org/wiki/SPDY) is a protocol that was developed and spearheaded by Google. They certainly developed it in the open and invited everyone to participate but it was obvious that they benefited by being in control over both a popular browser implementation and a significant server population with well-used services. When the HTTPbis group decided it was time to start working on http2, SPDY had already proven that it was a working concept. It had shown it was possible to deploy on the Internet and there were published numbers that proved how well it performed. The http2 work began with the SPDY/3 draft that was basically made into the http2 draft-00 with a little search and replace. diff --git a/en/part6.md b/en/part6.md index 4a8f1fa..cc45bec 100644 --- a/en/part6.md +++ b/en/part6.md @@ -59,11 +59,11 @@ The HTTP 1.1 request sizes have actually gotten so large that they sometimes end ### 6.5.1. Compression is a tricky subject -HTTPS and SPDY compression were found to be vulnerable to the [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) and [CRIME](http://en.wikipedia.org/wiki/CRIME) attacks. By inserting known text into the stream and figuring out how that changes the output, an attacker can figure out what's being sent in an encrypted payload. +HTTPS and SPDY compression were found to be vulnerable to the [BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) and [CRIME](https://en.wikipedia.org/wiki/CRIME) attacks. By inserting known text into the stream and figuring out how that changes the output, an attacker can figure out what's being sent in an encrypted payload. Doing compression on dynamic content for a protocol - without becoming vulnerable to one of these attacks - requires some thought and careful consideration. This is what the HTTPbis team tried to do. -Enter [HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2, which – as the name suggests - is a compression format especially crafted for http2 headers, and it is being specified in a separate internet draft. The new format, together with other counter-measures (such as a bit that asks intermediaries to not compress a specific header and optional padding of frames), should make it harder to exploit compression. +Enter [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2, which – as the name suggests - is a compression format especially crafted for http2 headers, and it is being specified in a separate internet draft. The new format, together with other counter-measures (such as a bit that asks intermediaries to not compress a specific header and optional padding of frames), should make it harder to exploit compression. In the words of Roberto Peon (one of the creators of HPACK): diff --git a/en/part7.md b/en/part7.md index e835d4b..03bad0f 100644 --- a/en/part7.md +++ b/en/part7.md @@ -13,7 +13,7 @@ With the adoption of http2, there are reasons to suspect that TCP connections wi This will affect how HTTP load balancers work and there may arise situations when a site wants to suggest that the client connect to another host. It could be for performance reasons, or if a site is being taken down for maintenance, etc. The server will send the [Alt-Svc: -header](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (or ALTSVC +header](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (or ALTSVC frame with http2) telling the client about an alternative service: another route to the same content, using another service, host, and port number. diff --git a/en/part8.md b/en/part8.md index 4b9fa7e..b77e31b 100644 --- a/en/part8.md +++ b/en/part8.md @@ -53,8 +53,8 @@ server instance). Apache's httpd server has a http2 module [mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html) since 2.4.17 which was released on October 9, 2015. [H2O](https://h2o.examp1e.net/), [Apache Traffic -Server](http://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), -[Caddy](http://caddyserver.com/) and +Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), +[Caddy](https://caddyserver.com/) and [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) have all released http2 capable servers. @@ -101,7 +101,7 @@ for one source of info. Telecom and other network operators, for example in the ATIS Open Web Alliance, say that they [need unencrypted -traffic](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) +traffic](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) to offer caching, compression and other techniques necessary to provide a fast web experience over satellite, in airplanes and similar. http2 does not make TLS use mandatory so we shouldn't conflate the terms. @@ -120,7 +120,7 @@ If you really can't take a binary protocol, then you couldn't handle TLS and com ### 8.4.6. “It isn't any faster than HTTP/1.1” -This is of course subject to debate and discussions on how to measure what faster means, but already in the SPDY days many tests were performed that proved browser page loads were faster (like ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) by people at University of Washington and ["Evaluating the Performance of SPDY-enabled Web Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) by Hervé Servy) and such experiments have been repeated with http2 as well. I'm looking forward to seeing more such tests and experiments getting published. A [basic first test made by httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) might imply that HTTP/2 holds its promises. +This is of course subject to debate and discussions on how to measure what faster means, but already in the SPDY days many tests were performed that proved browser page loads were faster (like ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) by people at University of Washington and ["Evaluating the Performance of SPDY-enabled Web Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) by Hervé Servy) and such experiments have been repeated with http2 as well. I'm looking forward to seeing more such tests and experiments getting published. A [basic first test made by httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) might imply that HTTP/2 holds its promises. ### 8.4.7. “It has layering violations” diff --git a/es/README.md b/es/README.md index d1b102a..fac7625 100644 --- a/es/README.md +++ b/es/README.md @@ -4,7 +4,7 @@ http2 explicado Este es un documento detallado que describe HTTP/2 ([RFC 7540](https://httpwg.github.io/specs/rfc7540.html)), sus antecedentes, conceptos, el protocolo y algo sobre las implementaciones existentes y lo que nos puede deparar el futuro. -El sitio http://daniel.haxx.se/http2/ es el home canónico de este proyecto. +El sitio https://daniel.haxx.se/http2/ es el home canónico de este proyecto. En https://github.com/bagder/http2-explained se encuentra el código fuente de todo el contenido del libro. diff --git a/es/part1.md b/es/part1.md index 8915c07..fc388f3 100644 --- a/es/part1.md +++ b/es/part1.md @@ -2,7 +2,7 @@ Este es un documento que describe http2 desde un nivel técnico y de protocolo. Comenzó como una presentación, que hice en Estocolmo en abril de 2014, para más tarde extender y convertirse en un documento completo con todo detalle y explicaciones concisas. -RFC 7540 es el nombre oficial de la especificación final de http2 que ha sido publicada el 15 de Mayo de 2015: http://www.rfc-editor.org/rfc/rfc7540.txt +RFC 7540 es el nombre oficial de la especificación final de http2 que ha sido publicada el 15 de Mayo de 2015: https://www.rfc-editor.org/rfc/rfc7540.txt Todos los errores encontrados en este documento son míos propios (y del traducción), resultado de mis propios defectos. Por favor, reportarlos y haré las actualizaciones con sus correcciones. @@ -18,22 +18,22 @@ Mi nombre es Daniel Stenberg y trabajo en Mozilla. Llevo trabajando con open sou Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 ¡Ayuda! Si encuentras errores, omisiones o mentiras descaradas en este documento, por favor envíame un versión actualizada del párrafo afectado y haré versiones modificadas. ¡Se mencionará en los créditos a todo aquel que eche una mano!. Espero ir mejorando este documento a lo largo del tiempo. -El documento está disponible en [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +El documento está disponible en [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 Licencia -Este documento está licenciado bajo Creative Commons Attribution 4.0 license: http://creativecommons.org/licenses/by/4.0/ +Este documento está licenciado bajo Creative Commons Attribution 4.0 license: https://creativecommons.org/licenses/by/4.0/ ## 1.4 Historial del documento diff --git a/es/part11.md b/es/part11.md index c6c0ab5..1bfc0db 100644 --- a/es/part11.md +++ b/es/part11.md @@ -1,6 +1,6 @@ # 11. http2 en curl -El [proyecto curl](http://curl.haxx.se/) ha estado ofreciendo soporte experimental para http2 desde septiembre de 2013. +El [proyecto curl](https://curl.haxx.se/) ha estado ofreciendo soporte experimental para http2 desde septiembre de 2013. Siguiendo el espíritu de curl, pretendemos ofrecer todos los aspectos de http2 en la medida de nuestras posibilidades. Es un uso común de curl se usado como una herramienta de testeo, y una manera de “pingar” manualmente sitios web, y es nuestra intención mantenerlo igualmente para http2. @@ -35,12 +35,12 @@ Tu aplicación utilizará URLs normales con https:// o http://, pero habrá que ### 11.5.2 Multiplexación libcurl intenta mantener comportamientos existentes, por lo que se hace necesario que se active la multiplexación HTTP/2 en tu aplicación mediante la opción -[CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). De lo contrario se seguirá utilizando una petición en cada momento por conexión. +[CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). De lo contrario se seguirá utilizando una petición en cada momento por conexión. -Otro pequeño detalle a tener en cuenta es que al solicitar varias transferencias al mismo tiempo con libcurl, usando su interfaz multiple, una aplicación puede empezar varias transferencias al mismo tiempo, y que si se pretende que libcurl espere e introduzca todas ellas por la misma conexión en lugar de abrir nuevas conexiones, existe la opción [CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html). +Otro pequeño detalle a tener en cuenta es que al solicitar varias transferencias al mismo tiempo con libcurl, usando su interfaz multiple, una aplicación puede empezar varias transferencias al mismo tiempo, y que si se pretende que libcurl espere e introduzca todas ellas por la misma conexión en lugar de abrir nuevas conexiones, existe la opción [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html). ### 11.5.3 Server push -A partir de la versión libcurl 7.44.0 se da soporte para la funcionalidad HTTP/2 server push. Puedes utilizarla indicando un callback con la opción [CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). +A partir de la versión libcurl 7.44.0 se da soporte para la funcionalidad HTTP/2 server push. Puedes utilizarla indicando un callback con la opción [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Si la aplicación acepta el push, se creará una nueva transferencia con un manejador fácil CURL, y se enviará contenido, como cualquier otra transferencia. \ No newline at end of file diff --git a/es/part12.md b/es/part12.md index 0299d3c..860bfa1 100644 --- a/es/part12.md +++ b/es/part12.md @@ -12,4 +12,4 @@ El protocolo de Google, [QUIC](https://www.chromium.org/quic) (Quick UDP Interne QUIC permite la creación de conexiones con mucha menos latencia, soluciona la pérdida de paquetes al sólo bloquear flujos individuales en lugar de todos a la vez como hacer HTTP/2, y posibilita la creación de conexiones por distintas interfaces de red fácilmente – así también cubre otras áreas que MPTCP pretende resolver. -QUIC de momento está únicamente implementado por Google en Chrome y en sus servidores, y es código no fácilmente reutilizable en otras partes, aunque [libquic](https://github.com/devsisters/libquic) es un esfuerzo intentado conseguir eso exactamente. La especificación es todavía algo vaga y cambia rápidamente. Ya existe un [borrador](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) en el grupo de trabajo de transporte del IETF. +QUIC de momento está únicamente implementado por Google en Chrome y en sus servidores, y es código no fácilmente reutilizable en otras partes, aunque [libquic](https://github.com/devsisters/libquic) es un esfuerzo intentado conseguir eso exactamente. La especificación es todavía algo vaga y cambia rápidamente. Ya existe un [borrador](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) en el grupo de trabajo de transporte del IETF. diff --git a/es/part13.md b/es/part13.md index 815e805..e755406 100644 --- a/es/part13.md +++ b/es/part13.md @@ -2,14 +2,14 @@ Si encuentras este documento un poco ligero de contenido o de detalles técnicos, aquí tienes otros recursos para ayudar a satisfacer tu curiosidad: -- La lista de correo HTTPbis y su archivo: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- La lista de correo HTTPbis y su archivo: https://lists.w3.org/Archives/Public/ietf-http-wg/ - La especificación http2 actual en su versión en HTML: https://httpwg.github.io/specs/rfc7540.html - Detalles de networking http2 de Firefox: https://wiki.mozilla.org/Networking/http2 -- Detalles de la implementación http2 de curl: http://curl.haxx.se/dev/readme-http2.html +- Detalles de la implementación http2 de curl: https://curl.haxx.se/dev/readme-http2.html -- El sitio web de http2: http://http2.github.io/ y quizás su FAQ en particular: http://http2.github.io/faq/ +- El sitio web de http2: https://http2.github.io/ y quizás su FAQ en particular: https://http2.github.io/faq/ - - El capítulo sobre HTTP/2 de Ilya Grigorik's en su libro “High Performance Browser Networking”: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- El capítulo sobre HTTP/2 de Ilya Grigorik's en su libro “High Performance Browser Networking”: https://hpbn.co/http2/ diff --git a/es/part14.md b/es/part14.md index a7f4233..211bc01 100644 --- a/es/part14.md +++ b/es/part14.md @@ -2,7 +2,7 @@ Inspiración y la imagen del paquete con formato Lego de Mark Nottingham. -Los datos de tendencias HTTP vienen de http://httparchive.org. +Los datos de tendencias HTTP vienen de https://httparchive.org/. El gráfico RTT viene de las presentaciones hechas por Mike Belshe. diff --git a/es/part4.md b/es/part4.md index 7e073af..ed6ad0f 100644 --- a/es/part4.md +++ b/es/part4.md @@ -22,10 +22,10 @@ Algunos de los agentes más grandes en HTTP no estuvieron en los debates o reuni ### 4.1.1. La parte “bis” del nombre -El grupo se ha denominado HTTPbis de manera que la parte “bis” procede del [adverbio en latín para “dos”](http://en.wiktionary.org/wiki/bis#Latin). Bis es muy usado por el IETF bien como un sufijo o bien como parte de un nombre para una actualización o para la segunda parte de una especificación. En este caso para HTTP 1.1. +El grupo se ha denominado HTTPbis de manera que la parte “bis” procede del [adverbio en latín para “dos”](https://en.wiktionary.org/wiki/bis#Latin). Bis es muy usado por el IETF bien como un sufijo o bien como parte de un nombre para una actualización o para la segunda parte de una especificación. En este caso para HTTP 1.1. ## 4.2. http2 empieza en SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) es un protocolo encabezado y desarrollado por Google. Ha sido indudablemente desarrollado en abierto y todo el mundo ha sido invitado a participar, pero obviamente son los principales beneficiados al controlar una implementación muy popular de navegador y una parte significativa de la población de servidores con bastantes servicios muy conocidos. +[SPDY](https://en.wikipedia.org/wiki/SPDY) es un protocolo encabezado y desarrollado por Google. Ha sido indudablemente desarrollado en abierto y todo el mundo ha sido invitado a participar, pero obviamente son los principales beneficiados al controlar una implementación muy popular de navegador y una parte significativa de la población de servidores con bastantes servicios muy conocidos. Cuanto el grupo HTTPbis decidió que era hora de comenzar a trabajar en http2, SPDY había demostrado que era un concepto que funcionaba. Había demostrado que era posible desplegar en Internet y habían publicado números demostrando su rendimiento. El trabajo para http2 comenzó posteriormente desde el draft SPDY/3 que se convirtió en el draft-00 de http2 básicamente con un poco de búsqueda y reemplazo. diff --git a/es/part6.md b/es/part6.md index 3db40b8..ad1cc27 100644 --- a/es/part6.md +++ b/es/part6.md @@ -60,11 +60,11 @@ El tamaño en la peticiones HTTP 1.1 ha ido haciéndose tan grande en los últim ### 6.5.1. La compresión tiene truco -Las compresiones HTTPS y SPDY han resultado ser vulnerables a ataques [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) y [CRIME](http://en.wikipedia.org/wiki/CRIME). Insertando texto conocido en el flujo, y averiguando que es lo que cambio en el resultado comprimido, un atacante puede averiguar que se está enviando. +Las compresiones HTTPS y SPDY han resultado ser vulnerables a ataques [BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) y [CRIME](https://en.wikipedia.org/wiki/CRIME). Insertando texto conocido en el flujo, y averiguando que es lo que cambio en el resultado comprimido, un atacante puede averiguar que se está enviando. Hacer compresión en contenido dinámico para un protocolo evitando las vulnerabilidades de estos dos ataques, requiere reflexiones y consideraciones cuidadosas. Esto es lo que el grupo HTTPbis intenta hacer. -Se introduce [HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2, que – como sugiere adecuadamente su nombre – es un formato de compresión especialmente diseñado para cabeceras http2 y estrictamente hablando, está siendo especificado en otro borrador separado de Internet. El nuevo formato, junto con otras contra-medidas como un bit que solicita a los intermediarios no comprimir una cabecera específica o el desplazamiento opcional de tramas deberían hacer mucho más difícil llegar a romper esta compresión. +Se introduce [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header Compression for HTTP/2, que – como sugiere adecuadamente su nombre – es un formato de compresión especialmente diseñado para cabeceras http2 y estrictamente hablando, está siendo especificado en otro borrador separado de Internet. El nuevo formato, junto con otras contra-medidas como un bit que solicita a los intermediarios no comprimir una cabecera específica o el desplazamiento opcional de tramas deberían hacer mucho más difícil llegar a romper esta compresión. En palabras de Roberto Peon (uno de los creadores de HPACK): diff --git a/es/part7.md b/es/part7.md index a2f654c..35cf9c6 100644 --- a/es/part7.md +++ b/es/part7.md @@ -12,7 +12,7 @@ Durante la adopción de http2, existen razones para sospechar que las conexiones Esto afectará a como funcionan lo balanceadores HTTP y se generarán situaciones en las cuales un sitio querrá anunciar y sugerir que el cliente se conecte a otro host, tanto por razones de rendimiento, como porque el sitio puede necesitar mantenimiento u otra razón similar. -El servidor enviará entonces la cabecera [Alt-Svc: header](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (o la trama ALTSVC en http2) que indicará al cliente el servidor alternativo. Otra ruta al mismo contenido, utilizando otro servicio, dominio y número de puerto. +El servidor enviará entonces la cabecera [Alt-Svc: header](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (o la trama ALTSVC en http2) que indicará al cliente el servidor alternativo. Otra ruta al mismo contenido, utilizando otro servicio, dominio y número de puerto. El cliente intentará conectarse a ese servicio asíncronamente, y utilizará ese servicio alternativo si éste funciona correctamente. diff --git a/es/part8.md b/es/part8.md index f0a8b41..a6e5efa 100644 --- a/es/part8.md +++ b/es/part8.md @@ -36,7 +36,7 @@ Firefox ha sido el navegador que ha estado encabezando los borradores más nuevo Tanto curl como libcurl soportan http2 inseguro así como basado en TLS utilizando una de las distintas bibliotecas TLS. -[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](http://trafficserver.apache.org/) y [nghttp2](https://nghttp2.org/) han publicado todos ellos servidores con soporte para http2. +[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](https://trafficserver.apache.org/) y [nghttp2](https://nghttp2.org/) han publicado todos ellos servidores con soporte para http2. ### 8.3.1. Implementaciones pendientes @@ -85,9 +85,9 @@ Si no soportas un protocolo binario, entonces estas descartando TLS o la compres ### 8.4.6. “No es más rápido que HTTP/1.1” -Por supuesto que es algo sujeto a debate y a discusión en cómo se mide que significa más rápido, pero ya en los días de SPDY, se realizaron multitud de pruebas que demostraban que la página cargaba más rápido (por ejemplo ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) de la gente de la Univesidad de Washington y ["Evaluating the Performance of SPDY-enabled Web Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) por Hervé Servy) y dichos experimentos se han repetido también con http2. Tengo ganas de ver publicados los resultados de esas pruebas y experimentos. +Por supuesto que es algo sujeto a debate y a discusión en cómo se mide que significa más rápido, pero ya en los días de SPDY, se realizaron multitud de pruebas que demostraban que la página cargaba más rápido (por ejemplo ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) de la gente de la Univesidad de Washington y ["Evaluating the Performance of SPDY-enabled Web Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) por Hervé Servy) y dichos experimentos se han repetido también con http2. Tengo ganas de ver publicados los resultados de esas pruebas y experimentos. -Una primera prueba básica realizada por [httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) podría implicar que HTTP/2 cumple sus promesas. +Una primera prueba básica realizada por [httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) podría implicar que HTTP/2 cumple sus promesas. ### 8.4.7. “No respeta las capas” diff --git a/fr/README.md b/fr/README.md index 9e4da59..37b2dcd 100644 --- a/fr/README.md +++ b/fr/README.md @@ -5,7 +5,7 @@ Ceci est un document détaillé décrivant HTTP/2 ([RFC 7540](https://httpwg.github.io/specs/rfc7540.html)), les prémices, concepts, protocole, les implémentations existantes et ce que le futur pourrait nous réserver. -Référez-vous à http://daniel.haxx.se/http2/ pour tout ce qui concerne ce projet. +Référez-vous à https://daniel.haxx.se/http2/ pour tout ce qui concerne ce projet. Référez-vous à https://github.com/bagder/http2-explained pour le code source de ce livre. diff --git a/fr/part1.md b/fr/part1.md index e3f6379..0efa614 100644 --- a/fr/part1.md +++ b/fr/part1.md @@ -2,7 +2,7 @@ Ce document décrit http2 d'un point de vue technique et protocolaire. Il a commencé par une présentation à Stockholm réalisée par Daniel en avril 2014, présentation qui a été par la suite convertie et étoffée dans un document complet avec des explications détaillées. -La RFC 7540 est le nom officiel de la spécification http2 finale, elle a été publiée le 15 mai 2015 : http://www.rfc-editor.org/rfc/rfc7540.txt +La RFC 7540 est le nom officiel de la spécification http2 finale, elle a été publiée le 15 mai 2015 : https://www.rfc-editor.org/rfc/rfc7540.txt 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. @@ -16,21 +16,21 @@ Mon nom est Daniel Stenberg et je travaille chez Mozilla. J'ai travaillé dans l Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 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. -Ce document est disponible ici: [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +Ce document est disponible ici: [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 License -Ce document est couvert par la licence Creative Commons Attribution 4.0 : http://creativecommons.org/licenses/by/4.0/ +Ce document est couvert par la licence Creative Commons Attribution 4.0 : https://creativecommons.org/licenses/by/4.0/ ## 1.4 Historique du document diff --git a/fr/part11.md b/fr/part11.md index f1ef0a3..8858e3d 100644 --- a/fr/part11.md +++ b/fr/part11.md @@ -1,6 +1,6 @@ # 11. http2 et curl -Le [projet curl](http://curl.haxx.se/) a fourni un support http2 expérimental depuis septembre 2013. +Le [projet curl](https://curl.haxx.se/) a fourni un support http2 expérimental depuis septembre 2013. 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. @@ -34,10 +34,10 @@ Votre application utilisera http:// ou https:// comme d'habitude, mais vous pouv ### 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](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Sinon elle continuera à utiliser une requête à la fois par connexion. +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](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) pour chaque transfert que vous préférez attendre. +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. ### 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](http://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 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 diff --git a/fr/part12.md b/fr/part12.md index e48c8fb..d0a1f51 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](http://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) à l'IETF transport working group. \ No newline at end of file diff --git a/fr/part13.md b/fr/part13.md index bae9967..21aaca7 100644 --- a/fr/part13.md +++ b/fr/part13.md @@ -2,14 +2,14 @@ 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 : http://lists.w3.org/Archives/Public/ietf-http-wg/ +- La mailing-list HTTPbis et ses archives : https://lists.w3.org/Archives/Public/ietf-http-wg/ - La spécification http2 au format HTML : https://httpwg.github.io/specs/rfc7540.html - Les aspects réseaux http2 de Firefox : https://wiki.mozilla.org/Networking/http2 -- Détail d'implémentation http2 dans curl : http://curl.haxx.se/docs/http2.html +- Détail d'implémentation http2 dans curl : https://curl.haxx.se/docs/http2.html -- Les sites web http2: http://http2.github.io/ et en particulier la FAQ : http://http2.github.io/faq/ +- 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”: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html \ 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/ \ No newline at end of file diff --git a/fr/part14.md b/fr/part14.md index 4834df2..15d18ce 100644 --- a/fr/part14.md +++ b/fr/part14.md @@ -2,7 +2,7 @@ L'inspiration et l'assemblage Lego : Mark Nottingham -Les tendances HTTP : http://httparchive.org +Les tendances HTTP : https://httparchive.org/ Le graphique RTT (Aller-Retour) vient des présentations de Mike Belshe. diff --git a/fr/part4.md b/fr/part4.md index be2d17d..d503f41 100644 --- a/fr/part4.md +++ b/fr/part4.md @@ -22,10 +22,10 @@ Des acteurs importants de HTTP ont manqué à l'appel du groupe de travail penda ### 4.1.1. Le "bis" dans HTTPbis -Le groupe est appelé HTTPbis, le "bis" faisant référence au [latin "bis"](http://fr.wiktionary.org/wiki/bis#Latin). Bis est souvent utilisé comme suffixe ou partie d'un nom à l'IETF lors d'une mise à jour ou addendum d'une spécification. Comme ici avec HTTP 1.1, donc. +Le groupe est appelé HTTPbis, le "bis" faisant référence au [latin "bis"](https://fr.wiktionary.org/wiki/bis#Latin). Bis est souvent utilisé comme suffixe ou partie d'un nom à l'IETF lors d'une mise à jour ou addendum d'une spécification. Comme ici avec HTTP 1.1, donc. ## 4.2. http2 provient de SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) est un protocole développé par Google. Ils l'ont clairement créé dans un esprit d'ouverture et ont invité tout le monde à participer, mais il était évident qu'ils bénéficiaient d'une position de contrôle avec à la fois un navigateur populaire et un nombre significatif de serveurs très utilisés pour leurs services. +[SPDY](https://en.wikipedia.org/wiki/SPDY) est un protocole développé par Google. Ils l'ont clairement créé dans un esprit d'ouverture et ont invité tout le monde à participer, mais il était évident qu'ils bénéficiaient d'une position de contrôle avec à la fois un navigateur populaire et un nombre significatif de serveurs très utilisés pour leurs services. Quand le groupe HTTPbis décida de travailler sur http2, SPDY avait déjà prouvé que le concept fonctionnait. Il avait montré qu'il était possible de le déployer sur Internet et des mesures publiées montraient sa meilleure performance. Le travail sur http2 a donc démarré depuis le draft SPDY/3, rapidement transcrit dans un draft-00 de http2 grâce à quelques remplacements. diff --git a/fr/part6.md b/fr/part6.md index 7e542d3..f1f60a6 100644 --- a/fr/part6.md +++ b/fr/part6.md @@ -63,12 +63,12 @@ Les tailles de requêtes HTTP 1.1 sont devenues tellement importantes qu'elles d ### 6.5.1. La compression est un sujet délicat -Les compressions HTTPS et SPDY ont été vulnérables aux attaques [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) - et [CRIME](http://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é. +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. -Voici [HPACK](http://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 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 les les mots de Roberto Peon (l'un des créateurs de HPACK): diff --git a/fr/part7.md b/fr/part7.md index 48d56c6..748db0f 100644 --- a/fr/part7.md +++ b/fr/part7.md @@ -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:](http://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/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. 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. diff --git a/fr/part8.md b/fr/part8.md index ffb468d..76f6b66 100644 --- a/fr/part8.md +++ b/fr/part8.md @@ -66,7 +66,7 @@ Les gros sites ont déjà une présence mondiale et du coup des aller-retours mo Cela peut se révéler vrai. La négociation TLS ajoute un peu de latence, mais il existe des projets pour réduire encore les aller-retours en TLS. La surcharge du TLS par rapport à du texte en clair n'est pas neutre et a un impact CPU. L'impact en lui-même est sujet à discussions et mesures. Voir par exemple [istlsfastyet.com](https://istlsfastyet.com/) pour avoir une source d'information. -Les opérateurs télécom et réseaux, par exemple l'ATIS Open Web Alliance, indiquent qu'ils nécessitent du [trafic non chiffré](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) pour permettre au cache et à la compression de fonctionner, notamment pour une expérience web rapide par satellite. +Les opérateurs télécom et réseaux, par exemple l'ATIS Open Web Alliance, indiquent qu'ils nécessitent du [trafic non chiffré](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) pour permettre au cache et à la compression de fonctionner, notamment pour une expérience web rapide par satellite. http2 n'oblige pas à utiliser TLS, on ne devrait donc pas mélanger les deux. De nombreux utilisateurs ont indiqué leur préférence à utiliser TLS et nous devrions respecter ce droit à la vie privée. @@ -83,7 +83,7 @@ Si vous ne pouvez pas vous faire à un protocole binaire, alors vous ne pouviez ### 8.4.6. "Ce n'est pas plus rapide que HTTP/1.1" -Cela est bien sûr sujet à débat sur comment qualifier "plus rapide"; les tests menés lors des expérimentations SPDY montraient des temps de chargement de pages web plus rapides (voir [“How Speedy is SPDY?”](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) par University of Washington et [“Evaluating the Performance of SPDY-enabled Web Servers”](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) par Hervé Servy). Idem en http2 avec d'autres tests. Je souhaite voir davantage de tests publiés. Un [premier essai réalisé par httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) a tendance à montrer que HTTP/2 répond aux promesses. +Cela est bien sûr sujet à débat sur comment qualifier "plus rapide"; les tests menés lors des expérimentations SPDY montraient des temps de chargement de pages web plus rapides (voir [“How Speedy is SPDY?”](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) par University of Washington et [“Evaluating the Performance of SPDY-enabled Web Servers”](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) par Hervé Servy). Idem en http2 avec d'autres tests. Je souhaite voir davantage de tests publiés. Un [premier essai réalisé par httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) a tendance à montrer que HTTP/2 répond aux promesses. http2 est clairement plus rapide dans certains scénarios, en particulier avec les scénarios où une connexion à latence importante est utilisée avec un site comportant beaucoup de ressources à charger, ce nombre ayant tendance à augmenter. diff --git a/ja/STYLE-GUIDE-JA.md b/ja/STYLE-GUIDE-JA.md index 8efe8a7..2dc98b4 100644 --- a/ja/STYLE-GUIDE-JA.md +++ b/ja/STYLE-GUIDE-JA.md @@ -1,7 +1,7 @@ # 日本語翻訳スタイルガイド * ライセンスは以下に従います。 - > The document is distributed under the Creative Commons Attribution 4.0 license: http://creativecommons.org/licenses/by/4.0/ + > The document is distributed under the Creative Commons Attribution 4.0 license: https://creativecommons.org/licenses/by/4.0/ * 句読点は「、」「。」（それぞれU+3001、U+3002）を使う。句読点の目的で「,」「.」を使わない。 * 丸括弧は全角の「（」「）」（それぞれU+FF08、U+FF09）を使う。 * 日本語と英字の間に空白を挿入しない。 diff --git a/ja/part1.md b/ja/part1.md index faaf4d2..44ce597 100644 --- a/ja/part1.md +++ b/ja/part1.md @@ -2,7 +2,7 @@ この文書はhttp2を技術的にプロトコルレベルで記述したものです。始まりはDanielが2014年4月にストックホルムで行ったプレゼンテーションでした。後に拡張され、全ての詳細や丁寧な説明を含む立派な文書になりました。 -RFC 7540は公式なhttp2仕様書で、2015年5月15日に発行されました: http://www.rfc-editor.org/rfc/rfc7540.txt +RFC 7540は公式なhttp2仕様書で、2015年5月15日に発行されました: https://www.rfc-editor.org/rfc/rfc7540.txt この文書におけるすべての誤りは私自身のものであり、私の至らなさの致すところです。指摘していただければ次のバージョンで修正します。 @@ -16,21 +16,21 @@ RFC 7540は公式なhttp2仕様書で、2015年5月15日に発行されました Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 ご協力をお願い致します 間違いや脱字、エラー、明らかな嘘をこの文書に見つけた場合、修正した段落を私に送ってください。修正を取り込みます。私はもちろん助けてくれた人全てに適切な名誉を与えるつもりです。私はこの文書が時とともに改善されていくことを望んでいます。 -この文書は[http://daniel.haxx.se/http2](http://daniel.haxx.se/http2)で利用可能です。 +この文書は[https://daniel.haxx.se/http2](https://daniel.haxx.se/http2)で利用可能です。 ## 1.3 ライセンス -この文書はCreative Commons Attribution 4.0 license: http://creativecommons.org/licenses/by/4.0/ でライセンスされています。 +この文書はCreative Commons Attribution 4.0 license: https://creativecommons.org/licenses/by/4.0/ でライセンスされています。 ## 1.4 履歴 diff --git a/ja/part11.md b/ja/part11.md index baf55d5..52b4304 100644 --- a/ja/part11.md +++ b/ja/part11.md @@ -1,6 +1,6 @@ # 11. curlにおけるhttp2 -[curlプロジェクト](http://curl.haxx.se/)は試験的にhttp2のサポートを2013年9月から行っています。 +[curlプロジェクト](https://curl.haxx.se/)は試験的にhttp2のサポートを2013年9月から行っています。 curlの精神に則り、我々はできるかぎり全てのhttp2の機能を提供する予定です。curlはしばしばテストツール、そしてwebサイトをいろいろと弄くる開発者の手段として使われるので、http2でもこの伝統を引き継ぐ予定です。 @@ -35,10 +35,10 @@ curlにhttp2を使うように指示するには、平文、TLSに関係なく ### 11.5.2 多重化 -libcurlは既存の振る舞いを維持しようとするので、HTTP/2の多重化をアプリケーションで有効にするには[CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html)オプションを使います。このオプションを使わない場合、今まで同様に接続あたりの同時リクエスト数は1になります。 +libcurlは既存の振る舞いを維持しようとするので、HTTP/2の多重化をアプリケーションで有効にするには[CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html)オプションを使います。このオプションを使わない場合、今まで同様に接続あたりの同時リクエスト数は1になります。 -もうひとつ注意してほしいことは、multiインターフェースをつかって複数の転送を同時にlibcurlで行う場合、複数の接続が使われることになります。libcurlを少し待たせて同じ接続にすべての転送を多重化するには、待たせる転送に対して[CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html)オプションを使います。 +もうひとつ注意してほしいことは、multiインターフェースをつかって複数の転送を同時にlibcurlで行う場合、複数の接続が使われることになります。libcurlを少し待たせて同じ接続にすべての転送を多重化するには、待たせる転送に対して[CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html)オプションを使います。 ### 11.5.3 サーバープッシュ -libcurl 7.44.0以降はHTTP/2サーバープッシュをサポートしています。この機能を使うには[CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html)オプションを使ってプッシュコールバックをセットします。プッシュがアプリケーションによって受け入れられた場合、新しいCURL easy handleが作成されて、他の転送と同様にコンテンツを受信します。 +libcurl 7.44.0以降はHTTP/2サーバープッシュをサポートしています。この機能を使うには[CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html)オプションを使ってプッシュコールバックをセットします。プッシュがアプリケーションによって受け入れられた場合、新しいCURL easy handleが作成されて、他の転送と同様にコンテンツを受信します。 diff --git a/ja/part12.md b/ja/part12.md index 94175a0..1b323e3 100644 --- a/ja/part12.md +++ b/ja/part12.md @@ -12,4 +12,4 @@ Googleの[QUIC](https://www.chromium.org/quic)(Quick UDP Internet Connections) QUICは接続の作成を遥かに少ない遅延で行えます。HTTP/2ではパケットロスにより全ストリームがブロックされましたが、QUICでは対象のストリームだけがブロックされるだけですみます。別のネットワークインターフェースをまたいだ接続の維持も可能にします。つまりMPTCPが解決しようとしている問題の領域までカバーしているのです。 -QUICは現時点ではGoogleによってChromeとGoogleサーバーにだけ実装されています。コードは簡単に再利用できる形にはなっていません。[libquic](https://github.com/devsisters/libquic)というプロジェクトがそれを実現しようとしています。プロトコルは[ドラフト](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01)としてIETFトランスポートワーキンググループへ提出されました。 +QUICは現時点ではGoogleによってChromeとGoogleサーバーにだけ実装されています。コードは簡単に再利用できる形にはなっていません。[libquic](https://github.com/devsisters/libquic)というプロジェクトがそれを実現しようとしています。プロトコルは[ドラフト](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01)としてIETFトランスポートワーキンググループへ提出されました。 diff --git a/ja/part13.md b/ja/part13.md index f2f9c68..5487414 100644 --- a/ja/part13.md +++ b/ja/part13.md @@ -2,14 +2,14 @@ この文書の内容または技術的詳細が薄いと考えるなら、あなたの好奇心を満足させる参考文献をここに紹介します: -- HTTPbisメーリングリストとアーカイブ: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- HTTPbisメーリングリストとアーカイブ: https://lists.w3.org/Archives/Public/ietf-http-wg/ - HTML化されたhttp2仕様書: https://httpwg.github.io/specs/rfc7540.html - Firefoxのhttp2ネットワーキングに関する詳細: https://wiki.mozilla.org/Networking/http2 -- curlのhttp2実装に関する詳細: http://curl.haxx.se/docs/http2.html +- curlのhttp2実装に関する詳細: https://curl.haxx.se/docs/http2.html -- http2 webサイト: http://http2.github.io/ and perhaps in particular the FAQ: http://http2.github.io/faq/ +- http2 webサイト: https://http2.github.io/ and perhaps in particular the FAQ: https://http2.github.io/faq/ -- Ilya Grigorikの著書”High Performance Browser Networking”のHTTP/2の章: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- Ilya Grigorikの著書”High Performance Browser Networking”のHTTP/2の章: https://hpbn.co/http2/ diff --git a/ja/part14.md b/ja/part14.md index a1fb40f..33442d6 100644 --- a/ja/part14.md +++ b/ja/part14.md @@ -2,7 +2,7 @@ 発想とパッケージのフォーマットのレゴ画像は、Mark Nottingham氏から。 -HTTPトレンドデータは http://httparchive.org から。 +HTTPトレンドデータは https://httparchive.org/ から。 RTTのグラフはMike Belshe氏のプレゼンテーションから。 diff --git a/ja/part4.md b/ja/part4.md index 46e51bc..cb94874 100644 --- a/ja/part4.md +++ b/ja/part4.md @@ -22,10 +22,10 @@ HTTPの分野でのいくつかの大手プレイヤーはワーキンググル ### 4.1.1. ”bis”の由来 -グループはHTTPbisと命名されていますが、”bis”とは[2を意味するラテン語の副詞](http://en.wiktionary.org/wiki/bis#Latin)です。IETFではBisを仕様の更新や第二幕の時に接尾や名前の一部として使うことが一般的です。HTTP 1.1のときもこれに当てはまります。 +グループはHTTPbisと命名されていますが、”bis”とは[2を意味するラテン語の副詞](https://en.wiktionary.org/wiki/bis#Latin)です。IETFではBisを仕様の更新や第二幕の時に接尾や名前の一部として使うことが一般的です。HTTP 1.1のときもこれに当てはまります。 ## 4.2. http2はSPDYから始まった -[SPDY](http://en.wikipedia.org/wiki/SPDY)はGoogleによって主導され開発されたプロトコルです。彼らは確かにSPDYをオープンにし、誰でも参加できるようにしました。しかし人気のあるブラウザーとユーザーの多いサービスを稼働させている巨大なサーバー群の両方を自らの制御下に置いている、という事実から恩恵を得ていたということは間違いありません。 +[SPDY](https://en.wikipedia.org/wiki/SPDY)はGoogleによって主導され開発されたプロトコルです。彼らは確かにSPDYをオープンにし、誰でも参加できるようにしました。しかし人気のあるブラウザーとユーザーの多いサービスを稼働させている巨大なサーバー群の両方を自らの制御下に置いている、という事実から恩恵を得ていたということは間違いありません。 HTTPbisグループがhttp2について作業を開始しようと決定した時、SPDYはそれ自身のコンセプトの正しさをすでに証明していました。それはインターネットにデプロイ可能であることを示していましたし、その性能を証明する数値も公開されていました。http2は、SPDY/3ドラフトにほんの少しの文字列置換を施したものをhttp2ドラフト-00として始まったのです。 diff --git a/ja/part6.md b/ja/part6.md index 1f6a2ad..bb8c060 100644 --- a/ja/part6.md +++ b/ja/part6.md @@ -62,11 +62,11 @@ HTTP 1.1のリクエストのサイズはとても大きくなってきていて ### 6.5.1. 圧縮は注意を要する困難な問題 -HTTPSとSPDYの圧縮は[BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)と[CRIME](http://en.wikipedia.org/wiki/CRIME)攻撃に対して脆弱でした。文字列をストリームに挿入し出力がどのように変化するかを観測することで、攻撃者は何が送信されているのか知ることができます。 +HTTPSとSPDYの圧縮は[BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)と[CRIME](https://en.wikipedia.org/wiki/CRIME)攻撃に対して脆弱でした。文字列をストリームに挿入し出力がどのように変化するかを観測することで、攻撃者は何が送信されているのか知ることができます。 プロトコルの動的なコンテンツに対する圧縮を、これらの攻撃に対して脆弱ではない方法で行うには、注意深く考える必要があります。これこそHTTPbisチームが行おうとするところのものです。 -そこで[HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt)、HTTP/2のためのヘッダー圧縮、が誕生しました。名前が示す通り、http2ヘッダーのために生み出されたヘッダー圧縮フォーマットであり、独立したインターネットドラフトで定義されています。この新しいフォーマットは、中間装置に対しヘッダーフィールド単位に圧縮しないように指定するビットや、フレームにパッディングを付け加えるオプションもあいまって、悪用しにくくなっているはずです。 +そこで[HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt)、HTTP/2のためのヘッダー圧縮、が誕生しました。名前が示す通り、http2ヘッダーのために生み出されたヘッダー圧縮フォーマットであり、独立したインターネットドラフトで定義されています。この新しいフォーマットは、中間装置に対しヘッダーフィールド単位に圧縮しないように指定するビットや、フレームにパッディングを付け加えるオプションもあいまって、悪用しにくくなっているはずです。 Roberto Peon（HPACKを生み出した人々の中の一人）の言葉です: diff --git a/ja/part7.md b/ja/part7.md index 474b815..bff896a 100644 --- a/ja/part7.md +++ b/ja/part7.md @@ -12,7 +12,7 @@ http2の普及が進むにつれ、HTTP 1.xの時よりもTCP接続がはるか これはHTTPロードバランサーに影響を与え、サイトがクライアントに別のホストに接続してほしいという状況が生まれる可能性があります。それは性能のためだけではなく、サイトがメンテナンスや似たような理由でダウンするときもそうです。 -サーバーはそのような場合[Alt-Svcヘッダー](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (またはhttp2のALTSVCフレーム)を送信し、クライアントにオルタナティブサービスについて伝えます。別のサービス、ホスト、ポート番号を使って、同じコンテンツへ別のルートでアクセスするのです。 +サーバーはそのような場合[Alt-Svcヘッダー](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (またはhttp2のALTSVCフレーム)を送信し、クライアントにオルタナティブサービスについて伝えます。別のサービス、ホスト、ポート番号を使って、同じコンテンツへ別のルートでアクセスするのです。 クライアントはオルタナティブサービスに非同期的に接続を試行し、うまくいったときだけそれを使うようにします。 diff --git a/ja/part8.md b/ja/part8.md index a72e689..f5531a1 100644 --- a/ja/part8.md +++ b/ja/part8.md @@ -43,7 +43,7 @@ Firefoxは最新ドラフトにもっとも速く追随してきたブラウザ Apacheのhttpdサーバは2015年10月9日にリリースされた2.4.17からhttp2モジュール [mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html) が提供されています。 -[H2O](https://h2o.examp1e.net/)、[Apache Traffic Server](http://trafficserver.apache.org/)、[nghttp2](https://nghttp2.org/)、[Caddy](http://caddyserver.com/)、[LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview)は全てhttp2が使用できます。 +[H2O](https://h2o.examp1e.net/)、[Apache Traffic Server](https://trafficserver.apache.org/)、[nghttp2](https://nghttp2.org/)、[Caddy](https://caddyserver.com/)、[LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview)は全てhttp2が使用できます。 ### 8.3.3. その他 @@ -77,7 +77,7 @@ Googleが公式に[発表](https://blog.chromium.org/2015/02/hello-http2-goodbye これはある程度真実だといえます。TLSハンドシェイクは少し余計に時間がかかります。しかしTLSにおいて必要なラウンドトリップを削減する試みが今までもありましたし、現在も進行中です。通信路上で平文ではなくTLSを使うことによるオーバーヘッドは無視できないし、より多くのCPUと電力が同じトラッフィクパターンの平文に比較して使われることになります。それがどのくらいでどの程度の影響力を持つのかについては意見や測定結果次第です。有用な情報源の例として[istlsfastyet.com](https://istlsfastyet.com/)を参照してください。 -電話会社や他のネットワーク事業者、例えばATISオープンWebアライアンス、は、サテライトや機内のようなところでの高速なwebエクスペリエンスを提供するためにキャッシング、圧縮、その他諸々の技術が必要であり、それには[平文のトラッフィクが必要](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf)だと言っています。http2はTLSを必須としているわけではありませんのでこれ以上議論を複雑にすべきではありません。 +電話会社や他のネットワーク事業者、例えばATISオープンWebアライアンス、は、サテライトや機内のようなところでの高速なwebエクスペリエンスを提供するためにキャッシング、圧縮、その他諸々の技術が必要であり、それには[平文のトラッフィクが必要](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf)だと言っています。http2はTLSを必須としているわけではありませんのでこれ以上議論を複雑にすべきではありません。 多くのインターネットユーザーはTLSが広く使われることを望んでいますし、我々はユーザーのプライバシー保護を促進すべきです。 @@ -93,7 +93,7 @@ Googleが公式に[発表](https://blog.chromium.org/2015/02/hello-http2-goodbye ### 8.4.6. ”HTTP 1.1よりも速くない” -これについては、もちろん速いというのが何を意味してどうやって計測するのか議論しなければなりませんが、SPDYの頃から多くのテストが行われていて速いページロードを証明しています（例えば、ワシントン大学の人々による["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf)、Hervé Servyによる["Evaluating the Performance of SPDY-enabled Web Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers)）。このような実験はhttp2でも同様に繰り返されてきました。私はより多くのこのようなテストや実験が公開されることを楽しみにしています。[httpwatch.comによる最初の基本的なテスト](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2)はHTTP/2がその約束を果たしていることを示唆しています。 +これについては、もちろん速いというのが何を意味してどうやって計測するのか議論しなければなりませんが、SPDYの頃から多くのテストが行われていて速いページロードを証明しています（例えば、ワシントン大学の人々による["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf)、Hervé Servyによる["Evaluating the Performance of SPDY-enabled Web Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers)）。このような実験はhttp2でも同様に繰り返されてきました。私はより多くのこのようなテストや実験が公開されることを楽しみにしています。[httpwatch.comによる最初の基本的なテスト](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2)はHTTP/2がその約束を果たしていることを示唆しています。 ### 8.4.7. ”これは階層侵害だ” diff --git a/ko/README.md b/ko/README.md index 8a9fe60..6311258 100644 --- a/ko/README.md +++ b/ko/README.md @@ -6,7 +6,7 @@ http2 설명 7540](https://httpwg.github.io/specs/rfc7540.html)), 배경, 개념, 프로토콜과 현재 구현된 건들에 대한것과 앞으로 미래에 담을 내용이 서술되었습니다. -이 프로젝트는 http://daniel.haxx.se/http2/ 사이트가 공식적으로 인증된 페이지 입니다. +이 프로젝트는 https://daniel.haxx.se/http2/ 사이트가 공식적으로 인증된 페이지 입니다. 문서 전체의 소스코드는 https://github.com/bagder/http2-explained 참조하시기 바랍니다 diff --git a/ko/part1.md b/ko/part1.md index c4c3929..634098c 100644 --- a/ko/part1.md +++ b/ko/part1.md @@ -4,7 +4,7 @@ 2014년 4월 스톡홀롬에서 Daniel이 제출하며 시작되고 이후 세밀하고 정확한 설명으로 가득찬 문서로 전환되고 확장되었습니다. 2015년 5월 발행된 http2의 최종명세의 정식 명칭은 RFC 7540 입니다. -http://www.rfc-editor.org/rfc/rfc7540.txt +https://www.rfc-editor.org/rfc/rfc7540.txt 이 문서에 있는 잘못된 내용들은 모두 나의 결점에서 나온것입니다. 따라서 잘못된 부분은 언제든지 지적해주시기 바라며, 지속적으로 갱신되고 수정될 것입니다. @@ -20,21 +20,21 @@ http://www.rfc-editor.org/rfc/rfc7540.txt Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 도와주세요! 만약 이 문서를 보고 있는 당신이 잘못 된 정보나 누락, 주제넘은 내용을 찾는다면 저에게 해당 문맥을 수정, 최신화 하여 보내주신다면 저는 해당 버젼으로 반영하겠습니다. 저는 이 프로젝트를 돕는 모두에게 적당한 명예적인 보상을 드리겠습니다. 저는 오랜 시간동안 이 문서가 더 나아지길 바랍니다. -이 문서는 이 사이트에서 보실 수 있습니다. [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +이 문서는 이 사이트에서 보실 수 있습니다. [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 라이센스 -이 문서는 Creative commons Attribution 4.0에 해당하고 해당 라이센스는 http://creativecommons.org/licenses/by/4.0/ 여기서 확인하실 수 있습니다. +이 문서는 Creative commons Attribution 4.0에 해당하고 해당 라이센스는 https://creativecommons.org/licenses/by/4.0/ 여기서 확인하실 수 있습니다. ## 1.4 이 문서의 역사 diff --git a/ko/part11.md b/ko/part11.md index 7b0a639..2240690 100644 --- a/ko/part11.md +++ b/ko/part11.md @@ -47,15 +47,15 @@ curl은 아직 기본이 HTTP1.1이고 http2를 사용하는 경우에는 추가 ### 11.5.2 다중화 -libcurl은 기존의 행동을 유지하려고 하기 때문에 HTTP/2의 다중화 응용 프로그램에서 사용하려면 [CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) 옵션을 사용합니다. +libcurl은 기존의 행동을 유지하려고 하기 때문에 HTTP/2의 다중화 응용 프로그램에서 사용하려면 [CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) 옵션을 사용합니다. 이 옵션을 사용하지 않는 경우 지금까지와 같이 연결 당 동시 요청 수는 1이 됩니다. 또 하나 주의해야 할 것은 multi 인터페이스를 사용하여 여러 전송을 동시에 libcurl로 할 경우 다중 연결을 사용하는 것입니다. -libcurl을 동일한 연결에 모든 전송을 다중화 하려면 전송시 [CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) 옵션을 사용합니다. +libcurl을 동일한 연결에 모든 전송을 다중화 하려면 전송시 [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) 옵션을 사용합니다. ### 11.5.3 서버 푸시 libcurl 7.44.0 이후는 HTTP/2 서버 푸시를 지원하고 있습니다. -이 기능을 사용하려면 [CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) 옵션을 사용하여 푸시 콜백을 설정합니다. +이 기능을 사용하려면 [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) 옵션을 사용하여 푸시 콜백을 설정합니다. 푸시가 응용 프로그램에 의해 받아 들여진 경우 새로운 CURL easy handle이 생성되어 다른 전송 뿐만 아니라 컨텐츠를 수신합니다. diff --git a/ko/part12.md b/ko/part12.md index 3efd68f..3d8bbae 100644 --- a/ko/part12.md +++ b/ko/part12.md @@ -20,4 +20,4 @@ QUIC은 연결을 빠르게 할 수 있습니다. HTTP/2는 패킷 손실에 다른 네트워크 인터페이스를 동시에 연결 유지도 가능합니다. 즉 MPTCP이 해결 하려고 하는 문제의 영역까지 커버하려 합니다. QUIC은 현재 Google이 Chrome과 Google 서버에만 구현 되어 있습니다. 코드는 쉽게 재사용 할 수 있는 형태가 되어 있지 않습니다. -libquic라는 프로젝트가 그것을 실현 하려고 하고 있습니다. 프로토콜은 초안으로 [libquic](https://github.com/devsisters/libquic) 전송 워킹 그룹에 [제출](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) 되었습니다 . +libquic라는 프로젝트가 그것을 실현 하려고 하고 있습니다. 프로토콜은 초안으로 [libquic](https://github.com/devsisters/libquic) 전송 워킹 그룹에 [제출](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) 되었습니다 . diff --git a/ko/part13.md b/ko/part13.md index b80a3d4..1f5a25c 100644 --- a/ko/part13.md +++ b/ko/part13.md @@ -3,7 +3,7 @@ 이 문서의 내용 또는 기술적 세부사항이 얇다고 생각한다면 당신의 호기심을 만족시키는 참조 문헌을 여기에 소개합니다: -- HTTPbis 메일 링리스트와 아카이브 : http://lists.w3.org/Archives/Public/ietf-http-wg/ +- HTTPbis 메일 링리스트와 아카이브 : https://lists.w3.org/Archives/Public/ietf-http-wg/ - HTML의 실제 http2 사양 : https://httpwg.github.io/specs/rfc7540.html @@ -12,10 +12,10 @@ - Firefox의 http2 네트워킹 : https://wiki.mozilla.org/Networking/http2 -- curl의 http2 구현 : http://curl.haxx.se/docs/http2.html +- curl의 http2 구현 : https://curl.haxx.se/docs/http2.html -- http2 web 사이트 : http://http2.github.io/ 그리고 FAQ : http://http2.github.io/faq/ +- http2 web 사이트 : https://http2.github.io/ 그리고 FAQ : https://http2.github.io/faq/ -- Ilya Grigorik 의 저서 "High Performance Browser Networking" 의 HTTP / 2 장 : http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- Ilya Grigorik 의 저서 "High Performance Browser Networking" 의 HTTP / 2 장 : https://hpbn.co/http2/ diff --git a/ko/part14.md b/ko/part14.md index 9a1996d..c8d79ee 100644 --- a/ko/part14.md +++ b/ko/part14.md @@ -2,7 +2,7 @@ 발상과 패키지 형식의 레고 이미지는 Mark Nottingham. -HTTP 트렌드 데이터는 http://httparchive.org 에서 참고하였습니다. +HTTP 트렌드 데이터는 https://httparchive.org/ 에서 참고하였습니다. RTT 그래프는 Mike Belshe의 프레젠테이션에서 참고하였습니다. diff --git a/ko/part4.md b/ko/part4.md index 9d22f52..8bb994f 100644 --- a/ko/part4.md +++ b/ko/part4.md @@ -25,10 +25,10 @@ HTTP창시자 중 몇몇은 워킹 그룹 미팅과 논의로부터 잊혀졌습 ### 4.1.1. "bis"라는 이름에 대해서 -그룹의 이름은 HTTPbis에서 "bis"라는 이름은[Latin adverb for two](http://en.wiktionary.org/wiki/bis#Latin)에서 유래되었습니다. IETF에서 Bis는 보통 업데이트나 두번째 스펙을 표시할 경우에 접미사나 이름의 부분으로 사용됩니다. HTTp 1.1업데이트도 마찬가지입니다. +그룹의 이름은 HTTPbis에서 "bis"라는 이름은[Latin adverb for two](https://en.wiktionary.org/wiki/bis#Latin)에서 유래되었습니다. IETF에서 Bis는 보통 업데이트나 두번째 스펙을 표시할 경우에 접미사나 이름의 부분으로 사용됩니다. HTTp 1.1업데이트도 마찬가지입니다. ## 4.2. HTTP2는 SPDY로부터 시작되었다. -[SPDY](http://en.wikipedia.org/wiki/SPDY)는 Google에서 주도개발한 프로토콜입니다. 그들은 확실히 그것을 오픈하고 누구나 참여할 수 있도록 하였지만, 인기있는 브라우져와 사용자가 많은 서비스를 가동시키고 있는 거대한 서버군을 모두 자신의 통제하에 두고있다는 것에 대한 사실에서 확실한 이익이 있었습니다. +[SPDY](https://en.wikipedia.org/wiki/SPDY)는 Google에서 주도개발한 프로토콜입니다. 그들은 확실히 그것을 오픈하고 누구나 참여할 수 있도록 하였지만, 인기있는 브라우져와 사용자가 많은 서비스를 가동시키고 있는 거대한 서버군을 모두 자신의 통제하에 두고있다는 것에 대한 사실에서 확실한 이익이 있었습니다. HTTPbis에서 http2에 대한 작업을 하려 했을때, SPDY는 이미 자신의 워킹컨셉을 입증했습니다. 그것은 배포가 가능하다는 것을 보여주었고 그것의 성능도 수치로 입증하였습니다. SPDY/3 초안에서 시작된 http2 작업은 draft-00에서 약간의 변형을 기반으로 합니다. diff --git a/pt/README.md b/pt/README.md index 7a135da..8dbb72e 100644 --- a/pt/README.md +++ b/pt/README.md @@ -6,7 +6,7 @@ Este é um documento detalhado descrevendo HTTP/2 ([RFC protocolo e algo sobre implementações existentes e o que o futuro pode trazer. -Veja http://daniel.haxx.se/http2/ para a casa canônica deste projeto. +Veja https://daniel.haxx.se/http2/ para a casa canônica deste projeto. Veja https://github.com/bagder/http2-explained para o código fonte de todos os conteúdos do livro. diff --git a/pt/part1.md b/pt/part1.md index 20c1952..969b5ad 100644 --- a/pt/part1.md +++ b/pt/part1.md @@ -5,7 +5,7 @@ como uma apresentação que Daniel fez em Estocolmo em Abril 2014 que foi subsequentemente convertido e alargado para um documento com todos os detalhes e explicações adequadas. -RFC 7540 é o nome oficial da especificação final do HTTP2 e que foi publicado em 15 de maio de 2015: http://www.rfc-editor.org/rfc/rfc7540.txt +RFC 7540 é o nome oficial da especificação final do HTTP2 e que foi publicado em 15 de maio de 2015: https://www.rfc-editor.org/rfc/rfc7540.txt Todos e quaisquer erros neste documento são da minha autoria e os resultados da minha falha. Por favor indique-nos para que possam ser corrigidos numa versão actualizada. @@ -31,9 +31,9 @@ do HTTP 1.1 assim bem como no envolvimento do processo de estandardização do h Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 Ajuda! @@ -41,14 +41,14 @@ do HTTP 1.1 assim bem como no envolvimento do processo de estandardização do h Se encontrar problemas, omissões, erros ou mentiras descaradas neste documento, por favor envie-me uma versão corrigida do parágrafo e eu farei versões corrigidas. Eu darei os merecidos créditos a todas as pessoas que ajudarem! Eu espero fazer este documento melhor ao longo do tempo. -Este documento está disponível em [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +Este documento está disponível em [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 Licença -Este documento está licenciado sob a licença Creative Commons Attribution 4.0: http://creativecommons.org/licenses/by/4.0/ +Este documento está licenciado sob a licença Creative Commons Attribution 4.0: https://creativecommons.org/licenses/by/4.0/ ## 1.4 História do documento diff --git a/pt/part11.md b/pt/part11.md index b72bd81..545144d 100644 --- a/pt/part11.md +++ b/pt/part11.md @@ -1,6 +1,6 @@ # 11. http2 e curl -O [projeto curl](http://curl.haxx.se/) provê suporte experimental para http2 desde Setembro de 2013. +O [projeto curl](https://curl.haxx.se/) provê suporte experimental para http2 desde Setembro de 2013. No espírito do curl, nós pretendemos suportar cada detalhe do http2 que seja possível. curl é frequentemente utilizado como uma ferramenta de teste e uma maneira de “pingar” manualmente _sites_ e nós pretendemos manter isto para http2 também. @@ -34,10 +34,10 @@ Sua aplicação deve utilizar URLs https:// ou http:// normalmente, mas setar a ### 11.5.2 Multiplexação -Como libcurl tenta manter o comportamento existente o máximo possível, será necessário habilitar multiplexação HTTP/2 para sua aplicação com a opção [CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Caso contrário, continuará utilizando uma requisição de cada vez por conexão. +Como libcurl tenta manter o comportamento existente o máximo possível, será necessário habilitar multiplexação HTTP/2 para sua aplicação com a opção [CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Caso contrário, continuará utilizando uma requisição de cada vez por conexão. -Outro pequeno detalhe para ter em mente é que se várias requisições forem solicitadas de uma só vez com libcurl, utilizando sua interface múltipla, uma aplicação pode iniciar qualquer número de transferências de uma vez. Caso seja necessário que o libcurl espere um pouco para adicioná-las na mesma conexão, ao invés de abrir novas conexões para todas elas, a opção [CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) pode ser utilizada para cada transferência que você prefira esperar. +Outro pequeno detalhe para ter em mente é que se várias requisições forem solicitadas de uma só vez com libcurl, utilizando sua interface múltipla, uma aplicação pode iniciar qualquer número de transferências de uma vez. Caso seja necessário que o libcurl espere um pouco para adicioná-las na mesma conexão, ao invés de abrir novas conexões para todas elas, a opção [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) pode ser utilizada para cada transferência que você prefira esperar. ### 11.5.3 Server push -libcurl 7.44.0 e posteriores suportam HTTP/2 server push. Para utilizar esta funcionalidade, indique um callback na opção [CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Se a aplicação aceitar o _push_, uma nova transferência será criada utilizando “CURL easy handle” e o conteúdo será entregue nele, assim como qualquer outra transferência. +libcurl 7.44.0 e posteriores suportam HTTP/2 server push. Para utilizar esta funcionalidade, indique um callback na opção [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Se a aplicação aceitar o _push_, uma nova transferência será criada utilizando “CURL easy handle” e o conteúdo será entregue nele, assim como qualquer outra transferência. diff --git a/pt/part12.md b/pt/part12.md index 9f28f02..f68d3e0 100644 --- a/pt/part12.md +++ b/pt/part12.md @@ -12,4 +12,4 @@ O protocolo [QUIC](https://www.chromium.org/quic) (Quick UDP Internet Connection QUIC permite a criação de conexões com muito menos latência, resolve a perda de pacotes bloqueando apenas os fluxos individuais, ao invés de todos eles como faz o HTTP/2, e permite que novas conexões sejam feitas em diferentes interfaces de rede facilmente - também cobrindo áreas que o MPTCP pretende resolver. -QUIC é, por enquanto, implementado somente pelo Google no Chrome e em seus servidores e esse código não é facilmente reutilizado em outro lugar, mesmo que haja um esforço nesse sentido, como a [libquic](https://github.com/devsisters/libquic). O protocolo está em [draft](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) para o grupo de trabalho de transporte IETF. +QUIC é, por enquanto, implementado somente pelo Google no Chrome e em seus servidores e esse código não é facilmente reutilizado em outro lugar, mesmo que haja um esforço nesse sentido, como a [libquic](https://github.com/devsisters/libquic). O protocolo está em [draft](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) para o grupo de trabalho de transporte IETF. diff --git a/pt/part13.md b/pt/part13.md index a86626a..2455416 100644 --- a/pt/part13.md +++ b/pt/part13.md @@ -2,14 +2,14 @@ Se você acha que esse documento é um pouco superficial em conteúdo e detalhes técnicos, aqui estão recursos adicionar que podem ajudá-lo a satisfazer sua curiosidade: -- A lista de e-mails HTTPbis e seus arquivos: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- A lista de e-mails HTTPbis e seus arquivos: https://lists.w3.org/Archives/Public/ietf-http-wg/ - A especificação http2 em uma versão HTML: https://httpwg.github.io/specs/rfc7540.html - Detalhes de rede do http2 no Firefox: https://wiki.mozilla.org/Networking/http2 -- Detalhes de implementação do http2 no projeto curl: http://curl.haxx.se/docs/http2.html +- Detalhes de implementação do http2 no projeto curl: https://curl.haxx.se/docs/http2.html -- O _site_ http2: http://http2.github.io/ e, talvez, o FAQ: http://http2.github.io/faq/ +- O _site_ http2: https://http2.github.io/ e, talvez, o FAQ: https://http2.github.io/faq/ -- O capítulo sobre HTTP/2 do livro “High Performance Browser Networking” escrito por Ilya Grigorik: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- O capítulo sobre HTTP/2 do livro “High Performance Browser Networking” escrito por Ilya Grigorik: https://hpbn.co/http2/ diff --git a/pt/part14.md b/pt/part14.md index 41a69af..4bd6500 100644 --- a/pt/part14.md +++ b/pt/part14.md @@ -2,7 +2,7 @@ Inspiração e imagem de pacote no formato de Lego de Mark Nottingham. -Dados de tendência HTTP vêm do http://httparchive.org. +Dados de tendência HTTP vêm do https://httparchive.org/. O gráfico RTT vem de apresentações feitas por Mike Belshe. diff --git a/pt/part4.md b/pt/part4.md index 17052ea..16474c2 100644 --- a/pt/part4.md +++ b/pt/part4.md @@ -26,12 +26,12 @@ Alguns dos agentes principais no ramo de HTTP não estiveram nos debates e reuni ### 4.1.1. A parte "bis" do nome -O grupo chama-se HTTPbis de onde a parte "bis" vem do [advérbio de Latim dois ](http://en.wiktionary.org/wiki/bis#Latin). Bis é usado vulgarmente como sufixo ou parte do nome no IETF para uma actualização ou uma segunda revisão da especificação. Tal como no caso do HTTP 1.1. +O grupo chama-se HTTPbis de onde a parte "bis" vem do [advérbio de Latim dois ](https://en.wiktionary.org/wiki/bis#Latin). Bis é usado vulgarmente como sufixo ou parte do nome no IETF para uma actualização ou uma segunda revisão da especificação. Tal como no caso do HTTP 1.1. ## 4.2. http2 começou com o SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) é um protocolo encabeçado e desenvolvido pela Google. Eles certamente que o desenvolveram abertamente ao mundo e convidaram toda a gente a participar mas era obvio que iriam beneficiar se fosse controlado por ambas implementações nos browsers e uma população significante de servidores que sejam muito utilizados. +[SPDY](https://en.wikipedia.org/wiki/SPDY) é um protocolo encabeçado e desenvolvido pela Google. Eles certamente que o desenvolveram abertamente ao mundo e convidaram toda a gente a participar mas era obvio que iriam beneficiar se fosse controlado por ambas implementações nos browsers e uma população significante de servidores que sejam muito utilizados. Quando o grupo HTTPbis decidiu que era tempo de começar a trabalhar no http2, o SPDY ja tinha demonstrado que era um conceito que funcionava. Mostrou que era possível implementar na Internet e havia números publicados que provavam a sua performance. O trabalho http2 começou subsequentemente depois do rascunho do SPDY/3 que era basicamente o rascunho http2 draft-00 com um pouco de mudanças. diff --git a/pt/part6.md b/pt/part6.md index a0c302c..c299f17 100644 --- a/pt/part6.md +++ b/pt/part6.md @@ -61,11 +61,11 @@ As requisições HTTP 1.1 tem realmente crescido tanto de tamanho que às vezes ### 6.5.1. Compressão é um assunto complicado -A compressão de HTTPS e SPDY foi descoberta vulnerável aos ataques [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) e [CRIME](http://en.wikipedia.org/wiki/CRIME). Inserindo um texto conhecido no fluxo e descobrindo como isso altera a saída, um invasor pode descobrir o que está sendo enviado em uma carga criptografada. +A compressão de HTTPS e SPDY foi descoberta vulnerável aos ataques [BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) e [CRIME](https://en.wikipedia.org/wiki/CRIME). Inserindo um texto conhecido no fluxo e descobrindo como isso altera a saída, um invasor pode descobrir o que está sendo enviado em uma carga criptografada. Realizando compressão em conteúdo dinâmico para um protocolo - sem se tornar vulnerável a um destes ataques - exige um pouco de reflexão e análise cuidadosa. Isto é o que o time HTTPbis tentou fazer. -Entra o [HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt), compressão de cabeçalho para HTTP/2, que - como o nome sugere - é um formato de compressão especialmente concebido para cabeçalhos http2, e está sendo especificado em um projeto separado. O novo formato, juntamente com outras medidas (como alguns pedem a intermediários que não comprimam cabeçalhos específicos e preenchimento opcional de quadros), deve torná-lo mais difícil de explorar a compressão. +Entra o [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), compressão de cabeçalho para HTTP/2, que - como o nome sugere - é um formato de compressão especialmente concebido para cabeçalhos http2, e está sendo especificado em um projeto separado. O novo formato, juntamente com outras medidas (como alguns pedem a intermediários que não comprimam cabeçalhos específicos e preenchimento opcional de quadros), deve torná-lo mais difícil de explorar a compressão. Nas palavras de Roberto Peon (um dos criadores do HPACK): diff --git a/pt/part7.md b/pt/part7.md index fd5acdc..cf9657d 100644 --- a/pt/part7.md +++ b/pt/part7.md @@ -12,7 +12,7 @@ Com a adoção do http2, existem razões para suspeitar que as conexões TCP ser Isso afetará o trabalho de balanceamento de carga e podem surgir situações onde uma página queira sugerir ao cliente se conectar a outro servidor. Isto poderia acontecer por questões de desempenho (performance) ou se a página está em manutenção, etc. -O servidor enviará o cabeçalho [Alt-Svc: header](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (ou o quadro ALTSVC com http2) dizendo ao cliente sobre um serviço alternativo: outra rota para o mesmo conteúdo, utilizando outro serviço, servidor e porta. +O servidor enviará o cabeçalho [Alt-Svc: header](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (ou o quadro ALTSVC com http2) dizendo ao cliente sobre um serviço alternativo: outra rota para o mesmo conteúdo, utilizando outro serviço, servidor e porta. Um cliente tentará se conectar ao serviço assincronamente e somente utilizar esta alternativa se a nova conexão for realizada com sucesso. diff --git a/pt/part8.md b/pt/part8.md index 17f7789..f416590 100644 --- a/pt/part8.md +++ b/pt/part8.md @@ -47,7 +47,7 @@ O popular servidor Nginx oferece suporte http2 desde a versão [1.9.5](https://w O servidor httpd Apache tem um módulo http2 [mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html) desde a versão 2.4.17 que foi lançada em 9 de Outubro de 2015. -[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](http://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), [Caddy](http://caddyserver.com/) e [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) lançaram suas versões compatíveis com http2. +[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), [Caddy](https://caddyserver.com/) e [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) lançaram suas versões compatíveis com http2. ### 8.3.3 Outros @@ -81,7 +81,7 @@ De forma alguma. A capacidade de multiplexação certamente ajudará a melhorar Isto pode ser verdade, de certa forma. O “handshake” TLS adiciona um pequeno tempo extra, mas existem esforços em andamento para reduzir o número de viagens (“round-trips”) necessárias. A sobrecarga para fazer TLS por meio da conexão, ao invés de texto puro, não é insignificante e claramente consome mais CPU e energia será gasta da mesma forma que um tráfego não seguro. O quanto e o que isso impactará está sujeito a opiniões e medições. Veja, por exemplo, [istlsfastyet.com](https://istlsfastyet.com/) para mais informações. -Telecomunicações e outros operadores de rede, por exemplo o ATIS Open Web Alliance, dizem que eles [precisam de tráfego não criptografado](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) para oferecer cachê, compressão e outras técnicas necessárias para prover uma rápida experiência _web_ via satélite, para aviões e similares. http2 não torna o uso de TLS obrigatório, portanto não devemos ter problemas com os termos. +Telecomunicações e outros operadores de rede, por exemplo o ATIS Open Web Alliance, dizem que eles [precisam de tráfego não criptografado](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) para oferecer cachê, compressão e outras técnicas necessárias para prover uma rápida experiência _web_ via satélite, para aviões e similares. http2 não torna o uso de TLS obrigatório, portanto não devemos ter problemas com os termos. Muitos usuários da Internet expressaram uma preferência por utilizar TLS de forma mais ampla e nós devemos ajudar a proteger a privacidade dos usuários. @@ -97,7 +97,7 @@ Se você realmente não suporta um protocolo binário, então você também não ### 8.4.6. “Não é mais rápido do que HTTP/1.1” -Naturalmente é um tema sujeito a debate e discussões sobre como medir o que é mais rápido, mas, nos cenários do SPDY, muitos testes foram realizados e o tempo de carga de uma página foi mais rápido (por exemplo ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) pela University of Washington e ["Evaluating the Performance of SPDY-enabled Web Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) por Hervé Servy) e tais experiências também foram feitas com o http2. Estou ansioso para ver mais testes e experiências sendo publicadas. Um [primeiro teste básico feito pelo httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) pode indicar que o HTTP/2 cumpre o que promete. +Naturalmente é um tema sujeito a debate e discussões sobre como medir o que é mais rápido, mas, nos cenários do SPDY, muitos testes foram realizados e o tempo de carga de uma página foi mais rápido (por exemplo ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) pela University of Washington e ["Evaluating the Performance of SPDY-enabled Web Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) por Hervé Servy) e tais experiências também foram feitas com o http2. Estou ansioso para ver mais testes e experiências sendo publicadas. Um [primeiro teste básico feito pelo httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) pode indicar que o HTTP/2 cumpre o que promete. ### 8.4.7. “Não respeita camadas” diff --git a/ru/README.md b/ru/README.md index f9c9a0b..6d7a7e3 100644 --- a/ru/README.md +++ b/ru/README.md @@ -6,7 +6,7 @@ протокол и кое-что о существующих реализациях, а также, что можно ожидать в будущем. -Домашняя страница проекта: http://daniel.haxx.se/http2/ +Домашняя страница проекта: https://daniel.haxx.se/http2/ Исходный код содержимого книги: https://github.com/bagder/http2-explained diff --git a/ru/part1.md b/ru/part1.md index a311176..3a118ed 100644 --- a/ru/part1.md +++ b/ru/part1.md @@ -6,7 +6,7 @@ документ с деталями и надлежащими пояснениями. RFC 7540 – это официальное имя финальной спецификации http2 и она была -опубликована 15 мая 2015: http://www.rfc-editor.org/rfc/rfc7540.txt +опубликована 15 мая 2015: https://www.rfc-editor.org/rfc/rfc7540.txt Все ошибки в данном документе – мои собственные, появившиеся по моей вине. Пожалуйста сообщите мне о них и я выпущу обновление с исправлениями. @@ -29,9 +29,9 @@ HTTP 1.1, для соответствия новейшим требования Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2. Помогите! @@ -41,14 +41,14 @@ HTTP 1.1, для соответствия новейшим требования получиться сделать текст лучше. Этот документ доступен по ссылке -[http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +[https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3. Лицензия Этот документ лицензируется под лицензией Creative Commons Attribution 4.0: -http://creativecommons.org/licenses/by/4.0/ +https://creativecommons.org/licenses/by/4.0/ ## 1.4. История документа diff --git a/ru/part11.md b/ru/part11.md index e9e7743..78e7a5b 100644 --- a/ru/part11.md +++ b/ru/part11.md @@ -1,6 +1,6 @@ # 11. http2 в curl -[Проект curl](http://curl.haxx.se/) начал эксперименты с поддержкой http2, +[Проект curl](https://curl.haxx.se/) начал эксперименты с поддержкой http2, начиная с сентября 2013 года. В духе curl, мы намереваемся поддерживать все аспекты http2, которые сможем. @@ -62,7 +62,7 @@ Curl по прежнему по умолчанию использует HTTP/1.1 Поскольку lubcurl стремится сохранять своё привычное поведение, вам потребуется включить в вашем приложении HTTP/2 мультиплексирования с помощью опции -[CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). +[CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). В противном случае он продолжит использовать по одному одновременному запросу на соединение. @@ -72,7 +72,7 @@ Curl по прежнему по умолчанию использует HTTP/1.1 libcurl немного подождал перед запуском следующей передачи по существующему соединению вместо открытия нового соединения для всех их сразу, вы можете использовать опцию -[CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) для +[CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) для каждой индивидуальной передачи. ### 11.5.3 Посылка сервера @@ -80,7 +80,7 @@ libcurl немного подождал перед запуском следую libcurl версии 7.44.0 и более поздних поддерживает HTTP/2 посылку сервера. Вы можете получить эту возможность установив функцию обратного вызова с помощью опции -[CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). +[CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Если посылка поддерживается приложением, то будет создана новая передача данных, которую CURL легко запустит и получит содержимое так же, как и при любой другой передаче данных. diff --git a/ru/part12.md b/ru/part12.md index de07908..d51d43e 100644 --- a/ru/part12.md +++ b/ru/part12.md @@ -31,5 +31,5 @@ QUIC пока реализован Гуглом только в Chrome и на так просто повторно использовать в других местах, даже несмотря на [libquic](https://github.com/devsisters/libquic), который пытается решить этот вопрос. Протокол был передан как -[черновик](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) в рабочую +[черновик](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) в рабочую группу IETF по транспортным протоколам. diff --git a/ru/part13.md b/ru/part13.md index 68a274b..2a5c17e 100644 --- a/ru/part13.md +++ b/ru/part13.md @@ -5,7 +5,7 @@ ваше любопытство: - Список рассылки HTTPbis и его архивы: - http://lists.w3.org/Archives/Public/ietf-http-wg/ + https://lists.w3.org/Archives/Public/ietf-http-wg/ - Актуальная спецификация http2 в формате html: https://httpwg.github.io/specs/rfc7540.html @@ -13,10 +13,10 @@ - Детали сетевых решений в http2 Firefox: https://wiki.mozilla.org/Networking/http2 -- Детали реализация http2 в curl: http://curl.haxx.se/docs/http2.html +- Детали реализация http2 в curl: https://curl.haxx.se/docs/http2.html -- Сайт http2: http://http2.github.io/ и возможно, в частности, FAQ: - http://http2.github.io/faq/ +- Сайт http2: https://http2.github.io/ и возможно, в частности, FAQ: + https://http2.github.io/faq/ - Глава HTTP/2 в книге Ильи Григорика «High Performance Browser Networking»: - http://chimera.labs.oreilly.com/books/1230000000545/ch12.html + https://hpbn.co/http2/ diff --git a/ru/part14.md b/ru/part14.md index 2a9a533..43858d0 100644 --- a/ru/part14.md +++ b/ru/part14.md @@ -3,7 +3,7 @@ Вдохновение в работе, а также лего-изображение формата пакета получено от Марка Ноттингема. -Данные HTTP-тренда взяты с http://httparchive.org. +Данные HTTP-тренда взяты с https://httparchive.org/. График RTT взят из презентации, выполненной Майком Белше. diff --git a/ru/part4.md b/ru/part4.md index 2da6934..c524b88 100644 --- a/ru/part4.md +++ b/ru/part4.md @@ -45,13 +45,13 @@ RFC продолжатся до следующего года. ### 4.1.1. Суффикс «bis» Группа названа HTTPbis, где суффикс «bis» происходит от [латинского наречия, -которое означает «два»](http://en.wiktionary.org/wiki/bis#Latin). Бис часто +которое означает «два»](https://en.wiktionary.org/wiki/bis#Latin). Бис часто используют как суффикс или часть имени внутри IETF для обновления или второй попыткой работы над спецификацией. Также, как в случае HTTP 1.1. ## 4.2. http2 начался со SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) – это протокол, который был +[SPDY](https://en.wikipedia.org/wiki/SPDY) – это протокол, который был разработан и инициирован в Google. Они определённо разрабатывали его открыто и приглашали всех участвовать, но было очевидно, что они получают преимущество имея контроль над двумя реализациями: популярный веб-браузер и значительная diff --git a/ru/part6.md b/ru/part6.md index 8e9f3b3..c84d9d2 100644 --- a/ru/part6.md +++ b/ru/part6.md @@ -117,14 +117,14 @@ HTTP – это протокол без состояния. Вкратце, эт ### 6.5.1. Сжатие - это непростая тема Сжатие HTTPS и SPDY оказались уязвимыми к атакам -[BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) и -[CRIME](http://en.wikipedia.org/wiki/CRIME). Путём вставки известного текста в +[BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) и +[CRIME](https://en.wikipedia.org/wiki/CRIME). Путём вставки известного текста в поток и наблюдения за тем, как меняется зашифрованный вывод, атакующий мог выяснить, что было отправлено. Выполнение сжатия для динамического контента в протоколе без риска быть подверженным одной из известных атак, требует серьёзного обдумывания и внимательности. То, что команда HTTPbis и пытается делать. -Так появился [HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt), Сжатие +Так появился [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Сжатие заголовков для HTTP/2, который, как и подсказывает название, формат сжатия, предназначенный специально для http2-заголовков и, строго говоря, это отдельный интернет черновик спецификации. Новый формат совместно с другими контр-мерами, diff --git a/ru/part7.md b/ru/part7.md index 3e58d35..6ce54eb 100644 --- a/ru/part7.md +++ b/ru/part7.md @@ -30,7 +30,7 @@ обслуживания или подобных целей. Сервер отправляет заголовок -[Alt-Svc](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (или +[Alt-Svc](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (или ALTSVC-фрейм в http2), сообщая клиенту о наличии альтернативного сервиса. Дополнительный маршрут к такому же контенту, используя другой сервис, хост и номер порта. diff --git a/ru/part8.md b/ru/part8.md index e6af258..73a10e2 100644 --- a/ru/part8.md +++ b/ru/part8.md @@ -76,7 +76,7 @@ curl и libcurl поддерживают как незащищённый http2, одну из нескольких TLS-библиотек. [H2O](https://h2o.examp1e.net/), [Apache Traffic -Server](http://trafficserver.apache.org/) и [nghttp2](https://nghttp2.org/) +Server](https://trafficserver.apache.org/) и [nghttp2](https://nghttp2.org/) выпустили сервера с открытым исходным кодом с поддержкой http2. ### 8.3.1. Отсутствующие реализации @@ -142,7 +142,7 @@ Google публично как один из источников по теме. Телекомы и другие сетевые операторы, например ATIS Open Web Alliance, -утверждают, что им [нужен нешифрованный трафик](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf), чтобы осуществлять кэширование, +утверждают, что им [нужен нешифрованный трафик](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf), чтобы осуществлять кэширование, сжатие и другие технологии, требуемые для быстрой работы через спутники, в самолётах и подобных системах. @@ -180,11 +180,11 @@ http2 не обязывает использовать TLS, поэтому мы SPDY?»](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) людьми из университета Вашингтона и [«Оценка производительности веб-серверов с поддержкой -SPDY»](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) +SPDY»](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) Херва Серви) и подобные эксперименты был повторены также и для http2. Ждём дальнейших публикаций подобных тестов и экспериментов. [Первый базовый тест, проведёный в -httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2), +httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2), обнадёживает, что HTTP/2 сдерживает свои обещания. ### 8.4.7. “Он содержит нарушения независимости слоёв” diff --git a/sv/README.md b/sv/README.md index 2a55525..e79a0e3 100644 --- a/sv/README.md +++ b/sv/README.md @@ -6,7 +6,7 @@ Det här är ett detaljerat dokument som beskriver HTTP/2 ([RFC protokollen och lite om existerande implementationer och vad framtiden kanske erbjuder. -Se http://daniel.haxx.se/http2/ för projektets hemsida. +Se https://daniel.haxx.se/http2/ för projektets hemsida. Se https://github.com/bagder/http2-explained för källkoden till allt innehåll i boken. diff --git a/sv/part1.md b/sv/part1.md index b23ea1f..249e29d 100644 --- a/sv/part1.md +++ b/sv/part1.md @@ -6,7 +6,7 @@ sedemera gjordes om och breddades till ett fullt utvecklat dokument med alla detaljer och riktiga förklaringar. RFC 7540 är det officiella namnet på den slutliga http2-specifikationen och den -blev publicerad den 15:e maj 2015: http://www.rfc-editor.org/rfc/rfc7540.txt +blev publicerad den 15:e maj 2015: https://www.rfc-editor.org/rfc/rfc7540.txt Alla misstag i det är dokumentet är mina egna och resultatet av mina fel. Peka gärna ut dem så åtgärdar vi dem till en kommande uppdatering. @@ -29,9 +29,9 @@ arbetet med standardisering av http2. Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 Hjälp! @@ -41,13 +41,13 @@ kommer jag snart publicera en uppdated version. Jag ger ordentliga omnämnanden och tack till alla som hjälper till! Jag ämnar göra dokumentet bättre över tid. -Det här dokumentet finns tillgängligt på [http://daniel.haxx.se/http2](http://daniel.haxx.se/http2) +Det här dokumentet finns tillgängligt på [https://daniel.haxx.se/http2](https://daniel.haxx.se/http2) ## 1.3 Licens -Det här dokumentet är licenserat under Creative Commons Attribution 4.0 license: http://creativecommons.org/licenses/by/4.0/ +Det här dokumentet är licenserat under Creative Commons Attribution 4.0 license: https://creativecommons.org/licenses/by/4.0/ ## 1.4 Dokumenthistoria diff --git a/sv/part11.md b/sv/part11.md index da9e159..4161c59 100644 --- a/sv/part11.md +++ b/sv/part11.md @@ -1,6 +1,6 @@ # 11. http2 i curl -[curl-projektet](http://curl.haxx.se/) har tillhandahållit experimentell +[curl-projektet](https://curl.haxx.se/) har tillhandahållit experimentell support av http2 sedan september 2013. I curls anda ämnar vi supporta varje aspekt av http2 som vi bara kan. curl @@ -59,21 +59,21 @@ då göra sitt bästa för att använda http2, men annars fortsätta använda HT Eftersom libcurl försöker behålla nuvarande beteende så mycket som möjligt måste du slå på http2 multiplexing för din applikation med -[CURLMOPT_PIPELINING-optionen](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Annars kommer den fortsätta använda en request i taget per koppel. +[CURLMOPT_PIPELINING-optionen](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html). Annars kommer den fortsätta använda en request i taget per koppel. En annan liten detalj att ha i åtanke är att ifall du ber om flera överföringar samtidigt med libcurl, mha dess multi-interface, är att en applikation kan mycket väl starta ett antal överföringar samtidigt och ifall du då hellre vill att libcurl ska vänta lite för att köra alla över samma koppel istället för att starta nya koppel för alla, så använder du -[CURLOPT_PIPEWAIT-optionen](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) +[CURLOPT_PIPEWAIT-optionen](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) för varje individuell överföringing du hellre vill ska vänta. ### 11.5.3 Server push libcurl 7.44.0 och senare stöder HTTP/2 server push. Du kan dra nytta av den funktionen genom att sätta upp en push callback med -[CURLMOPT_PUSHFUNCTION-optionen](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Om +[CURLMOPT_PUSHFUNCTION-optionen](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html). Om "pushen" accepteras av applikationen kommer den skapa en ny överföring som en CURL easy handle och leverera data över den, precis som vilken annan överföring som helst. diff --git a/sv/part12.md b/sv/part12.md index f9d1dfa..c69c813 100644 --- a/sv/part12.md +++ b/sv/part12.md @@ -31,5 +31,5 @@ QUIC är än så länge bara implementerat av Google i Chrome och deras servrar, och den koden är inte lätt att återanvända på andra ställen, även om det finns ett [libquic](https://github.com/devsisters/libquic) som försöker precis det. Protokollet har skrivits ner som en [internet -draft](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) inom IETFs +draft](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) inom IETFs transportarbetsgrupp. diff --git a/sv/part13.md b/sv/part13.md index 0b663e4..6d5884b 100644 --- a/sv/part13.md +++ b/sv/part13.md @@ -3,14 +3,14 @@ Om du tycker att det här dokumentet var lite tunt på innehåll eller tekniska detaljer så finner du ytterligare resurser att främja din nyfikenhet här nedan: -- HTTPbis-arbetsgruppens e-postlista samt dess arkiv: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- HTTPbis-arbetsgruppens e-postlista samt dess arkiv: https://lists.w3.org/Archives/Public/ietf-http-wg/ - Den faktiska http2-specifikationen i HTML-version: https://httpwg.github.io/specs/rfc7540.html - Firefox http2-nätverksdetaljer: https://wiki.mozilla.org/Networking/http2 -- curls http2 implementationsdetaljer: http://curl.haxx.se/docs/http2.html +- curls http2 implementationsdetaljer: https://curl.haxx.se/docs/http2.html -- http2s webbplats: http://http2.github.io/ samt möjligtvis just denna specifika FAQ-fråga: http://http2.github.io/faq/ +- http2s webbplats: https://http2.github.io/ samt möjligtvis just denna specifika FAQ-fråga: https://http2.github.io/faq/ -- Ilya Grigoriks HTTP/2-kapitel i hans bok "High Performance Browser Networking": http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- Ilya Grigoriks HTTP/2-kapitel i hans bok "High Performance Browser Networking": https://hpbn.co/http2/ diff --git a/sv/part14.md b/sv/part14.md index 7551894..f367595 100644 --- a/sv/part14.md +++ b/sv/part14.md @@ -2,7 +2,7 @@ Inspiration och paketformatbilden i Lego kommer från Mark Nottingham. -HTTP trenddata kommer från http://httparchive.org. +HTTP trenddata kommer från https://httparchive.org/. RTT-graferna kommer från presentationer av Mike Belshe. diff --git a/sv/part4.md b/sv/part4.md index 9c61f00..dc37f05 100644 --- a/sv/part4.md +++ b/sv/part4.md @@ -49,7 +49,7 @@ som i fallet för HTTP 1.1. ## 4.2. http2 började från SPDY -[SPDY](http://en.wikipedia.org/wiki/SPDY) är ett protokoll som utvecklades och +[SPDY](https://en.wikipedia.org/wiki/SPDY) är ett protokoll som utvecklades och togs fram av Google. De utvecklade det visserligen öppet och bjöd in alla som vill att delta, men det var tydligt att de utnyttjade sin situation med att kontrollera både en populär webbläsare och ett signifikant server-bestånd med diff --git a/sv/part6.md b/sv/part6.md index b49e01a..ae5f8b5 100644 --- a/sv/part6.md +++ b/sv/part6.md @@ -113,8 +113,8 @@ argument för komprimering. ### 6.5.1. Komprimering är ett lurigt ämne HTTPS- och SPDY-komprimering befanns vara känsliga för -[BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)- och -[CRIME](http://en.wikipedia.org/wiki/CRIME)-attackerna. Genom att infoga känd +[BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)- och +[CRIME](https://en.wikipedia.org/wiki/CRIME)-attackerna. Genom att infoga känd text i strömmarna och se hur det förändrade utdatan, kunde en attackerare lista ut vad som skickades. @@ -122,7 +122,7 @@ Att komprimera dynamiskt innehåll för ett protokoll utan att bli sårbar för dessa attacker kräver lite omtanke och försiktiga övervägningnar. Det är vad HTTPbis-teamet försökte sig på. -In kommer då [HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt), Header- +In kommer då [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header- komprimering för http2, vilket – som namnet lämpligt indikerar - är ett komprimeringsformat speciellt framtaget för http2-headers och det är strikt talat specificerat i en egen specifikation. Det nya formatet, tillsammans med diff --git a/sv/part7.md b/sv/part7.md index 68ce60c..0f6ff15 100644 --- a/sv/part7.md +++ b/sv/part7.md @@ -30,7 +30,7 @@ annan host. Det kan vara för prestandans skull men även om en sajt håller på att tas ner för underhåll och liknande. Servern kommer då skicka -[Alt-Svc:-headern](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) +[Alt-Svc:-headern](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-07) (eller ALTSVC-paketet över http2) och berätta för klienten om en alternativ tjänst. En annan rutt till samma innehåll erbjudet av en annan tjänst, host och portnummer. diff --git a/sv/part8.md b/sv/part8.md index e1a5b48..2e059c9 100644 --- a/sv/part8.md +++ b/sv/part8.md @@ -74,7 +74,7 @@ curl och libcurl stöder osäker http2 likväl som TLS-baserad, användades en a flera olika TLS-bibliotek. [H2O](https://h2o.examp1e.net/), [Apache Traffic -Server](http://trafficserver.apache.org/) och [nghttp2](https://nghttp2.org/) +Server](https://trafficserver.apache.org/) och [nghttp2](https://nghttp2.org/) har alla släppt http2-kapabla open source-servrar. ### 8.3.1. Saknade implementationer @@ -143,7 +143,7 @@ en källa till sådan info. Telecom och andra nätverskoperatörer, till exempel inom ATIS Open Web Alliance, säger att [de behöver okrypterad -trafik](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) +trafik](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf) för att erbjuder cache, komprimering och andra tekniker som är nödvändiga för att tillhandahålla en snabb webbupplevelse över satelit, i flygplan och liknande. http2 gör inte TLS obligatoriskt så vi ska inte blanda ihop @@ -180,11 +180,11 @@ bevisade snabbare sidladdningar (som ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) av folk vid University of Washington och ["Evaluating the Performance of SPDY-enabled Web -Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) +Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) av Hervé Servy) och såna experiment har repeterats med http2 också. Jag ser fram emot att få se fler såna tester och experiment publicerade. Ett [grundläggande första test av -httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) +httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2) kan indikera att http2 håller sina löften. ### 8.4.7. “Den bryter mot lager-principer" diff --git a/tr/part1.md b/tr/part1.md index 4412611..0ff92d8 100644 --- a/tr/part1.md +++ b/tr/part1.md @@ -2,7 +2,7 @@ Bu belge http2'yi teknik açıdan ve protokol düzeyinde açıklamaktadır. Daniel'in Nisan 2014'de Stokholm'de yaptığı bir sunum ile başladı ve bütün detayları ve tüm açıklamaları ile birlikte tam bir dokümana dönüştü. -RFC 7540 son http2 şartnamesinin resmi adıdır ve 15 Mayıs 2015'de yayınlanmıştır(http://www.rfc-editor.org/rfc/rfc7540.txt). +RFC 7540 son http2 şartnamesinin resmi adıdır ve 15 Mayıs 2015'de yayınlanmıştır(https://www.rfc-editor.org/rfc/rfc7540.txt). Bu dokümanda bulunan tüm hatalar bana aittir ve kendi ihmalimin sonucudur. Lütfen güncellenen sürümlerde düzeltilmesi için hataları belirtin. @@ -25,13 +25,13 @@ Benim adım Daniel Stenberg ve Mozilla'da çalışıyorum. Açık kaynak ve ağ Eğer bu dokümanda hatalar, eksiklikler ve bariz yalanlar bulursanız lütfen bu bölümlerin yenilenen halini bana gönderin ve ben de versyonlarda bu hataları düzelteceğim. Yardımcı olan herkese tesekkür ederim. Bu belgeyi zamanla daha iyi hale getirmeyi umuyorum. -Bu doküman http://daniel.haxx.se/http2 adresinde mevcuttur. +Bu doküman https://daniel.haxx.se/http2 adresinde mevcuttur. ## 1.3 Lisans -Bu doküman Creative Commons Attribution 4.0 license altında yayınlanmaktadır (http://creativecommons.org/licenses/by/4.0/). +Bu doküman Creative Commons Attribution 4.0 license altında yayınlanmaktadır (https://creativecommons.org/licenses/by/4.0/). ## 1.4 Doküman tarihçesi diff --git a/tr/part11.md b/tr/part11.md index 09e4bcc..212ae41 100644 --- a/tr/part11.md +++ b/tr/part11.md @@ -1,6 +1,6 @@ # 11. curl içerisinde http2 -[curl projesi](http://curl.haxx.se/), Eylül 2013'ten beri deneysel http2 desteği sağlıyor. +[curl projesi](https://curl.haxx.se/), Eylül 2013'ten beri deneysel http2 desteği sağlıyor. curl ruhu içinde, mümkün olduğunca http2'nin her yönünü desteklemeyi düşünüyoruz. curl sıklıkla bir test aracı ve web sitelerinde takla(poke on) atmanın yolu olarak kullanılır ve bunu http2 için de tutmak niyetindeyiz. @@ -34,18 +34,18 @@ Uygulamanız normal gibi https: // veya http: // URL'leri kullanıyor ancak libc ### 11.5.2 Çoğullama -Libcurl mevcut davranışları büyük ölçüde korumaya çalıştığından, uygulamanız için [CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) seçeneği ile HTTP / 2 çoğullama özelliğini etkinleştirmeniz gerekir. Aksi takdirde, her bağlantı için bir defada bir istek kullanmaya devam edecektir. +Libcurl mevcut davranışları büyük ölçüde korumaya çalıştığından, uygulamanız için [CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html) seçeneği ile HTTP / 2 çoğullama özelliğini etkinleştirmeniz gerekir. Aksi takdirde, her bağlantı için bir defada bir istek kullanmaya devam edecektir. Another little detail to keep in mind is that if you ask for several transfers at once with libcurl, using its multi interface, an applicaton can very well start any number of transfers at once and if you then rather have libcurl wait a little to add them all over the same connection rather than opening new connections for all of them at once, you use the -[CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) option +[CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) option for each individual transfer you rather wait. -Akılda tutulması gereken diğer bir küçük ayrıntı da, bir seferde libcurl ile çoklu aktarım isterseniz, çoklu arayüzü kullanmak, bir uygulama aynı anda herhangi bir sayıda aktarmaya başlayabilir ve daha sonra libcurl'yı eklemek için biraz beklemek zorunda kalırsanız hepsinin aynı anda birden fazla bağlantı kurmasına değil, aynı bağlantıya her seferinde beklediğiniz her bir aktarım için [CURLOPT_PIPEWAIT] [CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) seçeneğini kullanabilirsiniz. +Akılda tutulması gereken diğer bir küçük ayrıntı da, bir seferde libcurl ile çoklu aktarım isterseniz, çoklu arayüzü kullanmak, bir uygulama aynı anda herhangi bir sayıda aktarmaya başlayabilir ve daha sonra libcurl'yı eklemek için biraz beklemek zorunda kalırsanız hepsinin aynı anda birden fazla bağlantı kurmasına değil, aynı bağlantıya her seferinde beklediğiniz her bir aktarım için [CURLOPT_PIPEWAIT] [CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html) seçeneğini kullanabilirsiniz. ### 11.5.3 Sunucu itme -libcurl 7.44.0 ve sonrası, HTTP / 2 sunucu itme özelliğini destekler. [CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) seçeneği ile bir geri arama geri alma kurarak bu özelliğin avantajından yararlanabilirsiniz. Baskı uygulama tarafından kabul edilirse, başka herhangi bir aktarımda olduğu gibi, CURL kolay işleyici olarak yeni bir aktarım oluşturacak ve içeriği teslim edecektir. \ No newline at end of file +libcurl 7.44.0 ve sonrası, HTTP / 2 sunucu itme özelliğini destekler. [CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html) seçeneği ile bir geri arama geri alma kurarak bu özelliğin avantajından yararlanabilirsiniz. Baskı uygulama tarafından kabul edilirse, başka herhangi bir aktarımda olduğu gibi, CURL kolay işleyici olarak yeni bir aktarım oluşturacak ve içeriği teslim edecektir. \ No newline at end of file diff --git a/tr/part12.md b/tr/part12.md index 6bd51b7..a125ecd 100644 --- a/tr/part12.md +++ b/tr/part12.md @@ -12,4 +12,4 @@ Google'ın [QUIC] (https://www.chromium.org/quic) (Hızlı UDP İnternet Bağlan QUIC, çok daha az gecikme ile bağlantıların oluşturulmasına izin verir, sadece HTTP / 2 için olduğu gibi her biri için değil, bireysel akışları engellemek için de paket kaybını çözer ve farklı ağ arayüzleri üzerinden kolayca bağlantı yapılmasını sağlar, dolayısıyla MPTCP'nin çözeceği alanları da kapsar. -QUIC şimdiye kadar yalnızca Google tarafından Chrome'da uygulanmaktadır ve bu kod, bir [libquic] (https://github.com/devsisters/libquic) çabasıyla tam olarak çalışılsa bile başka yerlerde kolayca yeniden kullanılamaz. Protokol IETF ulaştırma çalışma grubuna [taslak] (http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) olarak getirildi. +QUIC şimdiye kadar yalnızca Google tarafından Chrome'da uygulanmaktadır ve bu kod, bir [libquic] (https://github.com/devsisters/libquic) çabasıyla tam olarak çalışılsa bile başka yerlerde kolayca yeniden kullanılamaz. Protokol IETF ulaştırma çalışma grubuna [taslak] (https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01) olarak getirildi. diff --git a/tr/part13.md b/tr/part13.md index 71ca911..4152ce5 100644 --- a/tr/part13.md +++ b/tr/part13.md @@ -2,14 +2,14 @@ Bu belgenin içeriği veya teknik ayrıntıları biraz aydınlattığını düşünüyorsanız merakınızı gidermenize yardımcı olacak ek kaynaklar aşağıda belirtilmiştir: -- HTTPbis posta listesi ve arşivleri: http://lists.w3.org/Archives/Public/ietf-http-wg/ +- HTTPbis posta listesi ve arşivleri: https://lists.w3.org/Archives/Public/ietf-http-wg/ - HTML2 sürümünde asıl http2 belirtimi: https://httpwg.github.io/specs/rfc7540.html - Firefox http2 ağ ayrıntıları: https://wiki.mozilla.org/Networking/http2 -- curl http2 uygulama ayrıntıları: http://curl.haxx.se/docs/http2.html +- curl http2 uygulama ayrıntıları: https://curl.haxx.se/docs/http2.html -- Http2 web sitesi: http://http2.github.io/ and perhaps in particular the FAQ: http://http2.github.io/faq/ +- Http2 web sitesi: https://http2.github.io/ and perhaps in particular the FAQ: https://http2.github.io/faq/ -- Ilya Grigorik'in HTTP / 2 bölümü “High Performance Browser Networking”("Yüksek Performans Tarayıcı Ağı") kitabında: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html +- Ilya Grigorik'in HTTP / 2 bölümü “High Performance Browser Networking”("Yüksek Performans Tarayıcı Ağı") kitabında: https://hpbn.co/http2/ diff --git a/tr/part14.md b/tr/part14.md index 6520f33..157842c 100644 --- a/tr/part14.md +++ b/tr/part14.md @@ -2,7 +2,7 @@ Mark Nottingham'dan ilham ve paket formatı Lego görüntüsü. -HTTP eğilim verileri http://httparchive.org'dan gelir. +HTTP eğilim verileri https://httparchive.org/'dan gelir. RTT grafiği, Mike Belshe tarafından yapılan sunumlardan geliyor. diff --git a/tr/part4.md b/tr/part4.md index 7a1d853..2ea544a 100644 --- a/tr/part4.md +++ b/tr/part4.md @@ -22,10 +22,10 @@ HTTP sahasındaki daha büyük oyuncuların bazıları çalışma grubu tartış ### 4.1.1. İsmin "bis" bölümü -Grup, HTTPbis olarak adlandırıldı ve burada "bis" kısmı iki Latin alfabesinden [Latin adverb for two](http://en.wiktionary.org/wiki/bis#Latin) geliyor. Bis genellikle bir güncelleme için IETF içindeki adın bir sonek veya bir parçası olarak kullanılır veya ikinci bir beyanname'ye geçmek;bu durumda HTTP 1.1 güncellemesi. +Grup, HTTPbis olarak adlandırıldı ve burada "bis" kısmı iki Latin alfabesinden [Latin adverb for two](https://en.wiktionary.org/wiki/bis#Latin) geliyor. Bis genellikle bir güncelleme için IETF içindeki adın bir sonek veya bir parçası olarak kullanılır veya ikinci bir beyanname'ye geçmek;bu durumda HTTP 1.1 güncellemesi. ## 4.2. http2 SPDY'den başladı -[SPDY](http://en.wikipedia.org/wiki/SPDY) Google tarafından geliştirilen ve öncülük eden bir protokoldür. Kesinlikle bunu açık alanda geliştirdiler ve herkesi katılmaya davet ettiler, ancak hem popüler bir tarayıcı uygulaması hem de iyi kullanılan servislere sahip önemli bir sunucu popülasyonu üzerinde kontrol sahibi olduklarından yararlandıkları açıktır. +[SPDY](https://en.wikipedia.org/wiki/SPDY) Google tarafından geliştirilen ve öncülük eden bir protokoldür. Kesinlikle bunu açık alanda geliştirdiler ve herkesi katılmaya davet ettiler, ancak hem popüler bir tarayıcı uygulaması hem de iyi kullanılan servislere sahip önemli bir sunucu popülasyonu üzerinde kontrol sahibi olduklarından yararlandıkları açıktır. HTTPbis grubu http2 üzerinde çalışmaya başlamanın zamanı olduğuna karar verdiklerinde, SPDY zaten bir çalışma konsepti olduğunu kanıtlamıştı. İnternette konuşlandırmanın mümkün olduğunu göstermiş ve ne kadar iyi performansı olduğunu gösteren yayınlanmış rakamlar bulunmaktadır. Http2 çalışması, temelde http2 taslak-00'a küçük bir arama ve değiştirme ile yapılan SPDY/3 taslağı ile başladı. \ No newline at end of file diff --git a/tr/part6.md b/tr/part6.md index b8ef516..515c6db 100644 --- a/tr/part6.md +++ b/tr/part6.md @@ -59,11 +59,11 @@ HTTP 1.1 istek boyutları o kadar büyük oluyor ki bazen ilk TCP penceresinden ### 6.5.1. Sıkıştırma hileli bir konudur -HTTPS ve SPDY sıkıştırmasının [BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) ve [CRIME](http://en.wikipedia.org/wiki/CRIME) saldırılarına karşı savunmasız olduğu tespit edildi. Bilinen metni akışa çıktıyı ekleyerek, nasıl değiştirdiğini öğrenebilir, böylece saldırgan şifreli bir yükte gönderileni anlamaya çalışabilir. +HTTPS ve SPDY sıkıştırmasının [BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29) ve [CRIME](https://en.wikipedia.org/wiki/CRIME) saldırılarına karşı savunmasız olduğu tespit edildi. Bilinen metni akışa çıktıyı ekleyerek, nasıl değiştirdiğini öğrenebilir, böylece saldırgan şifreli bir yükte gönderileni anlamaya çalışabilir. Bir protokol için dinamik içeriğe sıkıştırma yapmak biraz düşünülmesi ve dikkatli olması gereken bir konudur(saldırılardan birine karşı savunmasız hale gelmeden yapılır). HTTPbis ekibi bunu yapmaya çalıştı. -[HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt) bakın, HPACK(adından da anlaşılacağı gibi), HTTP/2 için Başlık Sıkıştırmasıdır. Bu sıkıştırma biçimi özellikle http2 başlıkları için hazırlanmış olup, ayrı bir internet taslağında belirtilmektedir. Yeni format, diğer karşı ölçümlerle(belirli bir üstbilgiyi ve çerçevelerin dolgusunu(adding) sıkıştırmamasını sağlayan bir bit gibi), sıkıştırmanın kullanılmasını zorlaştırır. +[HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt) bakın, HPACK(adından da anlaşılacağı gibi), HTTP/2 için Başlık Sıkıştırmasıdır. Bu sıkıştırma biçimi özellikle http2 başlıkları için hazırlanmış olup, ayrı bir internet taslağında belirtilmektedir. Yeni format, diğer karşı ölçümlerle(belirli bir üstbilgiyi ve çerçevelerin dolgusunu(adding) sıkıştırmamasını sağlayan bir bit gibi), sıkıştırmanın kullanılmasını zorlaştırır. Roberto Peon'un (HPACK'in yaratıcılarından biri) sözleriyle: diff --git a/tr/part7.md b/tr/part7.md index 39dfa75..45bd577 100644 --- a/tr/part7.md +++ b/tr/part7.md @@ -12,7 +12,7 @@ Http2'nin kabulüyle, TCP bağlantılarının çok daha uzun olacağından ve HT Bir site müşterisinin başka bir barındırıcıya bağlanmasını önerdiğinde bu durum HTTP yük dengeleyicilerin çalışmasının etkilenmesine yol acabilir. Bu durum, performans nedenleriyle veya bakım vb. için olabilir. -Sunucu, müşteriye alternatif bir servis[Alt-Svc: header](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (yada http2 ile birlikte ALTSVC çerçevesi) hakkında bilgi vererek gönderir: aynı içeriğe başka bir rota, başka bir servis, ana makine ve port numarası kullanarak. +Sunucu, müşteriye alternatif bir servis[Alt-Svc: header](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10) (yada http2 ile birlikte ALTSVC çerçevesi) hakkında bilgi vererek gönderir: aynı içeriğe başka bir rota, başka bir servis, ana makine ve port numarası kullanarak. Bir istemci daha sonra bu hizmete eşzamansız olarak bağlanmaya çalışmalı ve yeni bağlantı başarılı olursa alternatifi kullanmalıdır. diff --git a/tr/part8.md b/tr/part8.md index fe711b0..3be06c9 100644 --- a/tr/part8.md +++ b/tr/part8.md @@ -44,14 +44,14 @@ Popüler Nginx sunucusu 22 Eylül 2015'te piyasaya sürülen [1.9.5](https://www Apache'nin httpd sunucusu, 9 Ekim 2015'te çıkan 2.4.17'den bu yana http2 modülü [mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html) içeriyor. [H2O](https://h2o.examp1e.net/), [Apache Traffic -Server](http://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), -[Caddy](http://caddyserver.com/) and +Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), +[Caddy](https://caddyserver.com/) and [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) have all released http2 capable servers. [H2O](https://h2o.examp1e.net/), [Apache Traffic -Server](http://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), -[Caddy](http://caddyserver.com/) ve +Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), +[Caddy](https://caddyserver.com/) ve [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview); bu yetenekli sunucuları hepsi http2'yi destekledi. ### 8.3.3 Diğerleri @@ -93,7 +93,7 @@ Hepsi değil. Çoklama yetenekleri, geniş coğrafi dağılımlara sahip olmayan Bu, bir dereceye kadar doğru olabilir. TLS el sıkışması biraz ekstra para harcatabilir, ancak TLS için gereken gidişatları azaltmaya yönelik mevcut ve devam eden çabalar vardır. Düz metin yerine wire-hat? üzerinde TLS yapmak için yapılan ek yük çaba önemsiz değildir, daha fazla CPU ve güç, güvenli olmayan bir protokol ile aynı trafik modelinde harcanır. Ne kadar ve ne gibi bir etkiye sahip olacağı düşünülür. Bir bilgi kaynağı için [istlsfastyet.com](https://istlsfastyet.com/)'a bakın. Telekom ve diğer ağ operatörleri, örneğin ATIS Open Web Alliance'da, uydu, uçak ve benzeri ortamlarda hızlı bir web deneyimi sağlamak için önbellek, sıkıştırma ve diğer teknikler sunacaklarını söylüyorlar[need unencrypted -traffic](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf). http2, TLS kullanımını zorunlu kılmaz, bu nedenle şartları birleştirmemeliyiz. +traffic](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf). http2, TLS kullanımını zorunlu kılmaz, bu nedenle şartları birleştirmemeliyiz. Pek çok İnternet kullanıcısı, kullanıcıların gizliliğinin korunması gerekçesiyle TLS'in daha yaygın kullanılmasını tercih ettiğini belirtti. @@ -113,7 +113,7 @@ If you really can't take a binary protocol, then you couldn't handle TLS and com ### 8.4.6. "HTTP / 1.1'den daha hızlı değil" -Bu tabi ki daha hızlı olanı ölçmenin nasıl yapıldığı üzerine tartışmalara tabidir, ancak daha önce SPDY günlerinde daha fazla tarayıcı sayfası yüklendiğini kanıtlayan birçok test yapıldı (like ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) by people at University of Washington and ["Evaluating the Performance of SPDY-enabled Web Servers"](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) by Hervé Servy) ve bu tür denemeler de http2 ile tekrarlandı. Bu tür testlerin ve deneylerin yayınlanmaya başlaması için sabırsızlıkla bekliyorum. [basic first test made by httpwatch.com](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2), HTTP / 2'nin sözlerini tuttuğunu ima edebilir. +Bu tabi ki daha hızlı olanı ölçmenin nasıl yapıldığı üzerine tartışmalara tabidir, ancak daha önce SPDY günlerinde daha fazla tarayıcı sayfası yüklendiğini kanıtlayan birçok test yapıldı (like ["How Speedy is SPDY?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) by people at University of Washington and ["Evaluating the Performance of SPDY-enabled Web Servers"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) by Hervé Servy) ve bu tür denemeler de http2 ile tekrarlandı. Bu tür testlerin ve deneylerin yayınlanmaya başlaması için sabırsızlıkla bekliyorum. [basic first test made by httpwatch.com](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2), HTTP / 2'nin sözlerini tuttuğunu ima edebilir. ### 8.4.7. "Katman ihlalleri var" diff --git a/zh/README.md b/zh/README.md index 5a57499..377a78d 100644 --- a/zh/README.md +++ b/zh/README.md @@ -4,7 +4,7 @@ http2讲解 这是一篇详细讲解HTTP/2（[RFC 7540](https://httpwg.github.io/specs/rfc7540.html)）的文档，主要内容包括该协议的背景、思想、协议本身的内容、对一些现有实现的探讨与对协议未来的展望。 -若想访问该文档官方主页，请至http://daniel.haxx.se/http2/ +若想访问该文档官方主页，请至https://daniel.haxx.se/http2/ 若想获取本书源码，请至https://github.com/bagder/http2-explained diff --git a/zh/part1.md b/zh/part1.md index e58d63e..fd02fd6 100644 --- a/zh/part1.md +++ b/zh/part1.md @@ -2,7 +2,7 @@ 这篇文档会从技术和协议层面来介绍http2。文档起源于2014年4月我在斯德哥尔摩做了一次相关的演讲，在那之后我对演讲内容的细节进行了一些解释和补充，从而写出了这篇文档。 -正式版http2规格标准叫做RFC 7540，发布于2015年5月15日：http://www.rfc-editor.org/rfc/rfc7540.txt +正式版http2规格标准叫做RFC 7540，发布于2015年5月15日：https://www.rfc-editor.org/rfc/rfc7540.txt 如果你有在这篇文章中发现任何我的失误造成的错误或疏漏，请帮我指正。我会在后续版本中修改。 @@ -16,21 +16,21 @@ Twitter: [@bagder](https://twitter.com/bagder) - Web: [daniel.haxx.se](http://daniel.haxx.se/) + Web: [daniel.haxx.se](https://daniel.haxx.se/) - Blog: [daniel.haxx.se/blog](http://daniel.haxx.se/blog/) + Blog: [daniel.haxx.se/blog](https://daniel.haxx.se/blog/) ## 1.2 帮助我！ 如果你在该文档里面发现任何错误、疏漏，请发送给我一份相关段落更改后的版本，我会进行修正并且注明所有对文档有贡献的人！希望能将这份文档变得越来越好。 -这篇文档可以在[http://daniel.haxx.se/http2](http://daniel.haxx.se/http2)下载。 +这篇文档可以在[https://daniel.haxx.se/http2](https://daniel.haxx.se/http2)下载。 ## 1.3 许可证 -这篇文档基于Createive Commons Attribution 4.0发布： [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/) +这篇文档基于Createive Commons Attribution 4.0发布： [https://creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/) ## 1.4 文档历史 diff --git a/zh/part11.md b/zh/part11.md index 6e187a5..4e779be 100644 --- a/zh/part11.md +++ b/zh/part11.md @@ -1,6 +1,6 @@ # 11. curl中的http2 -[curl项目](http://curl.haxx.se/)从2013年9月就开始对http2提供实验性的支持。 +[curl项目](https://curl.haxx.se/)从2013年9月就开始对http2提供实验性的支持。 为了遵从curl的要旨，我们尽可能全方位地支持http2。curl通常被用作一个网站连接测试工具，希望这项使命也能在http2上被得以延续。 @@ -34,11 +34,11 @@ curl可以使用许多不同TLS的底层库来提供TLS支持，http2也得这 ### 11.5.2 多路复用 -正如libcurl想尽可能量维持以前的用法，你需要通过[CURLMOPT_PIPELINING](http://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html)参数为你的程序启用HTTP/2多路复用功能。不然的话，它会保持一个连接只发送一个请求。 +正如libcurl想尽可能量维持以前的用法，你需要通过[CURLMOPT_PIPELINING](https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html)参数为你的程序启用HTTP/2多路复用功能。不然的话，它会保持一个连接只发送一个请求。 -另一个需要注意的小细节是，当你通过libcurl同时请求多个传输的时候，请使用多接口模式。这样能使应用程序能同时启用任意数量的传输。如果你宁愿让libcurl等待也要把它们放到同一个连接来传输的话，请使用[CURLOPT_PIPEWAIT](http://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html)参数。 +另一个需要注意的小细节是，当你通过libcurl同时请求多个传输的时候，请使用多接口模式。这样能使应用程序能同时启用任意数量的传输。如果你宁愿让libcurl等待也要把它们放到同一个连接来传输的话，请使用[CURLOPT_PIPEWAIT](https://curl.haxx.se/libcurl/c/CURLOPT_PIPEWAIT.html)参数。 ### 11.5.3 服务器推送 -libcurl 7.44.0及其后续版本开始支持HTTP/2服务器推送功能。你可以通过在[CURLMOPT_PUSHFUNCTION](http://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html)参数中设定一个推送回调来激活该功能。如果应用程序接受了该推送，它将为CURL建立一个新的传输，以便接受内容。 +libcurl 7.44.0及其后续版本开始支持HTTP/2服务器推送功能。你可以通过在[CURLMOPT_PUSHFUNCTION](https://curl.haxx.se/libcurl/c/CURLMOPT_PUSHFUNCTION.html)参数中设定一个推送回调来激活该功能。如果应用程序接受了该推送，它将为CURL建立一个新的传输，以便接受内容。 diff --git a/zh/part12.md b/zh/part12.md index c77823c..1bea9fa 100644 --- a/zh/part12.md +++ b/zh/part12.md @@ -12,6 +12,6 @@ Google的[QUIC](https://www.chromium.org/quic) （快速UDP互联网连接）协 QUIC可以创建更低延迟的连接，并且也像HTTP/2一样，通过仅仅阻塞部分流解决了包裹丢失这个问题，让连接在不同网络上建立变得更简单 － 这其实正是MPTCP想去解决的问题。 -QUIC现在还只有Google的Chrome和它后台服务器上的实现，虽然有第三方库[libquic](https://github.com/devsisters/libquic)，但这些代码仍然很难在其他地方被复用。该协议也被IETF通信工作组引入了[草案](http://tools.ietf.org/html/draft-tsvwg-quic-protocol-01)。 +QUIC现在还只有Google的Chrome和它后台服务器上的实现，虽然有第三方库[libquic](https://github.com/devsisters/libquic)，但这些代码仍然很难在其他地方被复用。该协议也被IETF通信工作组引入了[草案](https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01)。 \ No newline at end of file diff --git a/zh/part13.md b/zh/part13.md index 0ce1f56..a9b22ac 100644 --- a/zh/part13.md +++ b/zh/part13.md @@ -2,14 +2,14 @@ 如果对读者你来说，这份文档的内容或技术细节稍显浅尝辄止，下面的资源也许能满足你的好奇： -- HTTPBis小组邮件列表和归档：http://lists.w3.org/Archives/Public/ietf-http-wg/ +- HTTPBis小组邮件列表和归档：https://lists.w3.org/Archives/Public/ietf-http-wg/ - HTML版本的http2协议规范本体：https://httpwg.github.io/specs/rfc7540.html - Firefox http2网络细节：https://wiki.mozilla.org/Networking/http2 -- curl http2实现细节：http://curl.haxx.se/docs/http2.html +- curl http2实现细节：https://curl.haxx.se/docs/http2.html -- http2网站：http://http2.github.io/ ，以及关于http2的FAQ：http://http2.github.io/faq/ +- http2网站：https://http2.github.io/ ，以及关于http2的FAQ：https://http2.github.io/faq/ -- Ilya Grigorik的“High Performance Browser Networking”一书中关于HTTP/2的章节: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html \ No newline at end of file +- Ilya Grigorik的“High Performance Browser Networking”一书中关于HTTP/2的章节: https://hpbn.co/http2/ diff --git a/zh/part14.md b/zh/part14.md index 73f9436..3d81f59 100644 --- a/zh/part14.md +++ b/zh/part14.md @@ -2,7 +2,7 @@ 介绍数据包格式的乐高图片来自于Mark Nottingham，感谢他给我提供的灵感。 -HTTP趋势数据来自http://httparchive.org。 +HTTP趋势数据来自https://httparchive.org/。 RTT图来自Mike Belshe的演讲。 diff --git a/zh/part3.md b/zh/part3.md index 6f6bf3c..383e1e4 100644 --- a/zh/part3.md +++ b/zh/part3.md @@ -35,7 +35,7 @@ Inlining是另外一种防止发送很多小图请求的技巧，它将图片的 最初的HTTP 1.1规范提到一个客户端最多只能对同一主机建立两个TCP连接。因此，为了不和规范冲突，一些聪明的网站使用了新的主机名，这样的话，用户就能和网站建立更多的连接，从而降低载入时间。 -后来，两个连接的限制被取消了，现在的客户端可以轻松地和每个主机建立6-8个连接。但由于连接的上限依然存在，所以网站还是会用这种技术来提升连接的数量。而随着资源个数的提升（上面章节的图例），网站会需要更多的连接来保证HTTP协议的效率，从而提升载入速度。在现今的网站上，使用50甚至100个连接来打开一个页面已经并不罕见。根据[httparchive.org](http://httparchive.org)的最新记录显示，在Top 30万个URL中平均使用40（！）个TCP连接来显示页面，而且这个数字仍然在缓慢的增长中。 +后来，两个连接的限制被取消了，现在的客户端可以轻松地和每个主机建立6-8个连接。但由于连接的上限依然存在，所以网站还是会用这种技术来提升连接的数量。而随着资源个数的提升（上面章节的图例），网站会需要更多的连接来保证HTTP协议的效率，从而提升载入速度。在现今的网站上，使用50甚至100个连接来打开一个页面已经并不罕见。根据[httparchive.org](https://httparchive.org/)的最新记录显示，在Top 30万个URL中平均使用40（！）个TCP连接来显示页面，而且这个数字仍然在缓慢的增长中。 另外一个将图片或者其他资源分发到不同主机的理由是可以不使用cookies，毕竟现今cookies的大小已经非常可观了。无cookies的图片服务器往往意味着更小的HTTP请求以及更好的性能！ diff --git a/zh/part4.md b/zh/part4.md index 36fbccd..44f0a24 100644 --- a/zh/part4.md +++ b/zh/part4.md @@ -22,11 +22,11 @@ HTTPbis工作组（我们待会儿再解释这个名字）在2007年夏天成立 ### 4.1.1. 名字中的“bis” -工作组名字中的“bis”来自拉丁语中表示[“二”](http://en.wiktionary.org/wiki/bis#Latin)的副词，Bis通常被IETF用作名字的后缀来以表示标准的升级或者一些二次工作，比如这里是针对HTTP1.1。 +工作组名字中的“bis”来自拉丁语中表示[“二”](https://en.wiktionary.org/wiki/bis#Latin)的副词，Bis通常被IETF用作名字的后缀来以表示标准的升级或者一些二次工作，比如这里是针对HTTP1.1。 ## 4.2. 起源于SPDY的http2 -[SPDY](http://en.wikipedia.org/wiki/SPDY)是由Google牵头开发的协议。他们将其开源，使得每个人都可以参与开发。但很明显，他们通过控制浏览器的实现和享用着优质服务的大量用户来获益。 +[SPDY](https://en.wikipedia.org/wiki/SPDY)是由Google牵头开发的协议。他们将其开源，使得每个人都可以参与开发。但很明显，他们通过控制浏览器的实现和享用着优质服务的大量用户来获益。 当HTTPbis小组决定开始制定http2的时候，SPDY已经充分证实了它是一个非常好用的方案。当时已经有人在互联网上成功部署SPDY，并且也有一些文章讨论他的性能。因此，http2便基于SPDY/3草案进行一些修改之后发布了http2的draft-00。 diff --git a/zh/part6.md b/zh/part6.md index a0c78b0..015b9a0 100644 --- a/zh/part6.md +++ b/zh/part6.md @@ -59,11 +59,11 @@ HTTP 1.1请求的大小正变得越来越大，有时甚至会大于TCP窗口的 ### 6.5.1. 压缩是非常棘手的课题 -HTTPS和SPDY的压缩机制被发现有受[BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)和[CRIME](http://en.wikipedia.org/wiki/CRIME)攻击的隐患。通过向流中注入一些已知的文本来观察输出的变化，攻击者可以从加密的载荷中推导出原始发送的数据。 +HTTPS和SPDY的压缩机制被发现有受[BREACH](https://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)和[CRIME](https://en.wikipedia.org/wiki/CRIME)攻击的隐患。通过向流中注入一些已知的文本来观察输出的变化，攻击者可以从加密的载荷中推导出原始发送的数据。 为协议的动态内容进行压缩并使其免于被攻击，需要仔细且全面的考虑，而这也正是HTTPbis小组尝试去做的。 -[HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt)，HTTP/2头部压缩，顾名思义它是一个专为http2头部设计的压缩格式。确切的讲，它甚至被制定写入在另外一个单独的草案里。新的格式同时引入了一些其他对策让破解压缩变得困难，例如采用帧的可选填充和用一个bit作为标记，来让中间人不压缩指定的头部。 +[HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt)，HTTP/2头部压缩，顾名思义它是一个专为http2头部设计的压缩格式。确切的讲，它甚至被制定写入在另外一个单独的草案里。新的格式同时引入了一些其他对策让破解压缩变得困难，例如采用帧的可选填充和用一个bit作为标记，来让中间人不压缩指定的头部。 用Roberto Peon（HPACK的设计者之一）的话说 diff --git a/zh/part7.md b/zh/part7.md index 9f619e2..3ae5324 100644 --- a/zh/part7.md +++ b/zh/part7.md @@ -12,7 +12,7 @@ http2协议强制规定了接收方必须读取并忽略掉所有未知帧（即 但这会影响到HTTP负载均衡器的正常工作，比如在一个网站会出于性能的考虑，当然也可能是正常的维护或者一些类似的原因，想建议客户端连接到另外一个主机的时候。 -服务器将会通过发送[Alt-Svc头](http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10)（或者http2的ALTSVC帧）来告知客户端另一个备选服务。即另外一条指向不同的服务源、主机或端口，但却能获取同样内容的路由。 +服务器将会通过发送[Alt-Svc头](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10)（或者http2的ALTSVC帧）来告知客户端另一个备选服务。即另外一条指向不同的服务源、主机或端口，但却能获取同样内容的路由。 客户端应该尝试异步的去连接到该服务，如果连接成功的话，即可以使用该备选服务。 diff --git a/zh/part8.md b/zh/part8.md index d7c9e21..36f1bc1 100644 --- a/zh/part8.md +++ b/zh/part8.md @@ -44,7 +44,7 @@ Firefox一直紧跟最新的协议，Twitter也紧追不舍提供了基于http2 而Apache HTTPD服务器也实现了一个名为[mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html)的http2模块，并与2015年10月9号在2.4.17的版本中发布。 -此外，[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](http://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), [Caddy](http://caddyserver.com/) 以及 [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) 也都发布了可以工作于http2下的服务器。 +此外，[H2O](https://h2o.examp1e.net/), [Apache Traffic Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/), [Caddy](https://caddyserver.com/) 以及 [LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview) 也都发布了可以工作于http2下的服务器。 ### 8.3.3 其他 @@ -76,9 +76,9 @@ Wireshark同样支持了http2, 所以用它来分析http2网络数据流着实 ### 8.4.4. “TLS让速度变得更慢” -这个评价在某种程度上是对的。虽然TLS的握手确实增加了额外的开销，但也有越来越多的方案提出来减少TLS往返的时间。使用TLS而不是纯文本带来的开销是显著的，有可观证据表明，和传输同样的流量相比，TLS会消耗更多的CPU和其他资源。具体影响有多大以及怎么影响是一个和具体测量有关的课题。更多的例子可以参看[istlsfastyet.com](http://istlsfastyet.com)。 +这个评价在某种程度上是对的。虽然TLS的握手确实增加了额外的开销，但也有越来越多的方案提出来减少TLS往返的时间。使用TLS而不是纯文本带来的开销是显著的，有可观证据表明，和传输同样的流量相比，TLS会消耗更多的CPU和其他资源。具体影响有多大以及怎么影响是一个和具体测量有关的课题。更多的例子可以参看[istlsfastyet.com](https://istlsfastyet.com/)。 -Telecom和一些其他网络服务商，例如ATIS开放网络联盟，表示为了为卫星、飞机等提供的快速网络体验，他们需要一些[不加密的流量](http://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf )来提供caching，压缩和其他技术。 +Telecom和一些其他网络服务商，例如ATIS开放网络联盟，表示为了为卫星、飞机等提供的快速网络体验，他们需要一些[不加密的流量](https://www.atis.org/openweballiance/docs/OWAKickoffSlides051414.pdf )来提供caching，压缩和其他技术。 由于http2并不强制要求使用TLS，所以我们不应该为此担心。 @@ -96,7 +96,7 @@ Telecom和一些其他网络服务商，例如ATIS开放网络联盟，表示为 ### 8.4.6. “它根本没有比HTTP/1.1快” -当然，到底该如何定义和衡量“快”就是另外一个话题了，但在SPDY的时代，已经有很多实验证明了该协议会让浏览器载入页面变得更快（例如华盛顿大学的[“SPDY有多快？”](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf)和Hervé Servy的[“评估启用SPDY后的Web服务器的性能”](http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers/)），同样这些实验也可以被用来证明http2。我期待能有越来越多的诸如此类的测试实验结果发布。而这篇文章[httpwatch.com的一个简单测试](http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/)亦能证明HTTP/2名副其实。 +当然，到底该如何定义和衡量“快”就是另外一个话题了，但在SPDY的时代，已经有很多实验证明了该协议会让浏览器载入页面变得更快（例如华盛顿大学的[“SPDY有多快？”](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf)和Hervé Servy的[“评估启用SPDY后的Web服务器的性能”](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers/)），同样这些实验也可以被用来证明http2。我期待能有越来越多的诸如此类的测试实验结果发布。而这篇文章[httpwatch.com的一个简单测试](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/)亦能证明HTTP/2名副其实。 ### 8.4.7. “它违反了网络分层”