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.8
Figure 23.3 Endereço IP versus números de portas

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

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

Capítulo 23 comunicação entre processos

Mais conteúdo relacionado

Mais procurados

Semelhante a Capítulo 23 comunicação entre processos

Mais de Faculdade Mater Christi

Capítulo 23 comunicação entre processos