puc-sp1 gerência de comunicações de dados - parte ii prof. milton kaoru kashiwakura

152
PUC-SP 1 Gerência de Comunicações de Gerência de Comunicações de Dados - Parte II Dados - Parte II Prof. Milton Kaoru Kashiwakura

Upload: lucas-mendes-de-lacerda

Post on 07-Apr-2016

217 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 1

Gerência de Comunicações de Gerência de Comunicações de Dados - Parte IIDados - Parte II

Prof. Milton Kaoru Kashiwakura

Page 2: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 2

Tamanho da Rede Tamanho da Rede

• Classificação:– LAN (“Local Area Network”)

• Pode atender um prédio ou campus

– MAN (“Metropolitan Area Network”)• Pode atender uma cidade

– WAN (“Wide Area Network”)• Pode atender “sites” em várias cidades, países ou continentes

• Principal diferença entre LAN e WAN é a escalabilidade

Page 3: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 3

Principal Elemento de WANPrincipal Elemento de WAN

• Packet Switches– É um computador que tem

processador, memória e dispositivos de I/O para enviar e receber pacotes

– Store and Forward, armazena o pacote quando este chega (store), avisa CPU que pacote chegou e determina para qual interface este vai (forward)

Page 4: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 4

Formando uma WANFormando uma WAN

• Escalabilidade: uma WAN deve poder crescer quanto necessário para conectar vários sites com vários computadores espalhado por enormes distancias geográficas

Page 5: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 5

Endereço Físico e roteamentoEndereço Físico e roteamento

• Endereço Físico hierárquico

Page 6: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 6

Roteamento na WANRoteamento na WAN

• Roteamento Universal: A tabela de roteamento deve conter um “next-hop route” para cada destino possível

• Roteamento Ótimo: Em um switch, o valor do “next-hop” na tabela de roteamento para um dado destino deve apontar para o caminho mais curto até o destino.

Page 7: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 7

NetworkNetwork

Page 8: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 8

Uso de “Default Routes”Uso de “Default Routes”

• “Default Route” é opcional, o uso de “default route” (*) é possível se mais que um destino tem o mesmo valor de “next-hop”

Page 9: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 9

Computação da Tabela de Computação da Tabela de RoteamentoRoteamento

• Roteamento Estático: um programa computa e instala rotas quando um packet switch é ligado; as rotas não mudam.

• Simplicidade e pequeno overhead• Inflexível

• Roteamento Dinamico: um programa constroi uma tabela de roteamento inicial quando o packet switch é ligado; o programa então altera a tabela se as condições da rede mudam.

• Trata problemas de rede automaticamente

Page 10: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 10

Computação “Shortest Path”Computação “Shortest Path”

• Algoritmo de Dijkstra computa o caminho mais curto no gráfico usando pesos nos links como medida de distancia.

Page 11: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 11

Algoritmo de DijkstraAlgoritmo de Dijkstra

• Dado um grafo com pesos não negativos associado a cada link e designado um nó de origem, o algoritmo computa a menor distancia a partir deste nó de origem para qualquer outro nó e a tabela de roteamento para o nó de origem.

• S= conjunto dos nós• D= peso dos links• R= Next-hop

Page 12: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 12

Algoritmo de DijsktraAlgoritmo de Dijsktra

sequência S D R

1 1,2,3,5,6,7 ->7 ,,11,0, , ,3 0,0,3,-,0,0,7

2 1,2,3,5,6 ->6 ,,11,0, , 8,3 0,0,3,-,0,7,73 1,2,3,5 ->3 ,16,10,0, , 8,3 0,7,7,-,0,7,7

4 1,2,5 ->2 ,13,10,0, , 8,3 0,7,7,-,0,7,7

5 1,5 ->5 ,13,10,0, 19, 8,3 0,7,7,-,7,7,7

6 1 28,13,10,0, 19, 8,3 7,7,7,-,7,7,7

Page 13: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 13

Proprietário da RedeProprietário da Rede

• Privado: tecnologia LAN é frequentemente usado para redes privadas; grandes corporações podem ter uma WAN privada para conectar computadores em multiplos sites.

• Público: é análogo ao sistema telefonico, qualquer um pode fazer uma assinatura para o serviço e conectar um computador.

Page 14: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 14

VPN – Virtual Private NetworkVPN – Virtual Private Network

• Uma VPN combina as vantagens das redes privadas e públicas permitindo que uma empresa com várias filiais tenha a ilusão de estar usando uma rede completamente privada, mas utilizando uma rede pública para transportar dados entre sites.

• O sistema VPN examina o destino, criptografa o pacote, e envia o resultado através de uma rede pública para o sistema VPN do site destino.

Page 15: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 15

Paradigma do ServiçoParadigma do Serviço

• Serviço Orientado a Conexão:– Opera análogo a um sistema telefonico– Stream interface– A comunicação não precisa ser contínuo– Facil de contabilizar e informa computador

imediatamente se a conexão cai.• Serviço Não Orientado a Conexão:

– Opera similar a um sistema de correio– Uma falha no sistema pode passar despercebido– Menor “overhead” inicial

Page 16: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 16

