Cap. 3 O nível de transporte

Transcrição

1 Cap. 3 O nível de transporte

2 Nota prévia A estrutura da apresentação é semelhante e utiliza algumas das figuras, textos e outros materiais do livro de base do curso Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 2

3 Organização do capítulo Serviços do nível transporte Multiplexing / Demultiplexing Estudo do transporte: UDP Como implementar a transferência fiável de dados Transporte orientado conexão: TCP Transferência fiável de dados Controlo de fluxo Gestão da conexão Controlo da saturação Controlo da saturação no protocolo TCP

4 Organização do capítulo Serviços do nível transporte Multiplexing / Demultiplexing Estudo do transporte: UDP Como implementar a transferência fiável de dados Transporte orientado conexão: TCP Transferência fiável de dados Controlo de fluxo Gestão da conexão Controlo da saturação Controlo da saturação no protocolo TCP

5 Nível transporte vs. Nível Rede Nível rede: comunicação HOST-HOST Endereços do nível rede (endereços IP) Nível transporte: comunicaçação PROCESSO-PROCESSO Portos (portos associados aos processos) Unidades de dados ao nível dos protocolos de transporte TPDU (Transport Protocol Data Unit) Transporte de datagramas UDP na pilha TCP/IP: <IP origem, Porto origem, IP destino, porto destino, datagrama UDP> Transporte de segmentos numa conexão TCP na pilha TCP/IP: <IP origem, Porto origem, IP destino, Porto destino, conexão TCP>

6 Protocolos do nível transporte Transporte fiável com ordenação de mensagens (TCP) Controlo de saturação (congestion) application transport network data link physical network data link physical network data link physical Controlo de fluxo (flow-control) Conexão (conection setup) Transporte não fiável e sem garantia de ordenação de mensagens UDP Sem qualquer extensão ao serviço de envio e recepção de datagramas IP (Best Effort) network data link physical network data link physical network data link physical network data link physical application transport network data link physical

7 Transporte processo-a-processo: outros requisitos (não tratados em UDP ou TCP) Aplicações com requisitos particulares de: Correcção de atrasos com controlo de latência variável) Garantias de isocronismo na transferência de mensagens Correcção de efeitos de atrasos variáveis, JITTER ou QoS (garantias de bandwidth mínima constante) Fluxos de cadeias de dados (data streaming, multimedia networking): application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical Protocolos específicos de suporte de aplicação (normalmente usam UDP como transporte base)

8 Papel do nível de transporte Geralmente o nível visível pelas aplicações: central em toda a arquitectura de protocolos Pode providenciar dois tipos de serviços: orientado à conexão (conection-oriented) e não orientado conexão (ou modo datagrama ou connectionless) Razões de ser do nível transporte: Melhorar a qualidade de serviço oferecida pelo nível rede e mascarar as suas deficiências (erros, percas, desordenação, etc.) Agregar/desagregar: multiplexing / demultiplexing Endereçamento extremo a extremo (end-to-end); exemplo: endereço IP + porta Disponibilizar uma interface (API) adequada às aplicações (ex: accept, connect, send, receive, read, write, close, ) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 8

9 Como se desenrola um protocolo de transporte host host API aplicação transporte Mensagens TPDUs (segmentos ou datagramas de transporte) aplicação transporte API rede Pacotes rede (pacotes do nível rede) Data-Link Tramas (frames) Data-Link Interface Física (Nível data link / nível físico) Interface Física Nível de ligação de dados / Nível Físico Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 9

10 Extremos da comunicação ao nível transporte (TCP/IP Communication End Points) Um endereço IP identifica um host. Para identificar o ponto de acesso a um serviço ao nível transporte é necessária alguma forma de desdobramento dentro do host. Em TCP/IP esse desdobramento faz-se através da noção de porta. Um ponto de terminação da comunicação é designado em TCP/IP por socket. Host Endereço IP processos portas e filas de espera Cada fila de espera corresponde a um socket distinto. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 10

11 Portas TCP/IP Portas usados em UDP e TCP estão normalizadas em gamas de utilização. Existe uma gama reservada e outra que pode ser usada para escrever novas aplicações Dentro das gamas reservadas, estão as portas fixas associadas a aplicações normalizadas. Exemplos: HTTP/TCP porta 80, o SMTP/TCP porta 25, FTP/TCP porta 21, DAYTIME/TCP porta 7, GOPHER/TCP porta 70, DNS/UDP 53, etc. Cada servidor que realiza um serviço normalizado tem uma porta fixa associada definida para o respectivo protocolo aplicacional As portas em UDP e TCP correspondem a filas de mensagens independentes mesmo que usem o mesmo número de porta. Ex: a porta 45 em UDP é diferente da porta 45 em TCP A afectação de números de portas normalizadas está a cargo do IANA (Internet Addressing and Naming Authority) Tabela de portos associados a serviços (ex., ver o ficheiro /etc/services) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 11

12 Organização do capítulo Serviços do nível transporte Multiplexing / Demultiplexing Estudo do transporte: UDP Como implementar a transferência fiável de dados Transporte orientado conexão: TCP Transferência fiável de dados Controlo de fluxo Gestão da conexão Controlo da saturação Controlo da saturação no protocolo TCP Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 12

13 Multiplexing / Demultiplexing Agregação/Desagregação Multiplexing and Demultiplexing: determinar qual a fila de espera (e indirectamente o processo) a quem os dados se destinam. Mensagens: application-layer data P1 header TPDU Ht M Hn segment M application transport network P3 Receptor M M application transport network P4 Emissor M P2 application transport network

14 Ex: recepção de datagramas UDP (agregação/desagregação ao longo da pilha) portas udp Dados no TPDU desmultiplexagem pelas portas TPDU ou datagrama UDP desmultiplexagem udp, tcp,... datagrama ip desmultiplexagem ip, icmp, arp,... Frame (trama) cabeçalho frame cabeçalho ip cabeçalho udp dados utilizador Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 14

15 Multiplexing / Demultiplexing (continuação) Os dados são marcados com a porta origem e destino que identificam inequivocamente a origem e o destino dos dados (communication endpoint) 32 bits Porto origem # Porto dest. # Outros campos do cabeçalho Terminologia: também se utilizam os termos segmento TCP, pacote TCP datagrama UDP ou pacote UDP para designar os TPDU TCP e UDP Dados Formato de um TPDU ou segmento Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 15

16 Exemplos com portas TCP host A source port: x dest. port: 23 server B Web client host C source port:23 dest. port: x Exemplo: Telnet Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web client host A Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Exemplo: Web server Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 16

17 Identificação dos sockets O Socket UDP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket. UDP Socket ID = ( local IP address, local port number) Nota: é possível fazer a associação de um socket UDP local a um socket UDP remoto. O Socket TCP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket, assim como pelo endereço IP remoto e a porta remota. TCP Socket ID = ( local IP address, local port number, remote IP address, remote port number) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 17

18 Sockets UDP - Connectionless demux (cont) DatagramSocket serversocket = new DatagramSocket(6428); P2 P3 P1 SP: 6428 DP: 9157 SP: 6428 DP: 5775 client IP: A SP: 9157 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP:B SP provides return address

19 Sockets TCP - Connection-oriented demux (cont) P1 P4 P5 P6 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B

20 Sockets TCP - Connection-oriented demux: Threaded Web Server P1 P4 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B

