A camada de aplicação

Uma aplicação de rede consiste em programas executados em sistemas finais: celulares, laptops e servidores. Seus processos trocam mensagens pela rede. Roteadores e comutadores encaminham os pacotes; eles não precisam que um novo programa de aplicação seja instalado sempre que alguém cria um serviço.

Duas formas de distribuir o trabalho

Uma arquitetura de aplicação descreve como a aplicação divide o trabalho entre hospedeiros. Ela é separada da arquitetura em camadas da rede. O desenvolvedor escolhe onde os programas são executados, contando com a rede existente para conectá-los.

Em uma arquitetura cliente-servidor, clientes contatam um servidor sempre ligado em um endereço conhecido. Um navegador solicita um documento a um servidor web, que retorna o documento. Outros navegadores não precisam estar online para que essa troca funcione. Um serviço popular pode distribuir o papel de servidor por milhares de máquinas em centros de dados; um nome público pode representar esse grupo. Equipamentos, energia, refrigeração e conexões com a internet custam dinheiro.

Uma arquitetura par a par, ou P2P, permite que dispositivos dos usuários troquem dados diretamente. Um par pode solicitar uma parte de arquivo e também enviar partes que já possui. Pares podem se desconectar ou mudar de endereço, então a aplicação deve encontrar pares disponíveis e continuar funcionando conforme os participantes mudam.

Acompanhe uma troca

Suponha que um grupo de pesquisa distribua um grande conjunto de dados. Em uma arquitetura cliente-servidor, cada pesquisador baixa uma cópia do servidor do grupo. Dez novos pesquisadores significam dez cópias a mais para esse servidor enviar. Em uma arquitetura P2P, pesquisadores que já possuem algumas partes as enviam aos recém-chegados. Cada pesquisador que entra pode acrescentar capacidade e também demanda. Isso é autoescalabilidade: os recursos da aplicação crescem com a participação.

A autoescalabilidade ainda depende de contribuições úteis. Um par com um enlace de upload lento acrescenta menos capacidade que um com um enlace rápido. Muitos enlaces residenciais são assimétricos: o download é mais rápido que o upload. Um par desconectado não contribui enquanto está offline. O software P2P também deve proteger os participantes contra pares não confiáveis e incentivar usuários a enviar dados em vez de apenas recebê-los.

Coordenação central e transferência direta

Uma arquitetura híbrida combina coordenação por servidor com transferência de dados P2P. Um rastreador do BitTorrent informa a um par sobre outros pares; ele não precisa enviar o arquivo em si. Da mesma forma, um serviço de chamadas pode localizar participantes por meio de um servidor, permitir que seus dispositivos troquem mídia diretamente e usar um servidor de retransmissão quando um caminho direto não estiver disponível. Classifique o caminho que transporta os dados separadamente do caminho que estabelece a comunicação.

As palavras cliente e servidor também descrevem papéis em uma troca individual. Se o par Mira inicia uma requisição ao par Leo, Mira é a cliente e Leo é o servidor nessa troca. Eles podem inverter os papéis um momento depois. P2P elimina a dependência de servidores de conteúdo dedicados; não elimina os papéis de quem inicia e de quem responde.

Um programa de aplicação em execução é um processo. Processos em hospedeiros diferentes trocam mensagens por meio de sockets, as interfaces de software entre as camadas de aplicação e transporte. O código da aplicação determina o significado da mensagem; o serviço de transporte carrega seus bytes ou datagramas.

Encontre o processo receptor

Um endereço IP identifica um hospedeiro, mas o hospedeiro pode executar muitos serviços. Um número de porta identifica uma extremidade de transporte nele. Para contatar um serviço HTTPS em 203.0.113.10, um cliente normalmente usa a porta 443 como destino. Seu próprio sistema operacional geralmente atribui uma porta de origem temporária, ou efêmera.

Portas são valores de 16 bits, de 0 a 65.535. Portas de sistema ocupam 0–1023, portas registradas 1024–49.151 e portas dinâmicas 49.152–65.535. Portas de serviços comuns incluem HTTP 80, HTTPS 443, transferência SMTP 25 e DNS 53. Uma porta faz parte do endereçamento e não indica se o tráfego é cifrado ou confiável.

Defina as mensagens em comum

Um protocolo da camada de aplicação define tipos de mensagem, sintaxe, semântica e regras de troca. Os tipos distinguem uma requisição de uma resposta. A sintaxe descreve campos e separadores. A semântica informa a cada participante o que esses campos significam. As regras de troca determinam quando um processo envia uma mensagem e como o receptor responde. Especificações públicas, muitas vezes RFCs, permitem que programas escritos por desenvolvedores diferentes se comuniquem.

Um protocolo é um componente de uma aplicação. A web também precisa de navegadores, servidores e documentos. Definir apenas o HTTP não constrói um navegador nem determina a aparência de sua interface.

Relacione o serviço à necessidade

Considere quatro necessidades: entrega correta, vazão suficiente, atraso aceitável e segurança. Um anexo de correio eletrônico exige todos os bytes. Uma chamada de voz tolera alguma perda de mídia, mas é prejudicada se o áudio antigo chega tarde demais. Um vídeo armazenado precisa de vazão sustentada próxima à sua taxa de bits codificada, enquanto um download elástico pode usar a taxa disponível.

O TCP inclui controle de fluxo para proteger o receptor e controle de congestionamento para reduzir a sobrecarga na rede. Ele não fornece largura de banda mínima nem prazo de entrega. O UDP em si não acrescenta confiabilidade nem controle de congestionamento. Escolhê-lo não elimina o congestionamento do caminho.

