Protocolo de transporte TCP (Transmission Control Protocol)

(1)

Protocolo de transporte TCP

(2)

TCP

Necessidade de entrega fiável de fluxos de dados

Aplicação Aplicação TCP TCP IP IP Aplicação Aplicação TCP TCP IP IP

Grandes volumes de dados

Transferência fiável

Transferência não fiável

Perda de pacotes

Entrega de pacotes fora de ordem

Entrega de pacotes com atraso considerável

Entrega de duplicados

Restrições ao tamanho do pacote

(3)

TCP - características

Orientado ao fluxo de dados - Do ponto de vista da aplicação, o

TCP transfere um fluxo contínuo de bytes através da rede

Orientado à ligação - A fiabilidade e o controlo de fluxo fornecidos

pelo TCP requerem que este inicialize e mantenha alguma informação de estado para cada fluxo de dados

Buffered Transfer - Para tornar a transferência mais eficiente e

minimizar o tráfego na rede, o TCP recolhe, do fluxo, dados suficientes para encher um datagrama razoavelmente grande, antes de o

transmitir

Ligação Full-Duplex -Transferência concorrente em ambos os

(4)

Relação entre TCP e outros

protocolos

TCP numa máquina utiliza IP para comunicar com TCP noutra

máquina.

Int. de rede IP TCP Aplicação Int. de rede IP TCP Aplicação Int. de rede IP Rede 1 Rede 1

Rede 1 Rede 2Rede 2_{Rede 2} router

router

máquina A

máquina A _{Sistema de comunicações}_{Sistema de comunicações} máquina Bmáquina B visto pelo TCP

(5)

TCP e IP

IP oferece serviço “

melhor esforço”

(não fiável)

TCP utiliza IP

TCP fornece entrega fiável

Como é que isto é possível?

Confirmação Positiva

O receptor envia uma mensagem curta quando recebe dados; Esta mensagem chama-se Confirmação (Acknowledgment).

Retransmissão

O transmissor inicializa um temporizador, sempre que uma

mensagem é transmitida

Se o temporizador expira antes que seja recebida a confirmação, a

(6)

Confirmação positiva com

retransmissão

envia mensagem 1 retransmite mensagem 2 inicializa temporizador envia ack 1 recebe ack 1 envia mensagem 2 pacote perdido temporizador expira envia ack 2 transmissor receptor inicializa temporizador inicializa temporizador

(7)

Portos, ligações e pontos

terminais

TCP assenta sobre IP, assim como o UDP

TCP também utiliza portos para identificar o destino dentro da

mesma máquina

TCP permite que múltiplos programas numa máquina particular

comuniquem em simultâneo

Desmultiplexa o tráfego que entra para cada programa de

aplicação

TCP baseia-se no conceito de ligação

Interface com a Rede IP

UDP TCP

(8)

Portos, ligações e pontos

terminais

Uma ligação é equivalente a um circuito virtual entre dois

programas de aplicação

Ligações são identificadas por um par de pontos terminais

TCP define ponto terminal como um par de inteiros – (endereço

IP, porto)

Porto TCP pode ser partilhado por várias ligações na mesma

máquina

TCP TCP IP IP X X aplicação aplicação TCP TCP IP IP Y Y aplicação aplicação 10.0.20.20 10.0.20.20 10.0.20.30 10.0.20.30 porto porto ((10.0.20.30, X), (10.0.20.20,Y)) ligação ponto terminal porto porto

(9)

TCP

Serviços fornecidos pelo TCP ao nível da aplicação

Estabelecimento e terminação de uma ligação TCP

Transferência normal de informação com o TCP

Serviços interactivos

Serviços com transferência de grandes quantidades de

informação

Timeout

e retransmissão (temporizadores)

(10)

Serviços fornecidos pelo TCP

Camada de rede utilizada – IP

Fornece um serviço à camada de aplicação diferente

do UDP

Orientado à ligação, fiável, fluxo de

bytes

Analogia aos telefones

O cliente diz “Olá”

O servidor diz “Quem é que está a chamar?”

Numa ligação TCP existem dois terminais a

comunicar

Os conceitos de

broadcast

e de

multicast

não são aplicáveis

no TCP

(11)

Fiabilidade no TCP

Informação da aplicação dividida em segmentos com o

comprimento óptimo

TCP mantém temporizador por cada segmento que envia

Se não é confirmada a recepção do segmento dentro de um

determinado tempo, segmento é retransmitido

Quando TCP recebe informação do outro extremo, envia uma

confirmação

TCP mantém

checksum

do cabeçalho e da informação

extremo-a-extremo

Quando chega um segmento com um checksum inválido, TCP

descarta-o e não envia confirmação

TCP re-sequencia informação e enviar pela ordem correcta à

(12)

Fiabilidade no TCP

Retransmissões – possibilidade de envio de

informação duplicada

TCP descarta informação duplicada

Controle de fluxos:

Cada extremo da comunicação tem uma fila de espera

limitada de armazenamento de pacotes de informação

Receptor tem capacidade de avisar o emissor de que ele

está a enviar informação a uma taxa demasiado elevada

Uma chamada é impedida de ocupar todo o espaço das filas

de espera

Pretende-se que estejam disponíveis para informação de

(13)

Informação nos segmentos

TCP

Quantidade de informação que é colocada nos segmentos TCP

pode ser diferente da quantidade de informação que a aplicação

envia em cada escrita

Várias escritas da aplicação podem criar apenas um segmento TCP TCP espera (durante um pequeno tempo) por mais informação

para enviar, se esta for muito pequena para colocar num segmento TCP

O outro extremo pode ler a informação de forma diferente que foi

escrita

Diferença em relação ao UDP

TCP não interpreta o conteúdo dos

bytes –

a aplicação tem essa

(14)

Cabeçalho TCP

Número de portos – que identificam? Como é identificada a ligação? A combinação de endereço IP e número de porto é às vezes designada por

socket O par de sockets (4 elementos?) especificam os dois extremos que identificam unicamente cada ligação TCP na Internet.

(15)

Campos do cabeçalho TCP

Número de sequência – identificação do primeiro

byte

de dados

num segmento TCP

Cada byte enviado é numerado – número de confirmação contém o

próximo número de sequência que o receptor espera receber;

Enviar uma confirmação não custa nada

Campo de número de confirmação encontra-se sempre presente no

cabeçalho

Informação pode ser enviada juntamente com confirmação

TCP fornece um serviço nos dois sentidos à aplicação –

informação pode fluir num sentido independentemente do outro

sentido

Cada extremo de uma ligação tem de manter um número de

(16)

Campos do cabeçalho TCP

TCP – sem confirmações selectivas ou

negativas

Número de confirmação indica que o receptor

recebeu até àquele número mas não incluindo

esse

byte

Se os

bytes

1-1024 e 2049-3072 são recebidos, o

receptor envia confirmação do

byte

1025

Se os

bytes

1025-2048 chegam, mas com um erro de

checksum

, TCP apenas pode enviar uma confirmação do

byte

1025

Tamanho do cabeçalho

Sem campo de opções é de 20

bytes

;

(17)

Campos do cabeçalho TCP

6 flags

:

URG – apontador de urgência é válido ACK – número de confirmação é válido

PSH – o receptor deve enviar esta informação à aplicação o mais

rapidamente possível

RST – reset da ligação

SYN – sincronizar os números de sequência para iniciar a ligação FIN – emissor finalizou o envio de informação

Controlo de fluxo em TCP é possibilitado por cada extremo

anunciando o tamanho da janela de transmissão

Número de bytes, a começar pelo especificado no número de

sequência de confirmação, que o receptor pode receber

Limitação do tamanho da janela?

Opção de escala da janela – possibilita a utilização de janelas

(18)

Campos do cabeçalho TCP

checksum

– é obrigatório

Utiliza o pseudo-cabeçalho, tal como no UDP

Ponteiro de urgência

Número de sequência do último byte com informação urgente

Opções

Opção de tamanho máximo do segmento (MSS)

Opção especificada no primeiro segmento enviado (estabelecimento da ligação)

Especifica o tamanho máximo do segmento que o emissor pode receber

No estabelecimento e terminação da ligação, segmentos

enviados contêm apenas o cabeçalho TCP

Cabeçalho sem informação – confirmações, se não existe

(19)

Estabelecimento e terminação

de uma ligação TCP

svr4 % telnet bsdi discard Trying 192.82.148.3 ... Connected to bsdi. Escape character is '^]'. ^] telnet> quit Connection closed. Estabelecimento 1 0.0 svr4.1037 > bsdi.discard: S1415531521:1415531521(0) win 4096<mss 1024>

2 0.002402 (0.0024) bsdi.discard > svr4.1037: S1823083521:1823083521(0)ack1415531522 win 4096<mss 1024> 3 0.007224 (0.0048) svr4.1037 > bsdi.discard:.ack1823083522 win 4096

Terminação

4 4.155441 (4.1482) svr4.1037 > bsdi.discard: F1415531522:1415531522(0) ack1823083522 win 4096

5 4.156747 (0.0013) bsdi.discard > svr4.1037: . ack1415531523 win 4096

6 4.158144 (0.0014) bsdi.discard > svr4.1037: F1823083522:1823083522(0) ack1415531523win 4096

(20)

Protocolo de estabelecimento

da ligação

Iniciar a ligação (cliente) - envia

segmento SYN

Número de porto do servidor onde o

cliente se quer ligar

Número de sequência inicial do cliente

(ISN), etc

Servidor responde com o seu segmento

SYN

Número de sequência inicial do servidor

(ISN)

Confirmação do SYN do cliente,

confirmando o ISN do cliente +1; Um SYN consome 1 número de sequência

Cliente confirma o SYN do servidor,

confirmando o ISN do servidor +1

3 segmentos – estabelecimento da

ligação - three-way handshake.

(21)

Protocolo de estabelecimento

da ligação

O extremo que envia o primeiro SYN efectua um

open

activo

O outro extremo efectua um

open

passivo

O ISN é escolhido por cada extremo da comunicação

Varia ao longo do tempo

Cada ligação tem um ISN diferente

Contador de 32

bits

que incrementa 1 por cada 4

microsegundos

Prevenir que os pacotes que se atrasam na rede sejam

(22)

Protocolo de terminação da

ligação

Quatro segmentos para terminar uma ligação

Meio fecho do TCP

Ligação com envio independente de informação nos dois sentidos Cada ligação é terminada de uma forma independente

Cada extremo envia um segmento FIN (resultado de um close na aplicação) quando termina o envio de informação

Quando TCP recebe um FIN, necessita de notificar a aplicação que o outro extremo terminou o envio de informação nessa direcção

No entanto, TCP pode enviar informação no outro sentido

Cenário normal - os dois extremos fecham a ligação com pouco tempo de intervalo.

Primeiro close - close activo Último close - close passivo

(23)

Protocolo de terminação da

ligação

FINs são causados pela aplicação

ACK dos FINs são enviados automaticamente pelo

software

TCP

FIN FIN ack do FIN ack do FIN Cliente Servidor Close da aplicação Envio de EOF para a aplicação Close da aplicação

(24)

Timeout

do estabelecimento

da ligação

Servidor de

discard

encontra-se desligado

Tipo de serviço 0x10 – baixo atraso

Frequência de envio do SYN por parte do cliente

Tempo que o cliente TCP continua a retransmitir antes de

desistir: 76 segundos

1 0.0 bsdi-1024 > svr4.discard: S291008001:291008001(0)win 4096<mss 1024> [tos 0x10]

2 5.8147 ( 5.8148) bsdi-1024 > svr4.discard: S291008001:291008001(0)win 4096<mss 1024> [tos 0x10]

3 29.815 (24.0006) bsdi-1024 > svr4.discard: S291008001:291008001(0)win 4096<mss 1024> [tos 0x10]

bsdi % date ; telnet svr4 discard ; date Thu Sep 24 16:24:11 MST 1992

Trying 192.82.148.2...

telnet: Unable to connect to remote host: Connection timed out Thu Sep 24 16:25:27 MST 1992

(25)

Comprimento máximo de um

segmento

Comprimento máximo de um segmento (MSS) - quantidade de

informação que o TCP pode enviar para o outro extremo

Se não é enviada a opção de MSS, por defeito o MSS é de 536

bytes

Quanto maior o MSS (sem fragmentação), maior é a

amortização do custo dos cabeçalhos IP e TCP

Ethernet

– MSS de 1460

bytes

Rede com o mesmo ID de rede mas diferente ID de sub-rede

pode ser uma rede física diferente

Maior parte das configurações têm opção em que o administrador

(26)

Comprimento máximo de um

segmento

MSS permite evitar fragmentação

Mesmo tendo sun anunciado um MSS de 1460, não vai enviar mais do

que 256 bytes de informação, para evitar fragmentação

Se os dois estiverem ligados à Ethernet, e uma rede intermédia tem

MTU de 296, ocorre fragmentação; única possibilidade é descobrir o MTU do caminho

1 0.0 sun.1093 > slip.discard:S517312000:517312000 (0)<mss 1460> ?

2 0.10 (0.00 slip.discard > sun.1093: S509556225:509556225 (0)ack517312001<mss 256> ? 3 0.10 (0.00) sun.1093 > slip.discard: . ack509556226

(27)

Meio fecho da ligação TCP

Um extremo da comunicação termina a sua saída de

informação, enquanto ainda recebe informação do outro

extremo

Nem todas as implementações suportam esta funcionalidade

Quando o extremo que recebeu o FIN termina o envio de

informação

Fecha a sua extremidade da ligação, enviando um FIN

Provoca o envio de uma mensagem de fim do ficheiro à aplicação

que iniciou o meio fecho

Quando este segundo FIN é confirmado, a ligação é

(28)

Meio fecho da ligação TCP

Porquê a existência do

meio fecho da ligação?

Algumas aplicações necessitam de uma forma de o cliente dizer ao servidor que terminou de enviar informação, mas permitir que o cliente ainda receba informação

Uma possibilidade

sem recorrer ao

meio fecho é utilizar duas ligações, mas apenas uma ligação com meio fecho é mais simples

(29)

As regras de

início e

terminação

de uma

ligação TCP

podem ser

sumariadas

num

diagrama de

transição de

estados.

(30)

Estados TCP

Estado ESTABLISHED é o estado em que existe transferência de

informação entre os dois extremos nos dois sentidos

As duas transições para o estado ESTABLISHED correspondem a abrir

uma ligação

As duas transições do estado ESTABLISHED correspondem à

terminação da ligação

Close activo: estados FIN_WAIT_1, FIN_WAIT_2, CLOSING,

TIME_WAIT

(31)

Estados TCP

(32)

Estado

TIME_WAIT

(2 MSL –

Maximum Segment Lifetime

)

TIME_WAIT - 2MSL

wait

MSL é o tempo máximo que um segmento pode existir na rede

antes de ser descartado (dependente da implementação 2 min,

1 min ou 30 seg)

O tempo de vida de um datagrama IP é baseado no número de

saltos, não no tempo

Quando o TCP faz um fecho activo e envia o ACK final, a ligação

pode estar no estado

TIME_WAIT

um tempo 2xMSL

Este tempo permite ao TCP reenviar o ACK final no caso de o ACK

se perder (se não recebe o ACK dentro de um timeout, o outro extremo retransmite o FIN final)

Enquanto a ligação TCP se encontra no estado 2MSL

wait

, o par

(33)

Estado

TIME_WAIT

Quaisquer segmentos que cheguem quando a ligação se

encontra no estado 2MSL

wait

são descartados

Normalmente é o cliente que faz o fecho activo e entra no

estado

TIME_WAIT

O servidor normalmente faz o fecho passivo, e não entra neste

estado

Se se terminar um cliente e iniciar o mesmo cliente de imediato,

o novo cliente não pode reutilizar o mesmo número de porto

local. Problema?

Com os servidores a situação é diferente, pois eles utilizam

portos definidos:

Se se terminar um servidor que tem uma ligação estabelecida, e de

imediato se tentar iniciar o servidor, ele não pode associar o seu número de porto, pois ele faz parte de uma ligação que se

encontra no estado 2MSL wait

(34)

Estado

TIME_WAIT

Inicia-se um servidor, liga-se-lhe um cliente, e termina-se o

servidor.

sun % sock -v -s 6666

connection on 140.252.13.33.6666 from 140.252.13.35.1081

Termina-se o servidor sun % sock -s 6666

can't bind local address: Address already in use (encontra-se no estado 2MSL wait) sun % netstat

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

(35)

Estado

TIME_WAIT

Mesmo erro no cliente se ele tenta atribuir um porto que faz

parte de uma ligação no estado 2MSL

wait

sun % sock -v bsdi echo

connected on 140.252.13.33.1162 to 140.252.13.35.7 hello there

hello there

^D

sun % sock -b1162 bsdi echo

can't bind local address: Address already in use

sun % sock -v -s 6666 (como servidor)

connection on 140.252.13.33.6666 from 140.252.13.35.1098 ^?

sun % sock -b6666 bsdi 1098 (como cliente)

can't bind local address: Address already in use (porto local cliente 6666, liga-se ao bsdi no porto 1098) sun % sock -A -b6666 bsdi 1098 (como cliente – opção SO_REUSEADDR)

active open error: Address already in use (porto local 6666 ok, mas o porto 1098 pertence à ligação no estado 2 MSL wait)

(36)

Conceito de

quiet time

2MSL

wait

dá protecção contra segmentos atrasados de uma

ligação anterior que sejam interpretados como fazendo parte da

nova ligação

Apenas funciona se um terminal com ligações no estado 2MSL wait

não crasha

Se no estado 2MSL

wait

existe um

crash

, o terminal faz o

reboot

, e imediatamente estabelece novas ligações com os

mesmos endereços IP e portos

Segmentos atrasados de ligações anteriores podem ser

confundidos como pertencentes à nova ligação

Pode acontecer devido à forma como é escolhido o número de

sequência inicial após o reboot

Para se proteger contra este cenário, TCP não deve estabelecer

novas ligações no espaço de MSL segundos depois de um

(37)

Segmentos

Reset

Bit

no cabeçalho TCP: RST para

reset

Reset

é enviado pelo TCP sempre que chega um segmento que

não parece correcto na ligação referenciada (?)

Qualquer informação em espera é descartada

Pedido de ligação para um porto não existente

Pedido de ligação chega e não existe processo à escuta no porto

especificado

UDP utilizava uma mensagem ICMP de porto inatingível TCP utiliza o reset

bsdi % telnet: svr4 20000 (não deve ser utilizado) Trying 140.252.13.34...

telnet: Unable to connect to remote host: Connection refused

1 0.0 bsdi.1087 > svr4.20000:S297416193:297416193(0)win 4096<mss 1024> [tos 0x10]

(38)

Detectar ligações meio

estabelecidas

Ligação meio estabelecida – um extremo fechou ou cancelou a

ligação sem o conhecimento do outro extremo

Se um dos extremos cracha, é desligado sem avisar o outro

extremo

Enquanto não houver necessidade de transferir informação, o

sistema que se encontra activo não detecta que o outro crachou

Desligar o cabo Ethernet no terminal do servidor Reboot do servidor após desligar o cabo

Re-ligar o cabo após reboot e tentar enviar nova linha do cliente ao servidor

O servidor fez o reboot e perdeu a memória das ligações que existiam antes do reboot

Nada sabe da ligação que o segmento referencia O receptor TCP (servidor) responde com um reset

(39)

Detectar ligações meio

estabelecidas

bsdi % telnet svr4 discard inicia o cliente Trying 140.252.13.34...

Connected to svr4. Escape character is '^]'

hi there linha enviada ok

reboot do servidor another line linha activa um reset Connection closed by foreign host.

1 0.0 bsdi.1102 > svr4.discard: S1591752193:1591752193(0)

2 0.004811 (0.0048) svr4.discard > bsdi.1102: S26368001:26368001(0)ack1591752194 3 0.006516 (0.0017) bsdi.1102 > svr4.discard: . ack1

4 5.167679 (5.1612) bsdi.1102 > svr4.discard: P1:11(10) ack1

5 5.201662 (0.0340) svr4.discard > bsdi.1102: . ack11

6 194.909 (189.708) bsdi.1102 > svr4.discard: P11:25(14)ack1

7 194.914 (0.0050) arp who-has bsdi tell svr4

8 194.915 (0.0007) arp reply bsdi is-at 0:0:c0:6f:2d:40

(40)

Estabelecimento simultâneo

da ligação

Duas aplicações fazem

open

activo ao mesmo tempo

TCP está preparado para suportar estabelecimentos de ligações

simultâneos

Apenas uma ligação resulta do processo

Transições de estados diferem dos apresentados anteriormente

Ambos os extremos enviam SYN quase ao mesmo tempo, entrando

no estado SYN_SENT

Ao receber o SYN, o estado muda para SYN_RCVD, e cada extremo

reenvia o SYN e confirma o SYN recebido

Quando cada extremo recebe o SYN e a confirmação, o estado

muda para ESTABLISHED

(41)

Terminação simultânea da

ligação

Possível que os dois extremos terminem de uma forma activa a

ligação ao mesmo tempo

Ambos os extremos passam do estado

ESTABLISHED

para

FIN_WAIT_1

quando a aplicação faz o

close

Quando o FIN é recebido, cada extremo transita do estado

FIN_WAIT_1

para

CLOSING

, e cada extremo envia o ACK final

Quando cada extremo recebe o ACK, o seu estado muda para

(42)

Opções TCP

Cada opção

começa com

kind

– tipo;

Tamanho da

opção;

Informação

sobre a

opção;

Kind

=1 –

Enchimento

para ser

múltiplo de 4

bytes

.

(43)

Projecto de um servidor TCP

Servidores TCP concorrentes

Quando chega um novo pedido ao servidor, este

aceita a ligação, invoca um novo processo para

processar o pedido do cliente

Invocar novo servidor

Dependente do sistema operativo

Unix - função fork(),

threads

Interacção entre TCP e servidores concorrentes

Número de portos associados a cada cliente

Múltiplos pedidos de ligação chegam praticamente ao

(44)

Projecto de um servidor TCP

-portos no servidor TCP

TCP desmultiplexa os segmentos que chegam, utilizando todos

os 4 valores que compreendem os endereços locais e não locais

O único extremo no porto 23 que pode receber pedidos de

ligação é o que se encontra no estado

LISTEN

Os extremos no estado

ESTABLISHED

não podem receber

segmentos

SYN

O extremo no estado

LISTEN

não pode receber segmentos de

dados

Proto Recv-Q Send-Q Local Address Foreign Address (state)

Tcp 0 0 140.252.1.29.23 140.252.1.32.34603 ESTABLISHED

Tcp 0 0 140.252.13.33.23 140.252.13.65.1030 ESTABLISHED

Tcp 0 0 140.252.13.33.23 140.252.13.65.1029 ESTABLISHED

(45)

Projecto de um servidor TCP

-restrição de endereços locais

Restringir o estabelecimento de ligações pela interface

140.252.1.29 Se um cliente se ligar através desta interface local, consegue

Mas se um terminal noutra rede se tenta ligar através de outra

interface, o pedido não é aceite pelo módulo TCP

O SYN é respondido com um RST

Proto Recv-Q Send-Q Local Address Foreign Address (state)

Tcp 0 0 140.252.1.29.8888 140.252.1.32.34614 ESTABLISHED

Tcp 0 0 140.252.1.29.8888 *.* LISTEN

1 0.0 bsdi.l026 > sun.8888: S3657920001:3657920001(0)win 4096<mss 1024> 2 0.000859 (0.0009) sun.8888 > bsdi.l026: R 0:0(0)ack3657920002win 0

(46)

Projecto de um servidor TCP

-fila de espera de chegada ped.

Um servidor concorrente invoca um novo

processo para processar o pedido do cliente

Devia estar sempre disponível para processar o

novo pedido

Múltiplos pedidos de ligação podem chegar

enquanto o servidor cria um novo processo, ou o sistema operativo está ocupado a correr processos com maior prioridade

Como é que estes pedidos são suportados no

TCP?

Fila de espera de tamanho finito para armazenar

pedidos

Limite para a fila de espera - backlog

Quando chega um pedido, existe um algoritmo do

TCP que, com base no número de ligações em fila de espera, decide se pode ou não aceitar a

ligação 0 1 2 3 4 5 Valor Backlog 1 2 4 5 7 8 BSD Máximo número de ligações em espera 0 1 2 3 4 5 Solaris

(47)

(48)

(49)

(50)

(51)

(52)

(53)

(54)

(55)

(56)

(57)

(58)

Serviços interactivos

Transferência de informação com o TCP

Aproximadamente metade dos segmentos TCP contêm

informação transmitida em grandes volumes (FTP, e-mail)

Outra metade contém informação interactiva (

Telnet

e

Rlogin

,

por exemplo)

Em relação à quantidade de informação, esta é maior em

informação transmitida em grandes volumes do que a

interactiva

Algoritmos diferentes no TCP para suportar ambos os tipos de

informação

Transferência de informação interactiva

Suporte de confirmações atrasadas

Algoritmo de Nagle para reduzir o número de pacotes pequenos

(59)

Funcionamento do

Rlogin

Comando interactivo numa ligação

Rlogin

envia um caracter de cada vez do cliente ao servidor

Cada vez que se pressiona uma tecla, é gerado um pacote de

informação

Enviadas do cliente para o servidor, um byte de cada vez Segmento de pressão da tecla enviado pelo cliente

Confirmação do servidor Echo da tecla no servidor Confirmação do echo no

cliente

Escrita de date\n – gera 6

conjuntos de envio de

(60)

(61)

Atrasos nas confirmações

Normalmente o TCP não envia a confirmação assim que recebe

informação

Atrasa a confirmação, na esperança de haver informação para

enviar no mesmo sentido da confirmação

Atraso de 200 ms na maior parte das implementações

Tempo para gerar cada

echo

dos caracteres é de 16.5, 16.3,

16.5, 16.4, and 17.3 ms

(62)

Algoritmo de

Nagle

Envio de 1 byte de cada vez: pacotes de 41 bytes

Aumento da congestão em redes de grande dimensão Solução: algoritmo de Naggle

Uma ligação TCP pode ter apenas um segmento pequeno que não

tenha sido confirmado

Não podem ser enviados segmentos pequenos adicionais enquanto a

confirmação não é recebida

Agrupamento da informação e envio num único segmento quando a

confirmação chega

Quanto mais rápidas são as confirmações, mais rapidamente a informação

é enviada

Menos segmentos são enviados

Falta de confirmações atrasadas

Existe sempre informação para transmitir antes do temporizador expirar

O cliente colecciona informação, mas não a envia enquanto a anterior

não for confirmada

(63)

TCP

Fluxo de volumes de largura de

banda TCP

(64)

Fluxo de volumes de largura

de banda TCP

Protocolo utilizado no TFTP -

stop-and-wait

TCP forma diferente de controle de fluxos – protocolo

da janela deslizante

Emissor pode transmitir múltiplos pacotes antes de parar e

esperar por uma confirmação

Transferência de informação muito mais rápida – não tem

de esperar por uma confirmação de cada vez que um pacote

é transmitido

Slow start

– técnica utilizada quando é detectada

congestão na rede

(65)

Transferência de

8192

bytes

:

cliente realiza 8

escritas de 1024

bytes

para a

rede.

(66)

Fluxo normal de informação

Segmento – confirmação do 2049 e não do 3073

Pacote inicialmente processado por uma rotina de serviço e

colocado numa fila de espera de entrada de pacotes IP

Os 3 segmentos são colocados na fila de espera pela ordem em

que são recebidos

IP passa os pacotes para a camada TCP pela mesma ordem

Quando o TCP processa o primeiro segmento, a ligação é marcada

para gerar uma confirmação retardada

TCP processa o próximo segmento, e dado que tem dois

segmentos à espera para confirmar, a confirmação dos 2 é gerada e a flag de envio de confirmações atrasadas é desactivada

TCP processa segmento seguinte, a ligação é marcada novamente

para atrasar a confirmação

Confirmação anuncia uma janela de 3072 bytes, porque ainda

existem 1024 bytes de informação na fila de espera de recepção TCP que a aplicação não leu

(67)

Fluxo normal de informação

Algumas confirmações de 2 segmentos recebidos

Protocolo de janela deslizante – receptor não tem de confirmar

cada pacote recebido

Confirmação de que o receptor recebeu correctamente todos os

bytes até ao número de sequência confirmado menos 1

Ordem dos pacotes depende de muitos factores

Implementação TCP de envio de informação Implementação TCP de recepção de informação

Leitura da informação pelo processo que recebe informação

Dependente do escalonamento dos processos efectuado pelo sistema operativo

Dinâmica da rede Colisões, etc

Não existe forma única de dois extremos TCP trocarem uma

(68)

Mesmo exemplo realizado uns minutos depois Receptor não envia confirmação do 3073; espera e envia confirmação do 4097 Confirmação dos últimos 1024 bytes aparece no segmento 17, com a confirmação do FIN

(69)

Emissor rápido, receptor lento

Emissor transmite 4

segmentos ?

Pára e espera por

uma confirmação Receptor envia confirmação com janela a 0: recebeu toda a informação mas encontra-se na fila de espera TCP (aplicação ainda não leu informação)

Outra confirmação –

actualização da janela –4096 bytes

(70)

Janelas deslizantes

Visualização do protocolo de janela deslizante:

Janela anunciada pelo receptor: janela oferecida (

bytes

4 a 9)

Receptor confirmou todos os bytes até e incluindo o número 3, e

anunciou uma janela com tamanho 6

Tamanho da janela é relativo ao número de sequência confirmado O emissor determina a janela utilizável: quantidade de informação

(71)

Movimento da janela

Janela move-se para a direita à medida que o

receptor confirma informação

Janela fecha quando o extremo esquerdo avança

para a direita

Informação é enviada e confirmada

Janela abre quando o extremo direito avança para

a direita, permitindo que mais informação possa

ser enviada

Processo no receptor lê informação confirmada,

libertando espaço na fila de espera de recepção TCP

Extremo esquerdo atinge o direito, janela nula

(72)

Exemplo (primeira

transferência de informação)

Emissor não tem

de transmitir uma janela completa

Confirmação de

informação –

janela desliza para a direita (relativo ao número seq.) Tamanho da janela pode diminuir (apenas pelo lado esquerdo)

Receptor não tem

de esperar que a janela encha para enviar

(73)

Exemplo

Escrita de 8192 bytes com

fila de espera de recepção de 6144

Cliente envia 6 segments e

pára

Segmento 10 confirma toda

a informação, mas anuncia uma janela de 2048

Aplicação de recepção

ainda tem de ler 2048

bytes

Segmento 13 contém uma

actualização da janela

Janela diminui quando são

enviados os dois últimos, mas vai sendo actualizada até fechar a ligação

(74)

Flag

PUSH

Notificação do emissor ao receptor para

passar toda a informação que tiver para o

processo de recepção

Numa aplicação interactiva, quando o cliente

envia um comando ao servidor, deve activar

a

flag

PUSH e esperar pela resposta do

(75)

Começo Lento (

Slow Start

)

Enviados vários segmentos para a rede, até ao tamanho da

janela anunciado pelo receptor

Funciona bem enquanto os dois extremos da comunicação se

encontram na mesma LAN

Problemas quando existem

routers

e ligações lentas entre o

emissor e o receptor

Router intermédio pode armazenar pacotes na sua fila de espera

até ficar sem espaço

Taxa de envio de informação numa ligação TCP pode ser

drasticamente reduzida

TCP tem de suportar o algoritmo de

slow start

Taxa a que novos pacotes devem ser enviados para a rede deve

ser igual à taxa à qual as confirmações são retornadas pelo outro extremo

(76)

Slow Start

Slow start adiciona uma nova janela ao emissor TCP: a janela de

congestão, cwnd

Quando uma nova ligação é estabelecida com um terminal numa outra

rede, janela de congestão é inicializada a 1 segmento: tamanho do segmento anunciado pelo outro extremo

De cada vez que é recebida uma

confirmação, a janela de congestão é aumentada de 1 segmento

Emissor pode transmitir até ao

mínimo entre a janela de congestão e a janela anunciada

Janela de congestão representa

um mecanismo de controle de fluxo imposto pelo emissor

Janela de recepção representa

(77)

Slow Start

Emissor começa por transmitir 1 segmento e espera pela

confirmação

Quando esta é recebida, a janela de congestão aumenta, e

podem ser enviados 2 segmentos

Quando cada um dos 2 segmentos é confirmado, a janela é

aumentada para 4

Crescimento exponencial do tamanho da janela de congestão

Assim que a rede fica congestionada, um

router

intermédio

pode começar a descartar pacotes

Descarte de pacotes é uma informação (ao emissor) de que a

janela de congestão era demasiado grande

O emissor reage diminuindo a janela de congestão

Se a congestão desaparecer, a janela aumenta novamente da

(78)

Slow Start

– exemplo

Informação atravessa uma

ligação SLIP

Quando é recebida uma

confirmação do primeiro segmento, a janela de congestão aumenta para 2

Quando é recebida a

confirmação do segundo segmento enviado, a janela de congestão é aumentada para 3 segmentos

Embora possa ser enviado

mais um segmento de informação, apenas 2 são enviados antes de chegar a próxima confirmação

(79)

Produto entre largura de

banda e atraso

Janela anunciada pelo receptor deve ter este tamanho - limita a

quantidade de informação transmitida pelo emissor

Capacidade da ligação:

cap

(bits) =

band

(bits/seg) x

rtt

(seg)

Exemplos

Linha telefónica T1 (1,544,000 bits/seg) com rtt de 60 mseg, dá

um produto de largura de banda/atraso de 11,580 bytes

Linha telefónica T3 (45,000,000 bits/seg) com mesmo rtt, dá um

produto de largura de banda/atraso de 337,500 bytes, que é maior do que a máxima janela que pode ser anunciada pelo TCP (65535

bytes)

(80)

Produto entre largura de

banda e atraso

Aumentar

rtt

da ligação para o dobro, aumenta a capacidade da

ligação TCP (número de

bytes

que podem ser enviados)

Aumentar a largura de banda da ligação para o dobro, também

aumenta o número de

bytes

que podem ser enviados

Capacidade da rede aumentou, velocidade de transmissão,

permitindo que os segmentos sejam enviados em metade do tempo

(81)

Congestão

Ligação com capacidade elevada que envia pacotes para uma

ligação lenta

Router 1 – ponto de congestão

Espaçamento das confirmações no retorno igual ao da ligação lenta Assumiu-se que o emissor não utilizou slow start e que o router 1

tem espaço para armazenar todos os 20 segmentos (senão seriam descartados)

(82)

Modo urgente

Suportado no TCP

Extremo diz ao outro que informação urgente foi colocada em

conjunto com o fluxo normal de informação

Extremo receptor decide o que fazer nessa situação

Dois campos no cabeçalho TCP

Activação da flag URG

Ponteiro de urgência é colocado a um offset positivo que tem de

ser adicionado ao número de sequência, para obter o número de sequência do último byte com informação urgente

TCP tem de informar o processo de recepção quando um

ponteiro urgente é recebido

Enquanto existir informação na posição corrente de leitura até

ao ponteiro de urgência, a aplicação é considerada estar em

modo urgente

Depois de o ponteiro passar, a aplicação retorna ao modo

(83)

TCP

(84)

Timeout

e retransmissão

Fiabilidade do TCP: cada extremo da ligação confirma a informação

que recebeu;

Assim como os segmentos de informação, as confirmações também

se podem perder;

Como são suportadas estas perdas no TCP?

Quando é enviada informação, é iniciado um temporizador;

Se a informação não é confirmada quando o temporizador expira, a

informação é retransmitida;

Elementos críticos da implementação: temporizador e estratégia de

retransmissão.

TCP gere 4 temporizadores diferentes para cada ligação:

Temporizador de retransmissão quando se espera uma confirmação do

outro extremo;

Temporizador de persistência que mantém informação do tamanho da

janela, mesmo que o outro extremo feche a janela de recepção;

Temporizador keepalive que detecta quando o outro extremo cracha ou

faz o reboot;

Temporizador 2MSL que mede o tempo que a ligação esteve no estado

(85)

Exemplo de

timeout

e

retransmissão

bsdi % telnet svr4 discard Trying 140.252.13.34... Connected to svr4. Escape character is '^]'.

Hello, world (enviada normalmente) (desligar o cabo antes de enviar a linha) and hi

(TCP desiste depois de 9 minutos) Connection closed by foreign host. 1 0.0 bsdi.1029 > svr4.dis:S1747921409:1747921409(0) win 4096<mss 1024>

2 0.004811 (0.0048) svr4.dis > bsdi.1029:S3416685569:3416685569(0)ack1747921410 win 4096<mss 1024> 3 0.006441 (0.0016) bsdi.1029 > svr4.dis:. ack1 win 4096

4 6.102290 (6.0958) bsdi.1029 > svr4.dis: P1:15(14) ack1win 4096

5 6.259410 (0.1571) svr4.dis > bsdi.1029:. ack15 win 4096

(86)

Medição do

rtt

Timeout

modificado de acordo com o

rtt

. Este varia ao longo do

tempo:

Rotas podem modificar-se; Tráfego da rede modifica-se.

Medição do

rtt

:

Envio de um byte com um número de sequência particular e

recepção da confirmação;

Especificação TCP original actualiza um estimador

rtt

:

R

← α

R

+ (1-

_α

)

M

, em que

_α

é um factor de suavização (0.9) e

M

é o

rtt

medido:

90% de cada nova estimativa tem informação da estimativa

anterior, e 10% da nova medição.

O

rtt

é actualizado em cada medição;

O temporizador de retransmissão é dado por

RTO = R

β

,

em que

β

é um factor de variação do atraso (2).

(87)

Medição do

rtt

É necessário captar a variância das medições

rtt

além do

estimador

rtt

;

Cálculo do

RTO

com base na média e variância do

rtt

permite

ter uma melhor resposta a flutuações nos

rtts

:

Err = M – A

A

é o estimador

rtt

A

_←

A

+

g Err

Ganho

g

(média) é 0.125

D

←

D

+

h

(|

Err

| -

D

)

D

é o desvio médio, ganho

h

(desvio) 0.25

RTO = A

+ 4

D

Um grande ganho do desvio, faz aumentar o

RTO

rapidamente

(88)

Medição do

rtt

– algoritmo de

Karn

Quando um pacote é transmitido, existe um

timeout

, o

RTO

é

recuado, o pacote é retransmitido com o

RTO

maior, e uma

confirmação é recebida:

Confirmação é da primeira ou da segunda transmissão?: Problema

da ambiguidade da retransmissão.

Para resolver esse problema, o algoritmo de

Karn

especifica que

quando existe um

timeout

e retransmissão, o estimador

rtt

não

é actualizado quando a confirmação chega;

Não se calcula um novo

RTO

enquanto não chegar uma

(89)

Envio de 32768 bytes de

informação;

Informação passa por duas

ligações SLIP de 9600 bits/seg – atrasos;

32 escritas de 1024 bytes:

MTU de 296 da ligação

SLIP, 128 segmentos, cada com 256 bytes de informação: Tempo total de transferência é de 45 seg; Um timeout e 3 retransmissões. Transferência de informação

nos primeiros 3 seg;

Slow start.

Medição do

(90)

Medições do

rtt

Maior parte das implementações TCP derivadas da

Berkeley

medem apenas um

rtt

por ligação em determinado tempo;

Temporização efectuada através do incremento de um contador

de cada vez que a rotina do temporizador de 500 ms é

invocada;

Quando chega uma confirmação com o número de sequência

correcto, o temporizador termina;

Se a informação não foi retransmitida quando a confirmação

chega, o

rtt

e o desvio médio são actualizados, com base nas

medições;

1º segmento – 3

pulsos

do relógio -

rtt

de 1500 ms;

2º segmento – 1

pulso

do relógio -

rtt

de 500 ms;

3º segmento – 2

pulsos

do relógio -

rtt

de 1000 ms.

(91)

Medições do

rtt

Relação entre os

rtts

actuais e os

pulsos

do relógio:

128 segmentos transmitidos, 18

amostras de rtt;

rtt medido, e RTO utilizado pelo

TCP para o timeout;

Faltas das amostras de rtts são

derivadas por retransmissões;

Nesta implementação o RTO

determinado pelo TCP é sempre um múltiplo de 500 ms.

(92)

Cálculo do estimador

rtt

Inicializações, actualizações dos estimadores rtt e cálculo do timeout de

retransmissão;

A = 0 e D = 3 seg;

Timeout inicial de retransmissão: RTO=A+2D=0+2x3=6 seg - RTO

para a transmissão do SYN inicial;

Se o SYN se perder...

Quando ocorre o timeout após 5.802 seg, o RTO é actualizado

RTO=A+4D=0+4x3=12 seg;

O recuo exponencial é aplicado ao RTO de 12:

Como este é o primeiro timeout, utiliza-se um multiplicador de 2: 24 seg; O próximo é determinado utilizando um multiplicador de 4: 48 seg.

Valores de A e D não são actualizados devido à retransmissão; Segmentos de confirmação apenas não têm temporizadores. 1 0.0 slip.1024 > vangogh. dis: S35648001:35648001(0) win 4096 <mss 256> 2 5.802377 (5.8024) slip.1024 > vangogh. dis: S35648001:35648001(0) win 4096<mss 256>

3 6.269395 (0.4670) vangogh.dis > slip.1024: S1365512705:1365512705(0)ack35648002 win 8192<mss 512> 4 6.270796 (0.0014) slip. 1024 > vangogh.dis: .ack1win 4096

(93)

Cálculo do estimador

rtt

Quando a confirmação do primeiro segmento chega, 3 pulsos de

relógio são contados, e os estimadores são inicializados:

A=M+0.5=1.5+0.5=2

D=A/2=1

RTO=A+4D=2+4x1=6 seg;

Confirmação do segundo segmento (1 pulso de relógio):

Err=M-A=0.5-2=-1.5

A=A+gErr=2-0.125x1.5=1.8125

D=D+h(|Err|-D)=1+0.25x(1.5-1)=1.125

(94)

Exemplo de congestão

Transmissão de segmentos de informação; Normal: aumento do número de sequência com o declive sendo a taxa de transmissão; Retransmissões – 3 quebras no gráfico: Apenas um segmento é retransmitido de cada vez. Depois de o segmento

final e do FIN serem enviados, levou 4 seg para receber as 14 confirmações finais.

(95)

1ª retransmissão -segmento 45 é perdido Confirmação de todos até ao byte 6657 8 confirmações com o mesmo número de sequência Recepção do segmento 62 força a retransmissão da informação anterior

(96)

Exemplo de congestão

Algumas implementações não esperam pelo

timeout

, contam o

número de confirmações duplicadas, e quando o terceiro é

recebido, retransmite apenas um segmento, aquele que pensa

que foi perdido

Algoritmo de retransmissão rápida, seguido do algoritmo de

recuperação rápida

Após retransmissão, o emissor continua a transmissão normal

de informação, sem esperar que o outro extremo confirme a

retransmissão

Receptor

Informação recebida em sequência: processo TCP de recepção

passa a informação ao processo de utilizador

Segmento 46 fora de ordem

TCP armazena os 256 bytes e responde com uma confirmação do número de sequência maior recebido

7 segmentos seguintes fora de ordem: informação armazenada pelo processo TCP e confirmações duplicadas são geradas

(97)

Exemplo de congestão

Não existe forma de o TCP avisar o outro extremo que um

segmento falta ou que chega fora de ordem

Envia confirmações do último recebido correctamente

Quando chega o segmento que se perdeu, o receptor TCP passa

essa toda a informação armazenada ao processo de utilizador, e

toda a informação é confirmada

Todas as retransmissões foram causadas por confirmações

duplicadas, indicando que um pacote foi perdido

(98)

Algoritmo evitar congestão

(

congestion avoidance

)

Aumento da janela de congestão: situação em que pacotes são

perdidos

Algoritmo de

congestion avoidance

suportado pelo TCP para

lidar com pacotes perdidos

Duas indicações de perda de pacotes

Timeout

Recepção de confirmações duplicadas

Congestion avoidance

e

slow start

são algoritmos

independentes com objectivos diferentes

Quando existe congestão, é necessário diminuir a taxa de envio

de pacotes, e por isso, o mecanismo de

slow start

ou de

congestion avoidance

são invocados

Timeout – Slow start

Confirmações duplicadas – congestion avoidance

Na prática os dois algoritmos são implementados em conjunto Após slow start pode-se entrar em congestion avoidance

(99)

Algoritmo evitar congestão

(

congestion avoidance

)

Congestion avoidance

e

slow start

requerem que sejam

mantidas 2 variáveis para cada ligação

Janela de congestão, cwnd

Tamanho limite de slow start, ssthresh

Funcionamento da simbiose entre os dois algoritmos

Inicialização: cwnd =1, ssthresh = 65535 bytes Rotina de saída TCP envia min(cwnd , advwnd)

percepção de congestão da rede vs espaço disponível na fila de espera do receptor

Quando ocorre congestionamento, metade do tamanho da janela

corrente é colocado em ssthresh. Se o congestionamento é indicada por um timeout, cwnd é colocada a 1 segmento

(100)

Algoritmo evitar congestão

(

congestion avoidance

)

Funcionamento da simbiose entre os dois algoritmos

(cont):

Quando informação é confirmada,

cwnd

aumenta,

dependente se é efectuado

slow start

ou

congestion

avoidance

:

Se cwnd ≤ ssthresh - slow start; senão congestion avoidance; Slow start continua enquanto a janela for metade da que era

quando ocorreu congestionamento e depois inicia-se

congestion avoidance

cwnd começa com 1 segmento, e é incrementado por 1

segmento por cada confirmação recebida

Em congestion avoidance, cwnd é incrementada por 1/cwnd

cada vez que uma confirmação é recebida: aumento aditivo

Aumento de cwnd de no máximo 1 segmento em cada rtt Slow start – aumento de cwnd do número de confirmações

(101)

Visualização de

slow start

e

congestion avoidance

Assume-se que congestão ocorreu quando cwnd tem um valor de 32 segmentos ssthresh é colocado a 16 segmentos e cwnd a 1

1 segmento é enviado no tempo 0 e, assumindo que confirmação é recebida no

tempo 1, cwnd é incrementada a 2

Crescimento exponencial continua até que cwnd = ssthresh

Após este ponto, o aumento de cwnd é linear, com um aumento máximo de 1

(102)

Algoritmos de retransmissão

rápida e recuperação rápida

TCP tem de gerar uma confirmação imediata (duplicada)

quando recebe um segmento fora de ordem; este tem de ser

gerado sem atrasos

Não sabendo se uma confirmação duplicada é causada por um

segmento perdido ou por reordenação dos segmentos, tem de

se esperar por algumas confirmações duplicadas

Se 3 ou mais confirmações duplicadas existirem, é uma

indicação forte de que um segmento se perdeu

É feita de imediato a retransmissão sem esperar que o

temporizador expire - algoritmo de rápida retransmissão

Depois, o algoritmo de

congestion avoidance

deve ser

(103)

Algoritmos de retransmissão

rápida e recuperação rápida

3 confirmações duplicadas – não existiu

slow start

Se o receptor só pode gerar confirmações duplicadas se outro

segmento seguinte foi recebido, significa que ainda existe

informação a fluir na rede, e não se quer reduzir abruptamente a

taxa de transmissão

Algoritmos de retransmissão e recuperação rápidas:

Quando é recebida a 3º confirmação duplicada, ssthresh =½cwnd

(corrente); retransmite-se o segmento

De cada vez que chega outra confirmação duplicada, cwnd=

cwnd+ss (tamanho do segmento) e transmite um pacote (se possível com o novo cwnd)

Quando vem uma confirmação de nova informação cwnd=ssthresh Este passo é congestion avoidance, dado que se está a diminuir a

taxa de transmissão para metade do valor quando o pacote foi perdido

(104)

Exemplo de congestão

1:257(256) 257:513(256) 513:769(256) 769:1025(256) 1025:1281(256) 1281:1537(256) 1537:1793(256) SYN SYN ACK Envio 1 2 3 4 5 6 7 8 9 10 11 12 Segmento 512 768 885 991 1089 256 256 cwnd slow start slow start cong. Avoid cong. Avoid cong. Avoid Inicializar Retransmissão Comentário ACK 257 ACK 513 ACK 769 ACK 1025 ACK 1281 SYN, ACK Recepção Acção 512 512 512 512 512 65535 512 ssthresh Variável

(105)

Exemplo de congestão

Timeout

– actualização de

ssthresh

e

cwnd

–

slow

start

ACK 257 e ACK 512 – actualização de

cwnd

– ainda

em

slow start

ACK 769 – sistema já não se encontra em

slow start

congestion avoidance

cwnd

←

cwnd

+

segsize

x

segsize/cwnd

+

segsize

/8

Aumento de 1/

cwnd

←

768 + 256 x 256/768 + 256/8 = 885

ACK 1025 -

cwnd

←

885 + 256x256/885 + 256/8 = 991.

(106)

Exemplo de congestão

Cada retransmissão aconteceu devido a 3 confirmações duplicadas: fast retransmit ssthresh é colocado a metade do tamanho da janela, mas cwnd aumenta enquanto as confirmações duplicadas são recebidas - fast recovery

(107)

Exemplo de congestão

Duas confirmações duplicadas -

cwnd

igual

Terceira confirmação –

cwnd

aumenta de 3

segmentos

ssthresh

=1/2

cwnd

=1/2*2048

cwnd

=

ssthresh+3*

ss (1024 + 3 * 256) – retransmissão

Confirmações seguintes -

cwnd

incrementada pelo

tamanho do segmento

Confirmação nova -

cwnd

=

ssthresh

(1024) e

(108)

Erros ICMP

Suporte de mensagens de erro ICMP - erro

de terminal e rede inatingíveis é ignorado,

pois são considerados erros transitórios

Estabilização dos protocolos de encaminhamento quando

existe mudança na topologia da rede

Estes erros não fazem terminar a ligação TCP

TCP continua a enviar a informação que causou o erro,

(109)

Re-paquetização

TCP efectua um

timeout

e retransmite – não tem de retransmitir

um segmento idêntico – repaquetização – envia um segmento

maior.

bsdi % sock svr4 discard hello there

Desligar cabo Ethernet

line number 2 and 3

Religar o cabo

1 0.0 bsdi. 1032 > svr4.discard:P1:13(12) ack1 2 0.14048 (0.1405) svr4.discard > bsdi.1032:.ack13

Cabo Ethernet desligado

3 26.4076 (26.2672) bsdi.1032 > svr4.discard: P13:27(14)ack1 4 27.6393 (1.2317) bsdi.1032 > svr4.discard: P13:27(14)ack1 5 30.6394 (3.0001) bsdi.1032 > svr4.discard: P13:27(14)ack1 Escrita da terceira linha

6 36.6396 (6.0002) bsdi.1032 > svr4.discard: P13:33(20)ack1 7 48.6401 (12.0005) bsdi.1032 > svr4.discard: P13:33(20)ack1 8 72.6407 (24.0006) bsdi.1032 > svr4.discard: P13:33(20)ack1 Cabo religado

(110)

Interacção entre IP e TCP

Forma como os routers tratam os datagramas IP pode ter efeito

significativo no desempenho de uma ligação TCP e na taxa de envio agregada de todas as ligações

Se um router atrasa uns datagramas mais do que outros, temporizador de

retransmissão do TCP é aumentado

Se o atraso excede temporizador de retransmissão, TCP assume que existiu

congestionamento

Router não tem mais capacidade de armazenamento de pacotes e

descarta-os: fila de espera enche

Primeiro algoritmo de escalonamento baseado em tail drop

Quando a fila de espera enche, router descarta todos os datagramas

adicionais; router descarta a cauda da sequência

Muitas perdas colocam TCP em slow start

Quando os datagramas são de várias ligações TCP diferentes

Router descarta segmentos de N ligações e não N segmentos de uma ligação