Redes de Comunicações 2. Camada Transporte: TCP e UDP

Capítulo 4 N O T A S D E A U L A, R E V 7.0 U E R J 2 0 1 8 F L Á V I O A L E N C A R D O R Ê G O B A R R O S Redes de Comunicações 2 Camada Transporte: TCP e UDP Flávio Alencar do Rego Barros Universidade do Estado do Rio de Janeiro E-mail: falencarrb@gmail.com

UERJ 2018 Redes de Comunicações 2 Pg. 104 Introdução à camada transporte: Se de um lado a camada de transporte pode ser entendida como aquela que parece estar mais distante dos interesses do engenheiro, talvez de maior interesse do analista de software, de outro, muito ao contrário deste primeiro sentimento, é exatamente ela que isola as camadas superiores (a camada aplicação particularmente) das questões de tecnologia, projeto e imperfeições da sub-rede que lhe é subjacente. Seu objetivo é oferecer um serviço eficiente, confiável e efetivo em custo às aplicações. Neste fascículo vamos ver os seus diversos elementos, como: 1) Endereçamento (portas e sockets) 2) multiplexação/demultiplexação 3) estabelecimento, fechamento de conexão 4) controle de fluxo e de congestionamento 5) estados do cliente e do servidor 6) entrega confiável 7) TCP e UDP De todos estes serviços, certamente o mais básico é a multiplexação/demultiplexação, onde o essencial é "acertar" o processo (UDP e TCP fazem isto, só que TCP faz mais ainda...), dado que a camada de rede já "acertou" a máquina. No entanto, chamamos sua atenção para o serviço de confiabilidade da camada transporte. É exatamente aqui que esta camada "esconde" aquelas imperfeições e características da rede que lhe é subjacente. A Internet é uma miscelânea de soluções desta infraestrutura, e, portanto, é o protocolo da camada de transporte que oferece um serviço confiável que facilita a vida dos desenvolvedores de aplicações. Este fascículo está organizado de tal forma que servirá como um roteiro do que será visto em sala de aula. Insistimos na necessidade de completar o estudo com leituras complementares, para isto, indicamos os textos mostrados nas referências bibliográficas, e indicamos também a feitura de exercícios. Neste capítulo indico os textos de apoio TCP-Kurose.pdf e TCP-IBM.pdf.

UERJ 2018 Redes de Comunicações 2 Pg. 105

UERJ 2018 Redes de Comunicações 2 Pg. 106 1 1 TCP = Transmission Control Protocol; UDP = User Datagram Protocol

UERJ 2018 Redes de Comunicações 2 Pg. 112 Flags: RST, SYN, FIN - estabelecer e encerrar conexão PSH - destinatário deve passar dados para a camada superior imediatamente. Este flag é útil no caso de upload de arquivo. URG - marcado como urgente pela camada superior. Reconhecimento cumulativo: suponha no exemplo anterior que Host B recebeu um segmento do Host A contendo os bytes 0 a 799 recebendo a seguir os bytes 801 a 832, não recebeu ainda os bytes 800 a 823. Então o segmento seguinte que B envia de volta a A conterá #ACK = 800. Suponha que a seguir B receba o byte que falta (#SEQ = 800), então o próximo segmento de B para A conterá #ACK = 833. TCP, portanto, provê reconhecimento cumulativo! Este exemplo de Telnet é um caso muito particular. O #SEQ (que é contado em bytes) segue um incremento unitário. Porém, isto não é o mais comum. Suponha um arquivo com 500000 bytes e o MSS (Maximum Segment Size) seja de 1000 bytes a ser transferido sobre uma conexão TCP. Então o TCP constrói uma seqüência de 500 segmentos numerados assim: 0; 1000; 2000;...; 499000.

UERJ 2018 Redes de Comunicações 2 Pg. 114 Retransmissões Vejamos agora o comportamento do emissor. Como sabemos, a infra-estrutura de rede oferecida pela camada 3 não é confiável. O TCP não pode ter certeza se certo segmento ou seu ACK está perdido, corrompido ou atrasado. Em todos estes casos, o emissor TCP retransmite o segmento, pode fazê-lo por estouro de timeout, ou através da retransmissão rápida. O TCP utiliza pipeline, o que significa que em certo momento vários segmentos foram transmitidos, mas ainda não foram reconhecidos. No slide 03-17 os exemplos sugerem outras características do TCP. Perceba no Exemplo 1 que o receptor B recebe pela segunda vez o mesmo segmento, reconhece esta situação e o descarta, mas efetua um segundo reconhecimento do mesmo. A conclusão é que do lado emissor, o recebimento de ACK duplicado pode significar atraso ou perda do primeiro ACK. A eventualidade de recebimento de 3 ACKs de um mesmo dado é indicação para o emissor que o segmento seguinte ao que foi triplamente reconhecido foi perdido (se diz que este fato configura um NACK implícito ). O emissor, neste caso, procede a

UERJ 2018 Redes de Comunicações 2 Pg. 115 uma retransmissão rápida. Observe que um ACK duplicado pode simplesmente significar reordenamento na chegada do segmento, não carecendo de parte do emissor qualquer procedimento de retransmissão O Exemplo 2 mostra uma situação típica onde o emissor A recebe o reconhecimento cumulativo de dois pacotes e o receptor B precisa reenviar o ack =100, pois seu primeiro ack = 100 pode ter se perdido (enquanto seu ack = 120 pode ter chegado, tudo vai depender de como o emissor responderá a seguir!), enquanto no Exemplo 3 o emissor A não retransmite nada, só o fará após estourar o relógio (timeout)! Estas duas modalidades de retransmissão timeout e retransmissão rápida terão impacto no controle de congestionamento que veremos mais à frente. Perceba a dificuldade inerente de quem tem a incumbência de prover confiabilidade (o TCP!) sobre um meio não confiável. Tal dificuldade é bem simbolizada pela metáfora dos generais bizantinos, que veremos na seção de gerência de conexão, outra parte difícil de lidar quando o meio é não confiável.

UERJ 2018 Redes de Comunicações 2 Pg. 122 A gerência de conexão apresenta uma característica simétrica no fechamento de conexão (e é também temporizada!) para reduzir o problema de perda de dados ocasionada pelo conhecido como Problema dos Exércitos Bizantinos. Neste problema ficam claras duas características de protocolos de transporte com conexão: a necessidade de sincronização e o preço de um acordo intrinsecamente não confiável entre entidades homólogas parceiras. Registre-se aqui que este problema (analisamos a seguir) junto com o problema de controle de congestionamento para tempo real (analisamos mais à frente) motivou o estabelecimento da alternativa de implementar protocolo de transporte não confiável. Em termos práticos, a maioria das aplicações da Internet se faz com protocolo confiável, TCP. Porém, algumas aplicações específicas, cada uma por suas razões específicas, se decide pelo protocolo de transporte não confiável, sem conexão, como é o caso do UDP. Estas tais aplicações são principalmente o serviço de nomes (DNS 2 ) e as aplicações multimídia. 2 Domain Name Service.

UERJ 2018 Redes de Comunicações 2 Pg. 123 O Problema dos Generais Bizantinos : Várias divisões do exército bizantino, cada qual comandada por um general, sitiam um campo inimigo. Os generais necessitam concordar ou não em atacar o inimigo de madrugada. É crucial a concordância, um ataque parcial resultará em derrota. As divisões estão dispersas e os generais podem se comunicar somente através de mensageiros. Os mensageiros podem ser interceptados pelo inimigo, assim não transmitindo suas mensagens. Isto corresponde à transmissão intrinsecamente não confiável, acarretando perda de mensagens. Alguns generais podem ser covardes ou preguiçosos, deixando de enviar ou atrasando o envio de mensagens. Alguns generais podem ser traidores, assim podem impedir os generais leais de alcançarem o consenso. Isto corresponde a processos ou o sistema de comunicação em falha, gerando mensagens inconsistentes. Existe também o aspecto da malícia. Hipóteses simplificadoras: Falha Parada: os processos falham de uma maneira limpa, parando de transmitir mensagens quando falham (fail stop). Comunicação Confiável: o sistema de comunicação somente pode perder mensagens, ou seja, não altera mensagens. Significa que as questões de malícia serão necessariamente tratadas (se o forem) nas camadas superiores. Este é o preço que se paga com TCP incluindo estas hipóteses simplificadoras. TCP, portanto, foi feito para comunicação unicast confiável não tempo real do tipo cliente-servidor (correio eletrônico, navegação Web, download/upload), e não para comunicação em grupo, ou multicast, tempo real ou com elasticidade em perdas!

UERJ 2018 Redes de Comunicações 2 Pg. 124 Estados do Cliente e Servidor no TCP:

UERJ 2018 Redes de Comunicações 2 Pg. 127 O mecanismo de controle de congestionamento do TCP usa duas entidades: CongWin e RcvByteAcked. A janela de congestionamento impõe uma limitação à taxa à qual o remetente TCP pode enviar tráfego, ou seja, a quantidade de dados não reconhecidos em um host se restrige: LastByteSent LastByteAcked = min [CongWin, RcvByteAcked } Para efeito de raciocínio simples considere RcvByteAcked grande o suficiente para não ser levado em consideração (Buffer de recepção é suficientemente grande). Nestes termos, o remetente apresenta uma taxa de envio de: ~ CongWin bytes/seg. RTT Como já vimos, o remetente percebe perdas de duas formas: ou através do timeout, ou através do recebimento de 3 ACKs duplicados para o mesmo dado. Existem dois modos de operação do controle de congestionamento: 1) Aumento aditivo, diminuição multiplicativa

UERJ 2018 Redes de Comunicações 2 Pg. 128 Se recebe ACK normal (não tem perdas), ele aumenta um pouco o CongWin: MSS MSS ( ) bytes 3 (aumento aditivo). Por exemplo, se MSS = 1460 bytes quando CongWin CongWin = 14600 bytes, então 10 segmentos são enviados dentro de 1 RTT e a cada ACK que chega, CongWin aumenta de 1 10MSS, o que significa que se dez segmentos forem reconhecidos, CongWin aumenta de 1 MSS. Esta fase de aumento linear de CongWin é chamada prevenção de congestionamento. Se se percebe perdas, com retransmissão rápida, CongWin cai à metade até chegar a 1 MSS (diminuição multiplicativa). 2) Timeout e SlowStart Quando uma conexão TCP se inicia, CongWin recebe o valor 1 MSS e a cada ACK recebido o emissor duplica CongWin até chegar-se à vazão (throuhgput) que ocorre perdas, provavelmente usando o método aí de cima. Esta é a chamada partida lenta (SlowStart). Quando no meio da transmissão ocorre timeout (e não 3 ACKs duplicados), é sinal que mudou as condições da rede e é hora de promover novo SlowStart para pesquisar o novo patamar de transmissão. O conceito do controle de congestionamento é que no Slow Start se busca rapidamente (exponencialmente) achar os limites da rede, enquanto no regime de prevenção de congestionamento se busca alcançar uma velocidade de cruzeiro. 3 MSS = Maximum Segment Size

UERJ 2018 Redes de Comunicações 2 Pg. 132 4 4 SNMP = Simple Network Management Protocol

UERJ 2018 Redes de Comunicações 2 Pg. 138 Comentários: No TCP, o cliente e o servidor trocam informações de controle da camada de transporte antes que eles troquem mensagens do nível aplicação. Este procedimento é chamado handshaking, preparando a passagem de pacotes entre processos. Após a fase de handshaking, uma conexão full-duplex entre os sockets dos dois processos fica estabelecida. Quando a aplicação termina de enviar mensagens, a conexão é interrompida. Este serviço é referido como orientado à conexão. O transporte confiável do TCP implica entrega de dados sem erros, perdas ou dados duplicados para o socket do processo destino. O mecanismo de controle de congestionamento se destina mais ao bom funcionamento da rede como um todo que aos processos comunicantes. O controle de fluxo tem efeito maior em aplicação de áudio e vídeo em tempo real. Aplicações em tempo real são tolerantes a perdas, de modo que não são realmente necessários serviços confiáveis de transporte. Por isto, muitos desenvolvedores preferem usar UDP, ao invés de TCP. UDP é um modelo de transporte minimalista. Não há handshaking entre processos. A entrega não é confiável. A boa analogia é considerar o UDP como uma

UERJ 2018 Redes de Comunicações 2 Pg. 139 longa linha de táxis esperando passageiros do outro lado da porta do emissor. O passageiro pega o táxi, este pode pegar diferentes rotas, pode quebrar, pode chegar ao destino fora de ordem. Pode também pegar engarrafamento e como não existem reconhecimentos de entrega, pode ser rápido o suficiente, apesar de também não oferecer garantias de tempo. Numa visão mais ampla da camada de transporte, podemos considerar que existem duas classes de protocolos de transporte: os orientados a fluxo (como o TCP) e os protocolos de solicitação/resposta (como o RPC Remote Procedure Call, que veremos brevemente no contexto de Sistemas Distribuídos), estes orientados a mensagens. Dentre os orientados a fluxo podemos subdividir os protocolos em duas classes: os que são confiáveis (como o TCP) e os não confiáveis (como o UDP). Os primeiros se adequam melhor às aplicações killers da Internet, como correio eletrônico, navegação Web e download de arquivos. Os segundos, os não confiáveis, são mais usados para aplicações de multimídia, como analisaremos brevemente. Textos de apoio TCP-Kurose.pdf e TCP-IBM.pdf.