capítulo 23 comunicação entre processos
DESCRIPTION
TRANSCRIPT
23.1
Capítulo 23
Comunicação entre
Processos:
UDP e TCP
Prof. Rodrigo Ronner [email protected]
rodrigoronner.blogspot.com
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
23.2
23-1 Comunicação entre Processos
A camada de transporte é responsável pelo processo a processo de
entrega a entrega de um pacote, que faz parte de uma mensagem, de
um processo para outro. Dois processos se comunicam em uma
relação cliente / servidor, como veremos :
Paradigma Cliente/Servidor
Multiplexação e Demultiplexação
Serviços sem conexão Versus Orientando a Conexão
Confiável Versus Não-confiável
Três Protocolos
Topicos Discutidos:
23.3
A camada de transporte é responsável
pela comunicação entre processos.
Note
23.4
Figure 23.1 Tipos de comunicação de dados
23.5
23-1 Paradigma Cliente/Servidor
• Embora existam várias maneiras de se realizar a comunicação entre processos, a mais comum
delas é por meio do paradigma cliente/servidor.
• Um processo no host local, denominado cliente, solicita serviços a outro processo, normalmente
localizado no host remoto, denominado servidor.
• Ambos os processos (cliente e servidor) têm o mesmo nome. Por exemplo, para obtermos o dia e
horário de uma máquina remota, precisamos de um processo cliente denominado Daytime, em
execução no host local e um processo servidor Daytame, em execução em uma máquina remota.
• Os sistemas operacionais atuais oferecem suporte tanto a ambientes multiusuários como
multiprogramação.
• Um computador remoto pode executar vários programas servidor simultaneamente, da mesma
forma que computadores locais podem executar um ou mais programas clientes.
1 – Host Local
2 – Processo Local
3 – Host remoto
4 – Processo remoto
23.6
23-1 Endereçamento
• Toda vez que precisamos transmitir algo para um destino específico entre vários existentes,
necessitaremos de um endereço.
• Na camada de enlace de dados, utilizaremos o endereço MAC para escolher um nó entre vários
nós.
• Na camada de Rede, utilizaremos o endereço IP para escolher um host entre milhões. Um
datagrama na camadada de Rede precisa de um endereço IP de destino para sua entrega e de
um endereço IP de origem para a resposta do destino
• Na camada de transporte, utilizaremos o endereço de camada de transporte, denominado
número de porta , para escolher entre vários processos que estão em execução no host de
destino. O número da porta de destino é necessário para entregar; o número de porta de origem
é necessário para resposta.
• Um computador remoto pode executar vários programas servidor simultaneamente, da mesma
forma que computadores locais podem executar um ou mais programas clientes.
1 – Host Local
2 – Processo Local
3 – Host remoto
4 – Processo remoto
23.7
Figure 23.2 Port numbers
23.8
Figure 23.3 Endereço IP versus números de portas
23.9
Figure 23.4 IANA Faixa
23.10
23-5 Endereços Socket
• Para se estabelecer uma conexão virtual que permita a comunicação entre processos finais,
necessitamos de dois identificadores, o endereços IP e o número da porta.
• A combinação entre um endereço IP e um número de porta é conhecida como endereço socket.
• O endereço socket no cliente define o processo cliente de forma exclusiva, da mesma forma que
o endereço socket no servidor estabelece o processo servidor de modo exclusivo(ver a figura
23.5)
• Os protocolos da camada de transporte precisa de um par de endereços socket: o endereço
socket no cliente e o endereço socket no servidor.
• Essas informações fazem parte do cabeçalho IP e do cabeçalho do protocolo de camada de
transporte.
• O cabeçalho IP contém os endereços IP; o cabeçalho UDP ou TCP contém os números das
portas.
23.11
23-1 Multiplexação e Demultiplexação
• Multiplexação
No lado do emissor, podem existir vários processos que precisem transmitir
pacotes. Entretanto, há somente um protocolo de camada de transporte em
execução em dado instante.
Trata-se de uma relação um vários-para-um e que requer a multiplexação.
• Demultiplexação
No lado receptor, a relação é de um-para-vários e requer demultiplexação. A
camada de transporte recebe os datagramas da camada de rede. Após verificação
de erros e a eliminação do cabeçalho, a camada de transporte entrega cada
mensagem para o processo usuário apropriado baseado no número de portas.
23.12
Figure 23.6 Multiplexação e Demultiplexação
23.13
Figure 23.7 Error control
23.14
Figure 23.8 Position of UDP, TCP, and SCTP in TCP/IP suite
23.15
23-2 USER DATAGRAM PROTOCOL (UDP)
O User Datagram Protocol (UDP) é chamada de sem conexão,
protocolo de transporte não confiável. Ele não adiciona nenhum
controle adicional aos serviços de entrega IP, exceto pelo fato de
implementar a comunicação entre processos, em vez da comunicação
entre hosts. Da mesma forma, a verificação de erros é implementada
de forma muito limitada.
Portas conhecidas no UDP
Datagramas de Usuários
Checksum
Operação do UDP
Uso do UDP
Topicos Discutidos:
:
23.16
Table 23.1 Well-known ports used with UDP
23.17
• Em UNIX, as portas conhecidas são armazenados em um arquivo
chamado / etc / services. • Cada linha neste arquivo dá o nome do servidor e o número de porta
conhecido.
• Podemos usar o grep utilitário para extrair a linha correspondente à
aplicação desejada. • O seguinte mostra a porta para o FTP. Note-se que FTP pode usar a
porta 21 com UDP ou TCP.
Example 23.1
23.18
Example 23.1 (continued)
SNMP usa dois números de porta (161 e 162), cada um para uma finalidade
diferente,
23.19
23-2 Datagramas de Usuário
Os pacotes UDP, denominados datagramas de usuário, possuem um cabeçalho de tamanho fixo 8
bytes.
Portas origem: Esse campo especifica o número da porta usada pelo processo em execução no host
de origem.
Ele tem 16 bits de comprimento, significando que o número da porta pode variar de 0 a 65535.
Portas destino: Esse campo especifica o número da porta usado pelo processo em execução no host
de destino. Ele também tem 16 bits de comprimento.
• Se o host de destino for um servidor (um cliente transmitindo uma solicitação), o número da
porta, na maioria dos casos, é um número de porta conhecido.
• Se o host de destino for um cliente (um servidor transmitindo sua resposta), o número da
porta, na maioria das vezes, é um número de porta efêmero.
Comprimento: Esse campo de 16 bits define o comprimento total de um datagrama UDP,
compreendendo cabeçalho mais dados. Os 16 bits podem definir um comprimento total entre 0 a 65535
bytes. Entretanto, o comprimento total deve ser menos, pois um datagrama UDP deve ser repassado
em um datagrama IP de comprimento total igual a 65535 bytes.
Checksum: Esse campo de 16 bits é usado para detectar erros na transmissão de datagrama UDP
(Cabeçalho mais dados).
23.20
Figure 23.9 Formato de um datagrama UDP
23.21
Comprimento de um datagrama UDP=
Comprimento total IP – Comprimento do
cabeçalho IP
Note
Serviços sem conexão: Isso significa que cada datagrama de usuário enviado pelo UDP é um datagrama independente. Não existe nenhuma relação entre os diferentes datagramas de usuário, mesmo se eles forem provenientes do mesmo processo de origem e tiverem o mesmo programa de destino.
• Os datagramas não são enumerados;
• Não existe mecanismo para estabelecer e/ou terminar uma conexão virtual, ao contrário do que acontece com o TCP.
23.22
Operação do UDP
Controle de Fluxo e de erros: UDP é um protocolo de transporte muitos simples e não confiável. Não implementa controle de fluxo e, portanto, nenhum mecanismo de janelamento. O Receptor pode ser inundado com um número excessivo de mensagens que chegam a ele.
• Não implementa controle de erros exceto checksum, Isso significa que o emissor não sabe se uma mensagem foi perdida ou duplicada.
• Quando receptor detecta um erro por meio do cheksum, o datagrama de usuário é descartado de maneira imperceptível.
• A ausência de controle de fluxo e de controle de erros significa que um processo de aplicação usando UDP deve implementar esses mecanismos.
23.23
Operação do UDP
Encapsulamento e Desencapsulamento: Para transmitir uma mensagem de um processo a outro, o protocolo UDP encapsula e desencapsula mensagens em um datagrama IP.
Formação de Filas: Quando um processo no lado cliente é iniciado, este solicita para o sistema operacional um número de porta. Algumas implementações criam tanto uma fila de chegada como uma de saída associada a cada processo, outras criam apenas uma fila de chegada associada a cada processo.
• Mesmo que um processo quiser se comunicar com vários processos, ele obterá apenas um número de porta e, finalmente, uma fila de chegada e outra de saída.
• As filas abertas pelo cliente são, na maioria dos casos, identificadas pelos números de porta efêmeros.
• As filas funcionam enquanto o processo está em execução. Quando processo termina, as filas são desalocadas da memória.
23.24
Operação do UDP
23.25
Figure 23.12 Queues in UDP
O UDP é adequado para um processo que requeira comunicação solicitação-resposta simples com pouca preocupação com controle de erros e de fluxo.
O UDP é adequadp para um processo que implemente mecanismos internos de controle de fluxo e de erros. Por exemplo TFTP (Trivial File Transfer Protocol) implementa mecanismos internos de controle de fluxo e de erros. Ele pode usar o UDP de maneira fácil.
O UDP é muito utilizado no gerenciamento de redes, protocolo SNMP.
O UDP é usado em alguns protocolos de roteamento para atualização de rotas como o RIP.
23.26
Uso do UDP
23.27
23-3 TCP
O TCP é um protocolo orientado a conexão, ele cria
uma conexão virtual entre dois TCPs para enviar
dados. Além disso, o TCP utiliza o fluxo e mecanismos
de controle de erros no nível de transporte.
Serviços TCP
Características TCP
Segmentos
Conexão TCP
Controle de Fluxo
Controle de Erro
Topicos Discutidos:
23.28
Tabela 23.2 Portas conhecidas TCP
O TCP, diferente do UDP, é um protocolo orientado a fluxo de dados.
No UDP, um processo envia mensagens, com delimitadores predefinidos, para o UDP, para serem transmitidas.
O UDP acrescenta seu próprio cabeçalho a cada uma dessas mensagens e as entregas para transmissão pelo IP.
Cada mensagem do processo é denominado datagrama de usuário e se torna, finalmente, um datagrama IP.
Nem o IP nem o UDP estabelecem relação entre os datagramas.
23.29
Serviço de Entrega de Fluxo de dados
23.30
Figure 23.13 Entrega de Fluxo de Dados
• O TCP possibilita a um processo enviar dados Na forma de um fluxo de bytes.
• O TCP cria um ambiente no qual os dois processos Parecem estar conectados
por um “canal” imaginário Que transporta dados pela internet.
Como existe a possibilidade dos processos de transmissão e de recepção não gerarem ou lerem dados em uma mesma velocidade, o TCP precisa de Buffers para seu armazenamento;
Existem dois buffers, um buffer de transmissão e um buffer de recepção, um em cada direção;
Uma forma de implementar um buffer é usar uma matriz circular de posições.
23.31
Buffers de transmissão e Recepção
EMISSOR:
No lado emissor, o buffer possui três tipos de câmaras.
A parte branca na figura 23.14 contém câmaras vazias que podem ser preenchidas pelo processo transmissor.
A área cinza armazena bytes que foram enviados, mas ainda não confirmados pelo receptor.
O TCP mantém esses buffers até o receber uma confirmação.
A área colorida contém bytes a serem enviados pelo transmissor TCP.
RECEPTOR:
A operação no buffer no lado do receptor é mais simples.
O buffer circular é dividido em duas áreas (segmentos brancos e coloridos).
O segmento branco possui câmaras vazias a serem preenchidas por bytes recebidos da rede.
As seções coloridas contém bytes recebidos que podem ser lido pelo processo receptor.
Quando um byte é lido pelo processo receptor, a câmara é limpa e acrescentado ao pool de câmaras vazias.
23.32
Buffers de transmissão e Recepção
23.33
Figura 23.14 Buffers de transmissão e recepção
Embora o sistema de buffers trate da disparidade entre as velocidades dos processos de geração e leitura de dados, precisamos de mais um passo antes de podermos efetivamente transmitir dados.
A camada IP, como provedora de serviço para o TCP, precisa enviar dados em pacotes, não na forma de um fluxo de bytes.
Na camada de transporte, o TCP agrupa determinado número de bytes em pacotes, denominados segmentos.
O TCP acrescenta um cabeçalho a cada segmento (para fins de controle) e entrega o segmento para a camada IP para sua transmissão.
Os segmentos são encapsulados em datagramas IP e transmitidos.
23.34
Segmentos
23.35
Figura 23.15 Segmento TCP
O TCP oferece serviços full duplex no qual dados podem fluir em ambos as direções simultaneamente;
Cada processo TCP implementa um buffer de transmissão e um de recepção e os segmentos trafegam e ambas as direções.
23.36
Comunicação Full-Duplex
O TCP, diferente do UDP, é um protocolo orientado a conexão. Quando um processo no ponto A quer enviar e receber dados de outro processo no ponto B, ocorre o seguinte:
Os dois processos TCPs estabelecem uma conexão entre eles;
Os dados são trocados em ambos os sentidos;
A conexão é encerrada.
Observe que esta é uma conexão virtual, e não uma conexão física;
Um segmento TCP é encapsulado em um datagrama IP e pode ser recebido fora de ordem, perdido ou corrompido e, em seguida, precisa ser reenviado;
Cada um deles pode ser transmitido por um caminho diferente até atingir o destino;
Não existe conexão física;
O TCP cria um ambiente orientado a fluxo de dados no qual ele assume a responsabilidade de entregar na ordem correta os bytes para outro ponto.
23.37
Serviços Orientados a conexão
Sistema de numeração:
Embora o software TCP mantenha controle sobre os segmentos que estão sendo transmitidos ou recebidos, não há nenhum campo especifico para indicar o número de um segmento no cabeçalho.
Em vez disso, existem dois campos genéricos denominados de número de sequência e número de confirmação.
Esses dois campos de referem ao número de bytes e não o número do segmento.
Número de Bytes:
Este se refere à quantidade de bytes de dados TCP que são transmitidos em uma conexão.
A numeração é independente para cada sentido de transmissão.
Quando o TCP recebe bytes de dados de um processo, ele os armazena no buffer de transmissão e os numera.
A numeração não é iniciada necessariamente, a partir de 0. Em vez disso, o TCP gera um número randômico entre 0 e 2^32 – 1 como número inicial para primeiro byte.
Por exemplo, se por acaso o número randômico for 1.057 e o total de dados a serem transmitidos for 6.000 bytes, os bytes são numerados de 1.057 a 7.056.
23.38
Recursos do TCP
Número de sequência:
Após os bytes terem sido numerados, o TCP atribui um número de sequência para cada segmento que está sendo transmitido.
O número de sequência para cada segmento é identificado pelo número do primeiro byte transportado no segmento.
Exemplo 23.3
Suponha que uma conexão TCP esteja transferindo um arquivo de 5.000 bytes. O primeiro deles recebe a numeração 10.001. Quais são os números de sequência para cada segmento se os dados foram enviados em cinco segmento, cada um deles transportando 1.000 bytes?
23.39
Recursos do TCP
23.40
A seguir, são apresentados os números de sequência de
cada segmento:
Example 23.3
Número de Confirmação:
Cada parte enumera os bytes, normalmente, com um número de byte inicial diferente.
O número de sequência em cada direção identifica o número do primeiro byte transportado pelo segmento.
Cada parte também usa um número de confirmação para confirmar os bytes que recebeu.
Entretanto, o número de confirmação identifica o número do próximo byte que a parte espera receber.
Além disso, o número de confirmação é cumulativo, significa que a parte pega o número do último byte recebido, são e salvo, incrementa 1 a ele e anuncia essa soma como número de confirmação.
O termo cumulativo, nesse caso, significa que, se uma parte usa 5.643 como número de confirmação, ela recebeu todos os bytes do inicio até 5.642. Note que isso não significa que a parte tenha recebido 5.642 bytes, porque o número do primeiro byte nem sempre começa em 0.
23.41
Recursos do TCP
Controle de Fluxo:
O TCP, diferente do UDP, implementa controle de fluxo. O receptor pode controlar a quantidade de dados que é enviada pelo emissor.
Isso é feito para evitar que o receptor fique sobrecarregado com uma quantidade excessiva de dados.
O sistema de controle de sequência possibilita que o TCP use um controle de fluxo orientado a bytes.
Controle de Erros:
Para fornecer um serviço de transporte confiável, o TCP implementa controle de erros.
Embora controle de erros considere o segmento como a unidade de dados para fins de detecção de erros (segmento corrompido ou perdido), o controle de erros é orientado a bytes.
Controle de Congestionamento:
O TCP, diferente do UDP, leva em conta o nível de congestionamento da rede.
A quantidade de dados que podem ser transmitidos por um emissor não é controlada apenas pelo receptor (controle de fluxo), mas também pelo nível de congestionamento na rede.
23.42
Recursos do TCP
23.43
Figure 23.16 O Formato de um segmento TCP
Endereço de porta de Origem/Destino :
Trata-se um campo de 16 bits que identifica o número da porta do programa de aplicação tanto no host emissor como no host receptor.
Número de sequência:
Identifica a posição deste segmento no fluxo de dados e cada conexão possui um fluxo de dados particular
Número de confirmação:
Utilizado para confirmar o recebimento de segmentos enviados anteriormente e especifica o próximo segmento aguardado
Comprimento do cabeçalho:
Esse campo de 4 bits identifica a quantidade de palavras de 4 bytes de um cabeçalho.
O comprimento do cabeçalho tem entre 20 e 60 bytes. Consequentemente, o valor desse campo pode ser entre 5 (5x4=20) e 15 (15x4=60).
Reservado:
Trata-se de um campo de 6 bits reservado para uso futuro.
Controle:
Esse campo define 6 bits de controle (flags) distintos.
23.44
Cabeçalho TCP
23.45
Figure 23.17 Control field
23.46
Table 23.3 Description of flags in the control field
Tamanho da Janela:
Esse campo define o tamanho de uma janela TCP, em bytes, que a outra parte deve manter, observe que o comprimento desse campo é de 16 bits, significando que o tamanho máximo de uma é de 65.535 bytes.
Normalmente, esse valor é conhecido como janela receptora (rwnd) e é determinado pelo receptor.
Nesse caso, o emissor deve obedecer àquilo que está configurado pelo receptor.
Checksum:
Verificação de erros
Urgent Point:
É válido apenas se a flag URG (Urgente) estiver ativo, é usado quando um segmento contém dados urgentes.
Opções:
Esse campo pode conter um total de até 40 bytes de informações opcionais que serão inclusas ao cabeçalho TCP. ( Não trataremos dessas opções aqui; consulte a lista de referência para mais informações).
23.47
Cabeçalho TCP
Estabelecimento da conexão:
O TCP transmite dados no modo full-duplex.
Quando dois processos TCPs em duas máquinas estão conectados, eles estão aptos a transmitir segmentos entre si, simultaneamente.
Isso implica que cada parte deve inicializar a comunicação e obter a aprovação da outra parte antes que quaisquer dados possam ser transferidos.
23.48
Conexão TCP
Handshaking de três vias:
O estabelecimento de uma conexão no TCP é denominado handshaking de três vias (three-way handshaking).
O processo começa com o servidor. O programa servidor informa ao TCP que está pronto para aceitar uma conexão.
Isso é chamado de uma abertura passiva.
Embora o servidor TCP esteja pronto para aceitar conexão de qualquer máquina do mundo, ele não é capaz de estabelecer, por si só, uma conexão.
23.49
Conexão TCP
23.50
Figure 23.18 Connection establishment using three-way handshaking
23.51
Exemplo Prático usando Wireshake (SYN)
23.52
Exemplo Prático usando Wireshake (SYN+ACK)
23.53
Exemplo Prático usando Wireshake (ACK)
23.54
Exemplo Prático usando Wireshake (FIN)
Transferência de Dados:
A figura 23.19 mostra um exemplo. Neste exemplo, após a conexão ser estabelecida (não mostrado na figura), o cliente transmite 2.000 bytes de dados em dois segmentos.
O servidor transmite então 2.000 bytes em um único segmento.
O cliente transmite mais um segmento.
Os três primeiros segmentos transportam dados, bem como confirmações, porém o último segmento de dados pelo cliente tem flag PSH (push) ativo, de modo que o servidor TCP saiba que deve entregar dados para processo servidor imediatamente, assim que eles forem recebidos.
23.55
Conexão TCP
23.56
Figure 23.19 Data transfer
Encerramento de uma conexão:
Qualquer umas das partes envolvidas na troca de dados (cliente ou servidor) pode encerrar uma conexão, embora esta tenha sido, normalmente, iniciada pelo cliente.
Atualmente, a maioria das implementações permite duas opções para encerramento de uma conexão: o three-way handshaking (handshaking de três vias) e o four-wat handshakig (handshaking de quatro vias) com opção de semi-encerramento.
Three-way Handshaking:
1 – Em uma situação normal, um cliente TCP, após receber um comando de encerramento do processo cliente, envia o primeiro segmento, um segmento FIN no qual a flag FIN está ativo. Como trata-se de apenas um segmento de controle, ele consumirá somente um número de sequência.
23.57
Conexão TCP
Three-way Handshaking:
2 – O servidor TCP, após receber um segmento FIN, informa a seu processo TCP sobre essa situação e transmite o segundo segmento, um segmento FIN+ACK, para confirmar o recebimento do segmento FIN do cliente e, ao mesmo tempo, para anunciar o encerramento da conexão na outra direção.
Esse segmento também pode conter o último bloco de dados do servidor. Se não estiver transportando dados, ele consumirá apenas um número de sequência.
3 – O cliente TCP transmite o último segmento, um segmento ACK, para confirmar o recebimento do segmento FIN do servidor TCP.
Esse segmento contém o número de confirmação, que é 1 mais o número de sequência recebido no segmento FIN do servidor.
Esse segmento pode transportar dados e não consome nenhum número de sequência.
23.58
Conexão TCP
23.59
Figure 23.20 Connection termination using three-way handshaking
Semi-encerramento:
No TCP, um lado pode interromper a transmissão de dados enquanto ainda recebe dados, Isso é denominado semi-encerramento.
Embora ambos os lados possam transmitir um semi-encerramento, normalmente ele é iniciado pelo cliente.
Ele pode ocorrer quando o servidor precisa de todos os dados antes de poder iniciar o processamento.
Um bom exemplo é a ordenação. Quando um cliente transmite dados para um servidor para serem ordenados, o servidor precisa receber todos os dados antes de iniciar o processo de ordenação dos mesmos.
23.60
Conexão TCP
23.61
Figure 23.21 Half-close
Janela Deslizante:
O TCP utiliza a técnica de janela deslizante (slidding Window), para implementar controle de fluxo.
A figura 23.22 mostra um bom exemplo de janela deslizante no TCP.
A Janela abrange parte do buffer, que contém os bytes recebidos do processo.
Os bytes dentro da janela são bytes que podem estar em trânsito; ele podem ser enviados sem se preocupar coma confirmação.
A janela imaginária possui duas paredes: uma à direita e outra à esquerda.
Uma janela pode ser aberta, fechada ou reduzida. Essas três atividades, como veremos, estão sob controle do receptor, não do emissor.
O emissor tem de obdecer às ordens de receptor.
23.62
Controle de Fluxo (Pág 728)
Janela Deslizante:
Abrir uma janela significa deslocar a parede direita mais para a direita.
Isso permite um número maior de bytes novos no buffer, candidatos a serem transmitidos.
Fechar uma janela significa deslocar a parede da esquerda mais para a direita.
Isso significa que alguns bytes foram confirmados e o emissor não precisa mais se preocupar com eles.
Reduzir a janela significa deslocar para esquerda a janela da direita, isso é veementemente desencorajado e não permitido em algumas implementações, pois significa renunciar à elegibilidade de alguns bytes para transmissão.
Este é um problema, caso o emissor já tenha enviado esses bytes.
23.63
Controle de Fluxo (Pág 728)
Em (a) é mostrada a representação da perspectiva do transmissor. O retângulo sombreado diz respeito aos quadros a serem enviados;
Cada vez que um quadro é enviado, o retângulo sombreado diminui da esquerda para a direita;
Quando ocorre o reconhecimento (ACK) de um quadro recebido pelo receptor, o retângulo aumenta da esquerda para a direita;
Os quadros antes da barra vertical são os quadros enviados e confirmados, não necessitando de armazenamento em buffer;
O quadro de índice 3, após a barra vertical, indica o quadro transmitido, mas ainda não confirmado e que precisa estar em buffer caso precise ser reenviado.
Em (b) é mostrada a perspectiva do receptor;
O retângulo sombreado representa os quadros a serem recebidos;
À medida que os quadros são reconhecidos (ACK), o retângulo diminui da esquerda para a direita;
À medida que os quadros são recebidos, o retângulo aumenta da esquerda para a direita.
23.65
Outro Exemplo com Janela Deslizante
23.66
Outro Exemplo com Janela Deslizante
23.67
Uma janela deslizante é usada para
implementar maior eficiência à
transmissão, bem como controle de fluxo
de dados, de modo que o destino não fique
sobrecarregado com dados. As janelas
deslizantes no TCP são orientadas a bytes.
Note
23.68
Qual é o valor da janela do receptor (rwnd) para o host A
se o receptor, host B, tem um tamanho do buffer de 5000
bytes e 1000 bytes de dados recebidos e não processados?
Example 23.4
Solução
O valor da rwnd = 5000 - 1000 = 4000. Host B pode
receber apenas 4000 bytes de dados antes de transbordar
seu buffer. Host B anuncia este valor em seu segmento ao
lado A.
23.69
Qual é o tamanho da janela para o host A se o valor de
rwnd é 3000 bytes e o valor do cwnd é de 3500 bytes?
Example 23.5
Solução
O tamanho da janela é o menor dos rwnd e cwnd, que é
de 3000 bytes.
23.70
Figura 23,23 mostra um exemplo não real de uma janela
deslizante. O remetente enviou bytes até 202. Assumimos
que cwnd é de 20 bytes (na realidade este valor é milhares
de bytes). O receptor enviou o número de confirmação de
200 com uma rwnd de 9 bytes (na realidade este valor é
milhares de bytes). O tamanho da janela do remetente é o
mínimo de rwnd e cwnd, ou 9 bytes. Bytes 200-202 são
enviadas, mas não reconhecido. Bytes 203-208 pode ser
enviado sem se preocupar com reconhecimento. Bytes 209
e acima não podem ser enviados.
Example 23.6
23.71
Figure 23.23 Example 23.6
23.72
Alguns Pontos Sobre TCP Janela deslizante: ❏ O tamanho da janela é o valor mínimo entre rwnd e
cwnd.
❏ A origem não deve enviar uma janela de dados
completa.
❏ A janela pode ser aberta ou fechada pelo receptor,
porém, não pode ser reduzida.
❏ O destino pode enviar uma confirmação a qualquer
instante desde que não resulte na redução de uma
janela.
❏ O receptor pode fechar temporariamente uma
janela; O emissor, entretando, sempre pode transmitir
um segmento de 1 byte após a janela ter sido fechada.
Note
O TCP é um protocolo de transporte confiável. Isso significa que um programa de aplicação, que entrega o fluxo de dados para o TCP, depende do TCP para entregar em ordem o fluxo inteiro para programa de aplicação na outra ponta, sem erros, e sem qualquer informação perdida ou duplicada.
Checksum
Cada segmento inclui um campo de checksum que é usado para validar a existência de um segmento corrompido;
Se o segmento estiver corrompido, ele será descartado pelo TCP de destino e considerado com perdido;
O TCP usa o campo de checksum de 16 bits, que é obrigatória em todos os segmentos.
23.73
Controle de Erros (Pág 731)
Confirmação
O TCP usa confirmação para validar o recebimento do segmento de dados;
Um segmento de controle que não transporta dados, mas que usa número de sequência, também deve ser confirmado;
Um segmento ACK jamais necessita de confirmação.
Retransmissão
O cerne do controle de erros é a retransmissão de segmentos;
Quando um segmento estiver corrompido, perdido ou com atraso, ele é retransmitido;
Em implementações modernas, um segmento é retransmitido em duas ocasiões: Quando o tempo do timer de retransmissão se esgota ou quando o emissor recebe três ACKs duplicados.
23.74
Controle de Erros
Retransmissão após RTO (Retransmission time-out)
As implementações recentes do TCP mantém um time RTO para todos os segmentos pendentes (transmitidos, mas não confirmados);
Quando vence o time-out, o primeiro segmento pendente é retransmitido, muito embora a falta de um ACK recebido possa ser enviado a um segmento com atraso, um ACK com atraso ou uma confirmação perdida;
Não existe um timer ativo para segmento que transporta apenas confirmação, significando que nenhum segmento desse tipo poderá ser reenviado;
O valor de RTO é dinâmico no TCP e é atualizado tomando-se como base RTT (Round-Trip Time, em inglês, tempo de ida e volta) do segmento;
O RTT é o tempo necessário para um segmento atingir o destino e uma confirmação ser recebida.
23.75
Controle de Erros
Retransmissão Após Três Segmentos ACK Duplicados
A regra anterior sobre a retransmissão de um segmento é suficiente se o valor de RTO não for muito grande. Algumas vezes, porém, um segmento é perdido e o receptor recebe um número tão grande de segmentos fora de ordem a ponto deles não poderem ser salvos (o tamanho do buffer é limitado).
Para amenizar essa situação, a maioria das implementações atuais segue a regra dos três ACKs duplicados e retransmite imediatamente um segmento faltante. Esse recurso é conhecido como retransmissão rápida.
23.76
Controle de Erros
Segmentos Fora de Ordem
Quando segmento estiver atrasado, perdido ou tiver sido descartado, os segmentos após este, chegarão fora de ordem. Originalmente, o TCP foi desenvolvido para descartar todos os segmentos fora de ordem, resultando na retransmissão de todos os segmentos faltantes e dos segmentos seguintes.
Hoje em dia, a maioria das implementações de TCP não descarta segmentos fora de ordem. Elas os armazenam, temporariamente, em um buffer e colocam uma flag indicando como segmentos fora de ordem até a chegada dos segmentos faltantes.
O TCP garante que os dados são entregues, em ordem, para processo receptor.
23.77
Controle de Erros
23.78
Figure 23.24 Operação Normal
23.79
Figure 23.25 Segmento Perdido
23.80
O receptor TCP entrega apenas dados
ordenados para o processo.
Note
23.81
Figure 23.26 Retransmissão Rápida