RED29004-2014-2

Diário de aula de RED - 2014-2 - Prof. Odilson T. Valle

Dados Importantes

Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª feira das 9h40 às 10h35 e 4ª das 14h25 às 15h20. Local: Lab. de Desenvolvimento.

Avaliações

• 3 avaliações (P1, P2 e P3)
• Seminário (S)
• Reavaliações (P1, P2 e P3)
• Nota final: NF = (P1 + P2 + P3 + S) / 4
• Conceito final:

Se NF < 6,0 = D --> Reprovado Se 6,0 =< NF < 7,5 = C --> Aprovado Se 7,5 =< NF < 9,0 = B --> Aprovado Se NF >= 9,0 = A --> Aprovado </syntaxhighlight> IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.

Plano de Ensino

Plano de Ensino

Aula Data Horas Conteúdo Recursos 1 1/8 2 Apresentação da disciplina Lab. Redes II, Projetor, Slides, Computadores 2 5/8 2 Introdução a Redes de Computadores Lab. Redes II, Projetor, Slides, Computadores 3 8/8 2 Comutação de Circuitos vs Comutação de Pacotes Lab. Redes II, Projetor, Slides, Computadores 4 12/8 2 Modelos de serviço Lab. Redes II, Projetor, Slides, Computadores 5 15/8 2 Arquitetura em camadas Lab. Redes II, Projetor, Slides, Computadores 6 19/8 2 Listas de exercícios 1 Lab. Redes II, Projetor, Slides, Computadores, Wiki 7 22/8 2 Uso de aplicações da Internet – Lab. 1 Lab. Redes II, Projetor, Slides, Computadores 8 26/8 2 Comunicação entre processos Lab. Redes II, Projetor, Slides, Computadores 9 29/8 2 Protocolos da Camada de Aplicação Lab. Redes II, Projetor, Slides, Computadores 10 2/9 2 Camada de aplicação: HTTP, FTP, SMTP, DNS – Lab. 2 Lab. Redes II, Projetor, Slides, Computadores 11 5/9 2 Camada de aplicação: HTTP, FTP, SMTP, DNS – Lab. 2 Lab. Redes II, Projetor, Slides, Computadores 12 9/9 2 Camada de aplicação: HTTP, FTP, SMTP, DNS – Lab. 2 Lab. Redes II, Projetor, Slides, Computadores 13 12/9 2 Correção das listas de exercícios (revisão) – Lab. 3 Lab. Redes II, Projetor, Slides, Computadores 14 16/9 2 Prova 1 (arquitetura em camadas, Internet, camada de aplicação) Lab. Redes II ou sala de aula 15 19/9 2 Camada de transporte: serviços oferecidos Lab. Redes II, Projetor, Slides, Computadores 16 23/9 2 Serviço não orientado à conexão: UDP Lab. Redes II, Projetor, Slides, Computadores 17 26/9 2 Transferência confiável de dados Lab. Redes II, Projetor, Slides, Computadores 18 30/9 2 Construindo um protocolo de transferência confiável – Lab. 4 Lab. Redes II, Projetor, Slides, Computadores 19 3/10 2 Protocolos dutados: Volta-N e Retransmissão Seletiva, Controle de fluxo e congestionamento Lab. Redes II, Projetor, Slides, Computadores 20 7/10 2 Protocolos orientados a conexão: TCP Lab. Redes II, Projetor, Slides, Computadores 21 10/10 2 Listas de exercícios 3, 4 e 5 Lab. Redes II, Projetor, Slides, Computadores, wiki 22 14/10 2 Correção das listas de exercícios (revisão) Lab. Redes II, Projetor, Slides, Computadores 23 17/10 2 Prova 2 (camada de transporte) Lab. Redes II ou sala de aula 24 21/10 2 Redes datagrama e circuito virtual Lab. Redes II, Projetor, Slides, Computadores 25 24/10 2 Camada de rede: roteamento e encaminhamento Lab. Redes II, Projetor, Slides, Computadores 26 31/10 2 Endereçamento e roteamento estático no IP Lab. Redes II, Projetor, Slides, Computadores 27 4/11 2 Exercícios CIDR Lab. Redes II, Projetor, Slides, Computadores, wiki 28 7/11 2 Roteamento hierárquico e Sistemas autônomos na Internet Lab. Redes II, Projetor, Slides, Computadores 29 11/11 2 Roteamento hierárquico e laboratório de roteamento estático Lab. Redes II, Projetor, Slides, Computadores 30 14/11 2 Laboratório de protocolos de roteamento Lab. Redes II, Projetor, Slides, Computadores 31 18/11 2 Introdução à camada de enlace Lab. Redes II, Projetor, Slides, Computadores 32 21/11 2 Introdução à camada de enlace Lab. Redes II, Projetor, Slides, Computadores 33 25/11 2 Laboratório de enlaces (LAN) Lab. Redes II, Projetor, Slides, Computadores 34 28/11 2 Correção das listas de exercícios (revisão) Lab. Redes II, Projetor, Slides, Computadores 35 2/12 2 Prova 3 (camadas de rede e enlace) Lab. Redes II ou sala de aula 36 5/12 2 Seminários Lab. Redes II, Projetor, Slides, Computadores 37 9/12 2 Seminários Lab. Redes II, Projetor, Slides, Computadores 38 12/12 2 Prova de recuperação Lab. Redes II ou sala de aula TOTAL 76