Por exemplo, um jogo que envia posições 30 vezes por segundo produz uma nova atualização a cada aproximadamente 33 ms. Ele pode usar UDP para que uma atualização perdida seja substituída por outra mais recente sem esperar sua retransmissão. O chat do jogo ainda precisa de entrega confiável, seja por TCP ou por confiabilidade acrescentada pelo próprio protocolo do jogo.

Acrescente segurança à pilha

Nem o TCP nem o UDP, por si só, cifram dados da aplicação. HTTP/1.1 e HTTP/2 costumam usar TLS sobre TCP para HTTPS. O TLS acrescenta confidencialidade, integridade e autenticação do servidor. O HTTP/3 usa QUIC sobre UDP; o QUIC fornece confiabilidade, controle de congestionamento e TLS 1.3 integrado. Vídeo armazenado entregue por HTTP usa, portanto, TCP ou QUIC, enquanto chamadas interativas frequentemente transportam mídia por UDP.

Uma página web geralmente contém vários objetos, cada um com sua própria URL. O HTML base indica imagens, scripts e outros arquivos. Em https://www.example.org/docs/intro.html, o esquema é https, o hospedeiro é www.example.org e o caminho é /docs/intro.html.

Leia uma requisição e uma resposta

O HTTP funciona por trocas de requisição e resposta. Uma requisição HTTP/1.1 começa com método, caminho e versão:

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

A linha de requisição e as linhas de cabeçalho terminam com CRLF. Uma linha em branco encerra os cabeçalhos, e um corpo opcional vem em seguida. Host é obrigatório no HTTP/1.1 porque vários sites podem compartilhar um endereço de servidor. Connection: close solicita o fechamento após a resposta.

GET obtém um objeto. HEAD solicita seus cabeçalhos de resposta sem o corpo. POST envia dados no corpo de uma requisição; um GET também pode transportar valores de formulário na sequência de consulta de sua URL. PUT armazena um objeto em uma URL especificada, e DELETE remove um objeto.

A resposta começa com uma linha de status como HTTP/1.1 200 OK, seguida de cabeçalhos, uma linha em branco e o corpo. Content-Type identifica a representação; Content-Length informa seu comprimento em bytes. As classes de status são 1xx informação, 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente e 5xx erro do servidor. Um 301 aponta para uma nova URL em Location; 304 permite reutilizar uma cópia em cache. Um 404 significa que o servidor respondeu que o objeto solicitado não foi encontrado, não que o servidor estava inacessível. Outros códigos úteis incluem 400, 500 e 505.

O HTTP não mantém estado: cada requisição pode ser entendida sem as requisições anteriores. Um site ainda pode manter o estado de login ou do carrinho acima do HTTP. Um GET comum repetido pode retornar o objeto novamente, enquanto uma requisição condicional pode validar uma cópia salva.

Conte os tempos de ida e volta

Para um objeto em uma nova conexão TCP, conte um RTT para estabelecer a conexão e um para a requisição e o início da resposta. Depois, acrescente o tempo de transmissão do objeto. Com RTT de 30 ms, tamanho de 500 kB e taxa de 50 Mbps:

O total é 60 ms mais 80 ms, ou 140 ms. Esse modelo desconsidera DNS, TLS e tempo de processamento. Uma negociação TLS 1.3 completa sobre a nova conexão TCP acrescenta mais um RTT.

Reutilize ou reabra a conexão

Uma conexão não persistente transporta um objeto. Uma conexão persistente pode transportar requisições posteriores sem outro estabelecimento TCP. A persistência é o padrão do HTTP/1.1, embora conexões inativas acabem sendo fechadas.

Para um objeto HTML e oito imagens pequenas, RTT de 20 ms e tempos de transmissão desprezíveis:

As requisições das imagens dependem do recebimento do HTML. Mesmo com buscas paralelas, elas não podem começar antes que suas URLs sejam conhecidas. Conte essas etapas de dependência antes de contar as negociações. Navegadores HTTP/1.1 costumam usar várias conexões por hospedeiro; o envio em pipeline é um modelo de cálculo de tempo, não um requisito para a persistência.

Requisições HTTP são independentes, mas uma loja pode se lembrar de um carrinho. Um navegador também pode reutilizar uma imagem em vez de baixá-la novamente. Cookies permitem o reconhecimento entre requisições; caches permitem a reutilização de respostas.

Acompanhe um cookie

Na primeira visita, shop.example.com cria uma entrada no banco de dados para um visitante e retorna Set-Cookie: id=1678. O navegador armazena esse valor. Requisições posteriores correspondentes incluem Cookie: id=1678, permitindo que o servidor consulte o carrinho. O cookie é um dado, não código executável, e o próprio carrinho pode permanecer no banco de dados do servidor.

Os atributos de um cookie controlam seu uso. Expires ou Max-Age define um prazo de validade; um cookie sem nenhum dos dois é um cookie de sessão. Domain e Path restringem as requisições correspondentes. Secure restringe o envio a HTTPS, HttpOnly impede o acesso por scripts da página e SameSite controla o envio em contextos entre sites. A restauração de sessão pode manter cookies de sessão quando um navegador restaura uma sessão anterior.

Cookies próprios pertencem ao site visitado. Um serviço de terceiros incorporado pode usar cookies em diferentes sites para reconhecer um navegador. O Safari bloqueia cookies de terceiros por padrão; o Firefox os separa por site; o Chrome oferece controles ao usuário e os bloqueia no modo de navegação anônima. As regras da União Europeia exigem consentimento para cookies que não sejam estritamente necessários para fornecer um serviço solicitado.

Acompanhe uma requisição atendida pelo cache

Um cache web armazena respostas HTTP. Um navegador tem seu próprio cache. Um proxy com cache fica entre clientes e servidores de origem: ele atende diretamente a um acerto de cache ou busca, armazena e encaminha uma resposta em caso de erro de cache. Ele atua como servidor perante o navegador e como cliente perante a origem. Um proxy pode existir sem armazenar conteúdo em cache.