Duração da Conexão e Duração da Conexão e PersistenciaPersistencia

• Serviço Orientado a Conexão pode ser :– Conexão Permanente, por

requerer esforço manual para ser estabelecido normalmente persiste por dias, meses ou anos.

– Conexão Chaveada, usado para conexões temporárias, de curta duração

Page 17: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 17

Exemplos de Paradigma de Exemplos de Paradigma de ServiçoServiço

Page 18: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 18

Desempenho da RedeDesempenho da Rede

• Delay (atraso)– Atraso de propagação (“propagation delay”)– Atraso do Chaveador (“Switching delay”)– Atraso do acesso ( “Access delay”)– Atraso de fila (“queueing delay”)

• Throughput (desempenho)– Taxa de transmissão em bps (bits por segundo)– Bandwidth e speed são utilizados como sinonimos– Mede capacidade e não velocidade

Page 19: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 19

Relação entre Delay e Relação entre Delay e ThroughputThroughput

• D = Do / (1-U)– Se a rede está “idle”, U é zero– D é delay efetivo– Do é delay quando a rede está “idle”

• T x D , mede o volume de dados que podem estar presente na rede. Uma rede com throughput T e delay D tem um total de TxD bits em transito.

Page 20: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 20

Protocolos e CamadaProtocolos e Camada

• Protocolo de comunicação é um conjunto de regras que especifica o formato da mensagem e a ação apropriada requerida para cada mensagem trocada entre computadores.

• Em vez de ter um único e enorme protocolo que especifica detalhadamente todas as formas de comunicação, projetista optaram por dividir o problema de comunicação em sub-pedaços e projetar um protocolo separado para cada sub-pedaço.

Page 21: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 21

Modelo de 7 camadasModelo de 7 camadas

• ISO (“International Organization for Standardization”)

• Modelo de 7 camadas ou OSI (“Open Systems Interconnection”)

Page 22: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 22

Camada 1 - FísicoCamada 1 - Físico

• Corresponde ao hardware básico da rede• Estabelece a interface elétrica e mecânica

do meio físico da rede (ex.: cabo)• Transporta os bits de um ponto a outro

Page 23: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 23

Camada 2 - EnlaceCamada 2 - Enlace

• É responsável pelo acesso ao meio físico• Lida com as funções de transferencia física,

enquadramento, controle de fluxo, controle de erros sobre um único enlace de transmissão

• Muitas vezes é dividida em duas: Controle do Enlace Lógico (LLC-”Logical Link Control”) e Controle de Acesso ao Meio (MAC – “Medium Access Control”)

Page 24: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 24

Camada 3 - RedeCamada 3 - Rede

• Estabelece, mantém e termina ligações lógicas e/ou físicas

• A camada de rede é responsável por converter endereços lógicos, em endereços físicos

• Implementa as funções de roteamento da rede e controle de fluxo entre o computador e a interface de rede.

Page 25: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 25

Camada 4 - TransporteCamada 4 - Transporte

• Está relacionado com a confiabilidade da troca de mensagem. Tem a responsabilidade de, se os dados forem enviados incorretamente, pedir a retransmissão dos mesmos.

• Considerado complexo

Page 26: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 26

Camada 5 - SessãoCamada 5 - Sessão

• Providencia um método para estabelecimento da conexão entre dois dispositivos para que os dispositivos possam enviar e receber dados.

• Gerencia o início e término da conexão• Especifica detalhes de segurança como

autenticação usando senha• Sincroniza fluxo de dados entre as aplicações

Page 27: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 27

Camada 6 - ApresentaçãoCamada 6 - Apresentação

• Auxilia na representação dos dados, chamada sintaxe. Ela examina a sintaxe usada pela aplicação origem e a utilizada pela aplicação destino, e se necessário, cria uma sintaxe de transferência para ser utilizada entre as duas

Page 28: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 28

Camada 7 - AplicaçãoCamada 7 - Aplicação

• Providencia os serviços para os aplicativos do usuário final, tais como correio eletrônico, transferência de arquivos, “login” remoto (emulação de terminal), gerenciamento de rede, etc.

• Especifica os detalhes de como uma aplicação faz requisição e como uma aplicação em outro computador responde.

Page 29: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 29

Pilhas: camadas do softwarePilhas: camadas do software

• Cada módulo comunica somente com o módulo imediatamente superior e inferior.

• Computador pode executar mais de uma pilha de protocolo por vez, se necessário.

Page 30: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 30

Múltiplos cabeçalhos encadeadosMúltiplos cabeçalhos encadeados

• Alguns softwares de protocolo faz mais que prepende de cabeçalho, insere caracter especial para marcar início e fim do quadro e insere caracteres adicionais no meio para evitar ocorrencia de caracteres especiais.

Page 31: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 31

Base Científica para uso de Base Científica para uso de camadas – Princípio das camadascamadas – Princípio das camadas

• Princípio de camada:• Software da camada N no

computador destino deve receber a mensagem exatamente como enviada pelo software de camada N do computador de origem.

Page 32: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 32

Técnicas utilizadas pelos Técnicas utilizadas pelos protocolosprotocolos

• Sequenciamento – utilizada para resolver problema de entrega fora de ordem.

• Sequenciamento – utilizado para eliminar pacotes duplicados

• Retransmissão – para resolver problema de perda de pacote

• Identificação única de cada sessão – para evitar repetição causado por atraso excessivo.

Page 33: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 33

Entrega fora de ordemEntrega fora de ordem

Chega ao destino

Envia

Solução: Sequenciamento

Page 34: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 34

Pacotes duplicadosPacotes duplicados

Chega ao destino

Envia

Solução: Sequenciamento

Page 35: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 35

Perda de pacotesPerda de pacotes

Chega ao destino

Envia

Solução: Retransmissão

Page 36: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 36

Pacote duplicado em sessões Pacote duplicado em sessões diferentesdiferentes

52 3 4 6 71 8

Destino:

Origem:

Solução: Identificador único da sessão

52 3 6 71 8

52 3 4 6 71 8

52 3 4 6 71 8

4

4

4

Page 37: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 37

Controle de Fluxo para evitar Controle de Fluxo para evitar “overrun”“overrun”

• Tw = min( B, Tg x W )

Page 38: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 38

Mecanismo para evitar Mecanismo para evitar congestionamento na redecongestionamento na rede

• Packet Switches informa o transmissor que houve congestionamento

• Utiliza perda de pacote como estimativa de congestionamento

Page 39: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 39

InternetworkingInternetworking

Page 40: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 40

Motivação - TecnologicaMotivação - Tecnologica

• Cada tecnologia de rede é projetado para atender um conjunto de premissas.– Tcnologias LAN são projetados para prover alta

velocidade a curtas distâncias.– Tecnologias WAN são projetados para prover

comunicação através de grandes áreas.• Conclusão: Não existe uma única tecnologia que

seja a melhor para atender a todas as necessidades.

Page 41: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 41

Motivação: Conceito de Motivação: Conceito de Serviço UniversalServiço Universal

• Problemas:– um computador conectado numa rede só pode se

comunicar com computadores da mesma rede.– Usuário para realizar uma determinada tarefa tinha que

se dirigir ao computador alocado para aquela tarefa.• Um Sistema de Comunicação que fornece Serviço

Universal possibilita que quaisquer pares de computadores se comuniquem.

• Serviço Universal é desejado porque aumenta a produtividade do indivíduo.

Page 42: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 42

Motivação : Serviço Universal Motivação : Serviço Universal em redes heterogeneasem redes heterogeneas

• Apesar do Serviço Universal ser altamente desejado, incompatibilidade de formatos de pacotes e esquemas de endereços físico desmotivavam as organizações em montar uma rede que incluia diferentes tecnologias.

• Internetworking é um esquema capaz de prover Serviço Universal em redes heterogêneas. O sistema resultante é conhecido como internetwork ou internet

Page 43: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 43

RoteadorRoteador

• Roteador é um computador dedicado para a tarefa de interconectar redes.

• Roteador pode interconectar redes que utilizam diferentes tecnologias, incluindo diferentes meios, esquemas de endereçamento físico, ou formato de ‘frame”.

Page 44: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 44

Arquitetura internetArquitetura internet

• Topologia internet depende :– Capacidade (largura de banda

das redes físicas e tráfego esperado)

– Confiabilidade desejada– Custo (dos roteadores

disponíveis e links)

Page 45: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 45

Rede VirtualRede Virtual

• A internet é um sistema de rede virtual, os detalhes das conexões físicas entre redes, endereços físicos, informações de roteamento são escondidos.

• Software de Protocolo em cada computador e roteadores são vitais para ter serviço universal.

Page 46: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 46

TCP/IPTCP/IP

• TCP/IP (“Transmission Control Protocol/Internet Protocol)

• O modelo de 7 camadas não correspodem exatamente ao modelo de camadas TCP/IP.

Page 47: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 47

Endereço IPEndereço IP

• Esquema de endereço abstrato que associa a cada host um endereço único. Utilizado pelos usuários, programas aplicativos e camadas superiores do protocolo de software.

• IPv4 usa 32 bits, hierárquico (prefixo + sufixo)

Page 48: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 48

NotaçãoNotação

Page 49: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 49

Exemplo de RedeExemplo de Rede• Autoridade para designar endereço:

– IANA (“Internet Assigned Number Authority”) designou para RIR ou LIR esta tarefa:

– APNIC (Asia Pacific Network Information Centre) - Asia/Pacific Region

– ARIN (American Registry for Internet Numbers) - North America and Sub-Sahara Africa

– LACNIC (Regional Latin-American and Caribbean IP Address Registry) – Latin America and some Caribbean Islands

– RIPE NCC (Réseaux IP Européens) - Europe, the Middle East, Central Asia, and African countries located north of the equator

Page 50: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 50

Endereços IP especiaisEndereços IP especiais

Page 51: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 51

Roteador e Endereço IPRoteador e Endereço IP

• Um endereço IP não identifica um computador específico. Um endereço IP identifica a conexão entre um computador e a rede.

Page 52: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 52

Mapeamento de EndereçoMapeamento de Endereço

• Antes que um software de protocolo possa enviar um pacote através da rede física o software deve traduzir o endereço de destino IP em endereço de hardware equivalente.