Material de apoio

Listas de exercícios

Lista de exercícios 1

Qual é a diferença entre um hospedeiro e um sistema final? Cite os tipos de sistemas finais. Um servidor web é um sistema final? O que caracteriza um protocolo? Dê um exemplo de um protocolo. O que é um programa cliente? O que é um programa servidor? Um programa servidor requisita e recebe serviços de um programa cliente? Quais são os dois tipos de serviços de transporte que a Internet provê às suas aplicações? Cite algumas características de cada um desses serviços. Quais são as vantagens de uma rede de comutação de circuitos em relação a uma rede de comutação de pacotes? Quais são os prós e contras da utilização de Circuitos Virtuais? Porque se afirma que a comutação de pacotes emprega multiplexação estatística? Compare a multiplexação estatística com a multiplexação que ocorre em TDM. A taxa de transmissão HFC é dedicada ou compartilhada entre os usuários? É possível haver colisões na direção do provedor – usuário de um canal HFC? Por quê? Cite cinco tecnologias de acesso. Classifique cada uma delas nas categorias acesso residencial, acesso corporativo ou acesso móvel. Modens discados, HFC e ADSL são usados para acesso residencial. Para cada uma dessas tecnologias de acesso, cite uma faixa de taxas de transmissão e comente se a largura de banda é compartilhada ou dedicada. Considere o envio de um pacote de uma máquina de origem a uma de destino por uma rota fixa. Relacione os componentes do atraso que formam o atraso fim-a-fim. Quais deles são constantes e quais são variáveis? Porque dividimos a arquitetura da Internet em camadas? Quais são as cinco camadas da pilha de protocolo da Internet? Quais as principais responsabilidades de cada uma dessas camadas? O que é uma mensagem de camada de aplicação? Um segmento da camada de transporte? Um datagrama da camada de rede? Um quadro de camada de enlace? Que camadas da pilha de protocolo da Internet um roteador implementa? Que camadas um comutador de enlace implementa? Que camadas um sistema final implementa?

Lista de exercícios 2 - Camada de Aplicação

Relacione cinco aplicações da Internet não proprietárias e os protocolos da camada de aplicação que elas usam. Qual é a diferença entre arquitetura de rede e arquitetura de aplicação? De que modo um mensageiro instantâneo é um híbrido das arquiteturas cliente-servidor e P2P? Para uma sessão de comunicação entre um par de processos, qual processo é o cliente e qual é o servidor? Que informação é usada por um processo que está rodando em um hospedeiro para identificar um processo que está rodando em outro hospedeiro? Porque o HTTP, FTP, SMTP, POP3 e IMAP rodam sobre TCP e não sobre UDP? Qual é a diferença entre HTTP persistente com paralelismo e HTTP persistente sem paralelismo. Qual dos dois é utilizado pelo HTTP/1.1? Descreva como o cache Web pode reduzir o atraso na recepção de um objeto desejado. O cachê Web reduzirá o atraso para todos os objetos requisitados por um usuário ou somente para alguns objetos? Por quê? Porque o DNS não é centralizado? O que são consultas recursivas e interativas em uma consulta DNS? Por que se diz que o FTP envia informações de controle “fora da banda”? Suponha que Alline envie uma mensagem a Eduardo por meio de uma conta de e-mail da web (como o gmail), e que Eduardo acesse seu e-mail por seu servidor utilizando POP3. Descreva como a mensagem vai do hospedeiro Alline até o hospedeiro de Eduardo. Não se esqueça de relacionar a série de protocolos de camada de aplicação usados para movimentar as mensagens entre os hospedeiros.

Lista de exercícios 3 - Camada de Aplicação

