2. Transmissão da Informação



Baixar 50.2 Kb.
Encontro05.09.2019
Tamanho50.2 Kb.



ÌNDICE





10. Nível de Transporte

2

10.1. Funções

2

10.2. Endereçamento

2

10.3. Estabelecimento de Conexões

3

10.4. Qualidade de Serviço

4

10.5. O Protocolo TCP (Transmission Control Protocol)

4

10.6. Controle de Fluxo e de Erros

5

10.6.1. Recuperação de Falhas

5

10.6.2. Controle de Congestão pelo TCP

5

10.6.3. UDP

6

10.6.4. TCP Sem Fio e UDP

6

10.6.5. Problemas de Rendimento em Redes de Computadores

6


10. NÍVEL DE TRANSPORTE
10.1. Funções
A camada de transporte não é apenas uma camada. É o verdadeiro coração ou núcleo da hierarquia de protocolos. Esta camada é responsável pela movimentação de dados, de maneira eficiente e confiável, entre processos (usuários), independentemente da rede física.

Na camada de transporte a comunicação é verdadeiramente fim a fim, isto é, a entidade da camada de transporte da máquina de origem se comunica apenas com a entidade de transporte da máquina de destino.

Os serviços da camada de transporte são bastante semelhantes aos da camada de rede. As razões da existência de duas camadas são:


  • A camada de rede não oferece um serviço totalmente confiável.

  • A camada de rede é parte da sub rede de comunicações e, em geral, é da conta da concessionária. O usuário não tem controle sobre a sub rede não podendo resolver problemas de mau serviço.

  • Os primitivos de serviço de transporte podem ser especificados independentemente dos de rede que podem variar de rede para rede.

Se as redes reais não tivessem falhas e seus primitivos de serviços fossem os mesmos não haveria necessidade da camada de transporte.
10.2. Endereçamento
Os pontos de acesso a serviços de transporte (SAP de transporte ou T-SAP) são análogos aos SAP de enlace e de rede.

Se o endereçamento não é hierárquico, deve haver um servidor de nomes que use os T-SAP como entrada e retorne SAP de rede como saída. Uma outra alternativa é o envio de endereços por difusão pedindo que a própria máquina de destino se identifique.

O endereçamento compreende o estabelecimento dos pontos de acesso ou TSAP. Na Internet os TSAP correspondem a pares (endereço IP, porta local). Nas redes ATM são os SAP da AAL. Por analogia os SAP na Internet são os endereços IP.

Multiplexação e Splitting

A multiplexação de um SAP de rede em vários T-SAP pode surgir por vários motivos. Um deles é o custo. Uma solução é a multiplexação de várias conexões de transporte na conexão de rede.



A conexão de rede pode oferecer uma banda passante muito mais baixa do que a necessária pela conexão de transporte. Uma solução nesse caso é realizar a divisão (splitting) da conexão de transporte em várias conexões de redes.


10.3. Estabelecimento de conexões
O grande problema no estabelecimento de conexões é a existência de duplicatas atrasadas. Este problema pode ser tratado por diversas maneiras:

  • Uso de endereços descartáveis.

  • Uso de identificadores de conexões (seqüenciais com tabela de identificadores obsoletos). Se uma máquina cai e perde a memória não há como saber quais os identificadores de conexões ainda são válidos.

  • Limitação do tempo de vida dos pacotes por:

  • projeto restrito de sub rede.

  • contador de saltos em cada pacote.

  • marca de tempo em cada pacote.


O que se necessita é assegurar que um pacote está morto bem como todas as notificações oriundas dele também. Para tanto é introduzido um pequeno múltiplo, T, da maior vida útil de um pacote. Caso se aguarde um tempo T após o início de um pacote, pode-se assegurar que todos os seus traços se foram e nem ele nem nenhuma de suas confirmações pode aparecer na rede.

Um método proposto por Tomlinson faz com que duas unidades de dados do protocolo de transporte (T-PDU) com numeração idêntica nunca estejam pendentes ao mesmo tempo. Para tanto, as numerações das T-PDU não se repetem dentro do período T , que é o tempo de vida máximo na rede para um pacote.


Figura 10.1 - (a)As TPDUs não podem entrar na área proibida.

(b) O problema da ressincronização.


Encerrar uma conexão é muito mais fácil que estabelecê-la. Um problema presente é evitar que dados sejam perdidos depois que um dos lados encerrou a conexão. Uma forma de resolver o problema é terminar uma conexão apenas depois de decorrido um certo tempo sem que chegue nenhuma T-PDU. Se um lado se desconectar, o outro vai notar a falta de atividade e também se desconectar. Uma entidade de transporte ao pedir uma desconexão aguarda por um tempo antes de fechar a conexão, podendo receber dados durante esse período.

