Protocolo HTTP

Posso dizer que esse é um dos protocolos, se não o mais usado entre os desenvolvedores. Esse protocolo vive na camada de aplicação e é o mecanismo principal usado pelas nossas aplicações para expor nossos serviços à internet. O HTTP faz a transferência de hipermídia que é a junção de hipertexto e multimídia e por isso ficou com esse nome. Esse formato possibilita que consigamos formar mensagens que contenha: texto, vídeo, som, foto, etc.

Verbos HTTP

Os verbos HTTP são métodos que realizam uma ação que é enviada ao servidor para processar por meio da solicitação de um cliente. São eles:

Alguns métodos como HEAD, GET, OPTIONS e TRACE são considerados seguros pelo motivo de não alterar nada no servidor e apenas solicitar informações. Recomendo a leitura desse artigo que eu escrevi sobre idempotência que mostra um outro lado nessa questão do método ser seguro ou não.

Códigos de estado

O HTTP envia como parte da resposta ao cliente um código que informa o estado da solicitação feita. Devemos imaginar que nem sempre a solicitação vai ser sucesso e que não temos bola de cristal para saber o que aconteceu caso alguma coisa tenha dado errado. Para isso temos uma lista de status que define que tipo de erro aconteceu. Os códigos são formados por 3 números: O primeiro dígito indica a natureza geral da resposta e o segundo e terceiro dígitos informam o problema exato encontrado. Desta forma, podemos considerar que os códigos de status são categorizados por seu primeiro dígito. São eles:

Formato da mensagem HTTP

As solicitações e resposta são sempre enviadas em formato de texto simples. Esse texto tem uma ordem de informações que são analisadas pelo destinatário. Nesse texto temos 3 componentes obrigatórios e 1 opcional.

1 º Componente: consiste no método, o caminho do recurso e a versão do protocolo HTTP. Ex: GET /users/id/12 HTTP/1.1

2 º Componente: headers e seus valores. Ex: Accept: application/json.

3º Componente: Linha vazia

4º Componente (Opcional): um corpo de mensagem de solicitação

GET /users/id/12 HTTP/1.1
Accept: application/json

{
  "name": "João da Silva",
  "email": "[email protected]"
}

O texto da resposta fornecida pelo servidor segue o mesmo padrão:

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 58
Location: /users/123

{
  "id": 123,
  "name": "João da Silva",
  "email": "[email protected]"
}

TCP e UDP

TCP (Transmission Control Protocol)

Este protocolo foi desenvolvido em 1974 e é usado para realizar a comunicação com um host e realizar a entrega confiável dos pacotes. Esse protocolo reside na camada de transporte e fornece a confiabilidade de entrega dos pacotes. Toda implementação que usa esse protocolo tem sua escrita feita para lidar com a perda de pacotes. Outro detalhe que o TCP nos entrega é a possibilidade de entregar os pacotes na ordem que foi enviado e caso haja algum problema no caminho ele refaz a solicitação e reordena os pacotes, fazendo assim o controle do fluxo.

Entretanto, o "custo" disso tudo acaba recaindo sobre a latência e desempenho, já que pode ocorrer idas e vindas para buscar o mesmo dado várias vezes dependendo do cenário de erro. Em uma aplicação que queremos desempenho como streaming de vídeo, jogos, devemos sacrificar a confiabilidade de que o dado foi entregue e para isso usamos o protocolo UDP.

Abaixo estão os mecanismos utilizados pelo TCP para garantir a entrega do pacote:

UDP (User Datagram Protocol)

Este protocolo é usado para comunicação simples onde não é exigido que haja confiança na entrega dos dados e também ele não cria uma conexão entre os host como o TCP realizada. Mais abaixo explicarei o que seria uma comunicação com conexão e sem conexão. o UDP não realiza o tratamento de erros igual o TCP faz e isso acaba dando mais desempenho a ele do que o TCP.

Comunicação com conexão e sem conexão

