capítulo 23 comunicação entre processos

23.1

Capítulo 23

Comunicação entre

Processos:

UDP e TCP

Prof. Rodrigo Ronner rodrigoronner@gmail.com

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