A liberação de uma conexão, por incrível que pareça, é um problema bastante complicado. No caso normal de não se desejar que ocorra perda de dados é difícil fazer uma desconexão.


10.4. Qualidade de Serviço
A qualidade de serviço pode ser caracterizada por uma série de parâmetros QoS (Quality of Service).:

  • O retardo no estabelecimento da conexão.

  • O retardo no encerramento da conexão.

  • A probabilidade de falha no estabelecimento da conexão.

  • A probabilidade de falha na liberação da conexão.

  • A vazão em cada sentido da conexão.

  • O retardo de transferência médio, também em cada sentido.

  • O retardo de transferência máximo, também em cada sentido.

  • A variação estatística do retardo.

  • A taxa de erro, expressa em porcentagem dos bits transmitidos.

  • A prioridade, ou a garantia de que serviços de maior prioridade tenham preferência sobre os de mais baixa prioridade.

  • Probabilidade de queda de uma conexão.


10.5. O Protocolo TCP
A arquitetura Internet permite que sejam utilizados dois tipos de protocolos em sua camada de transporte. O principal deles é o TCP (Transmission Control Protocol).

A outra opção é o UDP (User Datagram Protocol). O UDP opera no modo sem conexão e fornece um serviço datagrama não confiável, sendo uma simples extensão do protocolo IP. A principal função do UDP é multiplexar, na origem, e demultiplexar, no destino, o acesso ao nível inter rede.

O TCP é um protocolo orientado à conexão que fornece um serviço confiável de transferência de dados fim a fim. O TCP foi projetado para funcionar com base em um serviço de rede sem conexão e sem confirmação.

Alguns dos problemas com os que TCP deve tratar são:



  • pacotes perdidos ou destruídos por erros de transmissão.

  • expedição de pacotes fora de ordem ou duplicados.

Para permitir que vários processos em um host possam simultaneamente transmitir dados, o TCP utiliza o conceito de porta. Cada um dos usuários (processos de aplicação) que o TCP está atendendo em um dado momento é identificado por uma porta diferente. Como os identificadores de portas são selecionados isoladamente por cada entidade TCP, eles podem não ser únicos na inter rede.

Para obter um endereço TCP, o identificador da porta é concatenado ao endereço IP onde a entidade TCP está sendo executada, definindo um socket. Um socket, que é equivalente a um T-SAP, identifica univocamente um usuário TCP em toda a inter rede.

Processos servidores que são muito usados (FTP, Telnet etc.) são associados a portas fixas, que são divulgadas aos usuários.

As conexões são identificadas por um par de “end points” ou “sockets”. Uma conexão consiste de um circuito virtual entre dois programas de aplicação.

Exemplo: 128.10.2.3,25 especifica a porta TCP número 25 na máquina como o endereço IP 128.10.2.3.

As conexões TCP são full-duplex.

Os processos de aplicação transmitem seus dados fazendo chamadas ao TCP, passando como parâmetros os buffers onde estão os dados. O TCP empacota os dados armazenados nos buffers em segmentos e chama o módulo IP para transmitir os segmentos para o TCP destino. O TCP receptor coloca os dados recebidos em segmentos nos buffers do usuário destinatário e notifica-o da entrega.

A interface oferecida aos usuários de seus serviços baseia-se em chamadas para abrir (open) ou fechar (close) uma conexão, para enviar (send) ou receber (receive) dados, ou para obter informações sobre o estado (status) de uma conexão.


10.6. Controle de Fluxo e de Erros
10.6.1. Recuperação de Falhas
A recuperação de falhas quando a rede ou um roteador falha é simples.

As falhas de “hosts” são muito mais graves. Quando um servidor falha e retorna ao ar, suas tabelas são reinicializadas e ele não sabe aonde estava. Para tentar recuperar o estado anterior o servidor pode enviar uma mensagem em broadcast a todos os demais “hosts” anunciando sua falha e pedindo que os clientes informem o estado das conexões abertas.

Cada cliente pode estar em um de dois estados: com uma TPDU pendente ou sem TPDU pendente.

Ao receber uma TPDU o servidor pode confirmar o recebimento primeiro e gravar a TPDU depois ou gravar a TPDU primeiro e enviar a confirmação de recebimento depois.

O cliente pode ser programado de quatro maneiras:


  • sempre retransmitir a última TPDU.

  • nunca transmitir a última TPDU.

  • retransmitir apenas se houver TPDU pendente.

  • retransmitir apenas se não houver TPDU pendente.

