DEV Community: Gabriel Amarantes

[Boost]

Gabriel Amarantes — Wed, 08 Oct 2025 11:07:56 +0000

Understanding Codecs, Containers, and Bitrates: What Every Developer Using FFmpeg Should Know

Willem Janssen ・ Oct 7

#ffmpeg #video #dotnet #media

[Boost]

Gabriel Amarantes — Tue, 30 Sep 2025 11:17:38 +0000

Willem Janssen

Sep 30 '25

How to Build a Command-Line Video Converter with .NET 8 and FFmpeg

#csharp #tutorial #dotnet #cli

Comments 2

2 min read

[Boost]

Gabriel Amarantes — Fri, 26 Sep 2025 11:28:12 +0000

🚀 Clean Commit Messages: Why & How

Mhammed Talhaouy ・ Sep 26

#commit #git #development #ai

C# Parallelism - A Quick Overview

Gabriel Amarantes — Fri, 05 Sep 2025 13:00:00 +0000

Have you ever wondered how your PC can run so many apps at the same time? Or why your application freezes while processing something intensive?

In this article, we'll explore the concepts of Parallelism and Concurrency, specifically in C#. What are they? How are they different? And most importantly, how can we write parallel code to make our applications faster?

Let's get started!

What is Concurrency?

Concurrency means managing multiple tasks over the same period, but not necessarily executing them at the exact same instant.

Imagine a restaurant with just one chef. To be efficient, the chef starts boiling water for pasta. While the water is heating up (a waiting period), they start chopping vegetables for a salad. The chef is making progress on both tasks by switching between them. This is concurrency.

In computing, this is what happens on a single-core CPU. The CPU performs context switching: it runs a small piece of one task, then quickly switches to another. It does this so fast that it creates the illusion of tasks running at the same time.

What is Parallelism?

Parallelism is when multiple tasks are executed at the exact same time, each on its own CPU core.

Let's return to our restaurant. Now, it has two cooks. Cook 1 can make the pasta while Cook 2 makes the salad, simultaneously. They are working in parallel. This approach truly saves time because more work gets done in the same period.

Parallel programming uses this exact approach. Instead of running tasks one after another, we execute them simultaneously to maximize the use of our hardware. For example, an application processing video from multiple cameras can handle each feed at the same time.

True parallelism is only possible when you have more than one CPU core (or in our analogy, more than one cook!).

Threads

A thread is the smallest unit of execution within a process (a process is your running program, like an .exe). Every C# application starts with a main thread, but we can create additional threads (called worker threads) to run tasks in parallel or concurrently.

To create a thread manually, you instantiate the System.Threading.Thread class and pass it the method you want to execute. Then, you call the Start() method to begin execution.

You can request a thread to stop using a CancellationToken or pause it using Thread.Sleep. However, manually creating and destroying threads is resource-intensive, consuming significant CPU time and memory. Because of this complexity and cost, you should be careful when using the Thread class directly.

Task Parallel Library (TPL)

Fortunately, .NET provides a much better way to write parallel code without needing to manage threads manually. It’s a powerful library called the Task Parallel Library (TPL), and it handles all the complex work of dividing tasks among CPU cores for you. The TPL dynamically scales the degree of concurrency to use all available processor most efficiently.

Under the hood, the TPL uses the ThreadPool, which is a pool of pre-created worker threads ready to execute work. This avoids the high cost of creating and destroying threads for every small task.

TPL Examples

Scenario 1: Processing a Collection

Let’s look at a common scenario: processing a large collection of items. Imagine we have a method that performs a CPU-intensive operation, like converting thousands of videos.

Sequential code

Parallel code

By simply switching from foreach to Parallel.ForEach , we told the TPL to run the ConvertToMp4 operation on multiple CPU cores at the same time. The TPL automatically manages everything, and the result is a massive performance boost.

Scenario 2: Running Independent Operations

Now, let’s look another scenario: running two independent operations concurrently.

Sequential Code

Parallel Code

In the sequential code, we wait for GetMkvVideos() to finish completely before we even start GetMp4Videos().

By using Task.WhenAll, we start both operations at the same time and wait for them both to complete. This is ideal for asynchronous I/O operations (like database queries or API calls). While one operation is waiting for a response from the network, the other can be running. This overlaps the waiting periods, drastically reducing the total time and making better use of resources.

Conclusion

Use Parallel for CPU-Bound Work. Is your code doing heavy calculations, image processing, or complex transformation? Parallel.ForEach is an excellent choice.
Use async/await for I/O-Bound Work. Is your code waiting for a database, an API call, or reading a file from network? async/await with Task.WhenAll is the right tool. It prevents threads from being blocked while waiting.
Always Prefer the TPL over Thread. The Task Parallel Library (Task, Parallel.ForEach) is safer, more efficient, and easier to use than creating threads manually. Avoid new Thread() unless you have a very specific reason.
Measure, Don’t Guess! Parallelism has a small overhead. For very small or very fast loops, it can sometimes be slower than a sequential one. Always use a Stopwatch to measure your code and confirm you’re getting a real performance benefit.

Parallelism is a powerful tool in the modern C# developer’s toolkit. By understanding the basics of the TPL, you can unlock the full potential of today’s multi-core processors and build faster, more responsive applications.

References

For more informartion, check out the official Microsoft documentation:

Desvendando o HTTP: O Protocolo por Trás da Web e das APIs

Gabriel Amarantes — Tue, 01 Jul 2025 23:36:55 +0000

Imagine a internet como uma conversa global entre milhões de computadores. Para que essa comunicação funcione sem ruídos, todos precisam falar o mesmo "idioma". Esse idioma universal da web é o HTTP (Hypertext Transfer Protocol).
É graças a ele que seu navegador consegue carregar esta página e que as APIs RESTful, que você constrói e consome, trocam dados de forma estruturada e previsível.

Neste artigo vamos entender o HTTP. Desmontaremos suas mensagens, entenderemos seus métodos e códigos de status e veremos como tudo isso se aplica na prática com exemplos em ASP.NET Core. O objetivo é dar a você, desenvolvedor, o conhecimento necessário para construir sistemas mais robustos, eficientes e seguros.

O que é HTTP?

O HTTP (Hypertext Transfer Protocol), ou Protocolo de Transferência de Hipertexto, é um protocolo da camada de aplicação que funciona como o alicerce para a troca de dados na World Wide Web. Embora o nome "Hipertexto" remeta aos primórdios da web (links e documentos), hoje ele é usado para transferir qualquer tipo de dado: JSON, imagens, vídeos, etc.

Podemos pensar em um protocolo como um conjunto de regras para uma conversa. O HTTP define exatamente como essa conversa deve acontecer entre dois participantes principais: o cliente e o servidor.

Cliente-Servidor

A comunicação HTTP segue um fluxo rigoroso e unidirecional:

O Cliente Faz a Requisição: O cliente (um navegador, seu aplicativo C# ou até uma geladeira inteligente) sempre inicia a comunicação, enviando uma mensagem de requisição (request) a um servidor para solicitar um recurso ou ação (ex: "me dê a página de login" ou "crie este novo usuário").
O Servidor Envia a Resposta: O servidor (onde sua API ASP.NET Core está hospedada, por exemplo) processa a requisição e devolve uma mensagem de resposta (response), contendo o resultado daquela solicitação. O servidor nunca inicia uma conversa; ele apenas responde.

Essa comunicação é feita através de mensagens de texto legíveis por humanos (no HTTP/1.1) e transportada de forma confiável pelo TCP (Transmission Control Protocol), que garante que as mensagens cheguem sem erros e na ordem correta.

O protocolo HTTP não é exclusivo de navegadores, qualquer dispositivo conectado a rede pode usa-lo, como Smartphones, Carros, Geladeiras, SmartWatchs, etc.

Stateless

Uma das características mais importantes e definidoras do HTTP é que ele é stateless (sem estado). Isso significa que cada requisição é um evento completamente independente. O servidor não tem nenhuma memória das requisições anteriores feitas pelo mesmo cliente.

Imagine uma conversa onde, a cada frase que você fala, precisa se reapresentar e dar todo o contexto novamente. É assim que o HTTP funciona. Se você faz login em uma requisição, o servidor não se lembrará de você na próxima.

Embora pareça uma limitação, esse design torna o sistema mais simples e escalável. Para contornar essa "amnésia" e manter o contexto (como um usuário logado), os desenvolvedores utilizam estratégias como:

Tokens de Autorização (JWT): O cliente recebe um "crachá" (token) após o login e o apresenta em cada requisição futura para provar quem é.
Cookies: O servidor envia um pequeno dado (cookie) para o cliente armazenar. O cliente, então, envia esse mesmo cookie de volta a cada nova requisição para aquele servidor, ajudando a "lembrá-lo" de informações passadas.

Estrutura de uma mensagem HTTP

Tanto as requisições do cliente quanto as respostas do servidor seguem uma estrutura padrão, composta por três partes principais: uma linha inicial (Start-Line), um bloco de cabeçalhos (Headers) e, opcionalmente, um corpo (Body). Vamos entender cada uma.

Requisição (Request)

Imagine que nosso aplicativo C# precisa criar um novo usuário através de uma API. A mensagem HTTP enviada ao servidor seria parecida com esta:

Vamos analisar a estrutura:

Start-Line (Linha de Requisição): POST /api/usuarios HTTP/1.1
- Método (Verbo): POST. A ação que o cliente deseja executar;
- URI (Request Target): /api/usuarios. O caminho do recurso no servidor.
- Versão do HTTP: HTTP/1.1. A versão do protocolo que está sendo usada.
Headers (Cabeçalhos): O bloco de texto seguinte, contendo pares de chave-valor (Host, Content-Type, etc.), que fornecem metadados essenciais sobre a requisição.
Linha em Branco: Note que existe uma linha vazia que separa os cabeçalhos do corpo da mensagem. Isso não é opcional! É essa linha que sinaliza para o servidor o fim dos cabeçalhos e o início do corpo.
Body (Corpo): {"nome": "Usuario", ...}. É aqui que os dados são efetivamente enviados. O corpo é opcional e geralmente usado com métodos como POST, PUT e PATCH.

Resposta (Response)

Se o usuário for criado com sucesso, o servidor poderia responder com a seguinte mensagem:

A estrutura é muito similar:

Start-Line (Linha de Status): HTTP/1.1 201 Created
- Versão do HTTP: HTTP/1.1.
- Código de Status (Status Code): 201. Um número que indica o resultado da requisição.
- Mensagem de Status (Reason Phrase): Created. Uma breve descrição textual do código.
Headers (Cabeçalhos): Metadados sobre a resposta (Date, Content-Type, etc.).
Linha em Branco: Separa os cabeçalhos do corpo.
Body (Corpo): O recurso que foi criado ou solicitado, neste caso, o JSON do novo usuário.

Headers

Os cabeçalhos são o coração dos metadados no HTTP. Eles são pares de chave-valor, onde a chave não diferencia maiúsculas de minúsculas (case-insensitive). Abaixo estão alguns dos mais comuns que todo desenvolvedor deve conhecer:

Host: (Requisição) Especifica o domínio do servidor (e a porta, se não for a padrão). Essencial para que o servidor saiba qual site ou API está sendo chamado. Ex: Host: api.github.com.
Authorization: (Requisição) Fornece as credenciais para autenticar o cliente no servidor. Muito usado com o padrão Bearer Token para enviar JWTs. Ex: Authorization: Bearer <token>.
Accept: (Requisição) Informa ao servidor quais tipos de conteúdo (MIME types) o cliente é capaz de entender. Ex: Accept: application/json.
Content-Type: (Requisição/Resposta) Indica o tipo de mídia do corpo da mensagem. Ex: Content-Type: application/json; charset=utf-8.
Content-Length: (Requisição/Resposta) O tamanho do corpo da mensagem em bytes. Ex: Content-Length: 56.
User-Agent: (Requisição) Uma string que identifica o cliente (navegador, aplicação C#, etc.). Ex: User-Agent: MeuAppC#/1.0.
Allow: (Resposta) Em uma resposta 405 Method Not Allowed, o servidor informa quais métodos são permitidos para aquele recurso. Ex: Allow: GET, POST.
Location: (Resposta) Usado em redirecionamentos (status 3xx) ou em respostas de criação (status 201) para indicar a URL do novo recurso. Ex: Location: /api/usuarios/123.
Cookie: (Requisição) Contém os cookies previamente enviados pelo servidor com o cabeçalho Set-Cookie.
Set-Cookie: (Resposta) Envia um cookie do servidor para ser armazenado pelo cliente. Ex: Set-Cookie: sessionId=abc123; HttpOnly.

Métodos (ou verbos) HTTP

Se as mensagens HTTP são as "cartas" que trocamos com o servidor, os Métodos (ou Verbos) HTTP são a primeira palavra dessa carta, indicando a intenção principal: você quer ler, criar, modificar ou apagar algo? Em uma API RESTful, esses verbos são a base para a manipulação de recursos.

Antes de detalharmos cada um, precisamos entender dois conceitos técnicos cruciais que os diferenciam:

Segurança (Safe): Um método é considerado seguro se ele não altera o estado do recurso no servidor. Pense nisso como uma operação de "apenas leitura". Você pode fazer a requisição quantas vezes quiser sem causar efeitos colaterais.
Idempotência (Idempotent): Um método é idempotente se realizar a mesma requisição várias vezes produz exatamente o mesmo resultado que realizá-la uma única vez.
- Exemplo: DELETE /usuarios/123. A primeira chamada apaga o usuário. A segunda, terceira e quarta chamadas retornarão um erro "Não Encontrado", mas o estado final do servidor é o mesmo: o usuário 123 continua apagado.
- Contraexemplo: POST /usuarios. Chamar isso três vezes criará três novos usuários diferentes. Portanto, POST não é idempotente.

Verbos Essenciais do CRUD

GET (Ler)
O que faz: Solicita a representação de um recurso específico ou uma coleção de recursos.
Características: É seguro e é idempotente.
Exemplos:
- GET /api/usuarios (busca a lista de todos os usuários)
- GET /api/usuarios/123 (busca o usuário com ID 123)
Em ASP.NET Core: [HttpGet]

POST (Criar)
O que faz: Envia dados (no corpo da requisição) para o servidor para criar um novo recurso.
Características: Não é seguro e não é idempotente.
Exemplo: POST /api/usuarios (cria um novo usuário com os dados enviados no corpo)
Em ASP.NET Core: [HttpPost]

PUT (Atualizar/Substituir)
O que faz: Substitui completamente um recurso existente com os dados enviados no corpo. Se o recurso não existir, pode criá-lo.
Características: Não é seguro, mas é idempotente. (Enviar o mesmo corpo 5 vezes para a mesma URL resultará no mesmo estado final do recurso).
Exemplo: PUT /api/usuarios/123 (substitui todos os dados do usuário 123)
Em ASP.NET Core: [HttpPut]

DELETE (Apagar)
O que faz: Remove um recurso específico.
Características: Não é seguro, mas é idempotente.
Exemplo: DELETE /api/usuarios/123 (apaga o usuário 123)
Em ASP.NET Core: [HttpDelete]

PATCH (Atualizar/Modificar)
O que faz: Aplica uma modificação parcial a um recurso existente. Ao contrário do PUT, você envia apenas os campos que deseja alterar.
Características: Não é seguro e, geralmente, não é idempotente (duas requisições PATCH com "adicione 10 ao valor" teriam resultados diferentes se executadas duas vezes).
Exemplo: PATCH /api/usuarios/123 (atualiza apenas o e-mail do usuário 123)
Em ASP.NET Core: [HttpPatch]

Outros Métodos

Existem outros verbos que você pode encontrar, embora sejam menos comuns no desenvolvimento de APIs:

HEAD: Idêntico ao GET, mas o servidor retorna apenas os cabeçalhos, sem o corpo da resposta. Útil para verificar metadados (como o Content-Length de um arquivo grande) sem baixá-lo.
OPTIONS: Descreve as opções de comunicação para o recurso alvo. É muito usado nos bastidores pelo mecanismo de CORS do navegador.

Códigos de Status HTTP

Após o servidor processar uma requisição, ele envia de volta um Código de Status (Status Code). Esse número de três dígitos é a forma mais rápida e clara que uma API tem para dizer ao cliente o resultado da operação: "Deu tudo certo", "Você cometeu um erro" ou "Eu cometi um erro".

Dominar esses códigos é essencial para construir APIs previsíveis e fáceis de depurar. Eles são agrupados em cinco classes:

1. Informativa (100 - 199)

Raras no dia a dia do desenvolvimento de APIs REST. Indicam que a requisição foi recebida e o processo continua.

100 - Continue: Indica que o cliente pode continuar a requisição ou ignorar a resposta caso a requisição já tenha terminado;
101 - Switching Protocols: É usado para responder um header de solicitação de atualização do cliente e indica o protocolo para qual o servidor esta alternando.

2. Sucesso (200 -299)

A classe que todos gostamos de ver. Indica que a requisição foi recebida, entendida e aceita com sucesso.

200 - Ok: Indica um sucesso genérico, o resultado depende do do método HTTP. Por exemplo, quando retornamos este código em uma requisição GET significa que o recurso foi recuperado e transmitido no corpo da mensagem.
- Em ASP.NET Core: return Ok(meuRecurso);
201 - Created: A requisição foi um sucesso e um novo recurso foi criado. Normalmente retornado em uma requisição POST.
- Em ASP.NET Core: return CreatedAtAction(nameof(GetRecursoPorId), new { id = novoRecurso.Id }, novoRecurso);
202 - Accepted: A requisição foi recebida mas ainda não foi atendida. Normalmente utilizada quando o servidor esta processando outra solicitação, ou para vários processamentos ao mesmo tempo.
- Em ASP.NET Core: return Accepted();
204 - No Content: A requisição foi um sucesso, mas não possui conteúdo a retornar. Muito utilizado em um requisição DELETE ou PUT/PATCH.
- Em ASP.NET Core: return NoContent();

3. Redirecionamento (300 - 399)

Indica que o cliente precisa tomar uma ação adicional para completar a requisição, geralmente acessando uma nova URL.

301 - Moved Permanently: Utilizado quando a URL do recurso foi alterada permanentemente. A nova URL é passada na resposta.
302 - Found: Utilizado quando a URI foi alterada temporariamente.

4. Erro do Cliente (400 - 499)

A culpa é do cliente. A requisição tem algo errado: sintaxe inválida, falta de autenticação, etc. Esta é a classe mais importante para validação de dados em APIs.

400 - Bad Request: O servidor não conseguiu ou não vai processar a requisição por conta de um erro na requisição. Por exemplo, uma requisição malformada, erro de sintaxe, etc.
- Em ASP.NET Core: return BadRequest("O campo 'nome' é obrigatório.");
401 - Unauthorized: Embora o padrão HTTP especifique "não autorizado", semanticamente essa resposta significa "não autenticado". Ou seja, o cliente precisa se autenticar para obter a resposta solicitada.
403 - Forbidden: Agora sim, o cliente está autenticado (logado), mas ele não tem permissão para acessar aquele recurso específico. É uma questão de autorização, não de autenticação.
404 - Not Found: O servidor não conseguiu achar o recurso solicitado. Em um navegador, significa que a URL não foi reconhecida. Em uma API, também pode significar que o endpoint é válido mas o recurso solicitado não existe.
- Em ASP.NET Core: return NotFound();
429 - Too Many Requests: O cliente fez muitas requisições em um curto periodo de tempo e foi limitado.

5. Erro do Servidor (500 - 599)

A culpa é nossa (do servidor). Algo deu errado do nosso lado e não conseguimos atender a uma requisição aparentemente válida.

500 - Internal Server Error: O erro genérico. Em 99% dos casos em ASP.NET Core, isso significa que ocorreu uma exceção não tratada no seu código.
503 - Service Unavailable: O servidor não esta pronto para atender a requisição. Comumente utilizado quando servidor esta sobrecarregado ou em manutenção.

Consumindo e Criando Endpoints em ASP.NET Core

Até agora, vimos a teoria: a estrutura das mensagens, os verbos e os códigos de status. Agora, vamos ver como tudo isso funciona em .NET.

Nesta seção, vamos construir duas peças:

Um Servidor: Uma API RESTful simples com ASP.NET Core para gerenciar uma lista de produtos.
Um Cliente: Uma aplicação de Console em C# que consome essa API usando HttpClient.

Para ambos os projetos, usaremos a seguinte classe de modelo:

O Servidor em API ASP.NET Core

Vamos criar um Controller que expõe endpoints para listar e criar produtos. Em um projeto real, você usaria um banco de dados, mas para manter o foco no HTTP, usaremos uma lista estática em memória

O que este Controller faz?

[HttpGet]: Responde a requisições GET /api/products retornando a lista completa de produtos e um status 200 OK.
[HttpGet("{id}")]: Responde a GET /api/products/1, por exemplo. Ele busca o produto e retorna 200 OK se o encontrar, ou 404 Not Found se não encontrar.
[HttpPost]: Responde a POST /api/products. Ele recebe os dados de um novo produto do corpo (Body) da requisição, adiciona-o à lista e retorna um 201 Created, usando CreatedAtAction para gerar a URL correta do novo produto no header Location.

O Cliente com `HttpClient`

Agora, vamos criar uma aplicação de Console que irá chamar nossa API. Para isso, usaremos a classe HttpClient, a principal ferramenta do .NET para fazer requisições HTTP.

Program.cs de um projeto Console

O que este Cliente faz?

GetAllProductsAsync: Monta e envia uma requisição GET. Ele usa EnsureSuccessStatusCode() para verificar se a resposta foi um sucesso (qualquer código 2xx) e depois usa ReadFromJsonAsync para converter o JSON da resposta diretamente em uma lista de objetos Product.
CreateProductAsync: Usa PostAsJsonAsync para serializar um objeto Product para JSON e enviá-lo no corpo de uma requisição POST. Após a chamada, ele verifica se o status foi 201 Created e extrai o header Location para confirmar que a API retornou a URL do novo recurso, fechando o ciclo que iniciamos com CreatedAtAction no servidor.

HTTP/1.1 a HTTP/3

O HTTP não é uma tecnologia estática. À medida que a web evoluiu de simples páginas de texto para aplicações complexas e interativas, o protocolo precisou se adaptar para entregar mais conteúdo, mais rápido e de forma mais eficiente.

HTTP/1.1

Por quase duas décadas, o HTTP/1.1 foi a espinha dorsal da web. Ele trouxe melhorias cruciais sobre seu antecessor, como o reaproveitamento de conexões (Keep-Alive), que evitou o custo de abrir uma nova conexão TCP para cada recurso, e o header Host, que permitiu a hospedagem de múltiplos sites no mesmo IP.

No entanto, o HTTP/1.1 sofria de um problema fundamental de design: o Head-of-Line (HOL) Blocking.

Analogia para o HOL Blocking: Imagine um caixa de supermercado (uma conexão TCP). Você tem vários itens para passar (CSS, JS, imagens). O HTTP/1.1 funciona como uma única fila: você precisa esperar o item da frente ser processado para passar o próximo. Se o primeiro item for grande e demorado (uma imagem pesada), todos os outros itens pequenos (ícones, arquivos de estilo) ficam travados na fila, esperando.

HTTP/2

O HTTP/2 foi projetado especificamente para resolver o HOL Blocking no nível da aplicação. Sua principal inovação foi a Multiplexação.

Com a Multiplexação, voltando à nossa analogia, é como se o mesmo caixa de supermercado pudesse processar vários itens de clientes diferentes ao mesmo tempo, de forma intercalada, na mesma conexão. Uma imagem grande pode começar a ser processada, e enquanto isso, um arquivo CSS e um JS podem ser processados em paralelo sem esperar.

Outras melhorias importantes do HTTP/2 incluem:

Server Push: Uma correção importante aqui. Não se trata de enviar atualizações quando dados mudam. Na verdade, é a capacidade do servidor de antecipar as necessidades do cliente. Ao pedir uma página HTML, o servidor já "empurra" o CSS e o JS que ele sabe que serão necessários, sem esperar o navegador pedi-los. É como o caixa te entregar as pilhas junto com o controle remoto, porque ele sabe que você vai precisar.
Compressão de Cabeçalhos (HPACK): Reduz o tamanho dos metadados enviados em cada requisição, economizando banda.

HTTP/3

O HTTP/2 resolveu o HOL Blocking na aplicação, mas o problema ainda existia na camada de transporte (TCP). Se um único pacote TCP (um pedaço da nossa comunicação) se perdesse na rede, toda a conexão TCP parava para esperar a recuperação daquele pacote, bloqueando todos os fluxos multiplexados do HTTP/2.

A solução do HTTP/3 foi radical: abandonar o TCP e usar um novo protocolo de transporte chamado QUIC, que roda sobre UDP.

As principais vantagens são:

Eliminação do HOL Blocking do TCP: Como o QUIC gerencia seus próprios fluxos de forma independente, a perda de um pacote em um fluxo (ex: o de uma imagem) não bloqueia os outros (ex: o do CSS).
Conexão mais rápida: O processo de estabelecimento de conexão (handshake) é muito mais rápido que o do TCP com TLS.
Migração de Conexão (Connection ID): O HTTP/3 identifica a conexão por um "Connection ID", e não pelo par IP:Porta. Isso significa que se você sair do Wi-Fi e entrar no 4G, seu celular muda de IP, mas a conexão HTTP/3 continua ativa sem interrupções. É uma virada de jogo para a internet móvel.

Segurança com HTTPS

Até agora, vimos como o HTTP funciona. Mas, por padrão, ele transmite todos os dados em texto puro, o que é um enorme risco de segurança. Qualquer um que intercepte a comunicação pode ler tudo.

Para resolver isso, temos o HTTPS (Hypertext Transfer Protocol Secure). Ele não é um protocolo novo; é o mesmo HTTP que já conhecemos, mas com uma camada de segurança adicional fornecida pelo protocolo TLS (Transport Layer Security), o sucessor do antigo SSL.

O TLS oferece três garantias fundamentais, os pilares da comunicação segura na web:

Pilar 1: Criptografia (Confidencialidade)

O que é? Garante que os dados trocados entre o cliente e o servidor sejam ilegíveis para qualquer um.

Como funciona? Através da criptografia. Imagine que você quer enviar os dados do seu cartão de crédito. Sem criptografia, seria como enviar um cartão postal: qualquer um no caminho pode ler. Com a criptografia, é como colocar o cartão postal dentro de um cofre que só o destinatário tem a chave para abrir. Mesmo que alguém intercepte o cofre, verá apenas metal, não o conteúdo. Essa "mágica" é feita com um par de chaves (pública e privada) durante o aperto de mão inicial (handshake) para estabelecer uma conexão segura, e então com chaves simétricas mais rápidas para a troca de dados em si.

Pilar 2: Autenticidade

O que é? Garante que você está realmente se comunicando com o servidor que você espera (ex: google.com), e não com um impostor se passando por ele.

Como funciona? Através dos Certificados Digitais (SSL/TLS Certificates). O certificado é um "documento de identidade" digital para o servidor, emitido por uma Autoridade Certificadora (AC) confiável (como Let's Encrypt ou GoDaddy). Seu navegador já vem com uma lista de ACs em que ele confia.

Quando você acessa um site, o servidor apresenta esse certificado. Seu navegador verifica se:

O certificado foi emitido para o domínio que você está acessando.
O certificado não expirou.
Ele foi assinado por uma AC que o seu navegador confia.

Se tudo estiver correto, o navegador exibe o cadeado de segurança. Se não, ele exibe um aviso severo de que a conexão não é privada.

Pilar 3: Integridade

O que é? Assegura que os dados não foram modificados no meio do caminho.

Como funciona? Cada mensagem trocada inclui um "código de autenticação de mensagem" (MAC), que funciona como um selo de segurança. Esse código é gerado com base no conteúdo da mensagem e uma chave secreta que só o cliente e o servidor conhecem. Se um invasor alterar um único bit da mensagem, o MAC não corresponderá mais ao conteúdo, e a alteração será detectada imediatamente.

SSL vs. TLS

Você ouvirá os termos SSL e TLS usados quase como sinônimos, mas eles não são.

SSL (Secure Sockets Layer): Foi o protocolo original criado pela Netscape. Todas as suas versões (SSL 1.0, 2.0, 3.0) são hoje consideradas inseguras e obsoletas.
TLS (Transport Layer Security): É o sucessor oficial e moderno do SSL, mantido pela IETF. Estamos atualmente em versões como TLS 1.2 e 1.3.

A regra é simples: use sempre TLS. Embora as pessoas ainda falem em "certificado SSL", o protocolo que ele usa para garantir a segurança é, na verdade, o TLS.

Por que Dominar o HTTP é Crucial?

Ao longo deste artigo, fizemos uma viagem profunda pela espinha dorsal da web e das APIs. Desmontamos o HTTP, peça por peça, não como um acrônimo abstrato, mas como a linguagem viva que permite que nossos sistemas conversem. Vimos a estrutura de suas mensagens, a gramática de seus verbos e códigos de status, sua evolução em busca de performance com o HTTP/2 e HTTP/3, e a armadura indispensável de segurança que o HTTPS fornece.

E aqui, respondemos à pergunta central: por que um desenvolvedor deve se importar tanto com isso?

Porque o HTTP transcendeu os navegadores. Hoje, ele é o alicerce para praticamente toda a arquitetura de software moderna: de APIs RESTful que conectam seus microserviços, passando por aplicações mobile que consomem dados da nuvem, até dispositivos de IoT que enviam status para um servidor. Entender HTTP profundamente é a diferença entre apenas usar um framework como o ASP.NET Core e saber de verdade o que acontece sob o capô. É o que permite a você depurar problemas de forma mais inteligente, otimizar a performance de suas requisições e construir APIs que são não apenas funcionais, mas também seguras, eficientes e previsíveis.

É claro que, embora o HTTP seja o protagonista no palco da web, ele faz parte de um ecossistema mais amplo de protocolos, cada um com um propósito especializado:

FTP (File Transfer Protocol): Como o nome sugere, é otimizado para a transferência de arquivos entre cliente e servidor.
SMTP (Simple Mail Transfer Protocol): É o protocolo padrão para o envio de e-mails pela internet.
SSH (Secure Shell): Usado para administrar e executar comandos em servidores remotos de forma segura.
Modelos como o P2P (Peer-to-Peer): Oferecem uma arquitetura descentralizada onde os participantes se comunicam diretamente, em contraste com o modelo cliente-servidor centralizado do HTTP.

Reconhecer esses outros protocolos nos dá perspectiva. Mostra que, para cada tipo de problema de comunicação, existe uma ferramenta projetada para resolvê-lo da melhor forma.

No entanto, para você, desenvolvedor que constrói o futuro em serviços e aplicações conectadas, o HTTP continuará sendo seu principal campo de atuação. Dominá-lo não é apenas um diferencial; é a base sólida sobre a qual sistemas resilientes e de alta performance são construídos. Ele é o fluxo invisível, mas vital, que dá vida às aplicações que você cria todos os dias.

Referências

Documentação Essencial

MDN Web Docs sobre HTTP: O melhor e mais completo portal para desenvolvedores web entenderem todos os aspectos do HTTP, de conceitos básicos a listas de headers e códigos de status.
- MDN - Uma visão geral do HTTP
Cloudflare Learning Center: Explicações claras e acessíveis sobre conceitos de rede e segurança, incluindo a diferença entre SSL e TLS.
- Cloudflare - O que é SSL?

Para Desenvolvedores .NET

Microsoft Docs: Criar Web APIs com ASP.NET Core: O tutorial oficial da Microsoft para começar a construir APIs RESTful, como a que vimos no nosso exemplo prático.
- Tutorial: Criar uma API Web com o ASP.NET Core
Microsoft Docs: Fazer requisições HTTP com HttpClient: A documentação oficial sobre a classe HttpClient, com exemplos e melhores práticas (como o uso de IHttpClientFactory).
- Fazer solicitações HTTP usando a classe HttpClient

Artigos e Guias de Aprofundamento

Curso Alura - HTTP: entendendo a web por baixo dos panos: Um curso em português que oferece uma base sólida sobre o protocolo.
DevMedia - HTTP Headers: Um guia prático sobre os principais cabeçalhos HTTP.
- Artigo DevMedia

Leitura Avançada

Para os que desejam ir direto à fonte, as RFCs (Request for Comments) são os documentos que padronizam o protocolo na internet. A leitura é densa e técnica, mas é a especificação definitiva.

Um Guia para Gerenciar Segredos no .NET e Azure DevOps

Gabriel Amarantes — Thu, 19 Jun 2025 15:15:10 +0000

No mundo do desenvolvimento de software, uma das jornadas mais comuns é levar um projeto da nossa máquina local para o mundo, seja através de um repositório público no GitHub ou por meio de um pipeline de implantação contínua (CI/CD) no Azure DevOps. No entanto, precisamos ter uma atenção especial quando se trata de segurança.
Este artigo nasce de uma experiência real e de um desafio que enfrentei recentemente: Como gerenciar um projeto .NET que usa chaves de API secretas, mantendo um repositório público limpo e, ao mesmo tempo, garantindo que o build automatizado no Azure DevOps funcione perfeitamente?

Uma Chave Secreta no Lugar Errado

Minha jornada começou com um projeto de estudos e meu primeiro contato com o Azure. Decidi utilizar o Service Bus para implementar uma funcionalidade de exclusão de usuários de forma assíncrona, via mensageria.

Pense no Microsoft Azure Service Bus como um carteiro digital superconfiável. É um mediador de mensagens na nuvem que serve para desacoplar aplicações, permitindo que elas troquem dados de forma segura e assíncrona. Ele utiliza filas (para comunicação um-para-um, seguindo o padrão FIFO - "primeiro a entrar, primeiro a sair") e tópicos (para comunicação um-para-muitos).

Para conectar minha aplicação a uma fila do Service Bus, o Azure me forneceu uma connection string — uma chave de acesso vital para o funcionamento do serviço. A solução mais óbvia? Colocá-la diretamente no arquivo de configuração appsettings.json.
E foi aí que o dilema surgiu: como manter meu repositório público no GitHub sem expor essa chave?
A primeira ideia que pode vir à mente é a "solução manual": deixar a chave no arquivo appsettings.json durante o desenvolvimento e removê-la antes de cada commit. Mas essa abordagem é uma receita para o desastre. Em um trabalho de equipe (ou mesmo sozinho, num dia de pressa), é quase certo que alguém esquecerá de remover o segredo. Uma vez vazado, teríamos que invalidar e regenerar todas as chaves expostas, sem contar que o segredo antigo permaneceria para sempre visível no histórico de commits.
É para evitar essa armadilha que o ecossistema .NET nos oferece uma solução segura: o User Secrets.

Nunca Comite Segredos

O ponto de partida para qualquer projeto profissional é um princípio inegociável: nunca, jamais, armazene segredos diretamente no código-fonte.
Segredos incluem:

Chaves de API
Connection Strings de bancos de dados ou serviços (como o Azure Service Bus)
Senhas
Tokens de autenticação

Quando um segredo é "comitado" no Git, ele fica registrado no histórico do repositório para sempre. Mesmo que você o remova em um commit futuro, qualquer pessoa com acesso ao histórico pode encontrá-lo. Em um repositório público, isso é o mesmo que entregar as chaves do seu sistema para qualquer um.
A solução não é criar lógicas complexas para enviar códigos diferentes para repositórios diferentes, mas sim externalizar a configuração, ou seja, separar o código da configuração sensível.

A Segurança Local com User Secrets

Para resolver o problema localmente, precisamos entender como o .NET gerencia as configurações. O sistema é baseado em uma hierarquia de "provedores" que alimentam uma interface central, a IConfiguration.
Imagine que sua aplicação precisa de uma configuração. Ela pergunta à IConfiguration: "Qual é o valor para Settings:ServiceBus:DeleteUserAccount?". A IConfiguration, por sua vez, consulta seus provedores em uma ordem específica:

Arquivos appsettings.json: Primeiro, ela olha o appsettings.json e depois o appsettings.Development.json (que o sobrepõe).
User Secrets: Em seguida, ela consulta os segredos do usuário.
Variáveis de Ambiente: Depois, verifica se existe uma variável de ambiente com esse nome.
Linha de Comando: Por fim, olha os argumentos de linha de comando.

A regra é simples: o último provedor a ser lido, vence. Se o User Secrets tiver um valor para a chave, ele irá sobrepor o que estiver no appsettings.Development.json.

Setup Inicial

Com base nessa hierarquia, podemos usar o appsettings.Development.json como um "molde" para as configurações que a aplicação precisa, mas deixando os valores sensíveis em branco.

// Em appsettings.Development.json
{
  "Settings": {
    "ServiceBus": {
      "DeleteUserAccount": "" // Valor deixado em branco de propósito
    }
  }
}

Movendo o Segredo para o User Secrets.

A ferramenta User Secrets não criptografa os segredos, apenas os armazena em um arquivo secrets.json, localizado fora da pasta do seu projeto (geralmente no diretório de perfil do sistema operacional). Isso torna impossível que ele seja enviado acidentalmente para o Git.
Passo 1: Habilitar o User Secrets
No terminal, na raiz do seu projeto, execute:

dotnet user-secrets init

Esse comando adiciona uma tag <UserSecretsId> ao seu arquivo .csproj. É esse ID único que conecta seu projeto ao arquivo secrets.json correspondente.

Passo 2: Armazenar o Segredo
Agora, vamos definir o valor da nossa connection string. Usamos dois-pontos (:) para navegar na hierarquia do JSON:

dotnet user-secrets set "Settings:ServiceBus:DeleteUserAccount" "SuaConnectionStringSuperSecretaAqui"

E pronto! Quando você rodar sua aplicação em modo de desenvolvimento, o .NET irá ler o valor vazio do appsettings.Development.json e, em seguida, o sobreporá com o valor real guardado no User Secrets. Problema local resolvido de forma segura e elegante.

Testando a Portabilidade

E se outro desenvolvedor baixar o projeto? Ao fazer git pull em uma nova máquina, todo o código virá, incluindo o .csproj com o UserSecretsId. No entanto, o arquivo secrets.json não virá, pois ele é local ao primeiro computador.
Ao tentar rodar o projeto, ele falhará por não encontrar a chave. Este é um comportamento esperado e desejado, pois prova que o sistema é seguro. A solução é simples: cada desenvolvedor, em cada nova máquina, precisa configurar o segredo localmente apenas uma vez, executando o comando dotnet user-secrets set....

Automatizando com Segurança no Azure DevOps

Com o desenvolvimento local resolvido, é hora de automatizar o processo de build e teste com um pipeline de CI/CD.

Conceitos Fundamentais de CI/CD

Antes de criar o pipeline, vamos entender os blocos de construção do Azure DevOps:

CI/CD (Integração/Implantação Contínua): É a prática de automatizar as fases do desenvolvimento. A CI garante que o novo código de vários desenvolvedores seja integrado e testado automaticamente. A CD leva essa automação adiante, publicando o projeto em um ambiente (teste ou produção). O objetivo é entregar valor de forma mais rápida e confiável.
Pipeline: É o fluxo de trabalho que define todas as etapas da sua automação. Ele diz ao Azure DevOps o que fazer e em que ordem.
Agent (Agente): É a máquina (geralmente virtual e temporária, fornecida pela Microsoft) que executa os passos do seu pipeline.
Job (Trabalho): Um conjunto de passos que rodam juntos em um mesmo agente.
Task (Tarefa): A menor unidade de trabalho. É uma ação individual e pré-empacotada, como dotnet build, dotnet test ou a execução de um script.

Criando um Pipeline Simples com o Editor Clássico

No Azure DevOps, você pode criar um pipeline usando um arquivo YAML (código) ou o Editor Clássico (interface gráfica). Para quem está começando, o Editor Clássico é uma ótima porta de entrada. O processo geralmente segue estes passos:

Conexão: Você aponta o pipeline para o seu repositório de código.
Template: Você escolhe um template inicial. Para um projeto .NET, o template "ASP.NET Core" já adiciona as tarefas essenciais:
- dotnet restore (baixa as dependências)
- dotnet build (compila o código)
- dotnet test (executa os testes)
- dotnet publish (prepara os arquivos para implantação)
Execução: Você salva e executa o pipeline, que rodará em um agente na nuvem.

O Desafio e a Solução no Pipeline

É aqui que um novo problema surge. Ao executar o pipeline, ele falha com um erro genérico: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1.
Após investigar os logs, a causa fica clara: os testes estão falhando. Assim como a "nova máquina" do exemplo anterior, o agente de build do Azure DevOps é um ambiente limpo. Ele não tem acesso aos seus User Secrets. Ao executar os testes que dependem da connection string do Service Bus, o valor está vazio, causando a falha que interrompe todo o pipeline.
A solução é fornecer o segredo de forma segura durante a execução.

Variáveis de Pipeline Seguras

Primeiro, armazenamos o segredo de forma centralizada e segura no próprio pipeline.

No modo de edição do pipeline, vá para a aba Variables.
Crie uma Pipeline Variable com um nome claro, como ServiceBusConnectionString.
Cole o valor da sua chave e, o mais importante, clique no ícone de cadeado para marcar o valor como secreto. Ele será mascarado e não aparecerá nos logs.
Salve as variáveis.

Injetando Segredos com PowerShell

A solução universal e mais robusta é usar uma tarefa de PowerShell para definir a variável de ambiente.

Adicione a Tarefa: Na aba Tasks, adicione uma nova tarefa "PowerShell" à sua lista.
Posicione Corretamente: Arraste a tarefa PowerShell para que ela seja executada imediatamente antes da sua tarefa de dotnet test. A ordem é crucial.

Configure o Script:

Clique na tarefa PowerShell e defina o Type como Inline.

No campo Script, insira o seguinte comando:

Write-Host "Setting the Service Bus connection string as an environment variable."
Write-Host "##vso[task.setvariable variable=Settings__ServiceBus__DeleteUserAccount]$(ServiceBusConnectionString)"

Este comando ##vso[task.setvariable...] é uma instrução especial para o agente do Azure DevOps, ordenando que ele crie uma variável de ambiente (Settings__ServiceBus__DeleteUserAccount) com o valor da nossa variável de pipeline segura ($(ServiceBusConnectionString)).
A tarefa de teste, ao ser executada logo em seguida, herdará essa variável de ambiente. O sistema de configuração do .NET a detectará, seus testes encontrarão a chave necessária e o pipeline será executado com sucesso!

Azure Key Vault

Embora as variáveis de pipeline sejam ótimas para CI/CD, ambientes de produção exigem uma camada extra de segurança e gerenciamento. Para isso, a ferramenta definitiva é o Azure Key Vault.
Pense no Key Vault como um cofre centralizado e ultra-seguro na nuvem. Em vez de armazenar segredos no pipeline, sua aplicação, ao ser executada em produção, se autentica de forma segura no Key Vault para buscar as configurações de que precisa. Isso oferece vantagens imensas, como gerenciamento centralizado de todos os segredos, políticas de acesso granulares, rotação automática de chaves e logs de auditoria detalhados.

Conclusão

Separe Código e Configuração: O código deve ser o mesmo em todos os ambientes; a configuração sensível deve ser externa e específica de cada ambiente.
Trate Cada Ambiente de Forma Independente: O modo como você fornece um segredo para sua máquina local é diferente de como você o faz para um pipeline de CI ou para o ambiente de produção.
Use a Ferramenta Certa para o Trabalho: O ecossistema .NET e o Azure nos fornecem as ferramentas ideais para cada cenário: User Secrets para desenvolvimento, Variáveis de Pipeline para automação e Azure Key Vault para produção.

Ao seguir esses princípios, você garante que seu projeto não apenas funcione, mas que seja seguro. Para mim, essa jornada que começou com um simples connection string foi um aprendizado imenso, e espero que compartilhá-la possa ajudar outros desenvolvedores a trilhar um caminho mais seguro.
Para referência, o código-fonte do projeto que inspirou este artigo pode ser encontrado neste link do GitHub.

DEV Community: Gabriel Amarantes

[Boost]

Understanding Codecs, Containers, and Bitrates: What Every Developer Using FFmpeg Should Know

Willem Janssen ・ Oct 7

[Boost]

How to Build a Command-Line Video Converter with .NET 8 and FFmpeg

[Boost]

🚀 Clean Commit Messages: Why & How

Mhammed Talhaouy ・ Sep 26

C# Parallelism - A Quick Overview

What is Concurrency?

What is Parallelism?

Threads

Task Parallel Library (TPL)

TPL Examples

Scenario 1: Processing a Collection

Sequential code

Parallel code

Scenario 2: Running Independent Operations

Sequential Code

Parallel Code

Conclusion

References

Desvendando o HTTP: O Protocolo por Trás da Web e das APIs

O que é HTTP?

Cliente-Servidor

Stateless

Estrutura de uma mensagem HTTP

Requisição (Request)

Resposta (Response)

Headers

Métodos (ou verbos) HTTP

Verbos Essenciais do CRUD

Outros Métodos

Códigos de Status HTTP

1. Informativa (100 - 199)

2. Sucesso (200 -299)

3. Redirecionamento (300 - 399)

4. Erro do Cliente (400 - 499)

5. Erro do Servidor (500 - 599)

Consumindo e Criando Endpoints em ASP.NET Core

O Servidor em API ASP.NET Core

O Cliente com HttpClient

HTTP/1.1 a HTTP/3

HTTP/1.1

HTTP/2

HTTP/3

Segurança com HTTPS

Pilar 1: Criptografia (Confidencialidade)

Pilar 2: Autenticidade

Pilar 3: Integridade

SSL vs. TLS

Por que Dominar o HTTP é Crucial?

Referências

Documentação Essencial

Para Desenvolvedores .NET

Artigos e Guias de Aprofundamento

Leitura Avançada

Um Guia para Gerenciar Segredos no .NET e Azure DevOps

Uma Chave Secreta no Lugar Errado

Nunca Comite Segredos

A Segurança Local com User Secrets

Setup Inicial

Movendo o Segredo para o User Secrets.

Testando a Portabilidade

Automatizando com Segurança no Azure DevOps

Conceitos Fundamentais de CI/CD

Criando um Pipeline Simples com o Editor Clássico

O Desafio e a Solução no Pipeline

Variáveis de Pipeline Seguras

Injetando Segredos com PowerShell

Azure Key Vault

Conclusão

O Cliente com `HttpClient`