• A tradução de endereço IP para endereço físico equivalente é conhecido como “Resolução de Endereço”

Page 53: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 53

Tecnicas para resolução de Tecnicas para resolução de endereçoendereço

• Table Lookup• Closed-Form Computation• Message Exchange

Page 54: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 54

Table LookupTable Lookup

• Cada entrada contém par (P,H), onde P é o endereço de protocolo (IP) e H é endereço de hardware (Físico).

Page 55: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 55

Closed-Form ComputationClosed-Form Computation

• Endereço IP 220.123.5.101• Endereço de Hardware 101• Operação booleana

hardware_address = ip_address & 0xff

Page 56: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 56

Comparação Comparação

Page 57: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 57

ARP- Address Resolution ARP- Address Resolution ProtocolProtocol

• Envia mensgem broadcast para a rede

• Só computador com endereço IP consultado responde

Page 58: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 58

ARP – Formato da MensagemARP – Formato da Mensagem

Page 59: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 59

ARP - envioARP - envio

• Frame Ethernet

Page 60: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 60

Datagrama IPDatagrama IP

• Formato de pacote independente de hardware

Page 61: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 61

Encapsulamento do pacote IPEncapsulamento do pacote IP

Page 62: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 62

MTUMTU

Page 63: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 63

Rede VirtualRede Virtual

Page 64: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 64

MotivaçãoMotivação

• Tecnologia LAN - alta velocidade, curta distância

• Tecnologia WAN - comunicação em longas distâncias

• Resultado:– Não existe uma tecnologia que seja a melhor

para todas necessidades

Page 65: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 65

Serviço UniversalServiço Universal

• Um computador conectado numa dada rede só pode se comunicar com computadores conectados na mesma rede

• Várias redes para várias tarefas - o usuário era obrigado a se deslocar para o computador específico à tarefa (“insatisfação”)

• Solução : Serviço Universal

Page 66: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 66

Serviço UniversalServiço Universal

• Um sistema de comunicação que fornece serviço universal possibilita a comunicação de qualquer par arbitrário de computadores.

• O serviço universal é desejado porque aumenta a produtividade individual

• Redes heterogêneas :– esquema : INTERNETWORKING– sistema : INTERNET

Page 67: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 67

RoteadorRoteador

• É um computador de propósito especifico dedicado à tarefa de interconectar redes, seja de mesma tecnologia ou não, incluindo meios diferentes, esquema de endereços físicos diferentes ou formatos de quadro diferentes

Page 68: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 68

Rede VirtualRede Virtual

• Combinação de SW e HW faz parecer que a Internet é um sistema de rede uniforme

• Software de protocolo internet esconde os detalhes da rede física

• Abstração

Page 69: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 69

Protocolos para Protocolos para “Internetworking”“Internetworking”

• TCP/IP Internet Protocols• início nos anos de 1970

– ARPA (“Advanced Research Projects Agency”)• meados dos anos 1980

– NSF (“National Science Foundation”)– NSFNET (1987-1995)

Page 70: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 70

TCP/IP e Modelo de CamadasTCP/IP e Modelo de Camadas

• Camada 3– Formato dos pacotes– mecanismo

(“forwarding”)• Camada 4

– especifica como garantir uma transferencia segura

Page 71: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 71

Host, Roteador e TCP/IPHost, Roteador e TCP/IP

• Host - qualquer sistema de computador que conecta à internet e executa uma aplicação

• Roteador - Não usa todas as camadas do modelo TCP/IP. Por exemplo, um roteador não necessita da camada 5 para uma aplicação de transferencia de arquivo porque ele não executa tal aplicação

Page 72: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 72

Endereço para uma rede Endereço para uma rede virtualvirtual

• Esquema de endereço abstrato, cada “host” está associado a um único endereço IP.

• Usuários, programa de aplicação, e camadas superiores do protocolo TCP/IP usam este esquema.

• Hierarquia– prefixo (rede física)– sufixo (“host”)

Page 73: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 73

Notação ponto decimalNotação ponto decimal• Binário -> Decimal• 20 = 1• 21 = 2• 22 = 2*2 = 4• 23 = 2*2*2 = 8• 24 = 2*2*2*2 = 16• 25 = 2*2*2*2*2 = 32• 26 = 2*2*2*2*2*2 = 64• 27 = 2*2*2*2*2*2*2 = 128• Ex.: 10000001= 27 +20=129

Page 74: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 74

Autoridade para endereço IPAutoridade para endereço IP

• IANA (“Internet Assigned Number Authority”)– http://www.iana.org

• ARIN (“American Registry for Internet Numbers”)– http://www.arin.net

• FAPESP– http://registro.fapesp.br ou http://registro.br

Page 75: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 75

Exemplo de endereçamentoExemplo de endereçamento

• Os roteadores precisam ter um endereço IP para cada interface de rede.

• Ex.: Roteador 1– 128.10.0.5– 128.211.10.1

Page 76: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 76

Endereços IP EspeciaisEndereços IP Especiais

• Endereço da Rede– host address zero

• Endereço de Broadcast Direcionado– sufixo com todos os bits “1”