Um acerto próximo reduz o atraso, a carga na origem e o tráfego no enlace de acesso. Para 90 requisições por segundo com média de 1 Mbit cada, o tráfego oferecido é de 90 Mbps. Em um enlace de acesso de 100 Mbps, a intensidade de tráfego é 0,9, valor em que as filas podem ficar grandes. Uma taxa de acerto de 40% deixa 60% atravessando o enlace: 54 Mbps e intensidade de 0,54. Com acertos levando 10 ms e erros de cache 200 ms, o tempo médio de resposta é:

Esse cálculo de tráfego pressupõe o mesmo tamanho médio de objeto para os grupos de acertos e de erros de cache. Uma taxa de acerto medida apenas pela contagem de requisições não precisa ser igual à fração de bytes economizados quando os tamanhos dos objetos diferem.

Verifique a atualização antes de reutilizar

Um GET condicional envia If-Modified-Since com uma data de modificação salva, ou If-None-Match com um ETag salvo. Um objeto inalterado resulta em 304 Not Modified sem o corpo do objeto. O cache reutiliza sua cópia. Um objeto alterado resulta em 200 OK com o substituto. A validação economiza a transmissão do corpo, mas ainda exige uma ida e volta até a origem.

Um proxy compartilhado normalmente não consegue inspecionar o conteúdo de uma conexão HTTPS que passa por ele. Caches de navegador e servidores CDN que atendem em nome de um site podem armazenar respostas nas extremidades onde elas estão disponíveis em formato legível.

As versões do HTTP mantêm os significados de métodos, status, campos e URLs. Um 404 ainda significa que o recurso solicitado não foi encontrado. O que muda é como requisições e respostas trafegam: o HTTP/1.1 usa mensagens de texto, enquanto HTTP/2 e HTTP/3 usam quadros binários.

Permita o avanço de respostas pequenas

Em uma conexão HTTP/1.1, respostas ordenadas podem fazer um objeto pequeno esperar atrás de um grande. Isso é bloqueio de início de fila no nível da aplicação. Abrir várias conexões TCP reduz essa espera, mas exige estabelecimento adicional e dá à página várias conexões concorrentes com controle de congestionamento.

O HTTP/2 divide mensagens em quadros e atribui um fluxo a cada troca de requisição e resposta. O remetente intercala quadros de fluxos diferentes em uma conexão TCP. A compressão de cabeçalhos, chamada HPACK, reduz dados repetidos de campos. Prioridades podem orientar quais respostas são atendidas primeiro.

Para uma comparação simplificada, uma resposta grande tem 1.000 quadros e oito respostas pequenas têm dois quadros cada. Envie um quadro por intervalo de tempo. Enviar a resposta grande primeiro faz as respostas pequenas terminarem nos intervalos de 1.002 a 1.016, com média de 1.009. Enviar um quadro de cada fluxo não concluído por vez permite que as respostas pequenas terminem nos intervalos de 11 a 18, com média de 14,5. A resposta grande termina no intervalo 1.016. A intercalação altera os tempos de conclusão sem aumentar a taxa de transmissão do enlace.

O HTTP/2 também especificou o envio antecipado pelo servidor, que envia conteúdo antes de uma requisição. Os principais navegadores o desativaram. Uma resposta 103 Early Hints, por sua vez, indica recursos para que o navegador possa começar a solicitá-los.

Encontre o ponto de bloqueio restante

O TCP entrega um único fluxo ordenado de bytes. Se faltarem bytes, os posteriores esperam pela recuperação, mesmo quando contêm quadros de outro fluxo HTTP/2. O HTTP/2 elimina o bloqueio pela ordem das respostas, mas mantém esse bloqueio no nível de transporte.

O HTTP/3 mapeia o HTTP para o QUIC, um protocolo de transporte sobre UDP, e comprime cabeçalhos com QPACK. O QUIC fornece fluxos confiáveis, controle de fluxo e de congestionamento e segurança TLS 1.3. Cada fluxo tem sua própria ordem de entrega. Dados ausentes em um fluxo não impedem, por si só, a entrega de dados já recebidos em outro. O controle de congestionamento compartilhado e as dependências da aplicação ainda podem afetar vários fluxos.

O QUIC usa identificadores de conexão para que uma conexão sobreviva a uma mudança de endereço IP, como ao passar do Wi-Fi para uma rede celular. Sua implementação pode ser atualizada com uma biblioteca da aplicação, evitando o lento processo de implantação de mudanças no TCP em sistemas operacionais e dispositivos intermediários de rede.

Compare uma nova conexão

Com RTT de 50 ms e sem custo de DNS ou processamento, TCP mais TLS 1.3 leva dois RTTs antes que a primeira requisição HTTP/2 seja enviada. Uma primeira resposta começa após cerca de 150 ms. O QUIC combina o estabelecimento do transporte e da segurança em um RTT, de modo que uma resposta HTTP/3 pode começar após cerca de 100 ms. Conexões QUIC retomadas podem usar dados 0-RTT, mas o risco de repetição limita quais requisições podem ser enviadas antecipadamente com segurança.

Navegadores podem descobrir o HTTP/3 por meio de Alt-Svc ou de registros DNS HTTPS. Se o UDP estiver bloqueado, eles podem recorrer ao HTTP sobre TCP. O HTTP/3 continua confiável porque o QUIC fornece confiabilidade acima do UDP.

Um nome como www.example.org é conveniente para uma pessoa. Uma conexão precisa de um endereço IP. O Sistema de Nomes de Domínio, ou DNS, é tanto o banco de dados distribuído de registros de nomes quanto o protocolo de aplicação usado para consultá-lo. Ele normalmente usa a porta 53 e funciona separadamente do HTTP.

