Elementos e Protocolos da World Wide Web

Afluentes: Desenvolvimento Front-end I, Sistemas Distribuídos e Mobile

Aspectos elementares sobre a World Wide Web

"Conjunto de computadores autônomos interconectados por uma única tecnologia" — Tanenbaum (2003).

"É uma rede de computadores mundial, isto é, uma rede que interconecta milhões de equipamentos de computação em todo o mundo" — Kurose 2006.

Leonard Kleinrock

1960 - Leonard Kleinrock publica o primeiro trabalho sobre comutação de pacotes

• Durante sua pós-graduação no MIT (Instituto de Tecnologia de Massachusetts), ele desenvolveu uma teoria matemática de comutação de pacotes, dividindo os dados em pacotes que podem ser trocados por meio de uma rede. Dessa forma, vários usuários podem acessá-los em diferentes plataformas. A Internet foi baseada nessa tecnologia.
• A Agência de Projetos de Pesquisa Avançada (ARPA, hoje DARPA), com interesse no projeto, buscou uma equipe para construir, instalar e gerenciar um projeto para usar esse novo tipo de rede. Engenheiros da computação da Bolt Beranek & Newman (BBN), construiram uma máquina chamada IPM (Processador de Mensagens de Interface), o primeiro roteador.
• O primeiro nó de rede foi alocado na UCLA (University of California, Los Angeles), onde Kleinrock se tornou professor.
• A equipe do projeto criou uma rede usando uma infraestrutura existente, as linhas telefônicas.
• Em 29 de outubro de 1969, a equipe reunida no 3420 Boelter Hall tentou enviar a primeira mensagem ao Instituto de Pesquisa de Stanford: LOGIN. Eles conseguiram digitar as primeiras duas letras, mas o sistema caiu. Dessa forma, LO, foi a primeira mensagem enviada pela estrutura que se tornaria a Internet.
• Uma hora depois, eles tentaram novamente e conseguiram.
• Até dezembro de 1969, quatro nós foram instalados na UCLA, no Instituto de Pesquisa de Stanford, Universidade de Utah e Universidade da Califórnia em Santa Barbara. Em 1975, já havia 57 IMPs e em 1981, eram 213.

Segundo Kleinrock, na época "nós não sabíamos o que estávamos fazendo. Nós nem sequer tiramos uma foto.", o jornal da faculdade publicou uma notinha, mas passou despercebido.

Sala do projeto na UCLA

• Em 1970 surgiram de novas redes de comutação de pacotes: ALOHANET; Telnet; Redes SNA da IBM;
• Entre 1980 e 1990, aproximadamente 200 máquinas estavam conectadas à ARPAnet;
• E na década de 1990 ocorreu a popularização da internet.

Componentes

• Hospedeiros ou sistemas Finais são os equipamentos de computação conectados;
• Enlaces são os links de comunicação entre os sistemas finais são conectados entre si;
• Comutadores de pacotes encaminham a informação que chega a um de seus enlaces de entrada para um de saída. Ex: roteadores;
• Provedores de Serviçoes de Internet (Internet Service Providers - ISPs) são os responsáveis por prover o acesso dos sistemas comptutaciconais à internet;

Camadas de Protocolos

Camadas de rede

• Camada de Aplicação: inclui as aplicações de rede (navegador, aplicativo de e-mail, etc.) e seus protocolos (HTTP, SMTP, FTP, etc.).
• Camada de Transporte: transporta mensagens da camada de aplicação entre cliente e servidor de uma aplicação. Inclui os protocolos TCP e UDP;
• Camada de Rede: responsável pela movimentação dos pacotes (ou datagramas) de dados de uma máquina para outra e converte os endereços lógicos em endereços físicos.
• Camada de Enlace: roteia um datagrama por meio de roteadores entre a origem e o destino. Transforma os datagramas em quadros, com informações dos endereços físicos, para serem trafegados pela internet.
• Camada Física: movimenta os bits individuais que estão dentro dos quadros de um nó para o seguinte. Os bits são transformados em sinais compatíveis com o meio onde os dados são transmitidos.

Camadas de rede

Internet

• Pacotes chamados de datagramas
• Mecanismo global de endereçamento: Endereços IP
• Roteamento de datagramas para hosts remotos
• Move os dados entre as camadas Interface de Rede e Transporte
• Transporte
  • Comunicação fim-a-fim
  • Dois protocolos:
    • UDP: rápido, não robusto, leve, sem conexão
    • TCP: confiável, com conexão, controle de fluxo
• Serviços de Aplicação conhecidos:
  • Login remoto (telnet)
  • Transferência de arquivos (FTP)
  • Transferência de documentos de hipermídia (HTTP)
  • Correio eletrônico (SMTP)
  • Nomes de hosts a endereços IP (DNS)
  • Gerenciamento (SNMP)
  • Sistema de arquivos (NFS)

Protocolos

• Todos os padrões da internet são desenvolvidos pela Força de Trabalho de Engenharia de Internet (Internet Engineering Task Force - IETF);
• Os documentos padronizados IETF são denominados RFCs (Request for Comments - Pedido de Comentários);
• Os RFCs definem protocolos como TCP, IP, HTTP (para WEB) e SMTP.
• Os protocolos são regras que definem o formato, ordem das mensagens enviadas e recebidas pelas entidades da rede; e ações tomadas quando da transmissão ou recepção de mensagens. Eles controlam o envio e recebimento de mensagens (TCP, IP, HTTP, FTP, etc.).

DNS

• Domain Name System, ou sistema de nomes de domínios
• Sistema hierárquico e distribuído para organizar os nomes dos computadores, serviços ou máquina conectada à internet ou rede privada
• Associa nomes a endereços IP numéricos para facilitar a memorização (resolução de nomes)
• O IP é o real endereço do dispositivo na rede
• O aumento do número de servidores não degrada substancialmente o desempenho
• O DNS usa o UDP (User Datagram Protocol) na porta 53 para servir solicitações e requisições
• Arquitetura cliente-servidor e pode envolver vários servidores DNS na resposta de uma consulta.
• O serviço é normalmente implementado pelo software BIND, que encontra-se no servidor DNS primário
• O DNS secundário é um backup do primário para reestabelecer uma rota alternativa, caso o primeiro caia.

Existem centenas de servidores-raiz DNS (root servers) no mundo todo, agrupados em 13 zonas DNS raiz, das quais sem elas a Internet não funcionaria. Destes, dez estão localizados nos Estados Unidos da América, dois na Europa e um na Ásia. Para aumentar a base instalada destes servidores foram criadas réplicas localizadas por todo o mundo, inclusive no Brasil desde 2003.

Hierarquia

• Necessário ter uma organização distribuída e escalável devido ao tamanho da Internet
• Motivo:
  • Disponibilidade: se tivesse um único servidor e falhasse, o serviço seria interrompido para o mundo todo
  • Volume de tráfego: evita que apenas um servidor tenha que tratar de todos os pedidos, o que seria inviável
  • Distância: deixa os clientes mais próximos de algum servidor que responda mais rapidamente a requisição
  • Manutenção do banco de dados: apenas um banco de dados seria muito grande e precisaria atualizar muito frequentemente os dados.

Estrutura

A estrutura hierárquica dos servidores DNS se dividem em três categorias: Servidores-raiz, Servidores de domínio de topo e Servidores com autoridade.

Servidores-raiz

