Tamanho da janela e número de confirmação

Copiar e colar dos slides do meu professor:

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

Portanto, deduzo que o tamanho da janela representa quantos bytes o receptor coletará antes de enviar um ACK.

Mas não é isso que vejo nesta captura do Wireshark:

Como você pode ver na captura de tela (de uma transferência de arquivo TCP), o servidor está ACK a cada ~ 1400 bytes (observando o número ACK), mas ao mesmo tempo indica um tamanho de janela de 100.000 + bytes?

Pelo que entendi nos slides do meu professor, o servidor deve estar ACKing a cada 100.000 bytes? Por que ele está aceitando com muito mais frequência do que isso?

Ensino TCP e geralmente encontro pessoas que foram mal-ensinadas que o ACK é enviado apenas quando o tamanho da janela é atingido. Isso não é verdade. (Para ser realmente transparente, eu também ensinei isso incorretamente antes de conhecer melhor, para entender completamente o erro).

OBSERVAÇÃO, usarei o Receptor / Remetente para descrevê-lo, mas lembre-se de que o TCP é bidirecional e as duas partes mantêm um Tamanho da Janela.

O tamanho da janela (definido pelo receptor) é um limite rígido de quantos bytes o remetente pode enviar sem ser forçado a parar para aguardar uma confirmação.

O tamanho da janela não determina com que frequência o destinatário deve enviar confirmações. Originalmente, o protocolo TCP pedia que uma confirmação fosse enviada após o recebimento de cada segmento. Posteriormente, o TCP foi otimizado para permitir que o Receptor ignore as ACKs e envie uma confirmação de confirmação a cada outro pacote (ou mais).

O objetivo do TCP, então, é que o Remetente esteja continuamente enviando pacotes, sem demora ou interrupção, porque recebe continuamente confirmações, de forma que a contagem de "bytes em trânsito" seja sempre menor que o Tamanho da Janela. Se a qualquer momento, o remetente tiver enviado uma contagem de bytes igual ao tamanho da janela sem receber um ACK, será forçado a interromper o envio e aguardar.

O importante a considerar em tudo isso é o tempo de ida e volta. Freqüentemente, quando você estuda o TCP em um wireshark, apenas vê a perspectiva de uma parte na conversa do TCP, o que dificulta a dedução ou a verdadeira "visualização" do efeito da RTT. Para ilustrar o efeito da RTT, dê uma olhada nessas duas capturas. Ambos estão capturando a mesma conversa, um download de arquivo de 2 MB por HTTP, mas um é da perspectiva do Cliente e o outro é da perspectiva do Servidor .

Nota: é mais fácil analisar o TCP se você desativar o recurso Wireshark " Permitir que o subdissetor remonte os fluxos TCP "

Observe que, na captura do lado do servidor (quem é o remetente do arquivo), o servidor envia 8 pacotes de tamanho completo em uma linha (os números de pacote 6 a 13) antes de receber o primeiro ACK do pacote nº 14. que ACK, observe que o reconhecimento do cliente é referente ao segmento enviado no pacote nº 7. E o ACK que o Cliente enviou no pacote 20 é do segmento enviado no Pacote # 9.

Veja como o cliente está de fato reconhecendo todos os outros pacotes. Mas quase parece que os reconhece "atrasados". Mas, na verdade, esse é apenas o efeito do tempo de ida e volta. O Remetente pode enviar 7 ~ segmentos no tempo que leva para o primeiro segmento chegar ao cliente e o ACK do cliente chegar ao servidor. Se você observar a captura da perspectiva do cliente, ela parecerá muito 'limpa', ou seja, a cada segundo pacote recebido, ele envia um ACK.

Observe também o que acontece no pacote nº 23. O servidor enviou tudo o que pode, porque os "bytes em trânsito" atingem o tamanho da janela e, portanto, é forçado a parar de enviar. Até o próximo ACK chegar. Uma vez que os ACK estão chegando em todos os outros segmentos recebidos. Cada ACK permite que o remetente envie novamente dois novos segmentos, antes que a janela esteja cheia novamente e o servidor seja novamente forçado a pausar. Isso acontece até o pacote nº 51, quando o cliente (recuperação) aumenta significativamente o tamanho da janela, permitindo que o servidor (remetente) comece a transmitir dados desinibidos novamente ... pelo menos até o pacote nº 175, quando a nova janela é preenchida.

O tamanho da janela é usado para evitar congestionamentos no receptor (ao contrário da janela de congestionamento que tenta evitar congestionamentos na rede).

A funcionalidade é relativamente simples: o receptor informa o remetente sobre o tamanho da janela, o que geralmente representa o tamanho do buffer disponível. Portanto, esse número deve ser diminuído toda vez que um novo pacote chega ao receptor e deve ser aumentado cada vez que um pacote é processado no receptor.

No lado do remetente, o remetente tenta garantir que, a qualquer momento, ele / ela não tenha em trânsito mais bytes que a última janela anunciada recebida e, portanto, diminua a probabilidade de inundar o receptor.

Agora, a partir da sua saída do wireshark, podemos ver que o tamanho da sua janela é relativamente grande e, portanto, suas transmissões não são limitadas e você recebe um ACK para cada pacote enviado (como deve ser no cenário geral do caso em que nenhuma agregação de ACK é usada) . Atualmente, o tamanho máximo mais usado para quadros Ethernet é de 1500 bytes. Se você remover todos os cabeçalhos, verá que os bytes restantes são realmente o número pelo qual seus ACKs são aumentados.