diff --git a/src/posts/2024/03/http2-and-http3-explained.md b/src/posts/2024/03/http2-and-http3-explained.md
index 0369549..cee4587 100644
--- a/src/posts/2024/03/http2-and-http3-explained.md
+++ b/src/posts/2024/03/http2-and-http3-explained.md
@@ -126,6 +126,7 @@ With HTTP/2, this problem is solved with *streams*, each stream corresponds to a
HTTP/2 streams are composed by *frames*, each one containing: the frame type, the stream that it belongs to, and the length in bytes. In the diagram below, a coloured rectangle is a TCP packet and a ✉ is a HTTP/2 frame inside it. The first and third TCP packets carry frames of different streams.
```mermaid
+%%{init: {'theme':'neutral'}}%%
sequenceDiagram
rect rgb(239,190,125)
Client->>+Server: req1: #9993;1/1
+
req2: #9993;1/1
@@ -155,6 +156,7 @@ HTTP/2 solves the HTTP head-of-line blocking, but, this problem also happens wit
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.
```mermaid
+%%{init: {'theme':'neutral'}}%%
sequenceDiagram
rect rgb(239,190,125)
Client->>+Server: req1: #9993;1/1
+
req2: #9993;1/1
@@ -176,6 +178,7 @@ To solve TCP's head-of-line blocking, QUIC decided to use UDP for its transport
{% asset_img '2024_03_http3_quic_packets.png' 'HTTP3 QUIC packets' %}
```mermaid
+%%{init: {'theme':'neutral'}}%%
sequenceDiagram
rect rgb(253, 213, 224)
Client->>Server: req1: #9993;1/1
+
req2: #9993;1/1
+
req3: #9993;1/1
diff --git a/src/posts/2024/03/http2-e-http3-explicados.md b/src/posts/2024/03/http2-e-http3-explicados.md
index 758bba5..aa3eca9 100644
--- a/src/posts/2024/03/http2-e-http3-explicados.md
+++ b/src/posts/2024/03/http2-e-http3-explicados.md
@@ -114,7 +114,6 @@ Dentre as principais mudanças, estão a multiplexação de várias mensagens de
No HTTP/1.1, duas requisições HTTP não podem trafegar juntas em uma mesma conexão TCP - é necessário que a primeira delas termine para que a subseqüente se inicie. Isso se chama bloqueio de cabeça de fila (*head-of-line blocking*, em inglês). No diagrama abaixo, a requisição 2 não pode começar até que a resposta 1 tenha chegado, considerando que apenas uma conexão TCP é usada.
```mermaid
-%%{init: {'theme':'neutral'}}%%
sequenceDiagram
Cliente->>+Servidor: req 1
Servidor-->>-Cliente: res 1
@@ -182,18 +181,18 @@ Para resolver o bloqueio de cabeça de fila do TCP, o QUIC opta por utilizar o U
%%{init: {'theme':'neutral'}}%%
sequenceDiagram
rect rgb(253, 213, 224)
- Client->>Server: req1: #9993;1/1
+
req2: #9993;1/1
+
req3: #9993;1/1
+ Cliente->>Servidor: req1: #9993;1/1
+
req2: #9993;1/1
+
req3: #9993;1/1
end
rect rgb(179, 205, 230)
- Server--xClient: res1: #9993;1/2
+
res2: #9993;1/2
+ Servidor--xCliente: res1: #9993;1/2
+
res2: #9993;1/2
end
- Note over Client,Server: pacote QUIC perdido
não bloqueia outros pacotes
+ Note over Cliente,Servidor: pacote QUIC perdido
não bloqueia outros pacotes
rect rgb(179, 205, 230)
- Server-->>Client: res1: #9993;2/2
+
res2: #9993;2/2
+
res3: #9993;1/1
+ Servidor-->>Cliente: res1: #9993;2/2
+
res2: #9993;2/2
+
res3: #9993;1/1
end
- Note over Client,Server: reenvio do pacote perdido.
res3 não foi afetado
+ Note over Cliente,Servidor: reenvio do pacote perdido.
res3 não foi afetado
rect rgb(179, 205, 230)
- Server-->>Client: res1: #9993;1/2
+
res2: #9993;1/2
+ Servidor-->>Cliente: res1: #9993;1/2
+
res2: #9993;1/2
end
```