• 13 servidores raiz
• Um servidor-raiz (root name server') é um servidor de nome para a zona raiz do DNS e responde diretamente às requisições de registros da zona raiz, retornando a lista dos servidores de nomes designados para o domínio do topo apropriado
• Estão no primeiro passo para resolverr os nomes para endereços IP para a comunicação entre os hosts

Servidores de domínio de topo (top-level domain)

• Os domínios são formados por nomes separados por pontos
• O nome mais a direita é o domínio de topo (.com, .org, .net, .gov, .edu, etc.)
• Um servidor de domínio de topo conhece os endereços dos seridores autoritativos que pertencem àquele domnínio de topo
• Existem as terminaçãoes orientadas a países, como .br, .ar, .fr e com combinações .com.br, .edu.br, etc. (Country Code Top Level Domains)

Servidores com autoridade

• Possui registros originais que associam um domínio ao seu endereço IP
• Quando um domínio adquire um novo endereço, as informações deve ser adicionadas a pelo menos dois servidores autoritativos (principal e secundário)

Funcionamento

O diagrama a seguir disponibiliza uma visão geral sobre como os serviços DNS recursivos e autoritativos funcionam em conjunto para direcionar um usuário final para o seu website ou a sua aplicação.

Direcionamento do Tráfego DNS para uma aplicação Web.

1. Um usuário abre um navegador, digita www.exemplo.com na barra de endereços e aperta Enter.

2. A solicitação de www.exemplo.com é direcionada para um resolvedor DNS, que geralmente é gerenciado pelo ISP (Internet service provider – Provedor de serviços de internet) do usuário, como um provedor de internet a cabo, um provedor de banda larga DSL ou uma rede corporativa.

3. O resolvedor DNS do ISP encaminha a solicitação, que sai de www.exemplo.com e passa para um serviço de nome raiz DNS.

4. O resolvedor DNS do ISP encaminha novamente a solicitação de www.exemplo.com, mas desta vez para um dos servidores de nome TLD de domínios .com. O servidor de nome dos domínios .com responde a solicitação com os nomes dos quatro servidores de nome do Amazon Route 53 que estão associados ao domínio exemplo.com.

5. O resolvedor DNS do ISP escolhe um servidor de nome do Amazon Route 53 e encaminha a solicitação de www.exemplo.com para o servidor de nome em questão.

6. O servidor de nome do Amazon Route 53 procura na hosted zone exemplo.com pelo registro de www.exemplo.com, obtém o valor associado, como o endereço IP de um servidor web (192.0.2.44) e retorna o endereço IP ao resolvedor DNS.

7. Por fim, o resolvedor DNS do ISP obtém o endereço IP de que o usuário precisa. O resolvedor retorna este valor para o navegador. O resolvedor DNS também armazenará em cache o endereço IP de exemplo.com durante um período que você especificará para que ele possa responder mais rapidamente da próxima vez que alguém pesquisar por exemplo.com. Para obter mais informações, consulte a TTL (time to live – vida útil).

8. O navegador enviará uma solicitação de www.exemplo.com para o endereço IP que obteve do resolvedor DNS. O seu conteúdo poderá ser encontrado lá. Por exemplo, um servidor web em execução em uma instância do Amazon EC2 ou um bucket do Amazon S3 que seja configurado como um endpoint do website.

9.O servidor web ou outro recurso em 192.0.2.44 retornará a página web de www.exemplo.com para o navegador que, por sua vez, exibirá a página.

SMTP

• Simple Mail Transfer Protocol ou Protocolo de Transferência de Correio Simples
• Protocolo padrão de envio de mensagens de e-mail
• Sintaxe simples de texto
• Destinado a um ou mais destinatários
• Porta padrão 25 e 465 encriptografadas (SSL). Pode-se usar a porta 587 como alternativa

Exemplo

1. É estabelecida uma conexão entre o cliente e o servidor (emissor e receptor)
2. Inicia a comunicação (C cliente e S servidor)

C: MAIL FROM:<gendo@nerv.com.jp>
S: 250 OK
C: RCPT TO:<shinji@unit01.com.jp>
S: 250 OK
C: RCPT TO:<touji@unit01.com.jp>
S: 550 No such user here
C: RCPT TO:<asuka@unit02.com.jp>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Entrem nesses malditos robos
C: e vão lá fora defender Tokyo 2
C: <CRLF>.<CRLF>
S: 250 OK

Os clientes podem verificar no servidor sobre quais as extensões SMTP são suportadas com o comando EHLO (diferente de HELO), e o corpo da mensagem (depois de DATA) segue tipicamente em formato MIME.

POP3

• Post Office Protocol ou Protocolo dos Correios
• Utilizado para acesso remoto ao servidor de e-mals (RFC 1939)
• Pode transferir sequencialmente todas as mensagens de uma caixa de e-mails para um aplicativo de e-mail cliente, por exemplo Thundervird
• Utiliza as portas TCP 110 ou TCP 995 criptografada
• Funcionamento off-line:

1. Estabelece a conexão cliente-servidor
2. Efetua a autenticação
3. As mensagens são transferidas para o programa cliente
4. As mensagens são apagadas (opcionalmente) no servidor, mas pode configurar para não ser apagada e manter uma cópia no servidor.
5. A conexão é terminada
6. O leitor pode ler suas mensagens sem necessitar de conexão (off-line)

• Bastante útil quando o custo da ligação é proporcional ao tempo de ligação (como nas conexões discadas)

Comandos

USER name                   usuário
PASS password               senha
STAT                        retorna a quantidade de mensagens
LIST [msg]                  mostra o tamanho do e-mail [msg] se existir
RETR msg                    retorna o conteúdo do e-mail (linha a linha)
DELE msg                    apaga uma mensagem
NOOP                        servidor não faz nada e retorna um OK
RSET                        cancela pedidos de apagar se existirem
QUIT                        atualiza as transações e termina a conexão TCP

Campos de cabeçalho dos e-mails usados frequentemente

To: endereço de e-mail do destinatário
Cc: receptores destinatário (Carbon Copy)
From: endereço de e-mail do remetente
Reply-To: endereço de e-mail para onde as respostas devem ser enviadas
Return-Path: endereço e percurso de volta para o remetente (adicionado pelo último Agente de Transporte de Mensagens)
Subject: sumário da mensagem.

FTP

• File Transfer Protocol ou Protocolo de Transferência de Arquivos
• Responsável pelo envio e recebimento de arquivos pela internet
• Arquitetura cliente-servidor
• Os arquivos são hospedados em um servidor e clientes se conectam para a troca
• Baseado no TCP. É mais antigo, mas foi adaptado.
• O protocolo é especificado na RFC 959.
• Um cliente realiza uma conexão TCP na porta 21 do servidor (conexão de controle).
• Ela permanece aberta ao longo da sessão e estabelece uma segunda conexão, chamada conexão de dados, na porta 20
• Lista de comandos FTP

SSH

• Secure SHell
• Protocolo que garante que cliente e servidor troquem informações encriptografadas de forma segura e sem perda de informações
• Utiliza criptografia de chave pública para autenticar o computador remoto
• Os pares de chaves pública-privada podem ser geradas automaticamente ou de forma manual
• Usado normalmente para login remoto e teve como objetivo substituir o Telnet
• Também suporta redirecionamento de portas TCP, transferência de arquivos via SFTP, cópia segura SCP
• Usa como padrão a porta TCP 22
• Grande relevância para a Computação em Nuvem, permitindo conexões remotas à servidores através da Internet, sem comprometer a segurança dos dados.
• Existem duas principais especificações do protocolo, SSH-1 e SSH-2.

HTTP

• Hypertext Transfer Protocol ou Protocolo de Transferência de Hipertexto
• Protocolo cliente-servidor: requisições iniciadas pelo destinatário (navegador web)
  • Um computador cliente envia ao servidor uma requisição HTTP para um servidor usando um aplicativo (navegador web)
  • O servidor fornece os recursos, tais como documentos HTML e outros conteúdos e retorna uma resposta ao cliente.
• Protocolo de comunicação utilizado para sistemas de informação de hipermídia, distribuídos e colaborativos
• É a base para a comunicação de dados da World Wide Web
• Porta padrão 80
• A versão seguda é o HTTPS na porta 443

Sessão HTTP

• Sequência de transações de rede de requisição-resposta
• Cliente inicia uma requisição e é estabelecida uma conexão TCP
• Um servidor HTTP ouvindo na porta espera uma requisição do cliente
• Quando o servidor recebe a requisição, retorna uma linha de estado (ex. HTTP/1.1 200 OK) e uma mensagem própria
• O corpo da mensagem é o recurso solicitado ou uma mensagem de erro

Cookies

Da palavra em inglês biscoito. Recebeu esse nome de uma antiga gíria usada pelos programadores que consistia em um programa chamava um procedimento e recebia de volta algo que seria necessário apresentar novamente mais tarde para realizar algum trabalho. In the movie “The Matrix” Neo receives a cookie from the Oracle. Criado pela Netscape para solucionar o problema do envio e solicitação de arquivos, que era esquecido pelo servidor e que poderia ser usado por outros computadores com o mesmo IP conforme, o que causava problemas, pois não se sabia na realidade se era ou não aquele usuário mesmo.

• São arquivos ou strings e não programas executáveis
• Tratados pelo navegador como dados trocados entre o servidor e o navegador e alocados em uma pasta no computador o usuário
• Serve para manter a persistência das sessões HTTP
• Conteúdo de no máximo 4 kb e até 5 campos:
  • Domain: origem do cookie
  • Path: caminho da estrutura de diretórios no servidor que podem usar o cookie
  • Content: utiliza n dados com o formato "nome = valor"
  • Expires: faz o cookie persistir por um determinado tempo
  • Secure: se é seguro ou não

Mensagem HTTP

• tanto requisição como resposta são compostas por
  • uma linha inicial
  • nenhuma ou mais linhas de cabeçalho
  • uma linha em branco obrigatória finalizando o cabeçalho
  • corpo da mensagem (opcional)

Cabeçalho da mensagem (header)

• usado para transmitir informações adicionais
• especificado após a linha inicial da transação (método) seguido de dois pontos (:) e um valor
• Tipos de cabeçalhos:
  • general-header: envia informações adicionais
  • request-header: requisição do cliente
  • response-header: resposta do servidor
  • entity-header informação sobre o corpo da mensagem

Corpo da mensagem

• Se houver corpo, fica localizado abaixo do cabeçalho
• São incluídos nocabeçalhos de entidades que descrevem suas características (ex. Content-Type - tipo MIME, Content-Length - quantidade de bytes do corpo)

Alguns tipos MIME:

text/plain                     Arquivo no formato texto (ASCII)
text/html                      Arquivo no formato HTML, utilizado
Image/gif                      Imagem com o formato GIF
Image/jpeg                     Imagem com o formato JPEG
application/zip                Arquivo compactado
application/json               Arquivo no formato JSON
application/xml (ou text/xml) 	Arquivo no formato XML

Requisição

• Composta pelos campos:
  • uma linha inicial (Request-Line)
  • linhas de cabeçalhos (Request-header)
  • uma linha em branco obrigatória e um corpo de mensagem opcional
  • linha inicial de uma requisição, composta por três partes separadas por espaços:
    • o método (Method)
    • a identificação do URI (Request-URI)
    • a versão do HTTP (HTTP-Version) utilizado.

Request-URI é um identificador uniforme de recurso (Uniform Resource Identifier) que identifica sobre qual recurso será aplicada a requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de URL (Uniform Resource Locator), composto pela identificação do protocolo, pelo endereço do computador servidor e pelo documento requisitado.

Métodos

GET

• Requisita uma representação do recurso especificado
• Apenas recuperam dados

Envio:

GET /index.html HTTP/1.1
Host: www.exemplo.com

Resposta:

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

HEAD

• Variação do GET, mas não retorna nenhum recurso
• Uusado para obter metainformações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.

POST

• Envia dados para serem processados (ex. formulário HTML)
• Os dados são incluídos no corpo do comando
• Uma requisição POST requer que as informações sejam incluídas no corpo da mensagem e formatadas como uma query string, além dos cabeçalhos, seu tamanho (Content-Length) e seu formato (Content-Type).
• Oferece maior segurança em relação aos dados transferidos, diferente do método GET que os dados são anexados a URL, ficando visíveis ao usuário.

POST vs GET

POST /index.html HTTP/1.0
Accept: text/html
If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT
Content-Type: application/x-www-form-urlencoded
Content-Length: 41

Nome=NomePessoa&Idade=99&Curso=Computacao

PUT

• Semelhante ao POST, mas sobrescreve os dados, ficando apenas com o últimoo registro atualizado
• Se executar com o POST, são criados diversos registros para cada requisição realizada
• Veja que o put substitui todos os atuais dados do recurso de destino pelos dados passados na requisição. Estamos falando de uma atualização integral. Existe, então, a possibilidade de atualizar todo o recurso em apenas uma requisição.
• Em suma, na requisição, você envia todos os dados do recurso.

PATCH

• aplica modificações parciais em um recurso.
• Logo, é possível modificar apenas uma parte do recurso.
• Veja que estamos falando de um subconjunto de uma atualização complete (PUT), estamos falando de uma atualização parcial, o que torna as coisas mais flexíveis.
• Diferente do PUT, na requisição você só envia os dados que quer modificar.

DELETE

• Exclui o recurso.

TRACE

• Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido.

OPTIONS

• Recupera os métodos HTTP que o servidor aceita.

CONNECT

• Usado com um proxy para tornar um túnel SSL e TLS (conexão segura).