22 O protocolo UDP Nível de serviço do protocolo UDP Serviço best effort que só acrescenta multiplexagem e desmultiplexagem ao nível rede. As mensagens UDP (Datagramas UDP) podem ser perdidos ou entregues fora de ordem Ausência de conexão ( connectionless ): não é necessário nenhum estabelecimento de conexão ( handshaking ) entre o emissor e o receptor e cada datagrama é processado independentemente dos outros Vantagens do protocolo UDP Sem necessidade de conexão (o que evita um RTT suplementar e vários pacotes extra) Simples - sem estado do lado do emissor ou do receptor Cabeçalho mais pequeno que o TCP (8 bytes ao invés de 20 bytes) Sem controlo de saturação - os dados podem ser enviados à velocidade que o emissor desejar Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 22

23 Utilizações do protocolo UDP Geralmente utilizado pelas aplicações de streaming multimedia Tolerantes à perca de pacotes Sensíveis à velocidade de transmissão Outras utilizações do UDP (pela simplicidade e ausência de necessidade de conexão): DNS SNMP,... Outras vantagens: tráfego broadcasting, multicasting (difusão e comunicação multi-ponto) Se for necessária fiabilidade é sempre possível introduzi-la ao nível aplicação Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 23

24 Os datagramas UDP 32 bits Tamanho, em Bytes, do segmento UDP incluindo o cabeçalho source port # dest port # length checksum Dados aplicação (mensagem) Soma Complemento para 1 de todas as palavras de 16 bits Formato do datagrama UDP Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 24

25 Exemplo Nota Quando se somam números em complemento a 1 s, o carryout do bit mais significativo tem de ser adicionado ao resultado Exemplo: com dois inteiros de 16 bits Wraparound (carry out) sum checksum Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 25

26 Exemplo Soma (P1, P2) P1 P2 P3 Soma (P1,P2,P3) Complemento P1 P2 P3 CS Verif Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 26

27 UDP checksum Objectivo: detectar erros (e.g., bits invertidos) nos segmentos transmitidos Emissor: trata o conteúdo do segmento como uma sequência de inteiros de 16 bits checksum: soma (complemento a 1 s) do conteúdo do segmento O valor calculado é colocado no campo respectivo antes da emissão Receptor: calcula o valor do checksum Compara o valor calculado com o valor do campo do datagrama recebido: o datagrama tem pelo menos um erro = não foram detectados erros. O que não quer dizer que estes não possam existir. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 27

28 Recepção dos datagramas UDP portas udp Processamento de cabeçalhos do TPDU e cópia dos dados para a fila de espera (porta) associada ao processo desmultiplexagem pelas portas dados do datagrama ou tpdu udp Datagrama ou tpdu udp desmultiplexagem udp, tcp,... datagrama ip desmultiplexagem ip, icmp, arp,... frame cabeçalho frame cabeçalho ip cabeçalho udp dados utilizador Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 28

30 Fiabilidade ao nível transporte e data-link Os protocolos de transporte orientados à conexão são em alguma medida semelhantes aos protocolos data-link orientados à conexão. No entanto, dado que o ambiente de execução desses protocolos é muito diferente, os protocolos de transporte são substancialmente mais complexos pois a rede pode memorizar pacotes e trocar-lhes a ordem router canal físico de dados router host router rede router host Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 30

31 Transporte vs. Data-link Endereçamento e eventual necessidade de multiplexagem é mais complexa ao nível transporte A rede tem capacidade de bufferização e pode trocar a ordem dos segmentos O estabelecimento da conexão é mais complexo devido aos dois factores anteriores O dinamismo da rede tem implicações delicadas sobre a performance do nível transporte tendo que se introduzir mecanismos não só de controlo de fluxos, como também de controlo da saturação Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 31

32 Compensação dos erros Os níveis inferiores ao nível de transporte podem introduzir erros, sobretudo perca de pacotes (nível rede) e frames (nível data-link/nível físico) Os frames com erros são em geral recusados ao nível data-link podendo então ser assimilados a pacotes perdidos Os protocolos de transporte que introduzem fiabilidade têm de mascarar os erros, sob pena de violarem a sua especificação Para circuitos com uma taxa de erros elevada no nível data-link, podem usar-se protocolos para mascarar os erros a esse nível Reliable Data-Link Protocols: evitam que os erros se propaguem para os níveis superiores e que sejam estes que os têm de recuperar Uma aplicação que use UDP pode ter de realizar, ao nível aplicação, mecanismos de compensação dos erros Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 32

33 Canal fiável vs. Canal Não Fiável As características de não fiabilidade do canal determinam a complexidade do protocolo de transferência de dados subjacente: primitivas rdt, rdt_send(), rdp_receive() Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 33

34 Processamento dentro do nível transprte: pecepção inicial das primitivas para rdt rdt_send(): chamada down-call, (pela aplicação). Passagem dos dados da aplicação deliver_data(): up-call a partir de rdt para disponibilizar os dados Lado Emissor Lado Receptor udt_send(): chamada downcall, para transferir o pacote de transporte para o serviço não fiável rdt_rcv(): chamada up-call, sempre que chega um pacote no receptor

35 Máquina de estados do emissor e receptor se o canal já fosse fiável Se o canal (underlying) for perfeitamente fiável: Não há erros Nao se perdem pacotes FSMs (Finite-State-Machine) para emissor e receptor: Emissor envia dados para o canal (underlying ) Receptor recebe dados do canal (underlying) Wait for rdt_send(data) call from above packet = make_pkt(data) udt_send(packet) Emissor Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) rreceptor Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 35

36 Protocolo simplista e irrealista Exemplo de um protocolo em que não há erros nem perca de segmentos em que o receptor tem uma capacidade ilimitada de receber segmentos (isto é, que o receptor tem buffers disponíveis ou que a aplicação consome os dados em tempo útil) Todos os segmentos seriam bem recebidos Emissor tempo Receptor Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins DI - FCT/ UNL Transporte / 36

37 Canais não fiáveis introduzem erros (bit errors) e podem perder pacotes Percas ou erros na comunicação Ex., flip bits num pacote checksum permite detectar e descartar Detecção dos erros permite que dados incorrectos não sejam entregues à aplicação Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins DI - FCT/ UNL Transporte / 37

38 Recuperação ou mascaramento de erros Exige feedback do receptor, com controlo de confirmações (ACK,NAK) entre receptor e emissor acknowledgements (ACKs): receptor envia explicitamente ao emissor que o pacote foi bem recebido negative acknowledgements (NAKs): receptor envia explicitamente ao emissor que o pacote chegou com erros O emissor retransmite o pacote ao receber um NAK ou se não receber um ACK dentro de certo time-out ARQ (ou Automatic Repeat request) Protocols Detecção de Erros Feedback do Receptor Retransmissão pelo emissor Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins DI - FCT/ UNL Transporte / 38

39 Introdução de confirmações de recepção Emissor s1 Receptor ack O protocolo pressupõe que os segmentos não se perdem s2 ack Problema: os ACKs podem perder-se! ACK = Acknowledgement (confirmação ou aviso de recepção) tempo s3 ack Receptor saturado s4 Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 39

40 Perca de um segmento s1 Emissor tempo ack s2 ack s3 ack Receptor Quando um ACK se perde há uma situação de bloqueio eterno (deadlock) Como resolver? Introduzir temporização (timeouts) + retransmissão Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 40

