Resumo do capítulo 3 [Kurose] CAMADA DE TRANSPORTE

Prévia do material em texto

Capítulo 3 – Camada de Transporte
- Técnicas utilizadas pelos protocolos para reverter os dados perdidos ou corrompidos e congestionamentos
1. INTRODUÇÃO E SERVIÇOS DE CAMADA DE TRANSPORTE
- Fornece serviços de comunicação lógica (para a aplicação é como se os hospedeiros estivessem conectados diretamente, quando podem estar distantes e com inúmeros roteadores e enlaces entre eles) entre processos de aplicação que rodam em hospedeiros diferentes;
- Os protocolos da camada de transporte são implementados nos sistemas finais e não nos roteadores da rede;
- Transforma as mensagens da camada de aplicação em pacotes – fragmentos adicionados de cabeçalhos – (segmento) da camada de transporte; e repassa para a camada de rede do sistema final (que transformará os segmentos e datagramas: roteadores só olham p o cabeçalho adicionado pela camada de rede!)
Relação entre as camadas de transporte e a de rede
Camada transporte: comunicação lógica entre processos (multiplexação/demultiplexação de camada de transporte)
Camada rede: comunicação lógica entre hospedeiros
Serviços que um protocolo de transporte pode oferecer são, geralmente, limitados pelos serviços oferecidos pelos protocolos de rede; entretanto, um protocolo de transporte pode oferecer certos serviços mesmo que os protocolos de rede não tenham um serviço equivalente;
Visão geral da camada de transporte na Internet
- Protocolos da internet: TCP – Transmission Control Protocol – (orientado a conexão, confiável) e UDP – User Datagram Protocol – (não orientado a conexão, não confiável)
- O criador de uma aplicação de rede deve escolher entre um desses dois protocolos ao criar os sockets (portas em que dados passam da rede p o processo e do processo p rede);
(REDE – protocolo IP, serviço de entrega de melhor esforço, não garante entrega, ordem, integridade, não confiável; hospedeiro tem pelo menos um end. da camada rede, end. IP);
- TCP e UDP fornecem verificação de integridade (campos de detecção de erros nos cabeçalhos)
- TCP: transferência de dados confiável – corretude e ordem (controle de fluxo, números de seqüência, reconhecimentos, temporizadores); controle de congestionamento (serviço dirigido a toda a Internet, não a aplicação solicitante) complexo
2. MULTIPLEXAÇÃO E DEMULTIPLEXAÇÃO
Ampliação do serviço de entrega hospedeiro a hospedeiro (rede) para processo a processo para aplicação que roda nesse hospedeiro (transporte)
Receptor: a camada transporte precisará direcionar a aplicação a receber os dados vindos da camada de rede. Processos podem ter um ou mais sockets.
Demultiplexação: na extremidade receptora, a camada de transporte examina os campos, que direcionam a porta correta de um segmento que chega a camada de transporte, identifica a porta e direciona o segmento a este socket.
Multiplexação: no hospedeiro de origem, reunião de dados provenientes de diferentes portas e encapsulamento com informações de cabeçalho para criar segmentos. Portas precisam ter identificadores exclusivos (16 bits: 0-1023: números de porta bem conhecidos) e cada segmento campos especiais para indicar a porta que ele deve ser entregue (campo de número de porta da fonte e campo de número de porta do destino)
Multiplexação e demultiplexação não orientadas para conexão
Hospedeiro criando uma porta UDP:
DatagramSocket mySocket = new DatagramSocket(); ou
DatagramSocket mySocket = new DatagramSocket(19157);
Socket UDP: é identificado por um tupla com dois elementos: um end. IP de destino e um número de porta de destino. O número da porta fonte é um endereço de retorno
Multiplexação e demultiplexação orientadas para conexão
Socket TCP: identificado por uma tupla de quatro elementos: end. IP da fonte, n° de porta da fonte, end. IP destino e n° de porta de destino e estabelecimento de uma conexão TCP.
Cliente TCP estabelecendo uma conexão com o servidor (cria um socket TCP para o processo cliente, através do qual os dados irão entrar e sair do processo cliente):
Socket clientSocket = new Socket (“serverHostName”, 6789);
Servidor criando uma nova conexão:
Socket connectionSocket = welcomeSocket.accept();
O servidor olha para o tupla de quatro números e todos os próximos segmentos que chegarem com esses quatro valores serão demultiplexados para esta porta. O servidor pode suportar vários sockets TCP simultâneos
Servidores Web e TCP
Servidores Web geram um novo processo (cada um com seu próprio socket) ou criam uma nova thread para cada conexão cliente (sem uma correspondência unívoca entre processo e socket, aumenta o desempenho). Obs.: HTTP persistente e não-persistente
3. TRANSPORTE NÃO ORIENTADO PARA A CONEXÃO: UDP
Protocolo de transporte simples, serviço de multip./demultiplexação e verifica erros
A aplicação praticamente fala com o IP
Mensagens do processo aplicação + campos n° porta fonte e destino + 2 campos
Não há apresentação entre remetente e destinatário
DNS é um protocolo da camada de aplicação que utiliza UDP
Porque UDP:
- não há controle de congestionamento, nem insistência no envio, assim logo que uma aplicação envia uma mensagem ela é encapsulada e colocada na rede, não tem que esperar, ideal para aplicações em tempo real, que podem admitir algumas perdas, mas não atrasos.
- não há apresentação inicial (há no TCP), não induz atrasos para estabelecer conexão
- não há estados (há no TCP) de conexão nos sistemas finais, não usa buffers/parâmetros
- a sobrecarga nos pacotes é pequena: 8 bytes (no TCP são 20 bytes)
	Aplicação
	Protocolo de aplicação
	Protocolo de transporte
	Correio eletrônico
	SMTP
	TCP
	Acesso a terminal remoto
	Telnet
	TCP
	Web
	http
	TCP
	Transferência de arquivo
	FTP
	TCP
	Servidor remoto de arquivo
	NFS
	Tipicamente UDP
	Recepção de multimídia
	Tipicamente proprietária
	Tipicamente UDP
	Telefonia por Internet
	Tipicamente proprietária
	Tipicamente UDP
	Gerenciamento de rede
	SNMP
	Tipicamente UDP
	Protocolo de roteamento
	RIP
	Tipicamente UDP
	Tradução de nome
	DNS
	Tipicamente UDP
