ESTUDO GERAL REDES

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

//estudo geral redes
//materia P1
//o que e internet
milhões de dispositivos de computação conectados:
hospedeiros = sistemas finais rodando aplicações de rede
//enlaces de comunicação
fibra, cobre, rádio, satélite
taxa de transmissão = largura de banda
//O que é a Internet: visão dos elementos básicos
* protocolos controle de envio e recepção de msgs
p. e., TCP, IP, HTTP, Skype, Ethernet
//Internet: “rede de redes”
* vagamente hierárquica
* Internet pública versus intranet privada
//padrões da Internet
* RFC: Request For Comments
* IETF: Internet Engineering Task Force
//infraestrutura de comunicação 
possibilita aplicações distribuídas:
* Web, VoIP, e-mail, jogos, e-commerce, compartilhamento de arquivos
//serviços de comunicação fornecidos às aplicações:
* entrega de dados confiável da origem ao destino
* entrega de dados pelo “melhor esforço” (não confiável)
//o que e protocolo? protocolos de rede:
*Protocolos definem formato, ordem de msgs enviadas
e recebidas entre entidades de rede e ações tomadas
sobre transmissão e recepção de msgs
* máquinas em vez de humanos
* toda atividade de comunicação na Internet controlada por protocolos
//exemplo de protocolo:
*PC pede a conexao tcp, o servidor da a resposta com o link, e o pc recebe o arquivo.
//borda da rede:
* aplicações e hospedeiros
//redes de acesso, meios físicos:
* enlaces de comunicação com e sem fio
//núcleo da rede: 
* roteadores interconectados rede de redes
//BORDA DA REDE
//sistemas finais (hospedeiros):
executar programas de aplicação
p. e. Web, e-mail
na “borda da rede”
//modelo cliente/servidor
hospedeiro cliente solicita, recebe serviço de servidor sempre ativo
p. e. navegador/servidor Web; cliente/servidor de e-mail
//modelo peer-peer:
uso mínimo (ou nenhum) de servidores dedicados
p. e. Skype, BitTorrent
//Redes de acesso e meios físicos
//Como conectar sistemas finais ao roteador da borda?
* redes de acesso residencial
* redes de acesso institucional (escola, empresa)
* redes de acesso móvel
//Lembre-se: 
largura de banda (bits por segundo) da rede de acesso?
compartilhado ou dedicado?
//INTERNET DISCADA
* usa infraestrutura de telefonia existente casa conectada ao escritório central
* até 56 kbps de acesso direto ao roteador (geralmente menos)
* Não pode navegar e telefonar ao mesmo tempo:não está “sempre ligado”
//DSL - DIGITAL SUBSCRIBER LINE
* também usa infraestrutura de telefone existente
* até 1 Mbps upstream (hoje, normalmente < 256 kbps)
* até 8 Mbps downstream (hoje, normalmente < 1 Mbps)
* linha física dedicada à central telefônica
//Acesso residencial: modems a cabo
* não usa infraestrutura de telefone usa infraestrutura de TV a cabo
//HFC: Hybrid Fiber Coax
* assimétrico: até 30 Mbps downstream, 2 Mbps upstream
rede de cabo e fibra conecta casas ao roteador ISP
casas compartilham acesso ao roteador 
diferente de DSL, que tem acesso dedicado
//duas tecnologias óticas concorrentes: 
Passive Optical Network (PON) 
Active Optical Network (PAN)
//meios fisicos
* bit: propaga entre pares de transmissor/receptor
* enlace físico: o que fica entre transmissor e receptor
//meio guiado: 
* sinais se propagam em meio sólido: cobre, fibra, coaxial
//meio não guiado: 
* sinais se propagam livremente, p. e., rádio
//Par Trançado (TP) dois fios de cobre isolados
* categoria 3: fios de telefone tradicionais, Ethernet a 10 Mbps
* categoria 5: Ethernet a 100 Mbps
//Meio físico: cabo coaxial, fibra
//cabo coaxial:
* dois condutores de cobre concêntricos
* bidirecional
//banda base:
* único canal no cabo
* Ethernet legado
//banda larga:
* múltiplos canais no cabo
* HFC
//cabo de fibra ótica:
* fibra de vidro conduzindo pulsos de luz; cada pulso um bit
* operação em alta velocidade:
* * transmissão em alta velocidade ponto a ponto (p. e., 10-100 Gps)
* baixa taxa de erro: repetidores bastante espaçados;
imune a ruído eletromagnético.
//Meio físico: rádio
* sinal transportado no espectro eletromagnético
* nenhum “fio” físico
* bidirecional
* efeitos no ambiente de propagação:
* * reflexão 
* * obstrução por objetos
* * interferência
//O núcleo da rede
* malha de roteadores interconectados
//a questão fundamental: como os dados são transferidos pela rede?
* comutação de circuitos: circuito dedicado por chamada: rede telefônica
* comutação de pacotes: dados enviados pela rede em “pedaços” discretos
//Núcleo da rede: comutação de circuitos
//recursos fim a fim reservados para “chamada”
* largura de banda do enlace, capacidade de comutação
* recursos dedicados: sem compartilhamento
* desempenho tipo circuito (garantido)
* exige preparação de chamada
//Núcleo da rede: comutação de pacotes
* cada fluxo de dados fim a fim dividido em pacotes
* usuário A, pacotes de B compartilham recursos da rede
* cada pacote usa largura de banda total do enlace 
* recursos usados quando necessários
//disputa por recursos: 
* demanda de recurso agregado pode exceder quantidade disponível
* congestionamento: fila de pacotes, espera por uso do enlace
* store and forward: pacotes se movem um salto de cada vez
* * Nó recebe pacote completo antes de encaminhar
//Como ocorrem a perda e o atraso?
* pacotes se enfileiram em buffers de roteador 
* taxa de chegada de pacotes ao enlace ultrapassa capacidade de saída do enlace
* pacotes se enfileiram, esperam por sua vez
//Quatro fontes de atraso de pacote
1. processamento nodal: 
* verificar erros de bit
* determinar enlace de saída
2. enfileiramento
* tempo esperando por transmissão no enlace de saída
* depende do nível de congestionamento do roteador
3. atraso de transmissão:
* R = largura de banda do enlace (bps)
* L = tamanho do pacote (bits)
* tempo para enviar bits no enlace = L/R
4. atraso de propagação:
* d = tamanho do enlace físico
* s = vel. de propagação no meio (~2x108 m/s)
* atraso de propagação = d/s
//Atrasos e rotas “reais” da Internet
* Programa Traceroute: fornece medida do atraso da origem ao 
roteador ao longo do caminho de fim a fim da Internet
para o destino. Para todo i:
* * envia três pacotes que alcançarão roteador i no caminho para o destino
* * roteador i retornará pacotes ao emissor
* * emissor temporiza intervalo entre transmissão e resposta.
//Perda de pacote
* fila (ou buffer) antes do enlace no buffer tem capacidade finita
* pacote chegando à fila cheia descartado (ou perdido)
* último pacote pode ser retransmitido pelo nó anterior, pela origem ou de forma nenhuma
//Vazão
* vazão: taxa (bits/unidade de tempo) em que os bits são transferidos entre emissor/receptor
* instantânea: taxa em determinado ponto no tempo
* média: taxa por período de tempo maior
//Por que usar camadas?
lidando com sistemas complexos:
* estrutura explícita permite identificação e relação entre 
partes complexas do sistema
* modelo de referência em camadas para discussão
modularização facilita manutenção e atualização do sistema
* * mudança de implementação do serviço da camada transparente ao restante do sistema
* * p. e., mudanças no procedimento de porta não afeta o restante do sistema
* uso de camadas considerado prejudicial?
//Pilha de protocolos da Internet
//aplicação:
suporte a aplicações de rede FTP, SMTP, HTTP
//transporte:
transferência de dados processo-processo TCP, UDP
//rede:
roteamento de datagramas da origem ao destino =>IP, protocolos de roteamento
//enlace:
transferência de dados entre elementos vizinhos da rede =>PPP, Ethernet
//física:
bits “nos fios”
//Modelo de referência ISO/OSI
//apresentação:
permite que as aplicações interpretem significado de dados,
p. e., criptografia, compactação, convenções específicas da
máquina
//session:
sincronização, verificação, recuperação de troca de dados
Pilha da Internet “faltando” essas camadas!
//SEGURANÇA
// o campo da segurança de rede trata de:
* como defender as redes contra ataques
* como maus sujeitos atacam redes de computadores
* como projetar arquiteturas imunes a ataques
//Internet não criada originalmente com (muita) segurança em mente
* visão original: “um grupo de usuários mutuamente 
confiáveis conectados a uma rede transparente”
* projetistas de protocolos da Internet brincando de “contar novidades”
* considerações de segurança em todas as camadas!
//MALWARE em HOSPEDEIROS
* malware pode entrar em um hospedeiro por vírus, worm ou cavalo de Troia.
* malware do tipo spyware pode registrar toques de teclas, 
sites visitados na Web, enviar informações para sites de coleta.
* hospedeiro infectado pode ser alistado em um botnet,
usado para spam e ataques de DDoS.
* malware normalmente é autorreplicável: de um hospedeiro
infectado, busca entrada em outros hospedeiros
//cavalo de Troia
* parte oculta de algum software útil
* hoje, normalmente em uma página Web (Active-X, plug-in)
//vírus
* infecção ao receber objeto (p. e., anexo de e- -mail), executando ativamente
* autorreplicável: propaga- -se para outros hospedeiros, usuários
//DOS
Denial of Service (DoS): atacantes deixam recursos
(servidor, largura de banda) indisponíveis ao 
tráfego legítimo, sobrecarregando recurso com tráfego 
//Farejamento de pacotes: 
* meio de broadcast (Ethernet compartilhada, sem fio)
* interface de rede promíscua lê/registra todos os pacotes 
(p. e., incluindo senhas!) passando por
//IP spoofing: 
* enviar pacote com endereço de origem falso
//gravar-e-reproduzir:
informação confidencial (p. e., senha), é usada mais tarde
quem tem a senha é esse usuário, do ponto de vista do sistema
//MATERIA P2, MATERIA P2;
//MATERIA P2, MATERIA P2;
//MATERIA P2, MATERIA P2;
//MATERIA P2, MATERIA P2;
//MATERIA P2, MATERIA P2;
//arquitetura cliente-servidor
//servidor:
 