Divida o trabalho de nomes

Leia www.example.org. da direita para a esquerda: raiz, org, example e depois www. O ponto final representa a raiz e normalmente é omitido na escrita cotidiana. Um servidor centralizado para todos os nomes criaria um ponto de falha, um gargalo de tráfego e caminhos longos para clientes distantes.

Servidores raiz indicam aos resolvedores os servidores de domínio de nível superior. Servidores TLD indicam a eles os servidores autoritativos dos domínios subordinados ao TLD. Servidores autoritativos publicam os registros efetivos de um domínio. As 13 identidades nomeadas de servidores raiz são replicadas em muitas instâncias físicas; 13 não é o número de máquinas que dão suporte ao DNS mundial.

O hospedeiro normalmente envia sua pergunta a um resolvedor local, fornecido por sua organização, seu provedor de serviços de internet ou um serviço público. Esse resolvedor trabalha em nome do hospedeiro. Ele não é outro nível entre a raiz e o TLD na hierarquia de nomes.

Acompanhe uma consulta com cache vazio

Um laptop de campus precisa do endereço IPv4 de www.example.org:

1. O laptop pede a resposta final ao seu resolvedor local.
2. O resolvedor consulta um servidor raiz e recebe uma indicação dos servidores .org.
3. Ele consulta um servidor .org e recebe uma indicação dos servidores autoritativos de example.org.
4. Ele consulta um servidor autoritativo e recebe 203.0.113.25.
5. Ele retorna o endereço ao laptop.

São quatro pares de consulta e resposta, ou oito mensagens. A requisição do hospedeiro é recursiva: obtenha a resposta para mim. As consultas do resolvedor são iterativas: cada servidor contatado responde com base no que sabe ou encaminha o resolvedor adiante. A raiz não busca o endereço do servidor web em nome do laptop.

Reutilize respostas até o fim de seu TTL

Um registro de recurso contém um tempo de vida, ou TTL, medido em segundos. Resolvedores mantêm registros reutilizáveis em cache até o fim de seu tempo de vida permitido. Eles podem armazenar indicações em cache, assim como endereços finais. Uma delegação de TLD ou domínio já armazenada permite que uma consulta posterior pule etapas anteriores. Sistemas operacionais e navegadores também podem ter caches.

Com um RTT de 2 ms entre hospedeiro e resolvedor e um RTT de 30 ms para cada uma das três consultas sequenciais à hierarquia, a consulta com cache vazio leva cerca de 92 ms. Um endereço em cache no resolvedor leva cerca de 2 ms. Os tempos de espera são somados porque cada indicação fornece informações necessárias para a consulta seguinte.

O cache também atrasa mudanças. Se um resolvedor armazenou em cache um endereço com TTL de uma hora pouco antes de uma atualização, ele pode continuar retornando o endereço antigo pelo tempo de vida restante. Reduzir um TTL antes de uma mudança planejada limita essa sobreposição; alterar apenas o registro autoritativo não substitui todas as cópias em cache.

O DNS faz mais que consultar endereços a partir de nomes. Ele oferece suporte a apelidos, encontra servidores de correio e distribui carga ao retornar vários endereços para um serviço. Esses papéis explicam por que a entrega de correio eletrônico e a seleção de CDN também dependem do DNS.

O DNS armazena registros de recurso com nome, valor, tipo e TTL. O tipo informa ao resolvedor como interpretar o valor. Um registro de endereço, um apelido e um registro de servidor de correio respondem a perguntas diferentes sobre o mesmo domínio.

Leia o tipo de registro

Por exemplo, www.example.org. 3600 IN A 203.0.113.25 fornece o nome do registro, o TTL, a classe internet, o tipo e o endereço. Um valor NS é um nome, não um endereço. Uma indicação pode incluir um registro A separado que fornece o endereço do servidor de nomes, frequentemente chamado de registro de ligação (glue) quando necessário para resolver a delegação.

Um CNAME como media.example.org que aponta para edge.cdn.example.net leva o resolvedor a consultar o endereço do destino. Um registro MX, por sua vez, direciona a entrega de correio eletrônico. Com preferências 10 e 20, tente primeiro o servidor de correio com preferência 10; um número maior não significa prioridade maior.

Leia a mensagem que contém os registros

Consultas e respostas compartilham um formato. O cabeçalho de 12 bytes contém um número de identificação, indicadores e contagens de entradas em quatro seções. A resposta copia o ID da consulta para que quem a solicitou possa associá-la à troca.

A seção de pergunta identifica o que foi solicitado. A seção de resposta contém registros correspondentes. A seção de autoridade pode conter indicações NS, enquanto a seção adicional fornece registros úteis, como endereços de servidores de nomes. Na saída impressa de dig, qr marca uma resposta, rd significa que a recursão foi solicitada e ra significa que a recursão está disponível. NOERROR informa que não houve erro de DNS; NXDOMAIN informa que o nome consultado não existe. Uma resposta sem erro ainda pode não conter um registro do tipo solicitado.

Para publicar um novo domínio, um proprietário o registra e fornece as informações de seu servidor autoritativo. A delegação do domínio pai direciona consultas a esses servidores, que publicam os próprios registros de hospedeiro e de correio do domínio. Registrar o nome não transforma o registrador no servidor que mantém todos os registros.

Entrega e proteção

A maioria das pequenas trocas DNS usa a porta UDP 53. Uma resposta UDP truncada tem seu indicador TC ativado; o resolvedor pode tentar novamente pela porta TCP 53. O TCP também oferece suporte a transferências de zona. Portanto, o DNS não está restrito ao UDP.