• Endereço de Broadcast Limitado– todos os bits “1”– usado para conhecer o numero da rede

Page 77: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 77

Endereços IP EspeciaisEndereços IP Especiais

• Endereço “This Computer”– todos os bits “0”– “startup protocols” quando do “boot”

• Endereço de “loopback”– prefixo 127– teste da pilha TCP/IP– não há pacote na rede com endereço de

“loopback”

Page 78: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 78

Endereços IP EspeciaisEndereços IP Especiais

• Endereço Berkeley Broadcast– BSD Unix– sufixo, todo zero para indicar broadcast direcionado

Page 79: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 79

Ligando Endereço de Ligando Endereço de ProtocoloProtocolo

• Endereço de Protocolo é uma abstração providenciada pelo software

• A rede física não sabe como localizar um computador a partir do endereço de protocolo

• Antes de transmitir um pacote o endereço de protocolo do “next hop” deve ser transladado para um endereço de hw equivalente

Page 80: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 80

Resolução de EndereçoResolução de Endereço

• Mapeamento entre um endereço de protocolo e um endereço de hardware é chamado resolução de endereço

• Um “host” ou roteador usa resolução de endereço sempre que necessitar enviar um pacote para um outro computador na mesma rede física

• Um computador nunca resolve endereço de um computador conectado numa rede remota

Page 81: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 81

Técnica de Resolução de Técnica de Resolução de EndereçoEndereço

• “Table lookup”• “Closed Form computation”• “Message exchange”

Page 82: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 82

““Table Lookup”Table Lookup”

• Array (P,H)– P é endereço de

protocolo– H é endereço de

hardware• Técnica de busca

– sequencial– hashing– indexação direta

Page 83: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 83

““Closed Form Computation”Closed Form Computation”

• Quando um computador é conectado numa rede que usa endereço configurável, o administrador de rede deve escolher o endereço de hardware e o endereço IP. Os dois valores devem ser escolhidos de forma que a resolução de endereço seja trivial.

• Ex.: end. IP 220.123.5.1 e end. MAC 00:00:00:00:00:01

• end. IP 220.123.5.2 e end. MAC 00:00:00:00:00:02

Page 84: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 84

““Message Exchange”Message Exchange”

• Servidores– tem a tarefa de resolver as requisições de

endereço• Broadcast

– cada computador concorda em responder à resolução de endereço do seu endereço

Page 85: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 85

Resolução de Endereço - Resolução de Endereço - ResumoResumo

Característica Tipo deresolução

Pode ser utilizado com qualquer hardware T

Troca de endereço afeta todos os “hosts” T

Endereço de protocolo independente do endereço de hardware T, D

Endereço de hardware deve ser menor que endereço de protocolo C

Endereço de protocolo determinado pelo endereço de hardware C

Utiliza broadcast de hardware D

Adiciona tráfego na rede D

A resolução de endereço se dá com mínimo atraso T, C

Implementação é mais difícil D

T=table lookup; C=closed-form computation; D=dynamic message exchange

Page 86: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 86

ARP - “Address Resolution ARP - “Address Resolution Protocol”Protocol”

• incluso no protocolo TCP/IP• 2 tipos básicos de mensagens

– request• envia endereço IP e pede o correspondente endereço

de hardware– response

• resposta ao pedido de request, contém todas as informações do request + endereço de hardware

Page 87: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 87

Exemplo - ARPExemplo - ARP

• Request

• Response

Page 88: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 88

Formato da Mensagem ARPFormato da Mensagem ARP

• Ethernet e IP– Hardware

Address Type = 1

– Protocol Address Type = 0x0800Operation: 1= request ; 2=response

Page 89: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 89

Transmissão de uma Transmissão de uma mensagem ARPmensagem ARP

Page 90: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 90

Resolução de Endereço e Resolução de Endereço e Modelo de CamadasModelo de Camadas

• Modelo de 5 camadas

• Endereço de hardware nas camadas 1 e 2

• Endereço de protocolo nas demais

Page 91: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 91

Datagrama IPDatagrama IP

• pacote virtual• independente da rede física• pacote do protocolo TCP/IP• por conectar redes heterogêneas, um

roteador não pode transmitir uma cópia do quadro que chega de uma rede para outra distinta

Page 92: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 92

Datagrama IPDatagrama IP

• Mesma forma geral do quadro de hardware

• tamanho dos dados é variável e determinado pela aplicação– máximo de 64 K

octetos

Page 93: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 93

““Forwarding”Forwarding”

• Cada destino na tabela de rotas corresponde a uma rede

• O número de entradas na tabela de rotas é proporcional ao número de redes em uma internet

Page 94: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 94

Endereço IP e Entradas na Endereço IP e Entradas na Tabela de RotasTabela de Rotas

• If ((Mask[i] &D) == Destination[i]) forward to NextHop[i];

– onde D é endereço de destino do datagrama IP

Page 95: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 95

Entrega “Best-Effort”Entrega “Best-Effort”

• IP não garante que resolve problemas de:– duplicação de datagrama– entrega fora de ordem ou atrasado– dados corrompidos– perda de datagrama