Em uma aplicação de compartilhamento de arquivos P2P, você concorda com a afirmação: ”não existe nenhuma noção de lados cliente e servidor de uma sessão de comunicação”? Por que sim ou por que não? Relacione alguns agentes de usuário de aplicação de rede que você utiliza no dia-a-dia. O que significa o protocolo de apresentação (handshaking protocol)? Considere um site de comércio eletrônico que quer manter um registro de compras para cada um de seus clientes. Descreva como isso pode ser feito com cookies. Imagine uma aplicação que requeira “não perda de dados” e seja também altamente sensível ao atraso.

Transparências utilizadas durante as aulas

Slides do Kurose referentes ao capítulo 1

Slides do Kurose referentes ao capítulo 2, 6a. Ed.

Slides do Kurose referentes ao capítulo 2, 5a. Ed.

Slides do Prof. Emerson - DNS, FTP, Web, Email...

Roteiros para laboratório

Laboratório 1 -- Ping, traceroute, Web e HTTP

Laboratório 2 -- Wireshark e HTTP

Laboratório 3 - Serviço de Nomes (DNS)

Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios: mail.ifsc.edu.br www.sj.ifsc.edu.br www.google.com www.gmail.com www.amazon.co.uk www.gov.za www.sls.com.au Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim: host -t ns ifsc.edu.br Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup: # Use o nslookup para consultar o endereço IP de um nome qualquer ... nslookup www.ifsc.edu.br Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. Portanto, execute o wireshark: sudo wireshark ... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte: Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta? Que protocolo de transporte é usado? E que porta? Qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP ou SMTP? Qual o tipo de registro DNS acessado em cada consulta ? Que informações estão contidas nas respostas DNS? Há algo além do que foi pedido? Qual o tamanho das mensagens DNS? O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo: host -t mx ifsc.edu.br Descubra quem é o servidor que recebe emails nos seguintes domínios: gmail.com hotmail.com uol.com.br ufsc.br Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim: dig -x 200.180.10.13 ... o dig tem um resultado um pouco mais carregado que os outros utilitários (host e nslookup), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha ;; ANSWER SECTION:. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade. Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado? Descubra quem são os servidores raiz (topo de hierarquia DNS): host -t ns . ou dig -t ns . Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo: host -v -t a www.sj.ifsc.edu.br. j.root-servers.net. ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total? Repita esse exercício para os seguintes nomes de domínio: www.bbc.co.uk www.amazon.com www.thepiratebay.org www.reeec.illinois.edu www.inm.ras.ru Outros tipos de consulta usando o dig: explícita a um determinado servidor (@) dig @j.root-servers.net. +trace www.sj.ifsc.edu.br. mostra a consulta recursiva: dig +trace www.sj.ifsc.edu.br.

Laboratório 4 - Programação de sockets