O tráfego DNS clássico expõe os nomes consultados a observadores em seu caminho. DNS sobre TLS ou DNS sobre HTTPS cifra a troca entre cliente e resolvedor, geralmente nas portas 853 e 443, respectivamente. A cifragem dessa troca e a autenticidade de um registro são propriedades distintas.

No envenenamento de cache, um resolvedor aceita uma resposta falsificada e depois envia usuários ao endereço errado. IDs e portas de origem imprevisíveis dificultam a correspondência de respostas falsificadas. O DNSSEC acrescenta assinaturas que permitem verificar a autenticidade dos registros; ele não oculta a consulta. Uma inundação também pode tornar servidores DNS inacessíveis. A replicação e as indicações em cache reduzem a dependência da raiz para cada requisição, mas falhas em um provedor autoritativo amplamente usado ainda podem interromper muitos sites.

O correio eletrônico separa a composição de uma mensagem de sua entrega. Um agente de usuário é o aplicativo ou página web usado para ler e escrever mensagens. Um servidor de correio eletrônico armazena mensagens recebidas em caixas postais e mantém mensagens de saída em uma fila. O SMTP transfere mensagens entre sistemas.

Acompanhe a entrega após a submissão

Alice submete uma mensagem para Bob ao seu próprio servidor. Esse servidor consulta os registros MX do domínio de Bob, resolve o endereço do servidor escolhido e abre uma conexão TCP com a porta 25. Ele envia a mensagem ao servidor de Bob, que a armazena na caixa postal dele. O servidor de Alice é o cliente SMTP durante essa transferência, embora atenda ao agente de usuário dela em outra troca.

Se o destino estiver temporariamente indisponível, a fila de saída mantém a mensagem para novas tentativas. O dispositivo de Alice pode ficar offline enquanto o servidor continua trabalhando. Após falhas repetidas, um relatório de não entrega pode retornar ao remetente do envelope.

Leia a conversa

O SMTP usa comandos de texto e respostas numéricas. Eis uma troca de entrega abreviada; C: e S: identificam os dois interlocutores e não são transmitidos como parte de cada comando.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

EHLO apresenta o hospedeiro remetente. MAIL FROM define o remetente do envelope; cada RCPT TO nomeia um destinatário do envelope. DATA inicia a mensagem, e uma linha contendo apenas um ponto a encerra. Uma conexão pode transportar mais de uma mensagem. As classes de resposta distinguem sucesso (2xx), solicitação de mais dados (3xx), falha temporária (4xx) e falha permanente (5xx). Uma resposta 4xx exige uma nova tentativa posterior; uma falha 5xx precisa de outro tratamento, frequentemente uma devolução.

Separe endereços de entrega dos campos exibidos

O envelope controla o roteamento. Os campos From: e To: dentro da mensagem são exibidos ao leitor. Eles podem diferir do envelope. Um destinatário em cópia oculta pode aparecer em RCPT TO sem aparecer nos cabeçalhos visíveis da mensagem. Responder a uma mensagem e informar uma falha de entrega não precisam usar o mesmo endereço.

Um usuário normalmente submete mensagens por SMTP autenticado na porta 587 com STARTTLS ou na porta 465 com TLS desde o início. A transferência entre servidores normalmente usa a porta 25 e pode negociar STARTTLS. Submissão e transferência têm papéis diferentes, mesmo quando ambas usam SMTP. O HTTP geralmente busca objetos solicitados; o SMTP envia ativamente uma mensagem preparada.

Verifique o domínio do remetente

Um campo From: visível é fácil de falsificar. O SPF verifica se o hospedeiro remetente está autorizado para o domínio do envelope. O DKIM verifica a assinatura de uma mensagem usando uma chave pública publicada no DNS. O DMARC associa um resultado bem-sucedido de SPF ou DKIM ao domínio From visível por meio do alinhamento de domínios e publica uma política para falhas. A aprovação do SPF apenas para um domínio de envelope não relacionado não valida o remetente visível.

A transferência de correio, o conteúdo da mensagem e o acesso à caixa postal são partes separadas do correio eletrônico. O SMTP transfere uma mensagem para um servidor de correio. A mensagem tem seu próprio formato de cabeçalho e corpo, e um destinatário acessa mais tarde a caixa postal armazenada por outro protocolo.

Leia a própria mensagem

Uma mensagem começa com campos como From:, To:, Date:, Subject: e Message-ID:. Uma linha em branco separa esses cabeçalhos do corpo. Eles continuam fazendo parte da mensagem armazenada; os comandos SMTP MAIL FROM e RCPT TO não se tornam cabeçalhos da mensagem.

O formato básico usa linhas de texto. O MIME, Extensões multiuso do correio da internet, descreve conteúdo mais complexo com campos adicionais. Content-Type: text/plain; charset=UTF-8 descreve texto simples e sua codificação de caracteres. image/jpeg identifica uma imagem. multipart/mixed descreve várias partes, separadas por uma sequência delimitadora, como uma nota de texto seguida de um anexo. Cada parte pode ter seu próprio tipo de conteúdo e codificação de transferência.

Content-Transfer-Encoding descreve como uma parte é representada para transferência. Base64 transforma cada grupo de três bytes em quatro caracteres ASCII. Para um anexo de 3 MB, 3.000.000 bytes se tornam 4.000.000 caracteres antes das quebras de linha e dos cabeçalhos da mensagem. A codificação acrescenta cerca de um terço ao tamanho. Portanto, o limite de tamanho total de mensagem de um servidor não pode ser comparado apenas ao tamanho bruto do anexo. Quoted-printable é outra codificação adequada a texto predominantemente legível.

Escolha um protocolo de acesso ao correio eletrônico