* hospedeiro sempre ligado
* endereço IP permanente
* server farms por expansão
//clientes:
* comunicam-se com o servidor
* podem estar conectados intermitentemente
* podem ter endereços IP dinâmicos
* não se comunicam diretamente entre si
cada centro de dados usa de 50 a 100 megawatts de potência
//Arquitetura P2P pura
* nenhum servidor sempre ligado
* sistemas finais arbitrários se comunicam diretamente
* pares são conectados intermitentemente e mudam endereços IP
//Híbrido de cliente-servidor e P2P
//Skype
* aplicação P2P voice-over-IP P2P
* servidor centralizado: achando endereço da parte remota: 
* conexão cliente-cliente: direta (não através de servidor) 
//Mensagem instantânea
* bate-papo entre dois usuários é P2P
* serviço centralizado: detecção/localização da presença do cliente
* usuário registra seu endereço IP com servidor central quando entra on-line
* usuário contacta servidor central para descobrir endereços IP dos parceiros
//Que serviço de transporte uma aplicação precisa?
//perda de dados
algumas apls. (p. e., áudio) podem tolerar alguma perda
outras apls. (p. e., transferência de arquivos, telnet)]
exigem transferência de dados 100% confiável 
//temporização
algumas apls. (p. e., telefonia na Internet jogos interativos) 
exigem pouco atraso para serem “eficazes"
//serviço TCP:
* orientado a conexão: preparação exigida entre processos cliente e servidor
* transporte confiável entre processo emissor e receptor
* controle de fluxo: emissor não sobrecarrega receptor 
* controle de congestionamento: regula emissor quando a rede está sobrecarregada
* não oferece: temporização, garantias mínimas de vazão, segurança
//serviço UDP:
* transferência de dados não confiável entre processo emissor e receptor
* não oferece: preparação da conexão, confiabilidade, controle de fluxo,
controle de congest., temporização, garantia de vazão ou segurança 
//HTTP: HyperText Transfer Protocol
* protocolo da camada de aplicação da Web
* modelo cliente/servidor
* cliente: navegador que requisita, recebe, “exibe” objetos Web
* servidor: servidor Web envia objetos em resposta a requisições
//A diferença entre o HTTP/1.0 e o HTTP/1.1 é
* que este último faz uso de conexões TCP persistentes
//O HTTP/1.0 usa paralelismo de conexões TCP:
* Os vários Objetos ligados a um documento-base são
descarregados simultaneamente através de várias
conexões TCP.
//O HTTP/1.1 usa a técnica de pipelining:
* Nessa técnica, uma requisição para o Objeto
N não precisa esperar pela resposta ao Objeto
N-1.
//usa TCP:
* cliente inicia conexão TCP (cria socket) com servidor, porta 80
* servidor aceita conexão TCP do cliente
* mensagens HTTP (do protocolo da camada de aplicação) trocadas
entre navegador (cliente HTTP) e servidor Web (servidor HTTP)
conexão TCP fechada
//HTTP é “sem estado”
servidor não guarda informações sobre requisições passadas do cliente
//HTTP não persistente
no máximo um objeto é enviado por uma conexão TCP.
//HTTP persistente
múltiplos objetos podem ser enviados por uma única conexão TCP entre cliente e servidor.
//HTTP não persistente: tempo de resposta
definição de RTT: tempo para um pequeno pacote trafegar do cliente ao servidor e retornar.
tempo de resposta:
um RTT para iniciar a conexão TCP
um RTT para a requisição HTTP e primeiros bytes da resposta HTTP retornarem
tempo de transmissão de arquivo
total = 2RTT + tempo de transmissão
//problemas do HTTP não persistente: 
requer 2 RTTs por objeto
overhead do SO para cada conexão TCP
navegadores geralmente abrem conexões TCP paralelas para buscar objetos referenciados
//HTTP persistente:
servidor deixa a conexão aberta depois de enviar a resposta
mensagens HTTP seguintes entre cliente/servidor enviadas pela conexão aberta
cliente envia requisições assim que encontra um objeto referenciado
no mínimo um RTT para todos os objetos referenciados
//upload da entrada do formulario
//método POST:
página Web geralmente inclui entrada do formulário
entrada é enviada ao servidor no corpo da entidade
//método do URL:
usa o método GET
entrada é enviada no campo de URL da linha de requisição:
//O que os cookies podem ter:
autorização
carrinhos de compras
recomendações
estado da sessão do usuário (e-mail da Web)
//Como manter o “estado”:
extremidades do protocolo: mantêm estado no emissor/receptor por múltiplas transações
cookies: mensagens HTTP transportam estado
//Cookies e privacidade:
cookies permitem que os sites descubram muito sobre você
você pode fornecer nome e e-mail aos sites
//Caches Web (servidor proxy)
//objetivo: satisfazer a requisição do cliente sem envolver servidor de origem
usuário prepara navegador: acessos à Web via cache
navegador envia todas as requisições HTTP ao cache
objeto no cache: cache retorna objeto 
ou cache requisita objeto do servidor de origem, depois retorna objeto ao cliente
cache atua como cliente e servidor
normalmente, cache é instalado por ISP (da universidade, empresa, residencial)
//Por que caching Web?
reduz tempo de resposta à requisição do cliente
reduz tráfego no enlace de acesso de uma instituição
Internet densa com caches: permite que provedores de conteúdo “fracos”
remetam conteúdo efetivamente (mas o mesmo ocorre com compartilhamento de arquivos P2P)
//suposições
tamanho médio do objeto = 1.000.000 bits
taxa de requisição média dos navegadores da instituição aos servidores de origem = 15/s
atraso do roteador institucional a qualquer servidor de origem e de volta ao roteador = 2 s
//consequências
utilização na LAN = 15%
utilização no enlace de acesso = 100%
atraso total = atraso da Internet + atraso do acesso + atraso da LAN
 = 2 s + x minutos + y milissegundos