Para qualquer combinação das 8 possibilidades de programação de cliente e de servidor existe um conjunto de eventos que faz com que o protocolo falhe. De uma maneira geral, a recuperação de falhas de uma camada N só pode ser feita pela camada N + 1 e, mesmo assim, se a camada superior retiver suficiente informação.
10.6.2. Controle de Congestão pelo TCP
Muito embora a camada de rede tente gerenciar a congestão, a maioria do trabalho pesado é feita pelo TCP porque a maneira real de solucionar a congestão consiste na redução da taxa de transmissão.

Hoje em dia a perda de pacotes por erro de transmissão é relativamente raro. Todos os algoritmos Internet TCP supõe que a causa dos disparos de temporização é a congestão.

No algoritmo de partida lenta, ao se estabelecer uma conexão fixa-se um tamanho de janela. O receptor pode especificar um tamanho de janela baseado no tamanho de seu “buffer”. Se o transmissor concorda com esse tamanho de janela, não ocorrerão problemas de transbordamento de “buffers” na recepção, mas ainda podem estes ocorrer devido a congestão interna na rede.

O algoritmo prevê que cada transmissor tenha duas janelas



  • janela do receptor

  • janela de congestão

O número de bytes que pode ser transmitido será o mínimo dessas duas janelas.

A janela de congestão vai crescendo exponencialmente até a perda de um pacote ou que se alcance o tamanho da janela do receptor.

O algoritmo de congestão da Internet usa, além das janelas do receptor e de congestão, um terceiro parâmetro, o patamar. A partir desse ponto o crescimento passa a ser linear. Se não ocorrerem mais disparos de temporização a janela de congestão cresce até atingir o tamanho da janela do receptor.
10.6.3. UDP
A Internet também suporta um protocolo de transporte sem conexão, o User Data Protocol (UDP). Seu emprego ocorre em muitas aplicações cliente-servidor que tenham apenas uma requisição e uma resposta. Estabelecer e depois liberar uma conexão nestes casos é muito mais custoso.
10.6.4. TCP Sem Fio e UDP
Os protocolos de transporte deveriam ser independentes da tecnologia da rede subjacente. Na pratica isto não ocorre tendo em vista o algoritmo de controle de congestão.

Quando um temporizador dispara, por perda de pacote TCP julga estar em congestão e reduz a taxa de transmissão de pacotes. Contudo, se a rede tiver trechos sem fio, estes são pouco confiáveis e perdem pacotes, significando que é necessário mandar mais pacotes para compensar a baixa confiabilidade do meio. A redução da taxa de transmissão só vai tornar as coisas piores. Se a rede não for homogênea, contendo trechos com fio e trechos sem fio, será difícil, uma tomada de decisão sobre a melhor maneira de enfrentar a congestão.

O protocolo UDP também é afetado pela baixa confiabilidade da transmissão sem fio. Os programas que utilizam UDP o fazem considerando-o altamente confiável. Embora sabendo que não são fornecidas quaisquer garantias, os usuários esperam que o funcionamento do protocolo seja irrepreensível. Programas altamente baseados em UDP e que tenham dificuldade de recuperação de mensagens UDP perdidas devem ter sua migração para o ambiente sem fio cuidadosamente estudada.
10.6.5. Problemas de Rendimento em Redes de Computadores
O problema de rendimento é critico em redes de computadores. Muitas vezes o desempenho da rede é sofrível sem que ninguém consiga explicar o fato. A compreensão do desempenho de uma rede é mais uma arte do que uma ciência.

Os problemas de uma rede, em geral, são causados por sobrecarga momentânea. Podem também advir de desbalanceamento de recursos. Sobrecargas são comuns nos casos:



  • Pacotes transmitidos em difusão com erro

  • Recuperação da rede depois de falhas generalizadas (queda de energia)

Rendimento baixo também pode ocorrer por mau ajustamento da rede ou por falha na especificação de temporização.

Quando uma rede não se comporta como o previsto é preciso tomar providencias para melhora-la. Cada ciclo de melhoria de uma rede contém os seguintes passos:



  • Medição dor parâmetros relevantes de desempenho da rede

  • Tentativa de entendimento sobre o que está ocorrendo

  • Mudança de um parâmetro

Estes passos repetem-se até que a rede atinja o desempenho julgado satisfatório.

A medição de parâmetros de rendimento de redes apresenta alguns problemas que passam a ser relacionados abaixo:



  • Garantia que o tamanho da amostra é suficientemente grande

  • Garantia que as amostras são representativas

  • Cuidado no emprego de medidas grosseiras de tempo (granulação grossa)

  • Garantia que nada de inesperado ocorra durante os testes

  • Alteração de medidas por uso de cache ou “bufferização”

  • Compreensão do que está sendo medido

  • Extrapolação indevida dos resultados




Redes de Computadores - 1º Período de 2000 - Cap 10 - Fls.






©aneste.org 2017
enviar mensagem

    Página principal