O servidor do destinatário pode receber mensagens enquanto os dispositivos do destinatário estão offline. Quando ele retorna, um protocolo de acesso ao correio eletrônico permite que um cliente recupere mensagens armazenadas.

O IMAP pode buscar os cabeçalhos ou partes selecionadas de uma mensagem sem baixar todos os anexos. Ele costuma usar a porta 143 com STARTTLS ou a porta 993 com TLS desde o início. O POP3 costuma usar a porta 110 ou TLS na 995. Suas marcações de exclusão entram em vigor quando a sessão termina normalmente. Baixar e manter deixa cópias no servidor, mas o POP3 não oferece as pastas no servidor e os indicadores compartilhados do IMAP.

Suponha que Bob verifique suas mensagens em um laptop antes de sair de casa e depois em um celular. Se o laptop usar POP3 no modo baixar e excluir, o celular pode encontrar uma caixa postal vazia no servidor. Com IMAP, marcar uma mensagem como lida no laptop altera o estado no servidor, que o celular também pode ver. A diferença está na sincronização da caixa postal, não na entrega por SMTP.

Acompanhe uma mensagem de webmail além do navegador

Um navegador submete ou lê mensagens usando HTTPS. O provedor de webmail ainda usa SMTP para transferir mensagens ao servidor de outro domínio. Um caminho completo pode, portanto, usar HTTPS do remetente ao provedor, SMTP entre provedores e depois IMAP ou HTTPS na extremidade receptora. Chamar um serviço de webmail descreve sua interface de usuário e sua conexão com o navegador, não todos os protocolos usados no percurso da mensagem.

Distribuir um arquivo significa que cada destinatário deve obter uma cópia completa. O gargalo nem sempre é o servidor: um destinatário com download lento ou capacidade total de upload insuficiente pode determinar o tempo mínimo. O modelo padrão pressupõe que os enlaces de acesso são os gargalos e que o núcleo tem capacidade suficiente.

Compare os limites inferiores

Considere um arquivo com $F$ bits e $N$ destinatários. O servidor envia à taxa $u_s$; o par $i$ envia à taxa $u_i$ e baixa à taxa $d_i$. A menor taxa de download de um par é $d_{min}$. Use unidades correspondentes, como Mbit e Mbps, para que a divisão produza segundos.

Na distribuição cliente-servidor, o servidor precisa enviar $NF$ bits e o par mais lento precisa receber $F$ bits:

No P2P, o servidor precisa introduzir cada bit pelo menos uma vez. Os pares ainda precisam baixar o arquivo, e o sistema inteiro precisa enviar dados suficientes para todas as cópias:

Escolha o máximo, pois todos os requisitos devem ser atendidos durante a distribuição. Somar os termos pressuporia incorretamente que essas atividades de upload e download ocorrem uma após a outra. Esses são limites inferiores; sobrecarga do protocolo, pares indisponíveis e outros gargalos podem tornar as transferências reais mais lentas.

Faça uma comparação

Para um arquivo de 2 Gbit, use 2.000 Mbit. Considere o upload do servidor de 100 Mbps, o download mais lento de 20 Mbps e cada um dos 100 pares enviando a 5 Mbps.

O termo do servidor cliente-servidor é 200.000 Mbit dividido por 100 Mbps, ou 2.000 s. O termo do download mais lento é 100 s. Seu limite é, portanto, 2.000 s.

Para P2P, introduzir o arquivo leva pelo menos 20 s. O download mais lento ainda leva 100 s. A capacidade total de upload é 100 mais 500, ou 600 Mbps; distribuir 200.000 Mbit leva pelo menos cerca de 333 s. O limite P2P é de cerca de 333 s. Com 1.000 pares, o limite cliente-servidor sobe para 20.000 s, enquanto o limite P2P é de cerca de 392 s. Para taxas de upload iguais entre os pares, o termo de capacidade total se aproxima do tamanho do arquivo dividido pela taxa de upload de um par conforme o número de pares cresce.

Troque partes no BitTorrent

Um torrent é um grupo que compartilha um arquivo. Pares trocam partes, descobrem vizinhos por meio de um rastreador ou tabela hash distribuída e podem enviar dados antes de terminar o download. Um semeador tem o arquivo completo e continua a compartilhá-lo.

Mais raro primeiro escolhe uma parte necessária que o menor número de vizinhos possui, ajudando a preservar partes que poderiam desaparecer quando um par sai. Isso decide o que solicitar. A reciprocidade incentiva trocas úteis ao favorecer vizinhos que fornecem dados rapidamente; ela decide para quem enviar.

No projeto original, quatro vizinhos interessados são desbloqueados por vez, incluindo um desbloqueio otimista. A escolha regular é revista aproximadamente a cada 10 s e o par otimista aproximadamente a cada 30 s. Essa vaga exploratória dá aos recém-chegados uma forma de obter partes iniciais e ajuda a descobrir parceiros melhores. O rastreador coordena a descoberta; ele não é a fonte de dados de cada parte.

Um vídeo consiste em quadros exibidos ao longo do tempo. A compressão remove informações repetidas dentro de um quadro (redundância espacial) e entre quadros (redundância temporal). O resultado codificado tem uma taxa de bits: a quantidade de dados de vídeo necessária para cada segundo de reprodução.

Relacione taxa, tamanho e tempo de reprodução

Um vídeo de duas horas a 5 Mbps contém 36.000 Mbit, ou 4,5 GB. Multiplique a taxa pela duração para obter bits e depois divida por oito para obter bytes. Uma vazão média do caminho abaixo da taxa de vídeo selecionada acaba esvaziando qualquer buffer finito durante a reprodução contínua.

Um reprodutor pode começar antes de baixar o vídeo inteiro. Ele armazena os próximos dados em um buffer, medido aqui em segundos de vídeo reproduzível. A reprodução consome esse buffer enquanto os downloads o reabastecem. Um buffer inicial maior oferece proteção contra quedas de vazão, mas aumenta o atraso de inicialização.

Solicite um segmento por vez

O DASH, streaming adaptativo dinâmico sobre HTTP, armazena várias versões codificadas em taxas diferentes e divide cada uma em segmentos. Um manifesto lista as versões disponíveis e as URLs dos segmentos. O cliente solicita um segmento com HTTP GET e escolhe novamente uma versão no limite do segmento seguinte. O HLS usa uma abordagem semelhante com listas de reprodução.

O reprodutor toma a decisão de adaptação usando a vazão medida e o nível do buffer. Uma estimativa recente de vazão alta favorece uma taxa maior; um buffer baixo exige cautela. Escolher a maior taxa observada uma vez pode causar uma interrupção se o download seguinte ficar mais lento. Reprodutores também tentam evitar mudanças de qualidade frequentes e que distraiam o usuário.

Calcule o download de um segmento

Considere segmentos de 4 s codificados a 1; 2,5; 5 e 8 Mbps. Com uma vazão medida de 6 Mbps, o segmento de 5 Mbps contém 20 Mbit. Ele é baixado em cerca de 3,33 s, acrescentando 4 s de conteúdo reproduzível enquanto a reprodução consome cerca de 3,33 s. Com a reprodução em andamento, o buffer cresce cerca de 0,67 s.

Um segmento de 8 Mbps contém 32 Mbit e leva cerca de 5,33 s, então o buffer diminui cerca de 1,33 s. Os 6 Mbps do caminho são uma taxa de transferência; eles não transformam uma codificação de 8 Mbps em uma de 6 Mbps.

Se a vazão cair para 3 Mbps, o mesmo segmento de 5 Mbps levará cerca de 6,67 s. O buffer perde cerca de 2,67 s por segmento. Mudar para a versão de 2,5 Mbps produz um segmento de 10 Mbit que leva cerca de 3,33 s, permitindo que o buffer volte a crescer. Para uma reprodução ininterrupta durante um download, o buffer inicial também precisa durar até que novos dados reproduzíveis estejam disponíveis.

Streaming armazenado e chamadas interativas

O streaming de vídeo armazenado usa objetos HTTP comuns, que caches de navegador e servidores CDN podem fornecer. Portanto, ele funciona sobre TCP ou QUIC, conforme a versão do HTTP. Chamadas interativas frequentemente usam transporte de mídia baseado em UDP porque esperar por mídia antiga pode ser pior do que perdê-la.

Um evento ao vivo também pode usar streaming HTTP segmentado, mas o reprodutor espera a produção de cada segmento e mantém um buffer com atraso em relação ao evento ao vivo. Segmentos mais curtos podem reduzir esse atraso, aumentando o número de requisições. Ir para uma posição que não está no buffer também exige reabastecer o reprodutor, o que pode reduzir brevemente a qualidade.

Uma rede de distribuição de conteúdo, ou CDN, fornece cópias de conteúdo a partir de muitos locais. Ela evita enviar todos os espectadores a um único centro de dados distante e reduz transferências repetidas de longa distância. Distribuir a capacidade de atendimento também reduz a dependência de um único local.

Coloque o conteúdo perto dos usuários

Uma CDN privada pertence a um provedor; uma CDN de terceiros atende a muitos clientes. Ambas podem entregar imagens, scripts, software e páginas web, além de vídeo. A fonte original do conteúdo é a origem. Agrupamentos da CDN mantêm cópias para que a origem não precise atender a todas as requisições.

Há duas estratégias úteis de posicionamento:

Posicionamento e abastecimento de conteúdo são escolhas distintas. Com armazenamento sob demanda, um agrupamento que não possui um objeto busca-o na origem ou em outro agrupamento, armazena-o e o fornece. Com distribuição antecipada, o provedor envia objetos com antecedência, muitas vezes durante períodos de pouco tráfego. A primeira requisição de um objeto ausente do cache de uma CDN sob demanda ainda pode depender da origem.

Acompanhe uma transferência pelo DNS

Um usuário solicita https://video.stream.example.com/v/6Y7B23V:

1. O resolvedor do usuário consulta video.stream.example.com.
2. O servidor autoritativo do provedor retorna um CNAME para o espaço de nomes da CDN, como a1105.cdn.example.net.
3. O resolvedor segue esse nome até o serviço DNS autoritativo da CDN.
4. A CDN seleciona um agrupamento e retorna um endereço como 198.51.100.17.
5. O cliente se conecta a esse servidor por HTTPS e solicita o conteúdo.

O CNAME muda onde a resolução de nomes continua. O DNS retorna informações de nomes; os bytes do vídeo chegam depois por HTTP. Se o conteúdo estiver segmentado, muitas requisições comuns de segmentos seguem o mesmo caminho básico até um servidor selecionado.

Escolha uma localização útil

O agrupamento mais próximo no mapa pode ter um caminho de rede ruim ou estar sobrecarregado. Uma decisão baseada em DNS pode considerar a localização do resolvedor, que pode estar longe do usuário. Uma seleção melhor pode usar medições de atraso e perda, carga atual e, às vezes, informações sobre a rede do cliente.

O anycast IP oferece outro caminho para um serviço próximo: vários locais anunciam o mesmo endereço IP, e o roteamento da internet escolhe um caminho até um deles. A localização resultante depende do roteamento, não apenas da distância física. Um servidor perto do espectador ainda pode entregar vídeo de baixa qualidade se o próprio enlace de acesso do espectador for o gargalo.

