From fb09193325f6ca3140afa6272e460db0d317bd39 Mon Sep 17 00:00:00 2001 From: Alexandre Bonfitto Date: Wed, 13 Mar 2024 09:36:59 -0300 Subject: [PATCH] article: text changes --- src/posts/2024/03/http2-and-http3-explained.md | 4 ++-- src/posts/2024/03/http2-e-http3-explicados.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/posts/2024/03/http2-and-http3-explained.md b/src/posts/2024/03/http2-and-http3-explained.md index fd6d6e2..9e39a96 100644 --- a/src/posts/2024/03/http2-and-http3-explained.md +++ b/src/posts/2024/03/http2-and-http3-explained.md @@ -152,7 +152,7 @@ HTTP/3 was born from a new transport protocol, QUIC, created by Google in 2012. HTTP/2 solves the HTTP head-of-line blocking, but, this problem also happens with TCP and TLS. TCP understands that the data it needs to send is a contiguous sequence of packets, and if any packet is lost, it must be resent, in order to preserve information integrity. *With TCP, subsequent packets cannot be sent until the lost packet is successfully resent to the destination.* -The diagram below explains visually how this happens in HTTP/2. The second packet only had frames of response 1, but its loss delays both of responses - that means that in this case, there is no parallelism. +The diagram below explains visually how this happens in HTTP/2. The second packet only had frames of response 1, but its loss delays both response 1 and response 2 - that means that in this case, there is no parallelism. ```mermaid sequenceDiagram @@ -171,7 +171,7 @@ sequenceDiagram end ``` -To solve TCP's head-of-line blocking, QUIC decided to use UDP for its transport protocol, because UDP does not care for guarantees of arrival. The data integrity responsibility, that in TCP is part of the transport layer, is moved in QUIC to the application layer, and the frames of a message can arrive out of order, without blocking unrelated streams. +To solve TCP's head-of-line blocking, QUIC decided to use UDP for its transport protocol, because UDP does not care for guarantees of arrival. The responsibility of data integrity, that in TCP is part of the transport layer, is moved in QUIC to the application layer, and the frames of a message can arrive out of order, without blocking unrelated streams. {% asset_img '2024_03_http3_quic_packets.png' 'HTTP3 QUIC packets' %} diff --git a/src/posts/2024/03/http2-e-http3-explicados.md b/src/posts/2024/03/http2-e-http3-explicados.md index 82e30f6..9e60185 100644 --- a/src/posts/2024/03/http2-e-http3-explicados.md +++ b/src/posts/2024/03/http2-e-http3-explicados.md @@ -152,7 +152,7 @@ O HTTP/3 surgiu diante de um novo protocolo de transporte proposto pelo Google, O HTTP/2 consegue resolver o bloqueio de cabeça de fila relacionado ao HTTP, porém, esse tipo de bloqueio também existe no protocolo TCP e no TLS. O TCP entende que os dados que deve enviar fazem parte de uma seqüência de pacotes contígüos, e se um desses pacotes for perdido, ele deve ser reenviado para o destinatário, a fim de que se preserve a integridade da informação. *No TCP, pacotes subseqüentes não podem ser enviados enquanto o pacote perdido não chegar com sucesso no destino.* -O diagrama abaixo explica visualmente como isso ocorre no HTTP/2. O segundo pacote tinha *frames* apenas da resposta 1, porém a perda dele atrasa ambas as respostas - ou seja, não há paralelismo nesse caso. +O diagrama abaixo explica visualmente como isso ocorre no HTTP/2. O segundo pacote tinha *frames* apenas da resposta 1, porém a perda dele atrasa tanto a resposta 1 como a resposta 2 - ou seja, não há paralelismo nesse caso. ```mermaid sequenceDiagram