0% acharam este documento útil (0 voto)
9 visualizações15 páginas

Guia Visual Do Laboratório Wireshark - TCP

Este guia visual do laboratório Wireshark orienta sobre como responder questões relacionadas ao protocolo TCP usando a interface do Wireshark e um arquivo de rastreamento específico. As questões abordam a identificação de endereços IP, números de porta, números de sequência e detalhes dos segmentos TCP durante a transferência de um arquivo. O guia fornece passos detalhados para encontrar as informações necessárias em cada questão.

Enviado por

ggpt881
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
9 visualizações15 páginas

Guia Visual Do Laboratório Wireshark - TCP

Este guia visual do laboratório Wireshark orienta sobre como responder questões relacionadas ao protocolo TCP usando a interface do Wireshark e um arquivo de rastreamento específico. As questões abordam a identificação de endereços IP, números de porta, números de sequência e detalhes dos segmentos TCP durante a transferência de um arquivo. O guia fornece passos detalhados para encontrar as informações necessárias em cada questão.

Enviado por

ggpt881
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
Você está na página 1/ 15

Guia Visual do Laboratório Wireshark:

TCP
Este guia descreve como encontrar as respostas para as questões do laboratório TCP
utilizando a interface gráfica do Wireshark e o arquivo de rastreamento tcp-wireshark-
trace1-1.pcapng .

Como Usar Este Guia


Para cada questão, siga os passos descritos. Os termos como "Painel de Lista de
Pacotes", "Painel de Detalhes do Pacote" e "Painel de Bytes do Pacote" referem-se às
seções padrão da interface do Wireshark.

Questão 1: Qual é o endereço IP e o número da porta TCP usados pelo


computador cliente (origem) que está transferindo o arquivo alice.txt
para o gaia.cs.umass.edu?

Passos no Wireshark (Interface Gráfica):

1. Abra o arquivo de rastreamento:

◦ No Wireshark, vá em File > Open .


◦ Selecione o arquivo tcp-wireshark-trace1-1.pcapng e clique em Open .

2. Identifique o início da conexão TCP:

◦ A conexão TCP começa com um handshake de três vias. O primeiro pacote


deste handshake é um segmento SYN enviado pelo cliente para o servidor.
◦ No "Painel de Lista de Pacotes" (geralmente o painel superior), procure pelo
primeiro pacote. No arquivo tcp-wireshark-trace1-1.pcapng , este é o frame
número 1.
◦ A coluna "Info" para este pacote deve indicar algo como [SYN] Seq=0 Win=...
Len=0 MSS=... .
◦ O endereço de origem ( Source ) neste pacote será o do cliente, e o destino
( Destination ) será o do servidor gaia.cs.umass.edu (128.119.245.12).
3. Selecione o pacote SYN do cliente:

◦ Clique no frame número 1 na "Painel de Lista de Pacotes".

4. Examine os detalhes do cabeçalho IP:

◦ No "Painel de Detalhes do Pacote" (painel do meio), expanda a seção


Internet Protocol Version 4, Src: [IP do Cliente], Dst: [IP do Servidor] .
◦ O campo Source Address (ou Src ) mostrará o endereço IP do cliente.

5. Examine os detalhes do cabeçalho TCP:

◦ Ainda no "Painel de Detalhes do Pacote", expanda a seção Transmission


Control Protocol, Src Port: [Porta do Cliente], Dst Port: [Porta do Servidor],
Seq: ..., Ack: ... .
◦ O campo Source Port (ou Src Port ) mostrará o número da porta TCP usada
pelo cliente.

Informação a ser encontrada: * No frame #1, o Source Address na camada IP é


192.168.86.68. * No frame #1, o Source Port na camada TCP é 55639.

Conclusão para a Questão 1: O endereço IP do cliente é 192.168.86.68 e a porta TCP de


origem é 55639.

Questão 2: Qual é o endereço IP do gaia.cs.umass.edu? Em qual número


de porta ele está enviando e recebendo segmentos TCP para essa
conexão?

Passos no Wireshark (Interface Gráfica):