41 Introdução de temporizadores (Timeouts) Emissor s1 ack Receptor timeout timeout s2 s2 ack s3 s3 ack tempo duplicado Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 41

42 Problemas ainda mal resolvidos A solução anterior não resolve ainda o problema da perca de um ACK que poderá conduzir à aceitação de um segmento duplicado O mesmo problema poderá ser introduzido por um receptor lento (face ao timeout) a enviar o ACK Um timeout mal regulado, muito curto por exemplo, poderá conduzir ao mesmo problema Na verdade as velocidades relativas do emissor e receptor podem não ser constantes nem conhecidas a priori Note-se que um timeout muito elevado conduz a uma recuperação demasiado lenta de uma perda Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 42

43 Situações patológicas Emissor s1 Receptor timeout Timeout foi demasiado curto... tempo s2 ack s1 Problemas: s1 duplicado s2 perdeu-se Como resolver? > Nºs de sequência s3 Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 43

44 Números de sequência A solução consiste em introduzir números de sequência únicos para cada segmento. Estes números permitem ao receptor distingir dados esperados, dados repetidos, etc. Para se poupar espaço nos cabeçalhos interessa minimizar o número de bits a usar. O número pode então ser reutilizado ciclicamente desde que não se introduza confusão Crítico: regulação em função do ciclo de repetição e possível ocorrência de erros ou percas Notar que se um protocolo pressupõe que o nível de baixo não troca a ordem dos segmentos e que o emissor só avança quando tem a certeza que o receptor recebeu os últimos dados enviados, então um número de sequência representado num só bit seria suficiente Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 44

45 Protocolo stop & wait Emissor s0(0) Receptor timeout s0(0) a(0) timeout s1(1) a(0) ignorar duplicado mas enviar ack s1(1) ignorar ack duplicado a(1) s2(2) tempo a(2) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 45

46 Funcionamento (stop & wait) Emisor: Quando tem um segmento para transmitir, o emissor transmite-o e activa um temporizador. Depois podem suceder os seguintes eventos: O temporizador dispara reenvia o segmento Chega um ACK com o número de sequência esperado - passa adiante Chega um ACK com outro número de sequência - ignora-o Receptor: Quando recebe um segmento, o receptor emite sempre um ACK com o número de sequência igual ao do último segmento recebido correctamente. Se o segmento é novo, guarda-o e dá-o ao nível de cima, senão ignorao pois é um duplicado. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 46

47 Especificação FSM com ACKs ou NAKs rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Emissor Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Recepor

48 Tempo de transmissão e RTT Num canal de Km com a velocidade de transmissão de 1 Mpbs quantos segmentos de 1000 bytes se poderiam transmitir antes que chegue o ack do primeiro? Tt = nº de bits a transmitir / velocidade de transmissão = 8000 bits / bps = 0,008 s = 8 ms Tp = dimensão do canal / velocidade de propagação = km/ km/s = 0,05 s = 50 ms, logo RTT = 100 ms 1000 bytes = 8Kbits Tt Tp Km O ack do segmento chegará 108 ms depois do início da transmissão do mesmo, se se admitir que o tempo de processamento do receptor é nulo e que o tempo de transmissão do ack também é nulo. Resposta: ( Tt + Tp ) / Tt = 108 / 8 = 13,5 segmentos Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 48

49 Desempenho do protocolo Stop & Wait Circuito a 1 Mbps, RTT de 100 ms, frames de 1KB T Transm. = 8000 b/frame 10**6 bps = 8 ms Taxa de utilização = U = Fracção de tempo em que o emissor está a transmitir = 8 ms 108 ms = 0,074 = 7,4 % Conclusão: o protocolo não permite aproveitar completamente a capacidade do circuito! Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 49

50 Desempenho do protocolo Stop & Wait (cont) emissor receptor transmissão do 1º bit, t = 0 transmissão do último bit, t = Tt RTT recepção do 1º bit recepção do último bit, enviar ACK ACK chega, enviar o próximo segmento, t = RTT + Tt Taxa de utilização = U = (sem erros) Tt RTT + Tt = 8 ms 108 ms = 0,074 = 7,4 % Como melhorar? Pipelining no emissor! Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 50

51 Protocolos com pipelining transmissão do 1º bit, t = 0 transmissão do último bit, t = Tt emissor receptor ACK chega, enviar o próximo, t = RTT + Tt RTT 1º bit chega do 1º segmento último bit do 1º seg. chega, enviar ACK último bit do 2º seg. chega, enviar ACK último bit do 3º seg. chega, enviar ACK A taxa de utilização subiu 3 vezes! Taxa de utilização = U = (sem erros) 3 x Tt RTT + Tt = 3 x 8 ms 108 ms = 22,2 % Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 51

52 Protocolos com pipelining Pipelining: o emissor pode avançar e enviar segmentos mesmo que de alguns dos anteriores não esteja ainda confirmada a recepção. Duas formas genéricas destes protocolos: Go-Back-N (ou GBN) selective repeat (ou SR) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 52

53 Pipelining com Go-Back-N O emissor vai transmitindo segmentos para a frente, usando um buffer dito janela do emissor. nºs de sequência Emissor segmentos esquecidos pois já foram acknowledged Janela de emissão buffer de emissão segmentos no buffer de emissão à espera de serem acknowledged futuro nºs de sequência Receptor segmentos esquecidos pois já foram consumidos pelo nível superior segmento esperado pelo receptor (janela de um segmento) futuro Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 53

54 GBN Ex: Janela = 4 Timeout para o pkt2 Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 54

55 Funcionamento no emissor Dispõe de uma janela de até N segmentos consecutivos não acknowledged que pode ir transmitindo (N = tamanho da janela) Coloca um nº de sequência no cabeçalho dos segmentos que emite Activa um timeout para cada segmento transmitido timeout(n): retransmite o segmento emitido há mais tempo e todos os outros até ao fim da janela ( go back N ) ACK(n): confirma todos os segmentos para trás incluindo o do nº de sequência ( cumulative ACK ) pode evitar repetições se possível Há medida que se vão recebendo ACKs, o emissor ai avançando a janela (como se esta deslizasse ) GBN como sliding window peotocol Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 55

56 Máquina de estados do emissor Nota: a gestão dos timeouts indicada ainda está simplificada. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 56

57 Máquina de estados do receptor Recebe segmento com o número de sequência esperado: Entregar os dados ao nível superior Enviar ACK correspondente Recebe segmento fora de ordem (atrasado ou adiantado): Ignorar -> não há buffering suplementar no receptor! Enviar ACK com o nº de sequência do último segmento aceite, isto é, o último que foi retirado do buffer para entregar ao nível superior Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 57

58 O GBN o receptor não controla buffering de pacotes fora de ordem Implicações: - Simplicidade do receptor no controlo de mensagens fora de ordem (para suportar ordenação de mensagens entregues ao nível superior), dado o comportamento do emissor Desvantagem: - Subsequente retransmissão de uma mensagem que já antes tinha chegado correctamente pode depois falhar - Para janelas muito grandes e muitos atrasos (impostos por limitações de largura de banda) tende a haver muitos pacotes no pipeline. Basta um erro num pacote para obrigar à retransmissão de um elevado número de pacotes (o que tb implica que a janela enche) - Implicações no desempenho (pipeline muito preenchido e gera muitas retransmissões que seriam desnecessárias) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 58

