From f0bdc5f806da2bd68b30fc206971cf44d4b2c424 Mon Sep 17 00:00:00 2001 From: Alexandre Bonfitto Date: Tue, 12 Mar 2024 12:45:27 -0300 Subject: [PATCH] article: fix sequence diagram alternating between light and dark mode --- src/posts/2024/03/http2-and-http3-explained.md | 3 +++ src/posts/2024/03/http2-e-http3-explicados.md | 13 ++++++------- 2 files changed, 9 insertions(+), 7 deletions(-) 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 ```