Page 96: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 96

Formato do Header do Formato do Header do Datagrama IPDatagrama IP

• Type = tipo de dados• H.LEN em múltiplo de

32 bits• Time to live, ao passar

por roteador este valor é decrementado; se chegar a zero o datagrama é descartado

Page 97: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 97

Encapsulamento do Encapsulamento do Datagrama IPDatagrama IP

• Um datagrama é encapsulado em um quadro para transmissão pela rede física.

• O endereço de destino do quadro é o endereço do next hop

Page 98: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 98

Transmissão pela InternetTransmissão pela Internet

• Header depende da tecnologia de rede

Page 99: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 99

MTU, tamanho do datagrama MTU, tamanho do datagrama e encapsulamentoe encapsulamento

• MTU depende da tecnologia de rede

Page 100: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 100

Remontagem do datagrama Remontagem do datagrama fragmentadofragmentado

• A remontagem só ocorre no destino final• IP não garante a entrega, assim os fragmentos podem ser

perdidos ou chegar fora de ordem• Identification , fragment offset• O destino não sabe quantas fragmentações ocorreram

Page 101: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 101

Rede Virtual - ContinuaçãoRede Virtual - Continuação

Page 102: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 102

ICMP - “Internet Control ICMP - “Internet Control Message Protocol”Message Protocol”

• Na comunicação “best effort”– o datagrama pode ser perdido– o datagrama pode ser duplicado– o datagrama pode ter atraso– o datagrama pode ser entregue fora de ordem

• Apesar do serviço “best effort” não necessitar de qualquer mecanismo de detecção de erro ele não é realizado sem cuidado.

Page 103: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 103

ICMPICMP

• ICMP faz parte da pilha TCP/IP• É um mecanismo para reportar erro• Se houver erro no HEADER CHECKSUM

do cabeçalho do datagrama IP, o roteador/host:– Não consegue avisar o “host” origem da

mensagem que houve erro– Tem que descartar o datagrama

Page 104: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 104

Lista de mensagem ICMPLista de mensagem ICMP

• Type de 8 bits

Page 105: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 105

ICMP - Source QuenchICMP - Source Quench

• O roteador envia source quench sempre que ele receber mais datagrama do que ele pode tratar.

• O roteador descarta o datagrama• O “host” origem do datagrama descartado

ao receber a mensagem de source quench reduz a taxa de transmissão

Page 106: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 106

ICMP - Time ExceededICMP - Time Exceeded

• TIME TO LIVE do header é reduzido a ZERO– roteador envia mensagem ICMP de “Time

Exceed” para o “host” origem– o datagrama no roteador é descartado

• Fragmentação– o “host”envia mensagem Time Exceed se esgotar

o tempo para remontagem e todos os fragmentos não chegarem.

Page 107: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 107

ICMP - Destination ICMP - Destination UnreachableUnreachable

• Sempre que o roteador concluir que não dá para entregar o datagrama recebido ele envia uma mensagem Destination Unreachable para o “host” origem

• A mensagem Destination Unreachable especifica se o problema é na rede ou no “host”

Page 108: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 108

ICMP - RedirectICMP - Redirect

• Se o roteador concluir que o datagrama não deveria ser enviado para ele e sim para um outro roteador ele envia a mensagem Redirect para o “host” origem para que ele troque de rota.

Page 109: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 109

ICMP - Parameter ProblemICMP - Parameter Problem

• Um ou mais parâmetros especificado no datagrama está incorreto.

Page 110: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 110

ICMP - Echo Reply / RequestICMP - Echo Reply / Request

• Uma mensagem echo request pode ser enviada para o software ICMP de qualquer computador

• O computador que receber esta mensagem envia uma mensagem de echo reply

• A mensagem de echo reply transporta a mesma mensagem recebida no echo request.

Page 111: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 111

ICMP - Address Mask ICMP - Address Mask Request / ReplyRequest / Reply

• O “host” envia um broadcast de mensagem ICMP Address Mask Request quando do “boot”

• O roteador que recebe o request envia a mensagem ICMP Address Mask Reply que contém a máscara sub-net de 32 bits utilizado pela rede.

Page 112: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 112

Transporte da mensagem ICMPTransporte da mensagem ICMP

• ICMP usa IP para transportar a mensagem de erro ou de informação.

Page 113: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 113

Usando ICMP - “Ping”Usando ICMP - “Ping”

• “Ping” usa ICMP echo request / reply• Ao enviar a mensagem echo request para um

destino especifico este inicia uma espera• Ao término da espera se não chegar echo reply

ele retransmite echo request• Após algumas tentativas sem echo reply ele

declara que a máquina remota não é localizável.

Page 114: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 114

Usando ICMP - “Traceroute”Usando ICMP - “Traceroute”

• Utiliza TTL e ICMP Time Exceeded• TTL = 1, descobre o primeiro roteador• ...• TTL = n, descobre o n-ésimo roteador• UDP para um programa inexistente no

“host” destino• Destino envia mensagem ICMP

Destination Unreachable.

Page 115: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 115

Usando ICMP - “Path MTU”Usando ICMP - “Path MTU”