Material original: Slides do Kurose referentes ao capítulo 2, 6a. Ed., pags 54 à 58 Programação de sockets: criando aplicações de rede Há dois tipos de aplicações de rede: Uma delas é uma execução cuja operação é especificada em um padrão de protocolo. O outro tipo de aplicação de rede é uma aplicação de rede proprietária. Descrição da aplicação a ser desenvolvida em UDP e TCP Usaremos a aplicação cliente-servidor simples a seguir para demonstrar a programação de socket: Um cliente lê uma linha de caracteres (dados) do teclado e a envia para o servidor. O servidor recebe os dados e converte os caracteres para maiúsculas. O servidor envia os dados modificados ao cliente. O cliente recebe os dados modificados e apresenta a linha em sua tela. Programação de sockets com UDP A aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui. Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens vis sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes. Um exemplo de código bem simples para o lado Cliente: UDPClient.py Esta linha define que pode-se utilizar sockets dentro do programa from socket import * Define o endereço ip do servidor ao qual o cliente contactará serverName = 'ip_do_servidor' Define a porta de acesso ao servidor serverPort = 22222 Cria o socketdo cliente, denominado slientSocket. O primeiro parâmetro indica a família do endereço, em particular, AF_INET indica que a rede subjacente está usando IPv4. O segundo parâmetro indica que o socket é do tipo SOCK_DGRAM, o que significa que é um socket UDP. clientSocket = socket(AF_INET, SOCK_DGRAM) raw_input é uma função interna da linguagem Python que permite a solicitação de entrada de dados que será armazenada em message. message = raw_input('Entre com a sentanca em minuculas: ') O método sendto() acrescenta o endereço (e porta) de destino a mensagem e envia o pacote resultante pelo socket aberto. clientSocket.sendto(message,(serverName, serverPort)) Após o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variável modifiedMessage e o endereço de origem é armazenado em serverAddress. 2048 representa o tamanho do buffer. modifiedMessage, serverAddress = clientSocket.recvfrom(2048) Imprime a mensagem recebida na tela. print modifiedMessage Fecha o socket. clientSocket.close() </syntaxhighlight> O código do lado do Servidor (comentários somente nas linhas inéditas): UDPServer.py from socket import * serverPort = 22222 serverSocket = socket(AF_INET, SOCK_DGRAM) Vincula o número da porta, nesse caso 22222, ao sockect do servidor e "abre a porta". serverSocket.bind((, serverPort)) print "O servidor esta pronto para recepcao" Aguarda indefinidamente contatos por clientes while 1: message, clientAddress = serverSocket.recvfrom(2048) #Ao receber a mensagem do cliente converte todos os caracteres para maiúsculas. modifiedMessage = message.upper() serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight> Para testar se o servidor está com a "porta aberta" podemos utilizar o aplicativo nmap, que procura por portas abertas. Como exemplo vamos verificar somente se a porta 22222 UDP (-sU) está aberta: sudo nmap -p22222 -sU numero_do_ip_do_servidor Programação de sockets com TCP Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, ele primeiramente devem se apresentar, o primeiro socket da Figura abaixo, e estabelecer uma conexão TCP, o segundo socket da Figura abaixo. Todos os dados trafegarão pelo segundo socket. O processo TCPServer tem dois sockets: A aplicação cliente-servidor usando TCP: Um exemplo de código bem simples para o lado Cliente (comentários somente nas linhas inéditas): TCPClient.py from socket import * serverName = '127.0.0.1' serverPort = 33333 SOCK_STREAM habilita uso do TCP clientSocket = socket(AF_INET, SOCK_STREAM) Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito clientSocket.connect((serverName,serverPort)) message = raw_input('Entre com a sentanca em minuculas: ') Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket eh uma "tubulacao" direta entre ambos, basta empurrar dados clientSocket.send(message) modifiedMessage = clientSocket.recv(1024) print 'Mensagem do servidor: ', modifiedMessage clientSocket.close() </syntaxhighlight> O código do lado do Servidor (comentários somente nas linhas inéditas): TCPServer.py from socket import * serverPort = 33333 serverSocket = socket(AF_INET, SOCK_STREAM) serverSocket.bind((,serverPort)) Escuta as requisicoes das requisicoes TCP do cliente. Numero maximo de conexoes em fila = 1 serverSocket.listen(1) print 'O servidor esta pronto' while 1: #Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket, #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP #entre o clientSocket do cliente e o connectionSocket do servidor. connectionSocket, addr = serverSocket.accept() message = connectionSocket.recv(1024) messageMaiuscula = message.upper() connectionSocket.send(messageMaiuscula) connectionSocket.close() </syntaxhighlight> Teste do servidor: nmap -n -p33333 ip_do_servidor Roteiro de atividades Ligue a máquina virtual ARC-2-server Logue com: aluno - ARC-2-ser Configure a interface de rede sudo ifconfig eth0 192.168.2.X # onde X=102, 103, ..., 114, para, respectivamente M2, M3, ..., M14. </syntaxhighlight> Escreva o programa UDPServer.py nessa máquina e execute-o: python UDPServer.py </syntaxhighlight> Se apresentar erros de sintaxe corrija-os Teste com o nmap para verificar se a porta está aberta. Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o. Sucesso na execução do programa? Rode o WireShark, seguindo o modelo apresentado no Laboratório 2 Execute novamente o cliente e servidor e capture os pacotes com o WireShark. Repita os passos 4 a 10, só que agora para o protocolo TCP. Discuta com os colegas as diferenças observadas. Com seu cliente conecte o servidor de seu colega e vice-versa. Alguma diferença? Desafios Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente. Implemente um servidor HTTP "parcial", que aceite a requisição de 2 arquivos html, respondendo normalmente a estas requisições, ou seja, encaminha os arquivos solicitados, ou, caso contrário, devolva a mensagem padrão do protocolo HTTP: 404 Not Found. Veja detalhes das mensagens em Mensagens HTTP

Softwares

• Netkit: possibilita criar experimentos com redes compostas por máquinas virtuais Linux

Curiosidades

• Telex
• O Ciberespaço e as Redes de Computadores na Construção de Novo Conhecimento
• Uma história das Redes de Computadores
• Breve História da Internet

