article: text changes

alexandrehtrb · Mar 13, 2024 · fb09193 · fb09193
1 parent b5e7c61
commit fb09193
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 3 deletions.
diff --git 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
@@ -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