59 Generalização: buffer no receptor Emissor segmentos esquecidos pois já foram acknowledged tempo nºs de sequência Receptor buffer de emissão segmentos no buffer de emissão à espera de serem Acknowledged ou com buracos nºs de sequência Janela de emissão futuro Janela de recepção buffer de recepção Notas: > janela do emissor ser >1 permite pipelining > janela do receptor ser > 1 permite memorizar pacotes do futuro ( selective repeat ) > um protocolo com as duas janelas iguais a 1 diz-se ( stop and wait ) segmentos esquecidos pois já foram consumidos pela aplicação segmentos no buffer de recepção à espera de serem consumidos pela aplicação ou à espera de serem contíguos futuro Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 59

60 A janela do receptor ser superior a 1 permite pois optimizar o protocolo GBN timeout ack não chegou ignorados timeout ack8 ack não chegou buffered ignorados Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 60

61 Selective Repeat O receptor envia um ACK de todos os segmentos correctamente recebidos e que conseguiu bufferizar, mesmo recebidos fora de ordem O emissor activa logicamente um timeout para cada segmento enviado e desactiva o respectivo timeout quando recebe um ACK Quando dispara um timeout, o emissor só volta a enviar os segmentos para os quais ainda não tenha recebido um ACK O emissor continua limitado pela dimensão da sua janela Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 61

62 Visão das janelas rcv_base - N Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 62

63 Funcionamento do Selective Repeat Emissor: Dados do nível superior : Se está disponível um nº de sequência na janela, enviar segmento Timeout(n): reenviar segmento n, activar timeout(n) ACK(n) in [sendbase,sendbase +N]: Marcar o segmento n como recebido Se n é o menor segmento unacked, avançar a base da janela para o próximo unacked nº de sequência Receptor: Segmento n in [rcvbase, rcvbase +N-1] Send ACK(n) Out-of-order: bufferizar In-order: entregar (entregar também os outros segmentos contíguos já recebidos), avançar a base da janela para o próximo segmento não recebido Segmento n in [rcvbase-n, rcvbase-1] Send ACK(n) // mesmo que já tenha sido ACKed antes senão: ignorar Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 63

64 Funcionamento do Selective Repeat Transport Layer

65 Piggybacking Na prática os canais são quase sempre full-duplex. A implementação dos 2 canais de dados exigiria 4 canais lógicos por causa dos ACKs. Usa-se então uma técnica chamada piggybacking que consiste em introduzir os ACKs nos segmentos do canal do sentido contrário. Tem no entanto que se tomar em consideração o caso em que o tráfego é assimétrico. dados nº de sequência no sentido do envio nº de sequência do ack do tráfego do sentido contrário Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 65

66 Gestão dos números de sequência (piggybacking em TCP, ex: TELNET) Nºs de sequência: ACKs: Nº do primeiro byte presente no segmento Nº de sequência do próximo byte esperado pelo receptor ACK cumulativo O utilizador escreve C host A recebe o C ecoado Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 host B recebe C, ecoa C Cenário com telnet tempo Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 66

67 Outros mecanismos Uma outra alternativa ao envio de ACK de todos os segmentos recebidos, mesmo fora de ordem, é não enviar senão ACKS acumulados dos dados recebidos na ordem. Enviar NACKs (Negative Acknowledgement) sobre os segmentos em falta para que o emissor retransmita o mais cedo que possível, mesmo antes que o timeout seja desencadeado. Mas se se receber vários ACKs seguidos com o mesmo número de sequência, também se pode concluir que houve um segmento que se perdeu (mesmo que não tenha havido timeout). Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 67

68 Aspectos de dimensionamento de Números de Sequência e Timeouts Nºs de sequência Possuirão sempre um tamanho finito, viajando nos cabeçalhos dos segmentos. Problema da repetição cíclica (tamanho vs. repetição cíclica) Menor tamanho possível para diminuir o cabeçalho Tamanho está relacionado com a gestão das janelas e com a natureza do protocolo Timeouts Gestão e dimensão de janelas no emissor e no receptor Tamanho pode ainda ser condicionado pela necessidade de memorizar ou não os segmentos atasados Fortemente dependente do RTT em cada instante durante a evolução do protocolo Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 68

69 Selective Repeat: dilema devido ao n. de sequência Exemplo: janela = 3 seq # s: 0, 1, 2, 3 O receptor não se apercebe de qq diferença nos dois cenários mostrados! No caso (a) o emissor envia um duplicado, o receptor pensa que é um segmento novo Q: O nº de sequência está relacionado com a gestão e tamanho da janela do receptor.

70 Números de sequência e tamanhos da janela Emissor com janela de dimensão K, receptor com janela de dimensão 1, isto é, Go back N e nível inferior que mantém a ordem dos segmentos e não memoriza os atrasados : K + 1 Emissor e receptor com janelas de dimensão K, nível inferior mantém a ordem dos segmentos e não memoriza os atrasados: 2 K A questão é que pode haver desordenação de segmentos e estes serão entregues em condições de latência variável Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 70

71 Números de sequência e tamanhos da janela Então, uma vez que o nível inferior é o de uma rede que não mantém a ordem dos pacotes e que ainda pode memorizar os atrasados: então os nºs de sequência têm de acomodar o tráfego à velocidade máxima durante o máximo tempo de vida de um pacote (por convenção 3 minutos na Internet). <> Tt / RTT Tamanho da janela de emissão depende da relação RTT / Tt (ou da relação Tp/Tt) e influencia muito o rendimento do protocolo e taxa de utilização do canal Notar que quando a janela de emissão é maior do que 1, uma janela de recepção maior que 1 permite sempre aumentar o rendimento. Notar que o tamanho dos segmentos também é variável (de algumas dezenas de bytes a vários milhares de bytes). Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 71

72 Taxa de utilização de uma canal com janela de emissão igual a 1 T u = T t / (T t + RTT) = T t / T A T u - taxa de utilização T t - tempo de transmissão de um frame T A - tempo que medeia entre o início da transmissão e a recepção do respectivo ack T p - tempo de propagação de extremo a extremo T A = T t + 2 * Tp T u = T t / (T t + 2 * T p ) = 1 / ( T p / T t ) = 1 / ( A ) A = T p / T t = Tempo de propagação / tempo de transmissão O quociente A é tanto maior quanto maior for o tempo de propagação e menor for o tempo de transmissão. Em todos os casos está-se a desprezar o tempo de processamento (pelo receptor) e o tempo de transmissão do ACK. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 72

73 Exemplo num canal de 1 Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tu= 1 / 1+2A A = Tp / Tt Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = 1 / = s = 5 micro segundos A = / 1 = => 1 + 2A aprox. = 1 => Tu = 1 = 100% Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / = 10-3 = 1 ms Tempo de propagação = Tp = 1 / = s = 5 micro segundos A = / 10-3 = => 1 + 2A aprox. = 1 => Tu = 1 = 100% Conclusão: Num canal de pequena dimensão a taxa de utilização é sempre igual a 100% seja qual for a velocidade de transmissão, pois o tempo de propagação é muito reduzido. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 73

74 Exemplo num canal de 200 Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tu= 1 / 1+2A A = Tp / Tt Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = 200 / = s = 1 ms A = 10-3 / 1 = 10-3 => 1 + 2A aprox. = 1 => Tu = 100 % Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / = 10-3 s = 1 ms Tempo de propagação = Tp = 200 / = 10-3 s = 1 ms A = 10-3 / 10-3 = 1 => 1 + 2A = 3 => Tu = 33,33 % Conclusão: Num canal de média dimensão a taxa de utilização é 1 se o canal for de baixa velocidade mas diminui conforme a velocidade de transmissão vai aumentado, ou seja, se a velocidade de transmissão é significativa. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 74

75 Exemplo num canal de Km Funcionando a 1 Kbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / 1000 = 1 s Tempo de propagação = Tp = / = 0,250 s = 250 ms A = 0,250 / 1 = 0,250 => 1 + 2A = 1,5 => Tu = 66,66 % Tu= 1 / 1+2A A = Tp / Tt Funcionando a 1 Mbps (frame médio de 1000 bits) Tempo de transmissão = Tt = 1000 / = 10-3 s = 1 ms Tempo de propagação = Tp = / = 0,250 s = 250 ms A = 250 / 1 = 250 => 1 + 2A = 501 => Tu = 0,2 % Conclusão: Num canal de grande dimensão a velocidade de propagação é sempre significativa: janelas = 1 seria sempre uma má ideia!!! Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 75

76 Conclusões 1. Se a relação 1 + 2*Tp / Tt = 1 + 2A é próxima de 1, ou seja, quando o tempo de propagação é muito pequeno, uma janela de emissão de dimensão 1 pode ser adequada. 2. Caso essa relação seja > 1, (i.e, quando o tempo de propagação começa a ser significativo face ao tempo de transmissão), é sempre necessário aumentar a janela de emissão para aumentar a taxa de utilização. 3. A janela de recepção > 1 destina-se a recuperar melhor dos erros e a acomodar melhor as variações de velocidade do receptor ou poder evitar retransmissões de segmentos fora de ordem. Na ausência de erros, não garante só por si aumento de rendimento. 4. Quando a janela de emissão > 1, a taxa de utilização é aumentada proporcionalmente (sem poder ultrapassar 100 % como é óbvio). 5. Numa conexão de transporte, a rede pode introduzir um tempo de propagação significativo (como num canal de grande dimensão) pelo que uma janela de emissão igual a 1 seria sempre uma má ideia. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 76

77 Dimensionamento de timeouts O valor dos timeouts deve ser superior ao RTT. Um timeout demasiado curto ou demasiado longo diminui o rendimento do protocolo. Tradeoff: Retransmissão extemporânea vs. Lentidão de recuperação Um protocolo do nível transporte tem que avaliar dinamicamente o RTT para afinar o valor do time-out mais adequado no momento do envio de um segmento. Idealmente: TIMEOUT (SEGi) = Estimated RTT + DELTA Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 77

79 O Protocolo TCP Vinton Cerf*, Robert Khan*, IEEE Transactions on Communications Technology, May 74 * ACM s 2004 Turing Award Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 79

80 TCP: o protocolo RFCs: 793, 1122, 1323, 2018, 2581 Ponto a ponto: Um emissor e um receptor Byte stream ordenado e fiável: Não há delimitadores de mensagens MSS: Maximum Segment Size Pipelined: A janela do emissor é ajustada dinamicamente buffers de emissão e recepção full duplex: Cada conexão é bidireccional MSS: maximum segment size Orientado conexão: Um hand shaking (troca de mensagens de controlo) tem de ter lugar antes de qualquer troca de dados flow controlled: O emissor não afoga o receptor Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 80