//solução possível
aumentar largura de banda do
enlace de acesso para, digamos, 100 Mbps
consequência
utilização na LAN = 15%
utilização no enlace de acesso = 15%
atraso total = atraso da Internet + atraso do acesso + atraso da LAN = 2 s + x ms + y ms
normalmente, uma atualização dispendiosa
//FTP
transfere arquivo de/para hospedeiro remoto
modelo cliente/servidor
cliente: lado que inicia transferência (de/para remoto)
servidor: hospedeiro remoto
ftp: RFC 959
servidor ftp: porta 21
cliente FTP contacta servidor FTP na porta 21, TCP é protocolo de transporte
cliente autorizado por conexão de controle
cliente navega por diretório remoto enviando comandos por conexão de controle
quando servidor recebe comando de transferência de arquivo, abre 2a conexão TCP (para arquivo) com cliente
após transferir um arquivo, servidor fecha conexão de dados
servidor abre outra conexão de dados TCP para transferir outro arquivo
conexão de controle: “fora da banda”
servidor FTP mantém “estado”: diretório atual, autenticação anterior
//exemplos de comandos:
enviado como texto ASCII pelo canal de controle
USER nome-usuário
PASS senha
LIST retorna lista de arquivos no diretório atual
RETR nome-arquivo recupera (apanha) arquivo
STOR nome-arquivo armazena (coloca) arquivo no hospedeiro remoto
//exemplos de códigos de retorno
código e frase de estado (como no HTTP)
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
//CORREIO ELETRONICO
//Três componentes principais: 
agentes do usuário 
servidores de correio
Simple Mail Transfer Protocol: SMTP
//Agente do usuário
também chamado “leitor de correio”
redigir, editar, ler mensagens de correio eletrônico
p. e., Eudora, Outlook, elm, Mozilla Thunderbird
mensagens entrando e saindo armazenadas no servidor
//correio eletronico
usa TCP para transferir de modo confiável a mensagem de e-mail do cliente ao servidor, porta 25
transferência direta: servidor de envio ao servidor de recepção
três fases da transferência
handshaking (saudação)
transferência de mensagens
fechamento
interação comando/resposta
comandos: texto ASCII
resposta: código e frase de estado
mensagens devem estar em ASCII de 7 bits
//SMTP
SMTP usa conexões persistentes
SMTP requer que a mensagem (cabeçalho e corpo) esteja em ASCII de 7 bits
servidor SMTP usa CRLF.CRLF para determinar fim da mensagem
//Comparação com HTTP:
HTTP: puxa
SMTP: empurra
ambos têm interação de comando/resposta em ASCII, códigos de estado
HTTP: cada objeto encapsulado em sua própria mensagem de resposta
SMTP: múltiplos objetos enviados na mensagem multiparte
//pop3
//Mais sobre POP3
Exemplo anterior usa modo “download e excluir”
Bob não pode reler e- -mail se mudar o cliente
“Download-e-manter”: cópias de mensagens em clientes diferentes
POP3 é sem estado entre as sessões
//IMAP
Mantém todas as mensagens em um local: o servidor
Permite que o usuário organize msgs em pastas
IMAP mantém estado do usuário entre sessões:
nomes de pastas e mapeamento entre IDs de mensagem e nome de pasta
//Domain Name System:
banco de dados distribuído implementado na hierarquia de muitosservidores de nomes
protocolo em nível de aplicação hospedeiro, roteadores, servidores de nomes se comunicam para resolver nomes (tradução endereço/nome)
Nota: função básica da Internet, implementada como protocolo em nível de aplicação
complexidade na “borda” da rede
//Serviços de DNS
tradução nome de hospedeiro -> endereço IP
apelidos de hospedeiro
nomes canônicos
apelidos de servidor de correio
distribuição de carga
servidores Web replicados: conjunto de endereços IP para um nome canônico
//Por que não centralizar o DNS?
único ponto de falha
volume de tráfego
banco de dados centralizado distante
manutenção
Não é escalável!
//Arquitetura p2p pura
sem servidor sempre ligado
sistemas finais arbitrários se comunicam diretamente
pares estão conectados intermitentemente e mudam de endereços IP
//Três tópicos:
distribuição de arquivos
procura de informações
estudo de caso: Skype
//bitTorrent
arquivo dividido em pedaços de 256 KB.
torrent de ajuntamento de pares: 
não tem pedaços, mas os acumulará 
com o tempo
registra com rastreador para obter lista de 
pares, conecta a subconjunto de pares (“vizinhos”)
ao fazer download, par faz upload de pedaços para outros pares 
pares podem ir e vir
quando par tem arquivo inteiro, ele pode (de forma egoísta) sair ou (de forma altruísta) permanecer
//Distributed Hash Table (DHT)
DHT = banco de dados P2P distribuído
banco de dados tem duplas (chave, valor); 
chave: número ss; valor: nome humano
chave: tipo conteúdo; valor: endereço IP
pares consultam BD com chave
BD retorna valores que combinam com a chave
pares também podem inserir duplas (chave, valor)
//Estudo de caso do P2P: Skype
inerentemente P2P: pares de usuários se comunicam.
protocolo próprio da camada de aplicação (deduzido por engenharia reversa) 
sobreposição hierárquica com SNs
índice compara usernames com endereços IP; distribuído por SNs
//Programação de sockets
//Objetivo:
aprender a criar aplicação cliente-servidor que se comunica usando sockets
//API socket
introduzida no BSD4.1 UNIX em 1981
criada, usada e liberada explicitamente pelas apls.
paradigma cliente-servidor
dois tipos de serviços de transporte por meio da API socket: 
UDP
TCP
//fundamentos da programação de socket
servidor deve estar rodando antes que o cliente possa lhe enviar algo
servidor deve ter um socket (porta) pelo qual recebe e envia segmentos
da mesma forma, o cliente precisa de um socket
//Serviço TCP: transferência confiável de bytes de um processo para outro
//cliente deve contactar servidor
processo servidor primeiro deve estar rodando
servidor deve ter criado socket (porta) que aceita contato do cliente
//cliente contacta servidor:
criando socket TCP local ao cliente
especificando endereço IP, # porta do processo servidor
quando cliente cria socket: cliente TCP estabelece conexão com servidor TCP