• Fragmentação afeta o desempenho• Aplicações podem evitar fragmentação se

usar “Path MTU”, o menor MTU do caminho entre a origem e o destino

• Probe - conf. campo FLAGS para que não possa fragmentar a mensagem

• O roteador envia mensagem ICMP de erro.

Page 116: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 116

Protocolo de TransporteProtocolo de Transporte

Page 117: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 117

Protocolo de TransporteProtocolo de Transporte

• Camada da pilha de Protocolo TCP/IP• Conceitualmente entre as camadas de

– Aplicação– IP

Page 118: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 118

TerminologiaTerminologia• IP

– Providencia comunicação computador-a-computador– Endereços de origem e destino são computadores– Chamado de comunicação “máquina-a-máquina”

• Protocolo de Transporte– Providencia comunicação aplicação-a-aplicação– Necessita estender mecanismo de endereçamento para identificar

a aplicação– Chamado de comunicação “fim-a-fim”

Page 119: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 119

Funcionalidade do Protocolo Funcionalidade do Protocolo de Transportede Transporte

• Identifica a aplicação transmissora e receptora• Opcionalmente proporciona

– Confiabilidade– Controle de Fluxo– Controle de Congestionamento

• Nota: nem todo protocolo de transporte proporciona as facilidades acima

Page 120: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 120

Dois Protocolos de Transporte Dois Protocolos de Transporte DisponíveisDisponíveis

• “Transmission Control Protocol” (TCP)• “User Datagram Protocol” (UDP)• Maiores diferenças

– Interface para aplicação– Funcionalidade

Page 121: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 121

““User Datagram Protocol” User Datagram Protocol” (UDP)(UDP)

• Providencia transferência sem garantia• Requer mínimo

– “Overhead”– Processamento computacional– Comunicação

• Melhor para aplicações LAN

Page 122: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 122

Detalhes UDPDetalhes UDP

• Paradigma do serviço não orientado a conexão– interface orientado a mensagem

• Cada mensagem é encapsulada num datagrama IP

• O header UDP identifica :– Aplicação transmissora– Aplicação receptora

Page 123: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 123

Identificando uma aplicaçãoIdentificando uma aplicação

• O endereço IP não pode ser estendido– não tem bits sem uso

• Não pode usar valor dependente do SO– Process ID– Task number– Job name

• Deve trabalhar em todos os sistemas de computadores

Page 124: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 124

Identificando uma aplicação Identificando uma aplicação (continuação)(continuação)

• Nova abstração – usado somente com TCP/IP– identifica transmissor e receptor sem

ambiguidade• Técnica

– cada aplicação recebe um número inteiro único– chamado “protocol port number”

Page 125: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 125

Portas de ProtocoloPortas de Protocolo

• Servidor– segue o padrão– sempre usa o mesmo número de porta– usa número de portas baixa

• Cliente– obtém uma porta do software de protocolo não

utilizado– usa número de portas alta

Page 126: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 126

Exemplo de Portas de Exemplo de Portas de ProtocoloProtocolo

• aplicação Domain Name Server recebe o número de porta 53

• aplicação que usa DNS obtém o número de porta 28900

• datagrama UDP enviado a partir da aplicação para o servidor DNS tem:– número de porta origem 28900– número de porta destino 53

Page 127: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 127

Exemplo de Porta de Exemplo de Porta de Protocolo (continuação)Protocolo (continuação)

• Quando o servidor DNS responde, o datagrama UDP enviado tem:– número de porta origem 53– número de porta destino 28900

Page 128: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 128

TCP - “Transmission Control TCP - “Transmission Control Protocol”Protocol”

• Protocolo de transporte mais utilizado na Internet

• Usado massivamente• Serviço de entrega confiável• Serviço orientado à conexão• ponto a ponto• comunicação “full-duplex”

Page 129: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 129

TCP - CaracterísticasTCP - Características

• “Stream Interface” - sequência contínua de octetos

• “stream” dividido em segmentos para transmissão

• cada segmento é encapsulado em datagrama IP• utiliza porta de protocolo para identificar a

aplicação

Page 130: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 130

TCP - CaracterísticasTCP - Características

• TCP providencia um serviço de transporte de fluxo contínuo, “full duplex”, orientado à conexão e completamente confiável ( não há perda de dados ou duplicações). Permite que dois programas aplicativos forme uma conexão, envie dados em ambas as direções e então termine a conexão.

Page 131: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 131

Relação entre TCP e outros Relação entre TCP e outros protocolosprotocolos

• TCP em um computador usa IP para comunicar com TCP em outro computador

Page 132: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 132

Contradição aparenteContradição aparente

• IP oferece entrega “best effort”• TCP usa IP• TCP garante uma transferência

completamente confiável• Como isto é possível ?

Page 133: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 133

Obtendo confiabilidadeObtendo confiabilidade

• Conexão “startup” confiável• Transmissão de dados confiável• Conexão “shutdown” “polido”

Page 134: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 134

Transmissão de dados confiávelTransmissão de dados confiável

• “Positive acknowledgment”– Computador destino retorna uma mensagem curta quando o

dado chega– Chamado “acknowledgment”

• Retransmissão– Origem inicia um “timer” sempre que uma mensagem é