81 O protocolo TCP Connection oriented, reliable, full-duplex, end-to-end transport Stream oriented byte flow (unstructured) Um processo pode trabalhar simultaneamente com várias conexões Trabalha com "segmentos TCP" de comprimento variável (até MSS) e acomoda-se a canais com diferentes MTUs (Maximum Transfer Units) Implementa controlo de fluxo e fiabilidade através das técnicas de sliding window estudadas Utiliza temporizadores ajustados dinamicamente à situação da rede (RTTs estimados) Implementa controlo da saturação da rede Implementa um mecanismo de handshaking para estabelecimento da conexão (3 handshake): INIT ACK INIT ACK ACK INIT Implementa um mecanismo de controlo de fecho de conexão (FIN ACK FIN emissor; FIN ACK FIN receptor A terminação da conexão é ordenada e simétrica, isto é, espera até todos os dados serem recebidos de ambos os extremos Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 81

82 Conexões TCP Estabelecem canais full duplex (bi-direccionais) entre os extremos da comunicação socket = ( endereço IP, porta ) socket 1 socket 2 reliable, serial, full-duplex byte stream Uma conexão é inequivocamente identificada pelo par (socket 1, socket 2) Ou... (EndIP origem, porta origem, End. IP destino, porta destino, Conexão TCP) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 82

83 Conexões TCP Ex server: ServerSocket serversocket = new ServerSocket (port) Ex cliente: Socket clientsocket=new Socket ( hostname, port); socket 1 socket 2 RFC 793: (sic) send that data in segments at its own convenience MSS: determinado a partir do MTU (link-frame) do host emissor, para poder ser encapsulado num pacote IP que caiba numa frame data-link (Ex: 1460 bytes, 536 bytes, 512 bytes ) RFC 1191: path MTU para determinação do MSS Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 83

85 Transferência fíável de dados em TCP Usa as técnicas anteriormente apresentadas: aproximação hibrida entre GoBack N e Selective Repeat - Pipelining / Sliding window - Timeouts + Retransmission - Sequence Numbers: (size of segment control) + ACKs - Piggypacked ACKs - Cumulative ACK - Timeout estimation vs. RTT probing Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 85

86 O segmento TCP Ports Header Length (4 bits: nº de palavras de 32 bits Flags: URG: urgent data ACK: o campo de ACK é válido PSH: push data now RST, SYN, FIN: (Flags de controlo da conexão) head len source port 32 bits sequence number Dados (variável) dest port acknowledgement number not used U A P R S F checksum rcvr window size ptr urgent data Opções (variável) Contadores em bytes (não em segmentos!) Nº de bytes que o receptor pode aceitar Urgent Data (flag U) Internet checksum Opções: MSS,, Windows Scale Factor, NAKs,, Timestamps, Probing, RFC 854, RFC 1323 Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 86

87 Alguns dados sobre o cabeçalho Um segmento TCP pode ter no máximo bytes de dados (mas na prática são menores: os datagramas IP são na prática raramente superiores ao paylaod da frame data-link (ex., 1500 bits no caso de um nível data-link suportado numa ethernet) Os números de sequência são dos bytes transmitidos; o ack number denota o próximo byte esperado e não o último correctamente recebido TCP Header Length, indica o número de palavras de 32 bits do cabeçalho e é necessário devido às opções O campo Flags permite passar informação de controlo Window size permite indicar à outra extremidade quanto espaço há livre no buffer de recepção do emissor; o valor 0 é legal e permite indicar que o emissor está sem espaço. Campo de opções ex., permite negociar o MSS a usar na conexão, window scale option, utilização de negative acknowledgements, echo e echo reply probings,... etc Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 87

88 Gestao de números de sequência Byte Stream NUMBER do 1º BYTE DO SEGMENTO (e não o número de sequência de segmentos transmitidos) Ex: Enviar 500 KBytes MSS = 1KByte Nºs sequência: Sinit, Sinit+1000, Sinit+2000, A B B envia ACK de Sinit enviando Sinit+1000 B envia ACK de Sinit+1000 com Sinit+2000 Etc Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 88

89 Gestão dos números de sequência (piggybacking em TCP, ex: TELNET) Nºs de sequência: ACKs: Nº do primeiro byte presente no segmento Nº de sequência do próximo byte esperado pelo receptor ACK cumulativo O utilizador escreve C host A recebe o C ecoado Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 host B recebe C, ecoa C Cenário com telnet tempo Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 89

90 O segmento TCP: Flags do cabeçalho 32 bits Flags: URG: urgent data ACK: o campo de ACK é válido PSH: push data now RST, SYN, FIN: (flags de controlo da conexão) head len source port sequence number Dados (variável) dest port acknowledgement number not used U A P R S F checksum rcvr window size ptr urgent data Opções (variável) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 90

91 Flags e segmentos de controlo Cada segmento pode ou não ter flags posicionadas. Um segmento com flags posicionadas e sem dados é só de controlo. As flags são: ACK - Acknowledgement field is valid RST - Reset the connection (idem reject) SYN - Synchronyze sequence numbers (abertura da conexão com SYN = 1 e ACK = 0) FIN - Sender has reached the end of its byte stream (fecho da conexão) URG - Urgent pointer field is valid PSH - This segment requests a PUSH (o receptor não deve armazenar estes dados à espera de mais, devendo entregá-los imediatamente à aplicação) Os segmentos com SYN e FIN também têm números de sequência para poderem ser retransmitidos em caso de perca e para ambas as partes se colocarem de acordo sobre os valores iniciais (no caso do SYN). Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 91

92 Cenários de retransmissão Host A Host B Host A Host B timeout X loss Seq=92, 8 bytes data ACK=100 Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data SendBase = 100 time Seq=92, 8 bytes data ACK=100 Perca de um ACK Sendbase = 100 SendBase = 120 SendBase = 120 time Seq=92, 8 bytes data Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 92 Seq=92 timeout Timeout prematuro, ACKs cumulativos

93 Cenário com ACK acumulativo Host A Host B Seq=92, 8 bytes data timeout Seq=100, 20 bytes data X loss ACK=100 SendBase = 120 ACK=120 time Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 93

94 A gestão de timeouts em TCP P: Como determinar o valor do timeout? P: Como determinar o RTT? Maior que o RTT mas o RTT é variável! Demasiado curto: timeout prematuro Retransmissões desnecessárias Demasiado longo: reacção lenta à perca de segmentos RTTmedido: medir o tempo que medeia entre a transmissão e a recepção do ACK Ignorar as retransmissões e os segmentos cumulativamente ACKed O valor medido irá variar, pretende-se um RTT estimado menos sujeito a picos (smoother ou alisado ) Usar várias medidas e fazer médias, não usar apenas o último valor lido Idealmente: TIMEOUT (SEGi) = Estimated RTT + DELTA Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 94

95 Distribuição do valor do RTT probabilidade 0.3 Canal Físico 0.2 probabilidade Caso da INTERNET RTT (ms) RTT (ms) Distribuição da probabilidade do valor do RTT (round trip time Verifica-se que em função da carga da rede, existe uma grande variância do RTT: Numa rede carregada a 50% o RTT pode variar num factor de 4, Numa rede carregada a 90% o RTT pode variar num factor de 16 Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 95

96 Round Trip Time e Timeout Cálculo do RTT: Trata-se de uma amostragem pesada: a influência da última amostra decresce exponencialmente Valor típico de α : EstimatedRTT = (1- α)* EstimatedRTT + α * SampleRTT = * EstimatedRTT * SampleRTT Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 96

97 Exemplo da situação Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 97

98 Timeout vs. RTT EstimatedRTT = (1- α)* EstimatedRTT + α * SampleRTT = * EstimatedRTT * SampleRTT Valor do timeout a usar: TIMEOUT = RTTestimado + DELTA margem de segurança Grande variação do RTTestimado -> maior margem de segurança para valor DELTA DELTA = DevRTT : RTT variation (RFC 2988) DevRTT = (1-β)* DevRTT + β* SampleRTT-EstimatedRTT (tipicamente, β = 0.25) Idealmente: TimeoutInterval TIMEOUT = (SEGi) EstimatedRTT = Estimated + 4*DevRTT + DELTA Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 98

99 NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP visão resumida do processamento no emissor SendBase-1: last cumulatively ACKed byte Ex: SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is ACKed

100 Aspectos de optimização da gestão de timeouts Timeouts individuais calculados por cada segmento a enviar pelo emissor? Problemas? Evitar overhead usando um valor de referência (que vai sendo calculado como amostras em diferentes instantes - RFC 2988) Considerar apenas a estimativa de RTTs e cálculo de timeouts para segmentos não retransmitidos Como calcular timeouts no caso de segmentos retransmitidos? Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 100

101 Timeouts no caso de retransmissões O RTT dos segmentos retransmitidos não é usado para a estimativa do valor do timeout Sempre que se perde um segmento o valor do timeout usado é duplicado momentaneamente Permite de forma simples (ainda que limitada) um controlo de saturação Mas se houver retransmissões sucessivas (por perca de segmentos), o intervalo de timeouts para essas retransmssões cresce exponencialmente => possíveis aumentos signifiativos na latência. Como evitar? Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 101

102 Retransmissão rápida (após triplo ACK) Mecanismo que compensa a situação de um timeout poder tornar-se muito longo e implicar numa recuperação muito lenta de um segmento perdido TCP na sua aproximação standard (especificação) não utiliza NAKs (a não ser como opção) mas a recepção de ACKs duplicados pode ser interpretada como um NACK Se o emissor receber 3 ACKs com o mesmo número de sequência retransmite com urgência o segmento respectivo ao ACK recebido: fast retransmit: reenviar os segmentos antes de o timeout expirar Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 102

103 Retransmissão rápida (exemplo) Host A Host B triple duplicate ACKs seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 X ACK x1 ACK x1 ACK x1 ACK x1 resend seq X2 timeout time

104 Algoritmo para Fast Retransmission event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit

105 Gestão de ACKS [RFC 1122, RFC 2581] Evento Segmentos recebidos ordenados com números de sequência esperados, todos os segmentos anteriores já ACKed Segmentos recebidos na ordem esperada, todos os segmentos anteriores já ACKed menos um Segmento fora de ordem (gerando um buraco na janela de recepção) Chegada de um segmento que preenche parcial ou totalmente um buraco Acção do receptor Delayed ACK: esperar até 500ms por outro segmento na ordem. Se este não chegar enviar ACK Enviar imediatamente um ACK acumulativo Enviar ACK duplicado, indicando o nº de sequência do próximo byte esperado (o 1º do 1º buraco) Envio imediato de um ACK acumulativo Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 105

107 Controlo de fluxo Controlo de fluxo O emissor não satura os buffers do receptor por transmitir muito ou muito depressa, adaptando a velocidade da emissão à velocidade da recepção Não confundir com controlo de saturação (embora ambas as situações sejam controladas pelo emissor, reduzindo a emissão de pacotes) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 107

108 Controlo de fluxo Receptor: informa explicitamente o emissor do espaço livre no buffer de recepção RcvBuffer = tamanho do Buffer de recepção rwnd = RcvWindow = espaço livre no Buffer rwnd= RcvBuffer [LastByteRecvd LastByteRead] Enia rwnd no Campo RcvWindow no segmento TCP Buffer do receptor Emissor: evita que a dimensão dos dados ainda não confirmados (unacked) ultrapasse o valor de RcvWindow [LastByteSent LastByteAck] <= rwnd Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 108

110 Estabelecimento da conexão Three way handshake: 1: o cliente envia um segmento de controlo com a flag SYN posicionada para o servidor Com o nº de sequência inicial do cliente Payload sem dados 2: o servidor recebe o SYN, responde com um segmento de controlo com as flags SYN e ACK, isto é: ACK do SYN Inicia o buffer Especifica o nº de sequência inicial do servidor Payload sem dados 3: o cliente responde com um segmento de ACK Eventualmente (!!!) pode já enviar dados (payload) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 110

111 Funcionamento Tempo Host A SYN (seq = x ) Nº Seq. Inicial Host B SYN, ACK (seq=y, ack=x+1 ) Aloca Buffers + variáveis de sessão Aloca Buffers + variáveis de sessão Data, ACK (seq=x+1, ack=y+1 ) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 111

112 Números de sequência iniciais É essencial que, dadas as características da rede, os pacotes atrasados de uma conexão fechada não sejam interpretados como pacotes válidos de uma nova conexão entre os mesmos sockets. As técnicas usadas para lidar com este problema são uma ou mais das várias apresentadas a seguir: Ao fechar-se normalmente uma conexão espera-se o Maximum Network Packet Life Time ( MNPLT) antes de libertar as portas e os números de sequência ( estado TIME-WAIT no fecho de um socket que dura 30 segundos em algumas implementações pode atingir 1 ou 2 minutos). Após o boot espera-se o MNPLT Determinar o MNPLT adequado é delicado, o que conduz a valores muito elevados deste parâmetro, e portanto desinteressantes (actualmente vale 3 minutos) Usa-se um relógio monotonicamente crescente para gerar os números de sequência iniciais o que exige números de sequência com muitos bits se os canais admitem grandes velocidades de transmissão Usam-se números pseudo-aleatórios (usando o relógio da máquina como ponto de partida) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 112

113 Fecho da conexão com um protocolo assimétrico Host A Host B data Tempo disconnect request data Este protocolo conduziria à quebra abrupta de conexões com perca de dados Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 113

114 Fecho da conexão TCP Host A Host B Tempo disconnect request (FIN, seq = x ) ack ( ACK, ack = x+1 ) timeout disconnect request (FIN, seq = y, ack = x+1 ) ack ( ACK, ack = y+1 ) fim Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 114

115 Evolução do estado de uma conexão 30 s a 2 min TCP server lifecycle TCP client lifecycle Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 115

116 Ataques à disponibilidade (DoS) SYN Flood Attacks na abertura de conexões: - Estados de conexão imcompleta dos servidores => exaustão de recursos Solução via SYN Cookies SYN Cookie (como número de sequência NS gerado) = Hash (IPclient, PortClient, IPServer, PortServer, SecretNumber T ) gerado pelo servidor após recepção do segmento SYN SYNCookie enviado como nº de sequência no segmento SYNACK Clientes correctos devem mandar NS+1 no ACK ao SYNACK T mod 32 M SynCookie 5 bits 3 bits 24 bits Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 116

117 Ataques à disponibilidade (DDoS) SYN Flood Completed-Handshake Attacks na abertura de conexões: Não têm solução via SYN Cookies Milhares ou Dezenas de Mihares de clientes incorrectos procedem correctamente enviando o SYN cookie no ACK ao SYNACK Os diversos clientes apresentam-se com diferentes endereços IP (conjugação com ataques Sybill usando múltiplos endereços IP) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 117

119 Princípios do controlo da saturação (congestion control) Controlo de Saturação: informalmente: demasiados pacotes estão a ser injectados na rede para a capacidade que esta tem de os encaminhar diferente de controlo de fluxo! sintomas: Perca de pacotes (buffers com overflows) Tempos de trânsito elevados (filas de espera de dimensão elevada queueing) Tempos de trânsito com uma grande instabilidade (a rede está em rotura e tem comportamentos limite) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 119

120 Origens e consequências da saturação A saturação da rede implica um aumento significativo do tempo de trânsito dentro da rede Este aumento do tempo de trânsito conduz ao aumento das retransmissões Retransmissões são uma resposta a um sintoma de perca de pacotes (que pode estar a ser provocada eventualmente por saturação na rede) Mas as retransmissões não actual sobre as causas da saturação Muitas dessas retransmissões revelam-se inúteis, pelo que conduzem a um desperdício da capacidade da rede Devido também ao aumento das filas de espera, muitos pacotes são suprimidos. Cada pacote suprimido no interior da rede implica o desperdício da capacidade da mesma até aí consumida Em condições de saturação da rede, o rendimento desta começa a decair e a percentagem da sua capacidade que é aproveitada de forma útil decai também Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 120

121 Causas e consequências da saturação: cenario 1 Dois emissores e dois recetores Host A λ in : original data λ out um router, buffers infinitos Host B unlimited shared output link buffers Não necesidade de retransmissão Em caso de saturação: atrasos significativos Quando se atinge o máximo throuhput

122 Causas e consequências da saturação: cenário 2 Um router, mas buffers finitos Haverão retransmissões de pacotes pelo emissor Host A λ in : original data λ' in : original data, plus retransmitted data λ ou t Host B finite shared output link buffers

123 Consequências no cenário 2 Tem que se verificar : λ = λ in out (goodput) Retransmissão (perfeita) se houver percas : λ in > λ out Retransmissão de pacotes não necessariamente perdidos causa um maior λ in para um certo valor de λ out Melhor hipótese: nenhuma ou quase nenhuma retransmissão λ out R/2 λ in R/2 R/2 Outra hipótese: R/3 em cada 0.5 R, 2/3 são dados originais e 1/3 são retransmissões λ out λ in R/2 Caso em que cada pacote foi sempre R/4 retransmitido uma vez λ out R/2 λ in R/2 Implicações da saturação: - Mais trabalho (retransmissões) - Retransmissões desnecessárias: link carries multiple copies of pkt

124 Causas e consequências da saturação: cenário 3 4 emissores Múltiplas rotas (multi-hop) timeout/retransmissões Q: o que acontece se λ in e aumentam? λ in Host A λ in : original data λ' in : original data, plus retransmitted data finite shared output link buffers λ out Host B

125 Conclusões A saturação: conduz a um comportamento em que o rendimento da rede decresce rapidamente tem por sintomas: perca de pacotes, tempos de trânsito elevados, tempos de trânsito com uma grande instabilidade Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 125

126 Como lidar com a saturação? O equipamento de rede lida com a saturação suprimindo os pacotes que não consegue encaminhar No entanto, tal medida (só por si) não permite maximizar o rendimento da rede Uma supressão indiscriminada e inadequada pode até contribuir para o agravamento da situação É necessário encontrar formas de adaptar a procura à oferta e tal passa necessariamente por os hosts abrandarem o ritmo de geração de novo tráfego > Os hosts têm pois de ser notificados ou pelo menos reagirem à saturação Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 126

127 Aproximações ao controlo da saturação Existem duas classes de aproximações (e também utilizações conjuntas das mesmas): End-end: Os routers não dão feedback explícito da saturação O host final é que se apercebe da saturação pelo aumento do tempo de trânsito e pela perca de pacotes Aproximação usada pelo protocolo TCP Network-assisted: Os routers dão feedback explícito sobre a saturação aos hosts: Um bit assinala a saturação (SNA, DECbit, TCP/IP ECN, ATM) É eventualmente explicitado o ritmo a que o emissor deve transmitir Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 127

129 Controlo da saturação do protocolo TCP Solução: Controlo extremo a extremo ( end-end - sem suporte explícito da rede) Controlo de saturação na janela de transmissão Janela com W segmentos, cada um com MSS bytes, transmitidos em cada RTT, conduzem ao seguinte ritmo de transmissão: throughput = W * MSS RTT Bytes/sec Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 129

130 Filosofia do controlo da saturação em TCP Probing da banda passante disponível: Transmitir tão rápido quanto possível sem perca de segmentos Ir incrementando a janela até à perca de segmentos (saturação) Perante a perca, decrementar a janela e depois recomeçar a fazer probing Duas fases de controlo de saturação Slow start Congestion avoidance Variáveis de controlo Congwin (janela de saturação) Threshold (Valor limite para controlo das duas fases) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 130

131 Controlo da saturação do protocolo TCP Congwin (janela de saturação) Threshold (valor limite) Janela variável (crescendo e diminuindo), com W segmentos, cada um com MSS bytes, transmitidos em cada RTT mas limitada por congwin, regula o ritmo de transmissão: W Wmax (t) * MSS (t) * MSS Throughputmax(t) throughput(t) = = RTT Bytes/sec RTT min Bytes/sec Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 131

132 Controlo da saturação do protocolo TCP Congwin (janela de saturação) Threshold (valor limite) Maximum allowed window = minimum ( Receiver Window, Congwin ) Slow Start Congestion Avoidance W Wmax (t) * MSS (t) * MSS Throughputmax(t) throughput(t) = = RTT Bytes/sec RTT min Bytes/sec Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 132

133 Gestão da janela do emissor do ponto de vista da saturação Slow start Maximum allowed window = minimum ( Receiver Window, Congwin ) Congestion window gerida da seguinte forma durante esta fase: 1) No início ou após um período de saturação, o valor é igual a um segmento (equivalente ao MSS Maximum Segment Size ) 2) Por cada ACK chegado ao receptor (acked), Congwin é incrementada de 1 MSS (logo, duplica em cada RTT) Esta estratégia conduz a uma subida exponencial do valor de Congwin. Quando surge um timeout, anota-se o valor na variável Threshold e inicializa-se Congwin ao valor do MSS de novo. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 133

134 TCP Slowstart Slowstart algorithm Host A Host B início: Congwin = 1 para (cada segmento ACKed) Congwin = Congwin+1 MSS até (loss event OR CongWin > Threshold) RTT one segment two segments four segments Aumento exponencial (por RTT) da dimensão da janela time Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 134

135 Segunda fase subida linear Congestion avoidance /* slowstart acabou pois */ /* Congwin > threshold */ Até (loss event) { por cada w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 Recomeçar a fase slowstart Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 135

136 Variantes (Tahoe vs. Reno) O Algoritmo descrito tem a designação de TCP Tahoe. A variante corrente, designada por TCP Reno, trata a perca de um pacote isolado (assinalada por aparecerem 3 ACKs seguidos da mesma sequência) de forma diferente. Com TCP Reno, quando a perca isolada de um pacote é detectada, a Congwin é reduzida a metade mas a fase slow start é evitada entrando-se logo na fase de subida linear ( congestion avoidance ). Existem outras variantes mais modernas deste algoritmo (TCP Vegas, etc.) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 136

137 Tahoe vs. Reno Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 137

138 Visão sintética Se a CongWin está abaixo de Threshold, o emissor está na fase slow-start, a janela cresce exponencialmente. Quando a CongWin está acima de Threshold, o emissor está na fase congestion-avoidance, a janela cresce linearmente. Se ocorre um triple duplicate ACK, Threshold = CongWin/2 e CongWin = Threshold. Se ocore um timeout, Threshold = CongWin/2 e CongWin = 1 MSS (ou CongWin = Thereshold - Reno) Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 138

139 Acções Event State TCP Sender Action Commentary ACK receipt for previously unacked data Slow Start (SS) CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance Resulting in a doubling of CongWin every RTT ACK receipt for previously unacked data Congestion Avoidance (CA) CongWin = CongWin+MSS * (MSS/ CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT Loss event detected by triple duplicate ACK SS or CA Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Timeout SS or CA Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start Duplicate ACK SS or CA Increment duplicate ACK count for segment being acked Enter slow start CongWin and Threshold not changed Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 139

140 Filosofia do TCP perante a saturação real O protocolo TCP procura encontrar um ponto de equilíbrio que permita extrair o máximo de rendimento da rede sem provocar saturação Quando a rede está saturada, o desvio padrão do RTT começa a aumentar significativamente, pelo que o valor do timeout usado também aumenta significativamente Ao mesmo tempo perdem-se pacotes pelo que Congwin tem frequentemente o valor de um MSS e o valor do time-out é duplicado Este conjunto de factores conduz a que o desempenho das ligações TCP nestas circunstância seja muito afectado Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 140

141 Desempenho do TCP Quando a janela tem a dimensão W (em bytes) e está estável, a taxa ou velocidade de transmissão ou capacidade, da conexão TCP, é: W / RTT No entanto, a conexão nunca tem o mesmo valor de janela pois o TCP tentaria aumentar a mesma. Admitindo que o valor máximo que não provocaria saturação fosse W, quando a janela tiver W+MSS aparece um timeout e a mesma é reduzida a W/2, pelo que, desprezando a fase de slow start, a taxa de transmissão da conexão fica reduzida a: W / 2. RTT Assim, dado o valor da janela variar constantemente entre W / 2 e W, podese considerar que em velocidade de cruzeiro a taxa de transmissão da conexão TCP será: 0,75. W / RTT W / RTT é a fracção máxima da capacidade da rede que a conexão poderia usar. Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 141

142 Variação da janela Long-lived TCP connection Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 142

143 Equidade (ou fairness ) do protocolo TCP Se o protocolo TCP for equitativo, então se N conexões TCP partilham um link, cada uma deveria obter 1/N da capacidade do link TCP connection 1 TCP connection 2 bottleneck router capacity R Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 143

144 Ilustração intuitiva Duas conexões: Consideremos que cada uma está já na fase congestion avoidance Sempre que há perca de pacotes o valor de Treshold é dividido por 2 R equal bandwidth share Connection 2 throughput Connection 1 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase R Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 144

145 Conclusão Se a rede só tivesse tráfego TCP, os canais seriam partilhados com bastante equidade ( fairness ou justiça) Tal não é verdade pois existem outros tipos de tráfego (UDP) A saturação penaliza o tráfego TCP mais do que outros tipos de tráfego Uma aplicação que use várias conexões TCP em paralelo obtêm uma fracção mais significativa da banda do que uma que só utilize uma conexão Este aspecto é tanto mais verdade quanto mais saturada estiver a rede Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins Copyright DI - FCT/ UNL Transporte / 145

Exibir mais