A ideia desses dois conceitos é a seguinte: na comunicação com conexão, antes de transmitir os dados, os hosts precisam estabelecer uma linha de comunicação — como um “aperto de mão” entre eles, sinalizando que podem começar a trocar informações. Esse é o caso do protocolo TCP, que realiza esse processo de handshaking entre os hosts.

Por outro lado, na comunicação sem conexão, utilizada pelo UDP, os dados são enviados diretamente, sem esse handshaking. Nesse tipo de comunicação, a transmissão acontece em uma única direção, sem que o remetente receba uma confirmação (“ok”) de que o pacote foi entregue, ao contrário do TCP, que garante esse retorno.

Lembrando que a garantia de entrega dos pacotes pelo TCP não se dá pelo handshaking e sim por outro mecanismos conforme citado acima. O handshaking valida se o host está ativo e está disponível para começar a comunicação.

Resumidamente, o protocolo TCP e UDP é isso:

Restrições de rede

Temos alguns detalhes como largura de banda, latência e intensidade do sinal. Cada uma dessas restrições, tem um papel importante para definir o tamanho máximo de uma unidade atômica de dados (menor bloco de informação que é tratado ou transmitido de forma independente em uma rede). Essas limitações exigem que os dados transmitidos pela rede precisam incluir vários atributos para que cada nó que receba tal dado seja possível interpretar o contexto.

Abaixo está uma pincelada nessas 3 restrições

Largura de banda

Largura de banda é a quantidade máxima de dados que podem ser transmitidos por uma rede em um dado intervalo de tempo, geralmente medida em bits por segundo (bps).
Uma analogia comum compara a rede a uma rodovia: os dados são os carros, e a largura da estrada representa a largura de banda. Quanto mais faixas (ou maior a largura da estrada), mais carros (bits) podem passar ao mesmo tempo.

É importante não confundir largura de banda com a velocidade de navegação percebida, que também depende de outros fatores como latência, congestionamento e perdas. A largura de banda representa o potencial teórico máximo de transmissão, mas o valor efetivo pode ser menor na prática.

Latência

Segundo o livro latência é:

A latência é o tempo entre o momento inicial em que um sinal é enviado e o primeiro momento em que uma resposta a esse sinal pode ser iniciada. É o atraso de uma rede

Um dos exemplos que usamos para medir a latência é o famoso ping, que envia uma solicitação simples a outro dispositivo e mede o tempo de ida e volta. O tempo que o outro dispositivo leva para processar a solicitação é descartado da conta para medir a latência

Força do sinal

A intensidade do sinal pode variar nas redes, especialmente nas sem fio ou nas que usam fios de cobre. A distância e a resistência afetam o sinal, o que pode fazer os dados chegarem corrompidos. Para resolver isso, os engenheiros usam técnicas como isolar os fios e aumentar a força do sinal. No entanto, em redes grandes, a confiabilidade diminui e a perda de dados acaba acontecendo. Por isso, é melhor dividir os dados em pacotes pequenos, o que ajuda a minimizar o impacto de erros e torna mais fácil enviar novamente os pacotes perdidos.

Se um bit em um pacote for perdido, isso pode corromper o pacote todo. Então, quanto menores os pacotes, menos dados serão perdidos. Mas se os pacotes forem muito pequenos, o desempenho da rede pode cair. Por isso, os pacotes geralmente têm entre algumas centenas de bytes e alguns kilobytes. Além disso, os pacotes precisam ter um sistema de detecção de erros, para que, se um pacote estiver corrompido, ele possa ser descartado e enviado de novo. A comunicação nas redes é feita com pacotes pequenos para garantir que os dados cheguem de forma confiável.

Com isso finalizamos essa parte, mais teórica, mas promete que no próximo artigo terá um pouco mais de emoção porque iremos falar sobre Streams em C#.

Navegação

• Artigo Anterior: Resumo do Livro Hands-On Network Programming with C# and .NET Core - Parte 2
• Próximo Artigo: Trabalhando com Stream no C#