O Open Connect da Netflix instala equipamentos em redes de provedores de serviços de internet e se conecta em pontos de troca de tráfego. O conteúdo é carregado antes da demanda, reduzindo o tráfego de saída nos horários de pico. Seus serviços de aplicação e a entrega de vídeo codificado não precisam funcionar na mesma infraestrutura. Outros projetos de CDN privada podem preencher caches sob demanda. Em cada caso, o streaming adaptativo controla a taxa que o reprodutor solicita, enquanto a CDN ajuda a determinar o caminho e o servidor que atendem a essas requisições.

Sockets Python enviam bytes. Codifique uma string antes de enviá-la e decodifique os bytes recebidos depois; a codificação de texto padrão é UTF-8. AF_INET seleciona IPv4 e SOCK_DGRAM seleciona UDP. Comece com um serviço local para que ambos os processos possam usar o endereço de loopback 127.0.0.1.

Execute primeiro o receptor

Este servidor trata datagramas curtos de texto e responde em letras maiúsculas:

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind atribui ao socket seu endereço e sua porta de recepção. A vinculação a 127.0.0.1 aceita apenas tráfego local. A string de endereço vazia "", por sua vez, vincula o socket a todas as interfaces IPv4, tornando o serviço acessível a outros hospedeiros quando a rede permite. Pare o servidor em execução antes de iniciar outra cópia na mesma extremidade.

recvfrom bloqueia até a chegada de um datagrama. Ele retorna os dados e o endereço do remetente, incluindo sua porta. O servidor usa o par retornado como destino de sendto, podendo assim responder a clientes cujas portas efêmeras não conhecia antecipadamente.

Envie uma requisição e limite a espera

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

O prefixo b cria um literal de bytes; "hello network".encode() produz os mesmos bytes. O sistema operacional atribui a porta local do cliente quando necessário. A resposta esperada é HELLO NETWORK. Nenhum dos programas chama listen ou accept, pois o UDP não estabelece uma conexão de transporte.

Uma resposta ausente não informa ao cliente exatamente o que falhou. A requisição ou a resposta pode ter se perdido, ou pode não haver servidor escutando. O tempo limite permite que a aplicação retome o controle. Alguns sistemas podem informar uma porta de destino fechada como erro; o Windows pode gerar ConnectionResetError durante a recepção.

Respeite os limites dos datagramas

Cada recepção trata um datagrama. Dois datagramas não são combinados em uma mensagem. Se o buffer de recepção for pequeno demais, o excesso desse datagrama será descartado em sistemas Unix típicos; o Windows pode informar um erro. Outra recepção não recupera a parte final ausente. Escolha um buffer grande o suficiente para as mensagens esperadas pela aplicação.

O limite da carga útil UDP sobre IPv4 é de 65.507 bytes com um cabeçalho IPv4 de tamanho mínimo. Esse é um máximo do protocolo, não uma meta útil para o tamanho rotineiro de datagramas. Um programa que precisa detectar perdas pode numerar mensagens, registrar os horários de envio com time.perf_counter() e contar tempos limite expirados. Dois tempos limite expirados em dez requisições resultam em uma taxa de perda medida de 20%. Tentar novamente uma requisição pode causar processamento duplicado, então um projeto com tempo limite e nova tentativa também pode precisar de uma forma de reconhecer números de mensagem repetidos.

O TCP fornece ao programa um fluxo de bytes ordenado. Ele não preserva os limites das chamadas sendall. Um teste curto e completo pode chegar em um único recv, mas um programa correto também deve tratar uma requisição dividida entre várias recepções.

Delimite uma requisição de texto

Escolha uma quebra de linha como delimitador. O cliente envia uma linha UTF-8, e o servidor retorna uma linha em maiúsculas. Este servidor lê até encontrar esse delimitador antes de decodificar:

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen cria um socket de escuta, ou socket de acolhimento. accept retorna um novo socket de conexão e o endereço do cliente. Use conn para os bytes desse cliente; o socket original permanece disponível para aceitar mais conexões. Aqui, os clientes são atendidos um por vez. A fila de cinco diz respeito a conexões pendentes, não a cinco threads de trabalho ativas.

Complete o lado do cliente

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

O resultado esperado é HELLO NETWORK. sendall continua enviando até que todos os bytes fornecidos sejam entregues para envio ou ocorra um erro. Uma única chamada send pode enviar apenas parte e informa quantos bytes aceitou. Nenhuma das chamadas fornece ao receptor os limites de mensagens da aplicação.

Esse serviço aceita uma linha por conexão. Um serviço persistente com várias mensagens manteria os bytes após a primeira quebra de linha para sua próxima mensagem. Prefixos de comprimento e o fechamento da direção de envio são outras opções de delimitação. Receber b"" significa que o par encerrou seu lado de envio; não é uma parte vazia cuja recepção deva ser tentada novamente.

Relacione o código a protocolos reais

Uma requisição HTTP/1.1 também é uma sequência de bytes:

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

Isso exibe o início da resposta bruta, incluindo seu status e seus cabeçalhos. Um servidor pode retornar um erro ou redirecionamento; o código não pressupõe um corpo de resposta específico. HTTPS na porta 443 precisa de uma camada TLS com verificação de certificado e nome de hospedeiro, não apenas de uma mudança no número da porta. Por exemplo, ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") envolve um socket conectado após import ssl. Uma conexão recusada normalmente significa que ninguém está escutando; tráfego descartado silenciosamente pode atingir o tempo limite. Para reinicializações rápidas do servidor no Unix, definir SO_REUSEADDR antes de bind pode permitir a reutilização enquanto uma conexão antiga está sendo encerrada; isso não permite que dois sockets de escuta ativos ocupem a mesma extremidade. Servidores concorrentes usam threads ou laços de eventos e distinguem conexões pelos pares de endereço e porta de ambas as extremidades.