1. 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.

2. 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:

3. 23.3
A camada de transporte é responsável
pela comunicação entre processos.
Note

4. 23.4
Figure 23.1 Tipos de comunicação de dados

5. 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

6. 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

7. 23.7
Figure 23.2 Port numbers

8. 23.8
Figure 23.3 Endereço IP versus números de portas

9. 23.9
Figure 23.4 IANA Faixa

10. 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.

11. 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.

12. 23.12
Figure 23.6 Multiplexação e Demultiplexação

13. 23.13
Figure 23.7 Error control

14. 23.14
Figure 23.8 Position of UDP, TCP, and SCTP in TCP/IP suite

15. 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:
:

16. 23.16
Table 23.1 Well-known ports used with UDP

17. 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

18. 23.18
Example 23.1 (continued)
SNMP usa dois números de porta (161 e 162), cada um para uma finalidade
diferente,

19. 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).

20. 23.20
Figure 23.9 Formato de um datagrama UDP

21. 23.21
Comprimento de um datagrama UDP=
Comprimento total IP – Comprimento do
cabeçalho IP
Note

22.  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

23.  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

24.  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

25. 23.25
Figure 23.12 Queues in UDP

26.  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

27. 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:

28. 23.28
Tabela 23.2 Portas conhecidas TCP

29.  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

30. 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.

31.  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

32. 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

33. 23.33
Figura 23.14 Buffers de transmissão e recepção

34.  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

35. 23.35
Figura 23.15 Segmento TCP

36.  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

37.  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

38. 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

39. 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

40. 23.40
A seguir, são apresentados os números de sequência de
cada segmento:
Example 23.3

41. 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

42. 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

43. 23.43
Figure 23.16 O Formato de um segmento TCP

44. 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

45. 23.45
Figure 23.17 Control field

46. 23.46
Table 23.3 Description of flags in the control field

47. 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

48. 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

49. 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

50. 23.50
Figure 23.18 Connection establishment using three-way handshaking

51. 23.51
Exemplo Prático usando Wireshake (SYN)

52. 23.52
Exemplo Prático usando Wireshake (SYN+ACK)

53. 23.53
Exemplo Prático usando Wireshake (ACK)

54. 23.54
Exemplo Prático usando Wireshake (FIN)

55. 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

56. 23.56
Figure 23.19 Data transfer

57. 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

58. 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

59. 23.59
Figure 23.20 Connection termination using three-way handshaking

60. 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

61. 23.61
Figure 23.21 Half-close

62. 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)

63. 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)

64.  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

65. 23.66
Outro Exemplo com Janela Deslizante

66. 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

67. 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.

68. 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.

69. 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

70. 23.71
Figure 23.23 Example 23.6

71. 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

72. 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)

73. 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

74. 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

75. 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

76. 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

77. 23.78
Figure 23.24 Operação Normal

78. 23.79
Figure 23.25 Segmento Perdido

79. 23.80
O receptor TCP entrega apenas dados
ordenados para o processo.
Note

80. 23.81
Figure 23.26 Retransmissão Rápida