Seminários

Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse modelo de relatório.

• Grupos e Temas para 2014-2:
  • Gustavo e Walter: 4G
  • Gabriel e Lucas: WiMax
  • Diego e Giulio: PLC
  • Fernando e Stephany: Zigbee
  • Vinícius e Clarice: ADSL
  • João e Marcos: IOT
  • Adalvir e Fabiano: NGN
  • Ronaldo: IEEE 802.11n

• Avaliação
  • Nota: 0,5 x Documento + 0,5 x Seminário
  • Nota final individual. Será dada uma nota por equipe (máximo = número_de_alunos_da_equipe * 10) e a equipe decide qual será a nota individual por aluno, sendo que a soma das notas dos alunos deverá ser igual a nota da equipe. O professor pode interferir na distribuição das notas dentro da equipe.

• Instruções sobre o Seminário de Redes I:
  • Data para definição de grupos e temas: 8/8/14.
  • 2 alunos por equipe.
  • Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem.
  • Data de entrega do documento: 21/11/14 (impreterivelmente).
  • O relatório pode ser redigido como uma página da wiki.
  • Duração da apresentação: 20 minutos + 5 minutos de perguntas.
  • As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
  • Se preferirem usar slides, usem esse modelo.

Diário de aulas

Aula 1 - 1/8/14: Apresentação da disciplina

Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação. Auto apresentação Apresentação da Wiki Ementa Plano de Ensino Apresentação do modelo de aulas a ser adotado Laboratórios Kurose Avaliações 3 avaliações (P1, P2 e P3) Seminários (S) Reavaliações (P1, P2 e P3) Nota final: NF = (P1 + P2 + P3 + S) / 4 Conceito final: Se NF < 6,0 = D --> Reprovado Se 6,0 =< NF < 7,5 = C --> Aprovado Se 7,5 =< NF < 9,0 = B --> Aprovado Se NF >= 9,0 = A --> Aprovado </syntaxhighlight> Qual o grande objetivo das redes de computadores? Relação com outras disciplinas do curso

Aula 2 - 5/8/14: Introdução a Redes de Computadores
Breve histórico sobre o surgimento das redes de computadores e a Internet Vídeo sobre surgimento da Internet Vídeo sobre o funcionamento das fibras ópticas Vídeo sobre fibra óptica Mapas de rede dorsais (Backbones) Mapa da rede Ipê (Internet acadêmica pública no Brasil) POP SC (ponto de presença de SC) Uma representação artística das interligações na Internet

Aula 3 - 8/8/14: Introdução a Redes de Computadores
Slides do Kurose referentes ao capítulo 1

Aula 4 - 12/8/14: Comutação de circuitos vs comutação de pacotes
Slides do Kurose referentes ao capítulo 1

Aula 5 - 15/8/14: Modelo de serviços
Slides do Kurose referentes ao capítulo 1

Aula 6 - 19/8/14: Arquitetura em camadas - Exercícios
Slides do Kurose referentes ao capítulo 1

Aula 7 - 22/8/14: Laboratório 1: Uso de aplicações da Internet
Laboratório 1 -- Ping, traceroute, Web e HTTP

Aula 8 - 26/8/14: Comunicação entre processos
Slides do Kurose referentes ao capítulo 2, 6a. Ed. Slides do Kurose referentes ao capítulo 2, 5a. Ed.

Aula 9 - 29/8/14: Protocolos da camada de aplicação - Laboratório 2: Wireshark e HTTP
Slides do Kurose referentes ao capítulo 2, 6a. Ed. Slides do Kurose referentes ao capítulo 2, 5a. Ed. Laboratório 2 -- Wireshark e HTTP

Aula 10 - 2/9/14: HTTP - FTP - SMTP
Slides do Kurose referentes ao capítulo 2, 6a. Ed. Slides do Kurose referentes ao capítulo 2, 5a. Ed.

Aula 11 - 5/9/14: DNS - Laboratório 3: Serviço de nomes
Slides do Prof. Emerson - DNS, FTP, Web, Email... Laboratório 3

Aula 12 - 9/9/14: Laboratório 3 (revisão) - P2P
Laboratório 3 Slides do Kurose referentes ao capítulo 2, 6a. Ed. Slides do Kurose referentes ao capítulo 2, 5a. Ed.

Aula 13 - 12/9/14: Aulas de dúvidas e listas de exercício
Listas de exercício

Aula 14 - 16/9/14: Avaliação 1: conceitos básicos e camada de aplicação
Sala 12