transmitida– Se o “timer” expirar antes que “acknowledgment” chegue, a

origem retransmite a mensagem

Page 135: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 135

Ilustração de uma retransmissãoIlustração de uma retransmissão

Page 136: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 136

Quanto tempo o TCP deverá Quanto tempo o TCP deverá esperar antes de retransmitir ?esperar antes de retransmitir ?

• Tempo para a chegada do “acknowledgment” depende:– da distância até o destino– das condições do tráfego corrente

• Multiplas conexões podem ser abertas simultaneamente

• As condições de tráfego podem variar rapidamente

Page 137: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 137

Ponto ImportantePonto Importante

O “delay” necessário para que um dado chegue no seu destino e um “acknowledgment” retorne depende do tráfego na Internet assim como da distância até o destino. O TCP por permitir que múltiplos programas de aplicação comuniquem com vários destinos concorrentemente, deve tratar uma variedade de “delays” que podem mudar rapidamente em função do tráfego.

Page 138: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 138

Resolvendo o problema da Resolvendo o problema da retransmissãoretransmissão

• Tome o “round trip time” (rtt) estimado de cada conexão

• Utilize o tempo estimado para retransmissão do conjunto corrente

• Este método é chamado retransmissão adaptativa

• É a chave do sucesso para o TCP

Page 139: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 139

Ilustração da retransmissão Ilustração da retransmissão adaptativa adaptativa

• “Timeout” depende do “round trip time” corrente estimado

Page 140: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 140

Controle de Fluxo TCPControle de Fluxo TCP

• Destino– Anuncia o tamanho do “buffer” disponível– O “buffer” chama-se “window”

• Origem– Pode enviar vários datagramas até o limite do

“window” antes que um “ack” retorne

Page 141: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 141

Anuncio do “window”Anuncio do “window”

• Cada “acknowledgment” transporta a informação do novo “window”– Chama-se “window advertisement”– O valor pode ser zero ( chama-se “closed

window” )• Interpretação: “Eu recebi até X de

mensagem e posso receber ainda mais Y octetos

Page 142: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 142

Ilustração de “window advertisement”Ilustração de “window advertisement”

Page 143: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 143

““Startup” e “Shutdown”Startup” e “Shutdown”

• Conexão “Startup”– Deve ser confiável

• Conexão “Shutdown”– Deve ser “polido”

• Difícil

Page 144: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 144

Porque é difícil Porque é difícil “Startup/Shutdown”“Startup/Shutdown”

• Segmentos podem ser:– Perdidos– Duplicados– Atrasados (“delayed”)– Entregue fora de ordem– Ambos os lados podem deixar de funcionar– Ambos os lados podem dar “reboot”

• É necessário evitar mensagem de “shutdown” duplicado

Page 145: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 145

Solução para Solução para “Startup/Shutdown” do TCP“Startup/Shutdown” do TCP

• Utiliza três trocas de mensagens• Conhecido como “3-way handshake”• É necessário e suficiente para:

– “Startup” confiável” e sem ambiguidade– “Shutdown” polido e sem ambiguidade

• SYN é usado para “startup”• FIN é usado para “shutdown”

Page 146: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 146

Ilustração de “3-way handshake”Ilustração de “3-way handshake”

Page 147: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 147

Formato do segmento TCPFormato do segmento TCP• Todos os segmentos TCP tem o mesmo formato

– Dados– Acknowledgment– SYN (“startup”)– FIN (“shutdown”)

• Segmento é dividido em duas partes:– “Header”– “Payload” (zero ou mais bytes de dados)

Page 148: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 148

Formato do segmento TCP Formato do segmento TCP (continuação)(continuação)

• O “Header” contém:– Números de porta de protocolo para identificar

• Aplicação transmissora• Aplicação receptora

– Bits para especificar itens como :• SYN• FIN• ACK

– Campo para “window advertisement”, acknowledgment, etc.

Page 149: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 149

Ilustração do Segmento TCPIlustração do Segmento TCP

• “Sequence number” especifica qual é a posição do segmento no fluxo dos dados transmitidos

• Poucos segmentos contém “options”

Page 150: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 150

ResumoResumo

• Protocolo de transporte está entre a aplicação e o Protocolo Internet

• Dois protocolos de transporte na pilha TCP/IP– “User Datagram Protocol” (UDP)– “Transmission Control Protocol” (TCP)

• UDP– Não confiável– Interface orientada à mensagem

Page 151: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 151

Resumo ( continuação)Resumo ( continuação)

• TCP– Protocolo de transporte mais utilizado na

Internet– Completamente confiável– Interface orientada a fluxo– Utiliza retransmissão adaptativa

Page 152: PUC-SP1 Gerência de Comunicações de Dados - Parte II Prof. Milton Kaoru Kashiwakura

PUC-SP 152

Resumo ( continuação )Resumo ( continuação )

• Porta de protocolo– Número Inteiro– Usado para identificar a aplicação no

transmissor e no receptor– Permite multiplas aplicações comunicando

simultaneamente e sem ambiguidade– ftp://ftp.registro.br/in-notes/iana/assignments/

port-numbers