Baixe Exercicios do capitulo 3 de redes - UNIFESP e outras Exercícios em PDF para Redes de Computadores, somente na Docsity!
Lista - Camada de Transporte Redes de Computadores Instituto de Ciência e Tecnologia - ICT Universidade Federal de São Paulo - UNIFESP 2o semestre de 2021
Observações:
- Lista de exercícios para fixação de conteúdo.
- Livro texto onde se encontram as questões:
- KUROSE, James F.; Ross, Keith W.. Redes de computadores e a internet: uma abordagem top- down. 5.ed. São Paulo: Addison-Wesley, 2010.
- A resolução da lista é INDIVIDUAL.
- Para cada questão, crie uma caixa de texto e a utilize para responder.
- As respostas são dissertativas. Pondere completude e objetividade nas respostas.
Nome:
Micael de Oliveira Pimpim
Exercícios de Fixação (pág. 215): 3, 4, 6, 7, 8, 9, 10, 11, 14, 15, 17
Problemas (pag. 216) 5, 6, 7, 14, 21, 33, 39
Questões Dissertativas (pag. 224) 2, 4
Perguntas
Fixação: 3- Considere uma conexão TCP entre o hospedeiro A e o hospedeiro B. Suponha que os segmentos TCP que trafegam do hospedeiro A para o hospedeiro B tenham número de porta da fonte x e número ele porta do destino y. Quais são os números de porta da fonte e do destino para os segmentos que trafegam do hospedeiro B para o hospedeiro A?
4- Descreva por que um desenvolvedor de aplicação pode escolher rodar uma aplicação sobre UDP em vez de sobre TCP.
6- É possível que uma aplicação desfrute de transferência confiável de dados mesmo quando roda sobre UDP? Caso a resposta seja afirmativa, como isso acontece?
7- Suponha que um processo no Computador C possua um socket UDP com número de porta 6789 e que o Computador A e o Computador B, individualmente, enviem um segmento UDP ao Computador C com número de porta de destino 6789. Esses dois segmentos serão encaminhados para o mesmo socket no Computador C? Se sim, como o
processo no Computador C saberá que esses dois segmentos vieram de dois computadores diferentes?
8- Suponha que um servidor da Web seja executado no Computador C na porta 80. Esse servidor utiliza conexões contínuas e, no momento, está recebendo solicitações de dois computadores diferentes, A e B. Todas as solicitações estão sendo enviadas através do mesmo socket no Computador C? Se eles estão passando por diferentes sockets, dois desses sockets possuem porta 80? Discuta e explique.
9- Nos nossos protocolos rdt, por que precisamos introduzir números de sequência?
10- Nos nossos protocolos rdt, por que precisamos introduzir tem temporizadores?
11- Suponha que o atraso de viagem de ida e volta entre o emissor e o receptor seja constante e conhecido para o emissor. Ainda seria necessário um temporizador no protocolo rdt 3.0, supondo que os pacotes podem ser perdidos? Explique.
14- Verdadeiro ou falso:
A. O hospedeiro A está enviando ao hospedeiro B um arquivo grande por uma conexão TCP. Suponha que o hospedeiro B não tenha dados para enviar para o hospedeiro A. O hospedeiro B não enviará reconhecimentos para o hospedeiro A porque ele não pode dar carona aos reconhecimentos dos dados. B. O tamanho de rwnd do TCP nunca muda enquanto dura a conexão. C. Suponha que o hospedeiro A esteja enviando ao hospedeiro B um arquivo grande por uma conexão TCP. O número de bytes não reconhecidos que o hospedeiro A envia não pode exceder o tamanho do buffer de recepção. D. Imagine que o hospedeiro A esteja enviando ao hospedeiro B um arquivo grande por uma conexão TCP. Se o número de sequência para um segmento dessa conexão for m, então o número de sequência para o segmento subsequente será necessariamente m + 1. E. O segmento TCP tem um campo em seu cabeçalho para Rwnd. F. Suponha que o último SampleRTT de uma conexão TCP seja igual a 1 segundo. Então, o valor corrente de Timeout Interval para a conexão será necessariamente ajustado para um valor 1 segundo. G. Imagine que o hospedeiro A envie ao hospedeiro B, por uma conexão TCP, um segmento com o número de sequência 38 e 4 bytes de dados. Nesse mesmo segmento, o número de reconhecimento será necessariamente 42.
15- Suponha que o hospedeiro A envie dois segmentos TCP um atrás do outro ao hospedeiro B sobre uma conexão TCP. O primeiro segmento tem número de sequência 90 e o segundo, número de sequência 110.
A. Quantos dados tem o primeiro segmento? B. Suponha que o primeiro segmento seja perdido, mas o segundo chegue a B. No reconhecimento que B envia a A, qual será o número de reconhecimento?
transferência de dados). O que aconteceria se todas as aplicações tentassem melhorar seus desempenhos utilizando conexões múltiplas? Cite algumas das dificuldades envolvidas na utilização de um elemento da rede para determinar se uma aplicação está ou não usando conexões TCP múltiplas.
Respostas Fixação: 3- Os números de porta da fonte e do destino para os segmentos que trafegam do hospedeiro B para o hospedeiro A são os mesmos que os números de porta do destino e da fonte, respectivamente, para os segmentos que trafegam do hospedeiro A para o hospedeiro B. Em outras palavras, o número de porta da fonte para os segmentos que trafegam do hospedeiro B para o hospedeiro A é o mesmo número de porta do destino para os segmentos que trafegam do hospedeiro A para o hospedeiro B, enquanto o número de porta do destino para os segmentos que trafegam do hospedeiro B para o hospedeiro A é o mesmo número de porta da fonte para os segmentos que trafegam do hospedeiro A para o hospedeiro B. Isso ocorre porque o protocolo TCP estabelece uma conexão bidirecional entre os dois hospedeiros, de modo que os segmentos de dados podem ser transmitidos em ambas as direções. Portanto, o número de porta da fonte e o número de porta do destino são simplesmente "invertidos" quando os segmentos são transmitidos na direção oposta.
4- Existem algumas razões pelas quais um desenvolvedor de aplicação pode escolher rodar uma aplicação sobre UDP em vez de sobre TCP:
- Velocidade: o UDP é geralmente mais rápido do que o TCP, pois ele não tem o overhead de retransmitir pacotes perdidos ou reordenar pacotes recebidos fora de ordem. Isso pode ser importante em aplicações que precisam de alta velocidade, como jogos online ou streaming de vídeo.
- Baixa latência: como o UDP não tem a mesma quantidade de overhead do TCP, ele também tende a ter menos latência. Isso pode ser importante em aplicações que precisam de tempo de resposta rápido, como chamadas de voz ou mensagens de bate-papo.
- Não confiabilidade: o UDP não oferece garantias de entrega confiável, o que significa que alguns pacotes podem ser perdidos ou chegar fora de ordem. Isso pode ser um problema em aplicações que precisam de confiabilidade, mas em alguns casos, a perda de alguns pacotes pode ser aceitável, como em aplicações de streaming de mídia onde a perda de alguns pacotes de áudio ou vídeo pode não ser percebida pelo usuário.
- Simplicidade: o UDP é mais simples do que o TCP, pois não tem que lidar com retransmissão de pacotes ou reordenação de pacotes. Isso pode tornar o UDP mais fácil de implementar em uma aplicação.
6- Sim, é possível que uma aplicação desfrute de transferência confiável de dados mesmo quando roda sobre UDP. Existem algumas maneiras de fazer isso:
- Camadas de protocolo adicionais: uma aplicação pode adicionar camadas de protocolo adicionais sobre o UDP para fornecer confiabilidade de entrega. Por exemplo, o protocolo Reliable User Datagram Protocol (RUDP) adiciona retransmissão de pacotes e reordenação de pacotes sobre o UDP para fornecer confiabilidade de entrega.
- Uso de sockets: Os sockets também podem ser usados para implementar transferência confiável de dados sobre o UDP. Os sockets são um mecanismo de interface de programação de aplicação (API) que permite que as aplicações se comuniquem através de uma rede. Eles são usados por vários protocolos de rede, incluindo o TCP e o UDP. Para implementar a transferência confiável de dados sobre o UDP usando sockets, uma aplicação pode adicionar camadas de protocolo adicionais sobre o UDP, como o RUDP mencionado anteriormente, ou adicionar verificação de integridade de dados aos pacotes enviados. A aplicação também pode ser projetada para lidar com a perda de pacotes e reordenação de pacotes de maneira a garantir confiabilidade de entrega.
- Verificação de integridade de dados: uma aplicação pode adicionar verificação de integridade de dados aos pacotes enviados sobre o UDP para garantir que os dados cheguem ao destino sem erros. Isso pode ser feito usando códigos de verificação de erro, como o Cyclic Redundancy Check (CRC), ou usando criptografia para garantir a integridade dos dados.
- Confiabilidade baseada em aplicação: a própria aplicação pode ser projetada para lidar com a perda de pacotes e reordenação de pacotes de maneira a garantir confiabilidade de entrega. Por exemplo, uma aplicação de mensagens de bate-papo pode incluir uma opção para o usuário reenviar uma mensagem se ela não for recebida pelo destinatário.
É importante observar que, enquanto essas técnicas podem aumentar a confiabilidade de entrega de dados sobre o UDP, elas ainda não oferecem a mesma confiabilidade de entrega do TCP, pois o TCP foi projetado especificamente para fornecer entrega confiável de dados.
7- Sim, esses dois segmentos UDP serão encaminhados para o mesmo socket no Computador C, pois ambos têm o mesmo número de porta de destino (6789). No entanto, o processo no Computador C será capaz de saber que os dois segmentos vieram de dois computadores diferentes, pois cada segmento UDP inclui o endereço IP e o número de porta da fonte, que identificam o computador que enviou o segmento.
Para ilustrar, suponha que o Computador A tenha o endereço IP 192.168.1.10 e o Computador B tenha o endereço IP 192.168.1.11. Quando o Computador A envia um segmento UDP para o Computador C com número de porta de destino 6789, ele inclui seu próprio endereço IP (192.168.1.10) e um número de porta da fonte aleatório (por exemplo, 1234). Quando o Computador B envia um segmento UDP para o Computador C com
temporizador expirar antes que o ACK seja recebido, o remetente assume que o pacote foi perdido e o retransmite.
Isso permite que os protocolos de transmissão de dados detectem e retransmitam pacotes perdidos, garantindo que todos os pacotes sejam entregues corretamente. Sem os temporizadores, o remetente não teria maneira de saber se um pacote foi perdido ou não, o que poderia levar a problemas de entrega de dados.
Além de gerenciar a retransmissão de pacotes perdidos, os temporizadores também são usados para evitar que os protocolos de transmissão de dados fiquem presos em loops de retransmissão indefinidos. Se um pacote é retransmitido várias vezes sem que um ACK seja recebido, o remetente pode assumir que o pacote foi perdido e desistir da transmissão, evitando que o protocolo fique preso em um loop de retransmissão.
11- Sim, ainda seria necessário um temporizador no protocolo rdt 3.0, mesmo que o atraso de ida e volta entre o emissor e o receptor seja constante e conhecido pelo emissor. Isso ocorre porque os temporizadores são usados para gerenciar a retransmissão de pacotes perdidos, que é um problema independente do atraso de ida e volta.
Mesmo que o atraso de ida e volta seja conhecido, é ainda possível que pacotes sejam perdidos durante a transmissão devido a problemas de rede, como congestão de tráfego ou erros de transmissão. Se um pacote é perdido, o remetente precisa ter uma maneira de detectar a perda e retransmitir o pacote, e isso é feito através do uso de um temporizador.
Portanto, independentemente do atraso de ida e volta, é necessário um temporizador no protocolo rdt 3.0 para gerenciar a retransmissão de pacotes perdidos e garantir a entrega confiável de dados.
14- a. Falso. O hospedeiro B pode enviar reconhecimentos para o hospedeiro A, mesmo se ele não tiver dados para enviar. Os reconhecimentos são usados para confirmar a recepção de pacotes pelo destinatário, e eles são enviados independentemente de haver ou não outros dados para enviar.
b. Falso. O tamanho de rwnd (receive window, janela de recepção) do TCP pode mudar durante a conexão. A janela de recepção é usada para controlar a quantidade de dados que o emissor pode enviar sem esperar por um reconhecimento, e o tamanho da janela é ajustado dinamicamente durante a conexão de acordo com a capacidade da rede e da máquina de destino.
c. Verdadeiro. O número de bytes não reconhecidos que o hospedeiro A envia não pode exceder o tamanho do buffer de recepção no hospedeiro B. O buffer de recepção é usado para armazenar os dados que chegam ao destinatário antes de serem processados, e o tamanho do buffer é limitado pelo sistema operacional do destinatário. Se o emissor tentar enviar mais dados do que o buffer pode armazenar, os dados extras serão descartados pelo sistema operacional do destinatário.
d. Verdadeiro. Se o número de sequência para um segmento de uma conexão TCP for m, então o número de sequência para o segmento subsequente será necessariamente m + 1.
Isso ocorre porque o número de sequência é usado para identificar a ordem em que os pacotes foram enviados, e cada pacote subsequente tem um número de sequência incrementalmente maior do que o anterior.
e. Verdadeiro. O segmento TCP tem um campo em seu cabeçalho para Rwnd (receive window, janela de recepção). A janela de recepção é usada para controlar a quantidade de dados que o emissor pode enviar sem esperar por um reconhecimento, e o tamanho da janela é enviado pelo destinatário no cabeçalho de cada segmento para informar o emissor da quantidade de dados que ele pode enviar sem esperar por um ACK.
f. Falso. O valor corrente de Timeout Interval (intervalo de tempo limite) para uma conexão TCP não é necessariamente ajustado para um valor de 1 segundo, mesmo que o último SampleRTT (tempo de amostragem de ida e volta) seja igual a 1 segundo. O intervalo de tempo limite é usado para determinar quando um pacote deve ser retransmitido, e ele é ajustado dinamicamente de acordo com o SampleRTT médio da conexão. Portanto, mesmo que o último SampleRTT seja igual a 1 segundo, o intervalo de tempo limite pode ser ajustado para um valor diferente dependendo do histórico de SampleRTT da conexão.
g. Falso. Se o hospedeiro A envia ao hospedeiro B, por uma conexão TCP, um segmento com o número de sequência 38 e 4 bytes de dados, o número de reconhecimento do segmento subsequente não será necessariamente 42. O número de reconhecimento é usado pelo destinatário para indicar ao emissor os dados que foram recebidos corretamente, e ele é baseado no número de sequência do último pacote recebido corretamente. Portanto, se o hospedeiro A envia um segmento com o número de sequência 38 e 4 bytes de dados, o número de reconhecimento do segmento subsequente dependerá do número de sequência do último pacote recebido corretamente pelo hospedeiro B, e não necessariamente será 42.
15- a. É impossível determinar quantos dados o primeiro segmento tem sem mais informações. O número de sequência do segmento indica a posição do primeiro byte de dados no fluxo de dados da conexão, mas não diz nada sobre a quantidade de dados no segmento.
b. Se o primeiro segmento for perdido, mas o segundo chegar ao hospedeiro B, o número de reconhecimento no reconhecimento enviado pelo hospedeiro B ao hospedeiro A será igual ao número de sequência do segundo segmento, que é 110. O número de reconhecimento é usado pelo destinatário para indicar ao emissor os dados que foram recebidos corretamente, e ele é baseado no número de sequência do último pacote recebido corretamente. Como o primeiro segmento foi perdido, o segundo segmento será o próximo pacote recebido pelo hospedeiro B, e o número de sequência desse pacote será usado como o número de reconhecimento no ACK enviado pelo hospedeiro B.
17- O TCP gostaria de dar a cada uma das conexões uma velocidade de transmissão igual a R/2 bps. Isso ocorre porque o enlace congestionado tem uma velocidade de R bps, e as duas conexões estão compartilhando o enlace na mesma direção. Como o enlace tem uma capacidade limitada, cada conexão deve receber apenas metade da capacidade do enlace para garantir que ambas as conexões recebam um tratamento justo. Portanto, o TCP
Para que a utilização do canal seja maior do que 95%, o tamanho da janela deve ser maior que 33 pacotes. Com base no tamanho do pacote de 1.500 bytes, isso equivale a um tamanho da janela de pelo menos 49.500 bytes.
21- No protocolo GBN (Go-Back-N), o tamanho da janela deve ser menor ou igual a k para evitar problemas como os mostrados na Figura 3.27. Isso ocorre porque o protocolo GBN permite que o emissor envie uma janela de pacotes não confirmados, mas exige que os pacotes sejam enviados e confirmados na ordem. Se a janela de pacotes não confirmados for maior que k, o receptor poderá receber pacotes fora de ordem, o que pode levar a problemas de sincronização.
Já no protocolo SR (Selective Repeat), o tamanho da janela pode ser maior que k sem problemas, desde que os pacotes sejam enviados e confirmados na ordem. Isso ocorre porque o protocolo SR permite que o receptor envie confirmações seletivas, ou seja, o receptor pode confirmar apenas os pacotes que recebeu na ordem correta e solicitar novamente os pacotes que foram perdidos ou recebidos fora de ordem. Dessa forma, o emissor pode continuar a enviar pacotes mesmo que a janela de pacotes não confirmados seja maior que k, desde que os pacotes sejam enviados e confirmados na ordem correta.
33- Existem várias razões pelas quais os projetistas do TCP podem ter optado por esperar até receber três ACKs duplicados antes de realizar uma retransmissão rápida para um segmento, como:
● Evitar retransmissões desnecessárias: Ao esperar até receber três ACKs duplicados antes de realizar uma retransmissão rápida, o TCP pode evitar retransmissões desnecessárias em caso de perda de um único ACK por problemas temporários de rede.
● Proteger contra ataques de congestão: Ao esperar até receber três ACKs duplicados antes de realizar uma retransmissão rápida, o TCP pode proteger-se contra ataques de congestão em que um atacante envia ACKs falsos para tentar enviar ainda mais tráfego para a rede.
● Evitar retransmissões excessivas: Ao esperar até receber três ACKs duplicados antes de realizar uma retransmissão rápida, o TCP pode evitar retransmissões excessivas em caso de perda de pacotes por problemas persistentes de congestão na rede. Isso pode ajudar a evitar a sobrecarga da rede com retransmissões desnecessárias e a garantir que o tráfego da rede flua de forma mais eficiente.
39- O mecanismo de duplicação do intervalo de temporização após um evento de esgotamento de temporização é uma forma de controle de congestão que permite ao TCP ajustar o tamanho da janela de transmissão de acordo com o estado da rede. No entanto, o TCP precisa de um mecanismo de controle de congestão que utiliza janelas (como o algoritmo de controle de congestão de janelas deslizantes) além desse mecanismo de duplicação do intervalo de esgotamento de temporização por várias razões, como:
● Adaptação mais rápida: O mecanismo de duplicação do intervalo de temporização só é acionado após um evento de esgotamento de temporização, o que pode levar algum tempo para acontecer. Enquanto isso, a janela de transmissão pode continuar a ser muito grande para a capacidade da rede, levando a uma congestão. O mecanismo de controle de congestão que utiliza janelas permite ao TCP ajustar o tamanho da janela de transmissão de forma mais rápida, reduzindo o risco de congestão.
● Controle mais preciso: O mecanismo de duplicação do intervalo de temporização é uma forma bastante grosseira de controlar a congestão, pois aumenta o intervalo de temporização de forma exponencial após cada evento de esgotamento de temporização. Isso pode levar a uma diminuição excessiva do tamanho da janela de transmissão, o que pode afetar negativamente a eficiência da rede. O mecanismo de controle de congestão que utiliza janelas permite um controle mais preciso da congestão, ajustando o tamanho da janela de transmissão de acordo com o estado da rede de forma mais sutil.
● Gerenciamento de várias conexões: O mecanismo de duplicação do intervalo de temporização é aplicado individualmente para cada conexão TCP, o que pode levar a uma diminuição excessiva do tamanho da janela de transmissão para conexões individuais em redes com várias conexões simultâneas. O mecanismo de controle de congestão que utiliza janelas permite um gerenciamento mais eficiente de várias conexões simultâneas, ajustando o tamanho da janela de transmissão de forma mais equilibrada entre as conexões.
Dissertativas:
2- Para tornar a Internet verdadeiramente justa, é necessário implementar mecanismos de controle de congestão que tratem todas as conexões de forma equilibrada, independentemente do número de conexões simultâneas que um cliente-servidor esteja criando. Alguns exemplos de mecanismos de controle de congestão que podem ser utilizados para alcançar essa justiça incluem:
● Algoritmos de controle de congestão baseados em pacotes: Esses algoritmos ajustam o tamanho da janela de transmissão de acordo com o número de pacotes perdidos ou entregues com atraso em uma rede. Eles são mais eficientes em redes com alta variação de atraso, pois conseguem ajustar o tamanho da janela de transmissão de forma mais precisa.
● Algoritmos de controle de congestão baseados em bits: Esses algoritmos ajustam o tamanho da janela de transmissão de acordo com a quantidade de bits enviados ou recebidos em uma rede. Eles são mais eficientes em redes com baixa variação de atraso, pois conseguem ajustar o tamanho da janela de transmissão de forma mais estável.
● Redistribuição de largura de banda: Esses mecanismos permitem que a largura de banda disponível em uma rede seja redistribuída de acordo com as necessidades