UDP não tem controle de congestionamento, se transferências fossem altas pode haver transbordamento com muitas perdas e acúmulo de sessões TCP???
É possível que uma aplicação tenha transferência de dados confiável utilizando UDP: adiciona-se mecanismos de reconhecimento e retransmissão na própria aplicação (vantagem – não gasta o tempo do TCP e nem submete-se ao seu controle; desvantagem – tarefa não trivial).
3.1 Estrutura do segmento UDP
 Campo de dados (mensagem da aplicação) + cabeçalho (quatro campos com 2 bytes cada: porta da fonte, porta destino, comprimento B , soma de verificação(receptor verifica se há erros))
3.2 Soma de verificação UDP
Remetente realiza complemento de 1 da soma de todas as palavras de 16 bits
Destinatário soma todas as palavras de 16 bits incluindo a soma de verificação:
- sem erros = tudo 1
Não faz nada para recuperar erros encontrados, repassa com aviso ou descarta
4. PRINCÍPIOS DA TRASFERÊNCIA CONFIÁVEL DE DADOS
Um protocolo com esta característica implementa a abstração do serviço fornecido a camadas superiores é um canal de dados confiável (dados não são corrompidos, nem perdidos, nem entregues fora de ordem), quando a camada abaixo pode não ser confiável! Ex: TCP é confiável, mas é implementado sobre uma camada de rede fim-a-fim não confiável (IP)!
Remetente: rdt_send() ->utd_send()
Canal não confiável
Destinatário: rdt_rcv() -> deliver_data
Além de pacotes com dados, há trocas de pacotes de controle 
4.1 Construindo um protocolo de transferência confiável de dados
Transferência confiável de dados sobre um canal perfeitamente confiável: rdt1.0
Remetente:
Aceita dados da camada superior = rdt_send(data)
Cria um pacote com os dados = make_pkt(data)
Envia-o para o canal = udt_send(data)
Destinatário:
Recebe um pacote do canal subjacente = rdt_rcv(packet)
Transferência confiável de dados porum canal com erros de bits: rdt2.0
Mensagens de controle: reconhecimentos positivo – ACK – e negativo –NAK – provoca retransmissão ( protocolos ARQ (Automatic Repeat reQuest) exigem: detecção de erros, realimentação do destinatário (com um ACK ou com um NAK) e retransmissão.
->Protocolo pare-e-espere (stop-and-wait)
->ACKs ou NAKs comrrompidos?
- ficar pedidndo confirmações (loop infinito)
- bits suficientes p q a soma de verificação além de detectar, consiga recuperar os erros
- ACK ou NAK truncados reenvia o pacote(pacotes duplicados, mas o destinatário não sabe se um pacote que chegou é um novo pacote ou se é retransmissão! ( adiciona-se um novo campo (contendo o número de seqüência) ao pacote de dados para que o remetente enumere seus pacotes. Obs.: neste protocolo pare-e-espere um bit é sufucuente! ( rdt2.1
Eliminando o NAK, no lugar envia-se um ACK do último pacote recebido corretamente: ACKs duplicados indicam que o destinatário não recebeu corretamente o pacote seguinte equivalente aos AKCs
Transferência confiável de dados por um canal com perdas e com erros de bits: rdt3.0
Como detectar a perda de pacote e o que fazer quando isso ocorre
Soma de verificação, números de seqüência, pacotes ACKs e retransmissões resolvem o 2° Perda: o remetente detectará e se recuperará da perda, esperará algum tempo
Tempo: o ideal é o quanto mais cedo detectar a perda reenviar, difícil cálculo, a escolha é ponderada de um valor provável, se um ACK não chegar nesse intervalo o remetente retransmite
Possibilidade de pacotes duplicados (os números de seqüência lidam com isso)
Retransmissão baseada no tempo: temporizador de contagem regressiva que interrompa o processo remetente após ter decorrido determinado tempo
- aciona-se o temporizador cada vez que um pacote é enviado
- responde-se a uma interrupção feita pelo temporizador
- parar o Temporizador
Como o número de seqüência varia entre 0 e 1 -> protocolo bit alternante
4.2 Protocolos de transferência confiável de dados com paralelismo
O protocolo para-e-espere tem baixíssimo desempenho (estimativa = 30 milissegundos)
A fração de tempo em que o remetente realmente envia dados para o canal = (L/R)/(RTT + L/R)
( Tempo real = capacidade de transmissão R (1 gigabit/seg)
Tamanho de pacote L (1 kbyte/pacote)
Tempo de tranmissao = L/R = 8 microssegundos
O remetente pode enviar vários pacotes sem esperar reconhecimentos ( pipelining/paralelismo
Paralelismo:-faixa de números de seqüência ampliada
-os lados remetente e destinatário precisarão reservar buffers para mais de um
-1 e 2 dependerão da maneira como um protocolo de transferência (pode ser GO-BAck-N ou repetição seletiva) responde a pacotes perdidos, corrompidos e atrasados
4.3 Go-Back-N (GBN)
Remetente pode transmitir múltiplos pacotes, limitado por um n° máximo (N) de pacotes não reconhecidos
Base: n° de seqüência do mais antigo pacote não reconhecido
Nextseqnum: menor n° de seqüência não utilizado
Intervalos:[0, base-1] -> pacotes já transmitidos e já reconhecidos
[base, nextseqnum-1] -> pacotes já enviados, mas não reconhecidos
[nextseqnum, base+N-1]-> podem ser enviados quando estiverem disponíveis
>= base+N ( não podem ser usados até que base seja reconhecido
Janela de tamanho N (Protocolo da janela deslizante)
O limite N: o controle de fluxo é uma das razões, controle de congestionamento também
O n° de seqüência é carregado num campo fixo do cabeçalho, de k bits, assim o intervalo de valores é [0, 2k -1]
O GBN responde a três tipos de eventos:
Chamada vinda de cima (verifica se a janela está cheia (nextseqnum<base+N), se não estiver, cria pacote (ajustas variáveis, tiver, nextseqnum), se estiver devolve p camada superior)
Recebimento de um ACK (o recebimento é cumulativo, até o n° de seqüência daquele AKC recebeu todos os pacotes corretamente)
Esgotamento de temporização (envia todos os pacotes que já tinham sido enviados, mas não tinham recebido a confirmação) (temporizador para o mais antigo)
O destinatário: enviará um ACK se todos os pacotes anteriores ao pacote recebido já estiverem OK, se não descarta e reenvia um ACK para o ultimo pacote OK ( o reconhecimento cumulativo é natural para o GBN
Poderia armazenar em um buffer os que chegassem fora de ordem, mas o remetente reenviaria de todo jeito, por isso descarta -> simplicidade de buffers no destinatário
Só mantém o n° de seq do próximo pacote esperado = expectedseqnum
Obs.: o GBN incorpora quase todas as técnicas da transferência de dados confiável (n° de seqüência, reconhecimentos cumulativos, somas de verificação, operação de esgotamento de temporização/retransmissão)
4.4 Repetição seletiva (Selective Repeat - SR)
O GNB pode sofrer com problemas de desempenho (tamanho da janela e produto – atraso e largura da banda – são grandes ( retransmissões desnecessárias)
SR faz o remetente retransmitir apenas os pacotes suspeitos de terem erros ou se perdido, o destinatário deve reconhecer individualmente os pacotes recebidos corretamente
Janela de tamanho N, mas pode já haver recebido ACKs de pacotes internos a janela
Remetente:
- Dados recebidos de cima: verifica se o próximo n° de seq. está na janela, envia/devolve
- Esgotamento de temporização: cada pacote tem o seu temporizador 
- ACK recebido: marca aquele pacote, se ele for o send_base arrasta a janela até o menos pacote não reconhecido
Destinatário: Pacotes fora de ordem ficam no buffer, até que os flutuantes sejam recebidos
- Pacote com o n° de seq. no intervalo [rcv_base, rcv_base+N-1] foi corretamente recebido: está dentro da janela do destinatário, um ACK é devolvido, vai p o buffer, se for a rcv_base a janela é deslocada (de acordo com o n° de pacotes que puderam ser entregues)
- Pacote com o n° de seq. no intervalo [rcv_base - N, rcv_base - 1] recebido: envia ACK, reconhecimento duplo necessário porque a janela do remetente poderia ficar fixa
- Qualquer outro: é ignorado
A falta de sincronização entre as janelas do remetente e destinatário tem conseqüências para faixa finita de números de seqüência (o tamanho da janela pode ser <= tamanho do espaço de numeração seqüencial/2)
Os pacotes tem tempo de vida máximos (3 min) para não ressurgirem e ficar no lugar de outro por causa do n° de seqüência.
5. TRANSPORTE ORIENTADO PARA CONEXÃO: TCP
O TCP inclui detecção de erro, retransmissão, reconhecimento cumulativo, temporizadores, campos de cabeçalho para n° de seqüência e de reconhecimento.
5.1 A conexão TCP
Orientado para conexão porque há apresentação! Iniciam variáveis de estado nessa conexão
O protocolo roda apenas nos sistemas finais, assim os elementos intermediários não armazenam estados de conexão TCP
Prove um serviço full-duplex (numa mesma conexão ambos os sentidos, envia e recebe)
É sempre ponto-a-ponto (um único remetente e um único destinatário) x multicast
Processo que inicia a conexão é o processo cliente, o outro é processo servidor. A aplicação informa a camada transporte que deseja estabelecer a conexão (Socket clienteSocket = new Socket(“hostname”, portNumber)), o cliente envia um segmento especial TCP, o servidor responde com outro e o cliente envia outro (já pode conter dados da camada aplicação) = apresentação de três vias!
Estabelecida a conexão TCP, dados passam pelo socket e estão nas mãos do TCP, que os direciona para o buffer de envio, a quantidade máxima a ser retira é limitada pelo tamanho máximo do segmento // não é o tamanho máximo do segmento TCP, mas dos dados // (MSS – estabelecido pelo tamanho do maior quadro de camada de enlace que pode ser enviado - MTU)
O TCP combina: dados fornecidos do cliente com um cabeçalho TCP ( segmentos TCP e extrai: os dados do segmento armazenando-os no buffer de recepção (a aplicação lê)
TCP consiste em: buffers, variáveis e um socket de conexão em cada hospedeiro
5.2 Estrutura do segmento TCP
Campo de dados: vêm da aplicação, tamanho limitadopelo MSS (o TCP pode fragmentar os dados em vários MSSs)
Campo decabeçalho: geralmente 20 bytes, inclui: n° de porta de fonte e de destino, campo de soma de verificação, campo de n° de seqüência (32 bits, serv. conf.), n° de reconhecimento (32 bits, serv. conf.), janela de recepção (16 bits, cont, fluxo), comprimento de cabeçalho (4 bits, quantas palavras de 32 bits),campo opções do TCP (pode variar, mas normalmente é vazio, negociação do MSS, tempo ou janela), campo flag (6 bits, ACK, RST, SYN, FIN, PSH, URG)
Números de seqüência e números de reconhecimento
Fundamentais para o serviço de transferência confiável de dados do TCP
TCP vê os dados como uma cadeia de dados não estruturada, mas ordenada (numera cada byte da cedia de dados)
N° de seqüência = n° do primeiro byte do segmento
N° de reconhecimento = o n° de reconhecimento que o hospedeiro A atribui a seu segmento é o n° de seqüência do próximo byte que ele estiver aguardando do hospedeiro B.
TCP só reconhece bytes até o primeiro que estiver faltando ( reconhecimentos cumulativos
Adecisao do que fazer com pacotes que chegam fora de ordem é de quem programar a implementação TCP, porque não há nada definido (na pratica, armazena-se)
Telnet: um estudo de caso para números de seqüência e números de reconhecimento
Hoje, prefere-se ssh, porque o telnet não utiliza criptografia
TCP usa piggypack (carona) uma confirmação é feita junta de um segmento de dados
5.3 Estimativas do tempo de viagem de ida e volta e de esgotamento de temporização
O TCP usa um mecanismo de controle de temporização/retransmissão para recuperar segmentos perdidos
Duração dos intervalos: maior que o RTT (qual o RTT, quanto maior)
Estimativa do tempo de ida e volta
RTT (SampleRTT) = quantidade de tempo transcorrido entre o momento que o segmento é enviado (passado ao IP) (s/ retransmissão)e o momento em que é recebido um reconhecimento. O TCP fica calculando, variações ocorrem, calcula uma média (móvel exponencial) ponderada
EstimatedRTT = (1-alfa)*EstimadedRTT + alfa*SampleRTT (alfa = 0,125 = 1/8)
DevRTT (variação RTT) = (1 - beta)*DevRTT + beta*|SampleRTT–EstimatedRTT| (beta=0,25) 
Obs.: TCP usa NAK implícito = três ACKs duplicados e paralelismo (o n° máximo de segmentos não reconhecidos é determinado pelos mecanismos de controle de fluxo e de congestionamento)
Estabelecimento e gerenciamento da temporização e retransmissão
EstimatedRTT + margem (proporcional ao DevRTT)
TimeoutInterval = EstimatedRTT + 4*DevRTT
5.4 Transferência confiável de dados
Com o serviço IP os datagramas podem ser perdidos, chegar fora de ordem, ser corrompidos
O TCP cria um serviço de transferência confiável de dados sobre este serviço de melhor esforço do IP, e garante que a cadeia de dados que a aplicação lê a partir do seu buffer de recebimento TCP não está corrompida, não tem lacuna, não tem duplicação e está em ordem!
Temporizador para cada segmento pode exigir sobrecarga, usa-se um único temporizador de retransmissão!
Usa apenas temporizadores para retransmissão
Usa temporizadores e reconhecimentos duplicados 
Eventos no remetente:
- dados recebidos da aplicação acima (se o temporizador não estiver ativado, é ativado)
- esgotamento do temporizador (reenvio do menor n° de seq. e inicializa o temporizador)
- recebimento de ACK (atualiza a send_base para y e reinicia o temporizador)
Alguns cenários interessantes 
ACK perdido, haverá reenvio (quando o temporizador esgotar), o destinatário receberá dado duplicado, descartará e reenviará o ACK
Remetente envia dois segmentos seguidos, o destinatário recebe e envia dois ACKs separados, mas eles atrasam. O primeiro segmento será retransmitido quando o temporizador esgotar, se os ACKs chegarem antes do temporizador esgotar de novo o segundo segmento não será retransmitido!
Remetente envia dois segmentos seguidos, o destinatário recebe e envia dois ACKs, o primeiro é perdido, se o segundo chegar antes do tempo esgotar não haverá reenvio!
Duplicação do tempo de expiração
Quando o tempo é esgotado o TCP reenvia o pacote com menos n° de seqüência e ajusta o tempo de expiração para o dobro de tempo do anterior. O tempo aumenta exponencialmente a cada expiração. A causa mais provável da expiração é o congestionamento ( o TCP demorará mais para retransmitir
Mas quando o temporizador é iniciado por ter recebido dados da aplicação ou ACK o TimeoutInterval é derivado dos valores de EstimatedRTT e DevRTT
Retransmissão rápida
O remetente pode detectar a perda de um pacote antes do timeout (pode demorar muito) analisando os ACKs duplicados
	Evento
	Ação do TCP destinatário
	Chegada de um segmento esperado, na ordem, mas todos anteriores já reconhecidos
	ACK retardado (espera 500 milisseg. e envia)
	Chegada de um segmento esperado, mas outro segmento esperando p enviar ACK
	Envio imediato de um ACK acumulativo
	Chegada de um segmento fora de ordem, n° de seq. maior que o esperado
	Envio imediato de um ACK duplicado com o n° de seq. esperado
	Chegada de um segmento que preenche parte da lacuna
	Envio de um ACK se este segmento começar na extremidade mais baixa
Se o remetente receber três ACKs duplicados é indicação que o segmento posterior ao segmento reconhecido três vezes foi perdido e o TCP remetente realiza uma retransmissão rápida, antes que o temporizador expire 
GBN ou repetição seletiva?
Semelhanças c GNB: reconhecimento cumulativo e segmentos fora de ordem corretamente recebidos não são reconhecidos individualmente, só precisa lembrar o menor n° de seqüência não reconhecido e o n° de seqüência do byte a ser enviado
Diferenças c GNB: TCP pode armazenar segmentos fora de ordem, o GNB pode ter que retrasmitir grande quantidade de dados se um ACK se perder, enquanto que o TCP pode nem precisar retransmitir se um ACK de um segmento posterior retornar antes do timeout! 
Semelhança c SR: o reconhecimento seletivo permite que o TCP reconheça seletivamente segmentos fora de ordem
O mecanismo de recuperação de erros do TCP é hibrido dos protocolos GNB e SR
5.5 Controle de fluxo
Hospedeiros de cada lado de uma conexão TCP reservam um buffer de recepção, quando os bytes estão corretos e na seqüência são colocados neste buffer e a aplicação lerá daí, isso pode demorar e, assim, o buffer pode ser saturado, para evitar isso o TCP tem o controle de fluxo
É um serviço de compatibilização de velocidades (taxas de envio e q aplicação receptora lê)
Controles de fluxo e de congestionamento regulam o remetente, mas têm propósitos distintos
Remetente mantém uma variável, janela de recepção (RcvWindow), que dá uma idéia do espaço de buffer disponível no destinatário
O receptor aloca um buffer de recepção com o tamanho RcvBuffer
Variáveis no destinatário:
- LastByteRead = n° do último byte lido do buffer pela aplicação do receptor
- LastByteRcvd = n° do último byte que chegou no buffer do receptor
Variáveis no remetente:
- LastByteSent
- LastByteAcked
Deve-se ter: 	LastByteRcvd – LastByteRead <= RcvBuffer
RcvWindow = RcvBuffer – (LastByteRcvd – LastByteRead)
LastByteSent – LastByteAcked <= RcvWindow
Processo: remetente diz ao destinatário qual o espaço do seu buffer colocando RcvWindow no campo de janela de recepção, inicialmente o destinatário estabelece RcvWindow = RcvBuffer
Problema: quando a RcvWindow for igual a 0 ( mesmo que o processo com aplicação esvazie o buffer o remetente não saberá disso porque o TCP não envia novos segmentos com o novo valor de RcvWindow para o remetente, para resolver o remetente deve continuar enviando segmentos com um byte de dados quando a janela de recepção for 0!
5.6 Gerenciamento da conexão TCP
O estabelecimento da conexão tem pesa nos atrasos. O estabelecimento: o processo cliente informa ao TCP cliente que quer estabelecer uma conexão com um processo servidor, o TCP faz
- lado cliente do TCP envia um segmento especial (sem dados da aplicação, o bit SYN éativado) ao lado servidor do TCP e escolhe um n° de seq. inicial (client_isn) já indicando no cabeçalho deste segmento, chamado SYN
- o servidor, quando receber o SYN, alocará buffers e variáveis TCP para esta conexão e envia segmento de aceitação (sem dados, SYN ativado, campo de reconhecimento = client_isn + 1, server_isn), este segmento é chamado de SYNACK
- o cliente reserva buffers e variáveis e envia mais um segmento (campo de reconhecimento = server_isn + 1, SYN desativado, pode conter dados)
Essa é a apresentação de três vias
Qualquer um do hospedeiros podem encerrar a conexão, que quando acaba libera as variáveis e os buffers
- o processo que deseja encerrar envia um segmento (FIN ativado)
- o outro hospedeiro emite uma confirmação ACK
- esse mesmo hospedeiro envia outro segmento com FIN ativado
- o outro hospedeiro (que iniciou o fechamento da conexão) envia um ACK
Estados do TCP
Cliente = CLOSED (inicia uma nova conexão criando um socket) envia SYN SYN_SENT recebe SYNACK e envia ACK ESTABLISHED pode enviar e receber segmentos TCP de dados, se quiser fechar a conexão envia segmento FIN -> FIN_WAIT_1-> recebe ACK -> FIN_WAIT_2 -> recebe segmento FIN e envia ACK ( TIME_WAIT ( reenvia o ACK final se tiver sido perdido (tempo 30, 60 ou 120 seg) 
Servidor = CLOSED ( aplicação cria uma porta de escuta ( LISTEN ( recebe SYN e envia SYNACK ( SYN_RCVD ((recebe ACK, não envia nada) ( ESTABILISHED ( recebe FIN, envia ACK ( CLOSE_WAIT ( envia FIN ( LAST_ACK ( recebe ACK
6. PRINCÍCPIOS DE CONTROLE DE CONGESTIONAMENTO
Causa: demasiadas fontes tentando enviar dados a uma taxa muito alta, mecanismos para regular os remetentes
6.1 As causas e os custos do congestionamento
Cenário 1: dois remetentes, um roteador com buffers infinitos
Remetentes A e B compartilham um único trecho de rede entre a fonte e o destino, A envia dados a uma taxa média de λin bytes/seg.. O protocolo de transporte não tem recuperação de perdas, controle de fluxo, nem de congestionamento. Desprezando-se sobrecargas a taxa que A oferece ao roteador os seus dados é λin bytes/seg. B é igual. Os pacotes passam por um roteador e um enlace de saída compartilhado de capacidade R. A vazão por conexão é igual a λin desde que λin seja <= R/2, quando maior a vazão é igual a R/2, entretanto quando se trabalha com taxas próximas a capacidade máxima da rede, o atraso médio fica cada vez maior e tende ao infinito (bom para vazão, péssimo para o atraso).
Custo da rede congestionada: há grandes atrasos de fila quando a taxa de chegada dos pacotes se aproxima da capacidade do enlace. 
Cenário 2: dois remetentes, um roteador com buffers finitos
Há descarte de pacotes quando o buffer já está cheio, mas há retransmissão dessas perdas, assim a taxa de envio da aplicação ao socket é λin, mas a taxa que a camada de transporte envia os segmentos (carga oferecida a rede) é λin` 
Se λin = λin` (só envia c roteadores livres) ( caso 1, mas sem ultrapassar R/2 (haveria perda)
Com retransmissões, se λin` = R/2 ( λout = R/3
Custo da rede congestionada: remetente deve realizar retransmissões para compensar os pacotes perdidos devido ao esgotamento do buffer Caso em que não houve perda, apenas atraso, mas há retransmissão: trabalho desperdiçado
Custo da rede congestionada: retransmissões desnecessárias 
Cenário 3: quatro remetentes, roteadores c buffers finitos, trajetos c múltiplos roteadores 
Para valores pequenos de λin os valores de λout acompanham
Situação em que um roteador deve dividir entre uma conexão direta – com alta taxa – e outra conexão que já passou por outro roteador e tem valores limitados será reduzida mais pode ir a zero se houver esgotamento do buffer! O trabalho do roteador já passado é descartado se houver perda num roteador seguinte
Custo da rede congestionada: descarte de pacotes e desperdício da transmissão já utilizada
6.2 Mecanismos de controle de congestionamento
Distinção: a camada de rede oferece ou não assistência ao controle explicita à de transporte
- controle de congestionamento fim-a-fim: não há assistência (nem indica se há) da camada de rede (IP), a perda de segmentos TCP (temporização, 3 ACKs duplicados) indicam o congestionamento (usa também o aumento dos atrasos de ida e volta), reduz-se a janela
- controle de congestionamento assistido pela rede: os roteadores fornecem informações ao remetente sobre o estado de congestionamento da rede (pode ser simples). Realimentação direta: pacote de congestionamento ou marcação em um pacote que está fluindo para o destinatário leva pelo menos uma viagem de ida e volta. 
7. CONTROLE DE CONGESTIONAMENTO TCP
Usa controle de congestionamento fim-a-fim
Obriga cada remetente a limitar a sua taxa de envio como uma função do congestionamento de rede percebido (Como o remetente limita? Como percebe? Qual o algoritmo dessa função?)
Contexto do algoritmo Reno
Variável adicional nos hospedeiros: janela de congestionamento (CongWin), limitação a taxa de envio de um remetente, deve-se ter:
LastByteSent – LastByteAcked <= min (CongWin, RcvWindow)
Análise desprezando a limitação da janela de recepção
A taxa de envio do remetente é de CongWin/RTT (ajusta CongWin ( ajusta a taxa)
Detecta congestionamento: perdas de pacotes
Quando o TCP percebe que os pacotes estão chegando corretamente (através dos reconhecimentos) aumenta o CongWin ( TCP é auto-regulado
Algoritmo de controle do congestionamento do TCP (tem três componentes):
Aumento aditivo, diminuição multiplicativa
Idéia básica: remetente reduzir taxa de envio (reduzindo CongWin) se há perda
Reduz à metade o valor de CongWin após um evento de perda (valor mínimo = 1 MSS)
O aumento da janela é gradativo, cada vez que recebe um reconhecimento aumenta 1MSS a cada tempo de viagem de ida e volta, fase de aumento linear é prevenção de congestionamento
Partida lenta
No inicio de uma conexão TCP, CongWin = 1 MSS, taxa inicial de envio = MSS/RTT
Esperar um crescimento considerável de CongWin demoraria muito, assim, na fase inicial ao invés de aumentar a taxa linearmente, o valor de CongWin é duplicado a cada RTT (exponencialmente) até uma perda cortá-la ao meio e a partir daí crescer linearmente
Reação a eventos de esgotamento de temporização
TCP reage diferente a eventos de perda detectados por ACKs ou pela temporização esgotada
Com ACKs reage como já descrito (corta no meio e cresce linearmente)
Com esgotamento o TCP entra numa fase de partida lenta (CongWin = 1 MSS, cresce exponencialmente até alcançar metade do valor que tinha antes do evento de esgotamento e passa a crescer linearmente)
Para isso o TCP mantém a variável Threshold indica onde a partida lenta terminará (não tem efeito inicial, ajustada com alto valor) recebe metade do valor de quando ocorreu o esgotamento
Obs.: o Tahoe (versão antiga) cortava sempre para 1 MSS. Reno considera que se há ACK algum segmento chegou! (eliminação da partida lenta após três ACKs = recuperação rápida)
Descrição macroscópica da dinâmica do TCP
Tamanho da janela = w bytes
Tempo de viagem de ida e volta = RTT
Taxa de transmissão ~= w/RTT
W = w quando ocorre uma perda
Taxa de transmissão ~= W/2*RTT, W/RTT
Vazão média de uma conexão = 0,75*W/RTT
TCPs futuros
L = taxa de perda
Vazão média de uma conexão = 1,22*MSS/ (RTT * raiz(L))
7.1 Justiça
Um mecanismo de controle de congestionamento é justo se a taxa média de trasmissao de cada conexão for = taxa de transmissão do enlace/n° de conexões TCP
TCP resulta em igual compartilhamento da largura de banda, as sessões cujos RTTs são menores conseguem obter largura da banda disponível mais rapidamente
Justiça e UDP
UDP usa uma taxa constante e ocasionalmente perde pacotes
Busca-se desenvolver mecanismos que impeçam que segmentos UDPs dominem o tráfego
Justiça e conexões TCP paralelas
Mesmo controlando o UDP, nada impede que uma aplicação rode sobre TCPs paralelos
7.2 Modelagem do atrasoTCP
Tempo para o TCP enviar um objeto (consideramos uma rede n congestionada e c 1 enlace)
Latência: tempo que o cliente inicia uma conexão e recebe o objeto completo (componentes fundamentais: apresentação inicial do TCP, a partida lenta e o tempo de transmissão do objeto)
Considerações:
- quantidade de dados a serem transmitidos limitada só pela janela de cong. remetente
- pacotes não perdido, nem corrompidos, não há retransmissão
- sobrecargas de cabeçalhos desprezadas
- o tamanho do objeto (O bits) é um múltiplo do MSS (S bits)
- pacotes sem tempo de transmissão n desprezíveis: segmentos TCP tamanho máximo
- taxa de transmissão do enlace R bps
Sem janela ( latência = 2 RTT + O/R
Janela de congestionamento estática TCP usa dinâmica
Tamanho da janela = W (servidor não pode ter mais que W segmentos não reconhecidos)
1) WS/R > RTT + S/R ( servidor recebe reconhecimento antes de completar o envio da janela; latência = 2RTT + O/R
2) WS/R > RTT + S/R ( envia a janela toda antes de receber um reconhecimento
K = O/WS
Duração de cada período de suspensão = RTT – (W – 1)S/R
Latência = 2RTT + O/R + (K - 1) [S/R + RTT – WS/R]
Janela de congestionamento dinâmica
A cada reconhecimento o servidor duplica o tamanho da janela
A k-ésima janela contém: 2k-1segmentos 
K (número de janelas que abrangem o objeto) = teto (log2((O/S) + 1))
Tempo de suspensão = min ([S/R + RTT - 2k-1 (S/R)], 0 )
Latência = 2 RTT + O/R + Somatório[k=1, k-1] (S/R + RTT - 2k-1S/R)+
N° de vezes que entra em suspensão //Q = chão (log2(1 + RTT/(S/R))) + 1// (P) = min (Q, K-1)
Latência = 2 RTT + O/R + P[S/R + RTT] – (2p –1) S/R
Obs.: a partida lenta não aumentara de maneira significativa a latência se RTT << O/R; para RTT maiores o efeito da partida lenta torna-se significativo para objetos pequenos para velocidades de transmissões menores