1. Use o mesmo pacote SYN do cliente (frame #1) ou o SYNACK do servidor (frame
#2):
◦ Se estiver olhando para o frame #1 (SYN do cliente para o servidor):
▪ Selecione o frame #1 no "Painel de Lista de Pacotes".
▪ No "Painel de Detalhes do Pacote", expanda a seção Internet Protocol
Version 4, Src: [IP do Cliente], Dst: [IP do Servidor] .
▪ O campo Destination Address (ou Dst ) mostrará o endereço IP do
servidor gaia.cs.umass.edu .
▪ Ainda no "Painel de Detalhes do Pacote", expanda a seção Transmission
Control Protocol, Src Port: [Porta do Cliente], Dst Port: [Porta do
Servidor], Seq: ..., Ack: ... .
▪ O campo Destination Port (ou Dst Port ) mostrará o número da porta
TCP na qual o servidor está escutando.
◦ Alternativamente, olhe para o frame #2 (SYNACK do servidor para o cliente):
▪ Selecione o frame #2 no "Painel de Lista de Pacotes".
▪ No "Painel de Detalhes do Pacote", expanda a seção Internet Protocol
Version 4, Src: [IP do Servidor], Dst: [IP do Cliente] .
▪ O campo Source Address (ou Src ) mostrará o endereço IP do servidor
gaia.cs.umass.edu .
▪ Ainda no "Painel de Detalhes do Pacote", expanda a seção Transmission
Control Protocol, Src Port: [Porta do Servidor], Dst Port: [Porta do
Cliente], Seq: ..., Ack: ... .
▪ O campo Source Port (ou Src Port ) mostrará o número da porta TCP
que o servidor está usando para esta conexão (que é a porta em que ele
recebeu a solicitação).

Informação a ser encontrada: * No frame #1, o Destination Address na camada IP é


128.119.245.12. * No frame #1, o Destination Port na camada TCP é 80. * Ou, no frame
#2, o Source Address na camada IP é 128.119.245.12. * No frame #2, o Source Port na
camada TCP é 80.

Conclusão para a Questão 2: O endereço IP do gaia.cs.umass.edu é 128.119.245.12 e


ele está usando a porta TCP 80 para esta conexão.

Questão 3: Qual é o número de sequência do segmento TCP SYN usado


para iniciar a conexão TCP entre o computador cliente e o
gaia.cs.umass.edu? O que há neste segmento TCP que identifica o
segmento como um segmento SYN?

Passos no Wireshark (Interface Gráfica):

1. Selecione o pacote SYN do cliente (frame #1):

◦ Conforme identificado na Questão 1, o primeiro pacote da conexão é o frame


#1, que é o segmento SYN enviado pelo cliente.
◦ Clique no frame número 1 no "Painel de Lista de Pacotes".

2. Examine os detalhes do cabeçalho TCP:

◦ No "Painel de Detalhes do Pacote", expanda a seção Transmission Control


Protocol, Src Port: ..., Dst Port: ..., Seq: ..., Ack: ... .
◦ Procure pelo campo Sequence number: [valor] ou Sequence number (raw):
[valor] . Este é o número de sequência do segmento SYN. O Wireshark pode
mostrar um número de sequência relativo (geralmente 0 ou 1 para o SYN
inicial) e o número de sequência bruto (raw). O laboratório geralmente se
refere ao número de sequência bruto, que neste caso é 0.

3. Identifique o que o marca como um segmento SYN:

◦ Ainda na seção Transmission Control Protocol expandida, procure pelo sub-


item Flags: 0x... (SYN) .
◦ Expanda a seção Flags . Você verá uma lista de todas as flags TCP (Reserved,
Nonce, CWR, ECN-Echo, Urgent, Acknowledgment, Push, Reset, Syn, Fin).
◦ Para um segmento SYN, a flag Syn estará marcada como Set (ou 1 ). Todas
as outras flags importantes como ACK (para um SYN puro) ou FIN estarão Not
set (ou 0 ).
◦ O valor hexadecimal das flags (por exemplo, 0x0002 ) também indica que o
bit SYN está ativo. O bit SYN é o segundo bit menos significativo (valor 2
quando ativo sozinho).

Informação a ser encontrada: * No frame #1, dentro dos detalhes do TCP, o Sequence
number (raw) é 0. * No frame #1, dentro dos detalhes do TCP, em Flags , a flag Syn: Set
(ou 1 ) estará visível. O valor das flags será 0x0002 (SYN) .

Conclusão para a Questão 3: O número de sequência do segmento TCP SYN é 0. Ele é


identificado como um segmento SYN porque a flag SYN no cabeçalho TCP está ativa
(setada como 1).

Questão 4: Qual é o número de sequência do segmento SYNACK enviado


por gaia.cs.umass.edu ao computador cliente em resposta ao SYN? O
que há no segmento que identifica o segmento como um segmento
SYNACK? Qual é o valor do campo Confirmação no segmento SYNACK?
Como gaia.cs.umass.edu determinou esse valor?

Passos no Wireshark (Interface Gráfica):

1. Selecione o pacote SYNACK do servidor (frame #2):

◦ O segundo pacote da conexão TCP é o segmento SYNACK enviado pelo


servidor em resposta ao SYN do cliente. No arquivo tcp-wireshark-
trace1-1.pcapng , este é o frame número 2.
◦ Clique no frame número 2 no "Painel de Lista de Pacotes". A coluna "Info"
deve indicar algo como [SYN, ACK] Seq=0 Ack=1 Win=... .

2. Examine os detalhes do cabeçalho TCP para o número de sequência do


SYNACK:

◦ No "Painel de Detalhes do Pacote", expanda a seção Transmission Control


Protocol, Src Port: 80, Dst Port: 55639, Seq: ..., Ack: ... .
◦ Procure pelo campo Sequence number: [valor] ou Sequence number (raw):
[valor] . Este é o número de sequência do segmento SYNACK. Para o frame #2,
o número de sequência bruto é 0.

3. Identifique o que o marca como um segmento SYNACK:

◦ Ainda na seção Transmission Control Protocol expandida, procure pelo sub-


item Flags: 0x... (SYN, ACK) .
◦ Expanda a seção Flags . Você verá que as flags Syn e Acknowledgment
(ACK) estarão ambas marcadas como Set (ou 1 ).
◦ O valor hexadecimal das flags (por exemplo, 0x0012 ) também indica que os
bits SYN (valor 2) e ACK (valor 16, ou 0x10) estão ativos (2 + 16 = 18, que é 0x12
em hexadecimal).

4. Encontre o valor do campo Confirmação (Acknowledgment Number):

◦ Na mesma seção Transmission Control Protocol expandida, procure pelo


campo Acknowledgment number: [valor] ou Acknowledgment number
(raw): [valor] .
◦ Para o frame #2, este valor será 1.

5. Como gaia.cs.umass.edu determinou o valor do campo Confirmação:

◦ O cliente enviou o segmento SYN (frame #1) com um número de sequência de


0.
◦ Um segmento SYN consome um número de sequência (mesmo que não
carregue dados de payload na maioria dos casos).
◦ O servidor ( gaia.cs.umass.edu ), ao receber o SYN com Seq=0, confirma o
recebimento desse número de sequência (e o byte implícito que ele
representa) configurando o campo de Confirmação para (Número de
Sequência do Cliente) + 1 .
◦ Portanto, o valor é 0 + 1 = 1 .

Informação a ser encontrada: * No frame #2, dentro dos detalhes do TCP, o Sequence
number (raw) é 0. * No frame #2, em Flags , as flags Syn: Set e Acknowledgment: Set
estarão visíveis. O valor das flags será 0x0012 (SYN, ACK) . * No frame #2, o
Acknowledgment number (raw) é 1.

Conclusão para a Questão 4: O número de sequência do segmento SYNACK é 0. Ele é


identificado como SYNACK porque as flags SYN e ACK estão ativas. O valor do campo
Confirmação é 1. O servidor determinou este valor adicionando 1 ao número de
sequência do SYN inicial do cliente (0+1=1).

Questão 5: Qual é o número de sequência do segmento TCP que contém


o cabeçalho do comando HTTP POST? Quantos bytes de dados estão
contidos no campo payload (dados) deste segmento TCP? Todos os
dados no arquivo transferido alice.txt cabem nesse único segmento?

Passos no Wireshark (Interface Gráfica):

1. Localize o primeiro segmento de dados HTTP POST:

◦ Após o handshake TCP (frames #1, #2, #3), o cliente começa a enviar dados. O
laboratório indica que o frame #4 é o primeiro segmento TCP que contém o
início da mensagem HTTP POST.
◦ No "Painel de Lista de Pacotes", selecione o frame número 4.
◦ Você pode confirmar que este é o início do POST olhando a coluna "Info"
(deve mostrar dados sendo enviados para a porta 80) ou, mais
detalhadamente, no painel de bytes.

2. Encontre o número de sequência do segmento:

◦ Com o frame #4 selecionado, no "Painel de Detalhes do Pacote", expanda a


seção Transmission Control Protocol, Src Port: ..., Dst Port: ..., Seq: ..., Ack: ... .
◦ Procure pelo campo Sequence number: [valor] ou Sequence number (raw):
[valor] . Para o frame #4, o número de sequência bruto é 4236649188. (O
número de sequência relativo, se exibido, seria 1, pois é o primeiro byte de
dados após o SYN do cliente que tinha Seq=0 e consumiu um número de
sequência).

3. Determine quantos bytes de dados estão no payload:

◦ Ainda na seção Transmission Control Protocol expandida, procure pelo


campo TCP Segment Len: [valor] ou, em versões mais antigas/outras
colunas, o comprimento do payload TCP pode ser inferido ou diretamente
listado. O campo TCP Segment Len (ou simplesmente Length se referindo
ao payload TCP na lista de pacotes para este segmento) indica o tamanho dos
dados no payload TCP.
◦ Para o frame #4, o TCP Segment Len é 1448 bytes.
◦ Alternativamente, no "Painel de Detalhes do Pacote", expanda a seção
Hypertext Transfer Protocol . Abaixo dela, você pode ver [TCP segment data
(1448 bytes)] ou similar, indicando o tamanho dos dados HTTP contidos
neste segmento TCP.

4. Verifique se todos os dados do arquivo alice.txt cabem no segmento:

◦ O laboratório menciona que o arquivo alice.txt tem cerca de 150KB (ou mais
precisamente, a Figura 3 do laboratório mostra que a mensagem HTTP POST
tem mais de 152K bytes, e a Questão 5 do relatório anterior indicou Content-
Length: 152881 bytes).
◦ Compare este tamanho total do arquivo (152881 bytes) com o payload do
segmento atual (1448 bytes).

Informação a ser encontrada: * No frame #4, o Sequence number (raw) é


4236649188. * No frame #4, o TCP Segment Len é 1448 bytes. * O arquivo alice.txt tem
152881 bytes.

Conclusão para a Questão 5: O número de sequência do segmento TCP que contém o


cabeçalho do comando HTTP POST (frame #4) é 4236649188. Este segmento contém
1448 bytes de dados no payload. Não, todos os dados do arquivo alice.txt (152881
bytes) não cabem neste único segmento.

Questão 6: Qual é o comprimento (cabeçalho mais carga útil) de cada


um dos quatro primeiros segmentos TCP de transporte de dados?

Passos no Wireshark (Interface Gráfica):

1. Identifique os quatro primeiros segmentos TCP de transporte de dados


enviados pelo cliente:

◦ Conforme vimos, o frame #4 é o primeiro segmento de dados do cliente.


◦ Os próximos segmentos de dados enviados pelo cliente serão os frames #5,
#6. O frame #7 e #8 são ACKs do servidor. O próximo segmento de dados do
cliente é o frame #9.
◦ Portanto, os quatro primeiros segmentos TCP de transporte de dados do
cliente são os frames #4, #5, #6 e #9.
2. Para cada um desses quatro frames (separadamente):

◦ Selecione o frame respectivo (por exemplo, frame #4) no "Painel de Lista de


Pacotes".

3. Encontre o comprimento do cabeçalho TCP:

◦ No "Painel de Detalhes do Pacote", expanda a seção Transmission Control


Protocol, ... .
◦ Procure pelo campo Header length: [valor] bytes . Este é o comprimento do
cabeçalho TCP.
◦ Para os frames #4, #5, #6 e #9, este valor é 32 bytes (20 bytes do cabeçalho
TCP base + 12 bytes de opções TCP, como Timestamps).

4. Encontre o comprimento do payload TCP (dados):

◦ Ainda na seção Transmission Control Protocol expandida, procure pelo


campo TCP Segment Len: [valor] .
◦ Para os frames #4, #5, #6 e #9, este valor é 1448 bytes.
◦ Alternativamente, a coluna "Length" no "Painel de Lista de Pacotes"
geralmente mostra o comprimento do payload da camada mais alta
encapsulada (neste caso, os dados TCP/HTTP) para pacotes de dados.

5. Calcule o comprimento total (cabeçalho + payload):

◦ Some o Header length e o TCP Segment Len para cada um dos quatro
segmentos.

Informação a ser encontrada para cada um dos frames #4, #5, #6, #9: * Frame #4: *
Cabeçalho TCP: 32 bytes * Payload TCP: 1448 bytes * Total: 32 + 1448 = 1480 bytes *
Frame #5: * Cabeçalho TCP: 32 bytes * Payload TCP: 1448 bytes * Total: 32 + 1448 = 1480
bytes * Frame #6: * Cabeçalho TCP: 32 bytes * Payload TCP: 1448 bytes * Total: 32 + 1448
= 1480 bytes * Frame #9: * Cabeçalho TCP: 32 bytes * Payload TCP: 1448 bytes * Total: 32
+ 1448 = 1480 bytes

Conclusão para a Questão 6: O comprimento (cabeçalho mais carga útil) de cada um


dos quatro primeiros segmentos TCP de transporte de dados (frames #4, #5, #6, #9) é
1480 bytes.
Questão 7: Qual é a quantidade mínima de espaço de buffer disponível
anunciada ao cliente por gaia.cs.umass.edu entre esses quatro
primeiros segmentos TCP portadores de dados? A falta de espaço no
buffer do receptor já estrangulou o remetente para esses quatro
primeiros segmentos de transporte de dados?

Passos no Wireshark (Interface Gráfica):

1. Entenda o que procurar:

◦ O espaço de buffer disponível é anunciado pelo receptor (servidor


gaia.cs.umass.edu ) no campo "Window Size" de seus segmentos TCP.
◦ Este valor pode ser afetado por uma opção de "Window Scaling" negociada
no handshake TCP.
◦ Precisamos olhar os ACKs enviados pelo servidor em resposta aos quatro
primeiros segmentos de dados do cliente (frames #4, #5, #6, #9).

2. Verifique o Fator de Escala da Janela (Window Scale Factor) do servidor:

◦ Selecione o pacote SYNACK do servidor (frame #2) no "Painel de Lista de


Pacotes".
◦ No "Painel de Detalhes do Pacote", expanda Transmission Control
Protocol, ... .
◦ Expanda Options: (X bytes), ... (geralmente 12 bytes para este rastreamento).
◦ Procure pela opção TCP Option - Window scale: [valor] (multiply by
[multiplicador]) .
◦ Para o frame #2, o servidor anuncia um fator de escala. O multiplicador é 128
(o valor da opção é 7, que significa 2^7 = 128).

3. Examine os ACKs do servidor para os primeiros segmentos de dados do cliente:

◦ Os primeiros segmentos de dados do cliente são #4, #5, #6. O primeiro ACK do
servidor para esses dados é o frame #7.
◦ Selecione o frame #7 no "Painel de Lista de Pacotes".
◦ No "Painel de Detalhes do Pacote", expanda Transmission Control
Protocol, ... .
◦ Encontre o campo Window size value: [valor_janela_anunciado] .
◦ Para o frame #7, o Window size value é 249.

◦ Calcule o tamanho real da janela: valor_janela_anunciado *


multiplicador_escala = 249 * 128 = 31872 bytes.

◦ O próximo ACK do servidor é o frame #8.


◦ Selecione o frame #8. O Window size value é 272.

◦ Tamanho real da janela: 272 * 128 = 34816 bytes.

◦ O quarto segmento de dados do cliente é o frame #9. O ACK do servidor que


reconhece os dados até o final do frame #9 (e possivelmente outros) é o
frame #16 (Seq do cliente no #9 é 4236653532, Len 1448. Próximo Seq
esperado pelo servidor: 4236653532 + 1448 = 4236654980. O frame #16 tem
Ack=4236654980).

◦ Selecione o frame #16. O Window size value é 317.


◦ Tamanho real da janela: 317 * 128 = 40576 bytes.

4. Determine a quantidade mínima de espaço de buffer anunciada:

◦ Compare os tamanhos de janela reais calculados para os ACKs relevantes


(31872 bytes no frame #7, 34816 bytes no frame #8, 40576 bytes no frame
#16). O menor deles é 31872 bytes.

5. Avalie se o remetente foi estrangulado:

◦ O cliente enviou quatro segmentos de dados, cada um com 1448 bytes de


payload, totalizando 4 * 1448 = 5792 bytes de dados "em trânsito" antes de
receber todos os ACKs para eles.
◦ Compare a quantidade de dados enviados (5792 bytes) com a menor janela
anunciada (31872 bytes).

Informação a ser encontrada: * Multiplicador de escala da janela do servidor (frame


#2): 128. * Frame #7 (ACK do servidor): Window size value : 249. Janela real: 31872 bytes.
* Frame #8 (ACK do servidor): Window size value : 272. Janela real: 34816 bytes. * Frame
#16 (ACK do servidor): Window size value : 317. Janela real: 40576 bytes. * Mínimo
espaço de buffer anunciado: 31872 bytes. * Dados enviados pelo cliente antes do ACK
completo para todos os quatro: 5792 bytes.

Conclusão para a Questão 7: A quantidade mínima de espaço de buffer disponível


anunciada pelo servidor ao cliente entre esses quatro primeiros segmentos de dados foi
de 31872 bytes. Como o cliente enviou 5792 bytes, que é consideravelmente menor que
a janela anunciada, a falta de espaço no buffer do receptor não estrangulou o remetente
para esses quatro primeiros segmentos.
Questão 8: Há segmentos retransmitidos no arquivo de rastreamento?
O que você verificou (no rastreamento) para responder a essa
pergunta?

Passos no Wireshark (Interface Gráfica):

1. Use o filtro de exibição para retransmissões:

◦ Na barra de "Filtro de Exibição" na parte superior da janela do Wireshark,


digite tcp.analysis.retransmission .
◦ Pressione Enter para aplicar o filtro.

2. Observe o "Painel de Lista de Pacotes":

◦ Se houver quaisquer segmentos que o Wireshark identificou como


retransmissões TCP, eles serão listados.
◦ Se nenhum pacote for exibido, significa que o Wireshark não detectou
nenhuma retransmissão com base em sua análise heurística (que geralmente
é bastante confiável para retransmissões comuns).

3. Verificação adicional (opcional, para aprendizado):

◦ Você também pode procurar por outros indicadores de problemas de rede


que podem levar a retransmissões, como:
▪ tcp.analysis.duplicate_ack : Indica ACKs duplicados, que podem
disparar uma retransmissão rápida.
▪ tcp.analysis.out_of_order : Indica segmentos que chegaram fora de
ordem.
▪ tcp.analysis.fast_retransmission : Indica um segmento que o Wireshark
acredita ser uma retransmissão rápida.
◦ No entanto, o filtro tcp.analysis.retransmission é o mais direto para a
pergunta.

Informação a ser encontrada: * Ao aplicar o filtro tcp.analysis.retransmission no


arquivo tcp-wireshark-trace1-1.pcapng , nenhum pacote é exibido.

Conclusão para a Questão 8: Não há segmentos retransmitidos no arquivo de


rastreamento tcp-wireshark-trace1-1.pcapng . Isso foi verificado aplicando o filtro de
exibição tcp.analysis.retransmission no Wireshark, que não resultou em nenhum
pacote listado.
Questão 9: Quantos dados o receptor normalmente reconhece em um
ACK entre os dez primeiros segmentos de transporte de dados enviados
do cliente para gaia.cs.umass.edu? Você consegue identificar casos em
que o receptor está ACKing todos os outros segmentos recebidos?

Passos no Wireshark (Interface Gráfica):

1. Identifique os primeiros dez segmentos de transporte de dados do cliente:

◦ Aplique um filtro para ver os pacotes de dados enviados pelo cliente:


ip.src == 192.168.86.68 && tcp.len > 0 (Lembre-se que 192.168.86.68 é o IP
do cliente e tcp.len > 0 significa que há payload TCP).
◦ No "Painel de Lista de Pacotes", observe os primeiros 10 pacotes que
aparecem. Anote seus números de frame e os números de sequência relativos
(ou brutos) e o comprimento do payload TCP ( tcp.len ).
▪ Frame #4: SeqRel=1, Len=1448
▪ Frame #5: SeqRel=1449, Len=1448
▪ Frame #6: SeqRel=2897, Len=1448
▪ Frame #9: SeqRel=4345, Len=1448
▪ Frame #11: SeqRel=5793, Len=1448
▪ Frame #12: SeqRel=7241, Len=1448
▪ Frame #15: SeqRel=8689, Len=1448
▪ Frame #17: SeqRel=10137, Len=1448
▪ Frame #18: SeqRel=11585, Len=1448
▪ Frame #20: SeqRel=13033, Len=1448

2. Identifique os ACKs correspondentes enviados pelo servidor:

◦ Remova o filtro anterior ou aplique um filtro para ver os ACKs do servidor:


ip.src == 128.119.245.12 && tcp.flags.ack == 1 && tcp.len == 0 (ACKs puros,
sem dados).
◦ Para cada segmento de dados do cliente, procure o ACK subsequente do
servidor. O campo "Acknowledgment number" no ACK do servidor indicará
qual número de sequência (relativo ao início da conexão do cliente) ele está
confirmando.

3. Analise quantos dados cada ACK reconhece:

◦ Frame #7 (ACK do servidor):

▪ Selecione o frame #7. No "Painel de Detalhes do Pacote", em


Transmission Control Protocol , o Acknowledgment number (relative)
é 1449. Isso significa que ele está reconhecendo os dados até o final do
primeiro segmento de dados do cliente (frame #4, que tinha SeqRel=1 e
Len=1448. Portanto, 1 + 1448 = 1449).
▪ Este ACK reconhece 1448 bytes de novos dados (o primeiro segmento).

◦ Frame #8 (ACK do servidor):

▪ Selecione o frame #8. O Acknowledgment number (relative) é 4345. O


ACK anterior (frame #7) reconheceu até 1449. Então, este ACK está
reconhecendo 4345 - 1449 = 2896 bytes de novos dados. Isso
corresponde aos próximos dois segmentos de 1448 bytes (frames #5 e
#6).
▪ Aqui vemos um caso de ACKing a cada dois segmentos recebidos
(Delayed ACK).

◦ Frame #10 (ACK do servidor):

▪ Selecione o frame #10. O Acknowledgment number (relative) é 7241. O


ACK anterior (frame #8) reconheceu até 4345. Então, este ACK está
reconhecendo 7241 - 4345 = 2896 bytes de novos dados (frames #9 e
#11).
▪ Outro caso de ACKing a cada dois segmentos.

◦ Continue essa análise para os ACKs subsequentes (ex: frame #14, #19, #21,
#23 no rastreamento original) para os próximos segmentos de dados do
cliente.

Informação a ser encontrada: * O primeiro ACK (frame #7) reconhece 1 segmento (1448
bytes). * Os ACKs subsequentes (frame #8, #10, etc.) geralmente reconhecem 2
segmentos (2896 bytes) de uma vez.

Conclusão para a Questão 9: O receptor (servidor) normalmente reconhece 2896 bytes


de dados em um ACK após o primeiro ACK (que reconhece 1448 bytes). Sim, é possível
identificar casos em que o receptor está ACKing a cada dois segmentos recebidos (por
exemplo, o frame #8 ACKing os frames #5 e #6; o frame #10 ACKing os frames #9 e #11).
Isso é uma implementação comum de Delayed ACKs.
Questão 10: Qual é a taxa de transferência (bytes transferidos por
unidade de tempo) para a conexão TCP? Explique como você calculou
esse valor.

Passos no Wireshark (Interface Gráfica):

1. Determine a quantidade total de dados da aplicação transferidos:

◦ A maneira mais precisa é encontrar o Content-Length da requisição HTTP


POST, se disponível e confiável, pois representa os dados da aplicação.
◦ No frame #4 (início do HTTP POST), no "Painel de Detalhes do Pacote",
expanda Hypertext Transfer Protocol . Procure por Content-Length: [valor] .
◦ No arquivo tcp-wireshark-trace1-1.pcapng , o Content-Length é 152881
bytes.

2. Encontre o tempo do primeiro segmento TCP que transporta dados da


aplicação:

◦ Este é o frame #4.


◦ Selecione o frame #4. No "Painel de Lista de Pacotes", a coluna "Time" mostra
o tempo relativo ao início da captura. Anote este valor. Ex: 0.000470
segundos (este valor pode variar ligeiramente dependendo de como o tempo
zero é definido, mas use o tempo do primeiro pacote de dados).
◦ Para ser mais preciso, você pode definir o tempo deste pacote como
referência temporal: clique com o botão direito no frame #4 > Set Time
Reference (toggle) .

3. Encontre o tempo do ACK do servidor que confirma o recebimento de todos os


dados da aplicação:

◦ O cliente enviou 152881 bytes de dados. O primeiro byte de dados tem


número de sequência relativo 1 (após o SYN).
◦ O último byte de dados terá o número de sequência relativo 1 + 152881 - 1 =
152881 .
◦ O servidor precisa confirmar o recebimento do próximo byte esperado, que é
152881 + 1 = 152882 (número de sequência relativo).
◦ Aplique um filtro de exibição para encontrar este ACK do servidor: ip.src ==
128.119.245.12 && tcp.ack_raw == 4236802069 (onde 4236802069 é o
número de ACK bruto correspondente a 152882 relativo. Para encontrar o ACK
bruto: Seq Bruto do SYN Cliente (0) + 152882 = 4236649187 + 152882 =
4236802069. Ou, se o Wireshark estiver mostrando números de ACK relativos,
filtre por tcp.ack == 152882 ).
◦ No arquivo tcp-wireshark-trace1-1.pcapng , este é o frame #216.
◦ Selecione o frame #216. Anote o valor da coluna "Time". Se você definiu o
frame #4 como referência de tempo, este tempo será o delta. Senão, será o
tempo absoluto da captura. Ex: 0.191614 segundos (tempo absoluto da
captura).

4. Calcule a duração da transferência:

◦ Duração = (Tempo do ACK final) - (Tempo do primeiro segmento de dados).


◦ Duração = 0.191614 s - 0.000470 s = 0.191144 segundos.

5. Calcule a taxa de transferência:

◦ Taxa de Transferência = (Total de Dados da Aplicação) / (Duração da


Transferência).
◦ Taxa de Transferência = 152881 bytes / 0.191144 segundos.

Informação a ser encontrada: * Total de dados da aplicação (Content-Length): 152881


bytes. * Tempo do frame #4 (primeiro dado): ~0.000470 s. * Tempo do frame #216 (ACK
final para todos os dados): ~0.191614 s. * Duração: ~0.191144 s.

Conclusão para a Questão 10: A taxa de transferência para a conexão TCP é calculada
dividindo o total de bytes de dados da aplicação (152881 bytes) pelo tempo que levou
para transferir esses dados (aproximadamente 0.191144 segundos). Taxa de
Transferência = 152881 bytes / 0.191144 s ≈ 799849.33 bytes/segundo (ou
aproximadamente 6.4 Mbps).

Este guia deve ajudar seu amigo a localizar visualmente as informações no Wireshark
para cada questão do laboratório. Lembre-se que os números exatos dos frames podem
variar se ele capturou o próprio tráfego, mas os princípios de onde procurar as
informações nos cabeçalhos TCP/IP e HTTP permanecem os mesmos.

Você também pode gostar

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy